A replacement PC can sign in to Microsoft 365 successfully and still fail to open the office file share. Start by checking the device’s actual join state, the identity the file server expects and the network path between them. Then separate the investigation into reachability, authentication and permissions.
Microsoft Entra join does not, by itself, grant access to an SMB share. This guide is for IT administrators investigating Windows clients. Start with the read-only checks below, then use the findings to choose the next investigation.
Record the environment before changing it
Write down the Windows edition and build, the exact error and its timestamp, the intended UNC path, and whether the failure occurs on the office LAN, an approved VPN or both. Also identify the server: an AD domain-member Windows file server, an AD-integrated NAS, a workgroup NAS or Azure Files. These can present a similar folder path while using different authentication designs.
Record whether the user has a synchronised on-premises Active Directory account or a cloud-only Microsoft Entra account, and whether they signed into Windows with a password, Windows Hello for Business or a security key. Do not collect their password or PIN.
Run this in the affected user’s Windows session:
dsregcmd /statusIn Device State, AzureAdJoined : YES with DomainJoined : NO indicates an Entra-joined device; both set to YES indicate hybrid join. WorkplaceJoined is a separate user-state value for registration. Signing into a work application is not enough evidence of the device’s join state. Microsoft documents these distinctions in its dsregcmd guide.
Keep the relevant results in the approved support system. Full output can contain device, tenant and user identifiers, so avoid posting it publicly.
1. Check the intended name and network path
Use the organisation’s supported server name and exact share path. Confirm that the share still exists and that the shortcut has not retained an old server name.
For a conventional SMB connection over TCP, these PowerShell checks help separate DNS from port reachability. Replace APPROVED-SERVER-NAME with your organisation’s actual supported file-server name before running them:
Resolve-DnsName APPROVED-SERVER-NAME
Test-NetConnection APPROVED-SERVER-NAME -Port 445Resolve-DnsName shows name-resolution results. Check them against the expected internal address and DNS design. Test-NetConnection tests TCP reachability; TcpTestSucceeded : True does not establish a successful SMB sign-in or permission to a folder. These commands target the conventional TCP path, not every possible SMB transport.
- If the name resolves incorrectly, investigate the client’s DNS settings, VPN DNS assignment and intended namespace.
- If TCP 445 fails, investigate routing, the approved VPN path, firewalls and the server’s listening service before changing file permissions.
- If the organisation uses AD-backed single sign-on, check the required path to its domain controllers as well as the file server. A working internet connection or a connected VPN icon is insufficient evidence.
Microsoft’s cloud-native endpoint guidance describes the on-premises resource and domain-controller connectivity required for that AD-backed scenario. Do not expose TCP 445 to the internet as a troubleshooting shortcut.
Changing the share path to an IP address also changes the authentication comparison. Windows does not normally attempt Kerberos when the target hostname is an IP address, as Microsoft explains in Kerberos over IP guidance. Keep the supported name. If an alias fails while the real name works, have the administrator investigate its service principal name and supported alias configuration; Microsoft documents SMB alias failures.
For a separate example of why a connected VPN does not prove name resolution works, see Osmicro’s RemoteApp connectivity investigation. Its application-specific settings should not be copied into an SMB environment without checking the design.
2. Establish which identity the server can authenticate
For single sign-on to an on-premises AD-backed share, confirm that the intended user exists in the relevant AD domain and that the required identity attributes are synchronised to Microsoft Entra ID. Microsoft’s on-premises SSO documentation also requires domain-controller connectivity and identifies additional configuration for passwordless sign-in.
A cloud-only account does not automatically become an account in an existing on-premises AD domain. Likewise, a NAS with its own local accounts needs a supported NAS authentication design. Repeatedly entering the same Microsoft 365 email address cannot establish that the server recognises it.
If the resource requires AD computer-account authentication, user SSO alone is insufficient: an Entra-only joined PC has no computer object in on-premises AD. Check this requirement when replacing a domain-joined device.
If Windows Hello for Business is involved, confirm the deployed trust model. Cloud Kerberos trust is one supported model with prerequisites and policy configuration. Microsoft notes that an Entra-joined user can still sign into Windows when the required Kerberos deployment is missing, yet lack on-premises SSO. Follow the cloud Kerberos trust deployment guide for the actual implementation rather than treating PIN removal or password resets as the fix.
Review existing SMB sessions and any saved credential entry for the specific server. Get-SmbConnection can show established client connections and the account used, according to Microsoft’s command reference. It does not explain every failed connection. Inspect the affected user’s context, and do not delete all saved credentials or disconnect every mapped drive as a first step.
If the target is Azure Files: identify the storage account’s configured identity source and follow that service’s prerequisites. Azure Files supports AD DS, Microsoft Entra Domain Services and Microsoft Entra Kerberos options. Its identity-based authentication overview should guide the investigation. Do not carry over an on-premises domain-controller requirement to every Azure Files design, or assume Entra join has configured the storage account.
3. Check access for the authenticated account
Once the administrator has established which account the server authenticated, inspect access to the exact share and folder. On a Windows file server, both share permissions and NTFS permissions matter. Review the intended groups, inheritance and applicable deny entries instead of granting broad access to see whether the error disappears. Microsoft’s SMB failure guide distinguishes connection stages and calls out both permission layers.
For Azure Files, share-level access and directory/file permissions are also separate checks. A share-level role alone does not grant access to every folder; see Microsoft’s Azure Files access-control overview.
A credential prompt suggests an authentication investigation, but an “access denied” or “network path not found” message is not a complete diagnosis. Correlate the timestamp with the relevant SMB client, server and authentication logs. Preserve the original error before retrying.
Check SMB security compatibility alongside these steps
A new PC may have stronger defaults than the device it replaced. Microsoft documents that Windows 11 version 24H2 Pro, Enterprise and Education require inbound and outbound SMB signing. A third-party server that cannot meet the client’s signing requirement, or relies on guest access, can fail even when the network path works.
Use the exact Windows build, applied policy and server documentation to compare requirements. Microsoft recommends enabling signing support on the third-party server rather than disabling signing on the client. See its SMB signing guidance.
Do not enable SMB1, allow insecure guest access, weaken signing or encryption, or turn off security software as a blanket workaround. An outdated NAS may need a supported configuration change, firmware update or replacement. Plan that through the normal change process, with a recorded starting configuration and a way to reverse the approved change.
Compare the working and failing paths
If an older PC still works, compare the two devices using the same supported server name and intended user. Record any difference in join state, sign-in method, network path, existing SMB session and security policy. A successful TCP test on both devices only narrows the reachability question.
Ask the administrator to correlate those observations with the server’s authentication records before choosing a correction. Changing several settings at once can hide the cause and make rollback harder.
Finish with a small authorised test
After an approved correction, test the original supported UNC path with the intended user and a harmless sample file. Confirm the required operation: listing, reading or, where authorised, creating and editing. Record the outcome and any remaining limitation. Do not test with client records or assume that opening the share proves write access.
A useful escalation includes:
- Windows edition/build, join state and sign-in method
- Server type, exact UNC path and approved network/VPN path
- User identity model and the account observed by the server
- Exact error, timestamp with time zone, DNS and TCP results
- A controlled comparison and relevant, redacted log entries
If the current identity and storage design cannot support the intended users, treat that as an infrastructure decision. Osmicro’s IT infrastructure services cover the wider environment, while IT support can help investigate the immediate access failure. The useful outcome is a supported access path with the right permissions and security controls.