T The Triage ManualTechnical Guides for IT Emergencies
P3 · Endpoint & Device Management

File and Print Sharing Broken After Windows Update — Network Profile Switched to Public

After Windows 10/11 cumulative or feature updates, network adapters may silently switch from Private/Domain to Public profile, which disables file and print sharing by activating the restrictive Public firewall profile that blocks SMB (TCP 445). Affected machines cannot browse network shares, connect to shared printers, or be discovered via Network Discovery. Resolution involves correcting the network profile back to Private or Domain using PowerShell or GUI, then re-enabling sharing settings and firewall rules. This is a recurring L2 ticket pattern following Patch Tuesday deployments.

Indicators

Likely causes

Diagnostic steps

  1. Check the current network profile for all adapters using PowerShell: Get-NetConnectionProfile
    Confirms whether any network adapter is set to Public rather than Private or DomainAuthenticated — the root condition causing sharing to break
  2. Navigate to Settings > Network & Internet > [Adapter] > Properties and check whether the profile is set to Public or Private. Alternatively, open Control Panel > Network and Sharing Centre and review the active network profile displayed.
    Provides UI-level confirmation of the network profile state and allows the technician to verify the user-facing symptom
  3. Open Control Panel > Network and Sharing Centre > Change advanced sharing settings, and verify whether 'Turn on file and printer sharing' is enabled for the Private (and/or Domain) profile, and whether 'Turn on network discovery' is also enabled.
    Determines whether sharing options were disabled as a consequence of the profile flip or were separately disabled
  4. Run PowerShell command: Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" | Select DisplayName, Enabled, Profile
    Confirms whether the File and Printer Sharing firewall rules are enabled and which profiles they apply to — rules may be correct but the wrong profile is active
  5. Check Windows Update history via Settings > Windows Update > Update History to identify any recent cumulative or feature update that preceded the onset of the issue.
    Establishes causal link between an update event and the profile/sharing change — useful for scoping the issue across the estate and for escalation to Microsoft if it is a known issue
  6. Attempt to access the affected machine's shares from a remote host (e.g., via \\<hostname>\sharename) and note whether the error is 'access denied', 'network path not found', or a timeout.
    Characterises the failure mode and helps distinguish between a firewall block, a sharing configuration issue, or an authentication/permission problem
  7. On domain-joined machines, run 'gpresult /h gpresult.html' in an elevated prompt and review applied GPO settings related to network profile and firewall.
    Determines if Group Policy is enforcing the Public profile or blocking sharing, which would require a GPO-level fix rather than a local settings change
  8. Determine which SMB protocol versions are enabled on the server: Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol
    Identifies whether SMB1, SMB2, or SMB3 is available; SMB1 is commonly disabled by security policy and legacy clients may fail silently with no clear error
  9. Enumerate active SMB shares and their share-level permissions on the server: Get-SmbShare | Select-Object Name, Path, Description; Get-SmbShareAccess -Name '<sharename>'
    Confirms shares exist as expected and reveals share-level permission misconfigurations causing access denials independent of firewall or profile issues
  10. Check the state and startup type of LanmanServer and LanmanWorkstation on the server: Get-Service -Name LanmanServer, LanmanWorkstation | Select-Object Name, Status, StartType
    Confirms whether core SMB services are running; a stopped or failed service blocks all share access regardless of firewall and profile configuration
  11. For printer sharing failures, verify the Print Spooler service is running and check for spooler crash events: Get-Service -Name Spooler | Select-Object Name, Status; Get-EventLog -LogName System -Source 'Service Control Manager' -Newest 20 | Where-Object { $_.Message -match 'Spooler' }
    Print Spooler crashes prevent any printer share from being accessible; isolates whether the issue is spooler-specific rather than a general SMB problem
  12. Review System and Security event logs on the server for SMB/auth errors: Get-EventLog -LogName System -EntryType Error -Newest 50 | Where-Object { $_.Source -match 'srv|mrxsmb|lanman|spooler' } | Select-Object TimeGenerated, EventID, Message | Format-List
    Surfaces specific error events such as service failures (7023, 7036), Kerberos errors, or audit failures (4625) to pinpoint root cause
  13. For authentication failures, verify time synchronisation between client and server (w32tm /query /status) and check SPN registration on the server (setspn -L <servername>)
    Kerberos fails silently when clock skew exceeds 5 minutes or when the server SPN is missing/duplicated — both produce 'access denied' symptoms that resemble permission issues

Resolution path

Prevention

Tools

References

windows-10windows-11file-sharingprint-sharingnetwork-profilepublic-networksmbtcp-445firewallwindows-updatel2lansharing-brokennetwork-discoverylanmanserverlanmanworkstationwindows-firewallgroup-policywindows-update-regressionclient-estategpresultrollbacksmb1smb2smb3print-spoolerkerberosntlmauthenticationaccess-deniedsmb-signingwindows-serverevent-id-7036event-id-7023net-useicaclssetspnw32tmshare-permissionsntfs-permissions