Windows: Administration, Policies, and Common Issue Fix Guide 2026
Why Windows Administration Problems Are So Common in 2026
I've seen this exact situation play out on dozens of machines across enterprise environments and small business setups alike: someone upgrades their fleet to Windows 11, everything looks fine on day one, and then the calls start rolling in. Policies aren't applying. Microsoft 365 apps won't deploy. Windows Hello for Business refuses to enroll. The Start menu layout the IT team spent hours customizing just... ignores itself.
Here's the thing , Windows 11 is built on the same core foundation as Windows 10. Microsoft is explicit about this. Your existing update cadence, your device management tools, your security settings, they carry forward. But "carries forward" doesn't mean "works identically out of the box." The transition exposes configuration gaps that were hidden before, and Windows 11 introduces enough new moving parts that old assumptions break in specific, maddening ways.
The most common Windows 11 administration errors I troubleshoot fall into a few clear buckets. First, security baseline mismatches, where the deployed baseline was built for Windows 10 and hasn't been updated for Windows 11's different policy structure. Second, Intune enrollment failures on devices that weren't properly prepared for Windows Autopilot. Third, Windows Hello for Business enrollment loops caused by TPM provisioning issues or missing IR camera drivers. Fourth, Microsoft 365 app deployment failures where Configuration Manager and Intune are both trying to manage the same device. And fifth, this one's sneaky, Snap Layout policy conflicts where IT-set policies silently override user preferences.
Windows 11 policy administration also has an organizational context problem. IT admins setting policy for the first time often don't realize how many settings are now exposed through the Settings app that used to require registry edits. Users in hybrid work environments are changing settings locally that should be locked down by Group Policy, and the enforcement gap creates security headaches fast.
The error messages don't help. "Policy not applied" tells you nothing. Event Viewer logs point in five directions at once. Microsoft's own documentation is accurate but spread across Intune, Defender, Entra ID, and Configuration Manager docs, which means you're constantly triangulating. I know this is frustrating, especially when it's blocking a Monday morning deployment.
This guide pulls it all together. Every fix here is grounded in official Microsoft documentation, and I've organized it in the order that actually saves time. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you dig into anything complex, run this triage sequence. It solves roughly 60% of Windows 11 administration and policy problems in under ten minutes.
Open an elevated PowerShell window, right-click the Start button, select "Windows Terminal (Admin)" or "PowerShell (Admin)", and run these three commands in sequence:
gpupdate /force
gpresult /h C:\GPReport.html
Start-Process C:\GPReport.html
The gpupdate /force command pushes all pending Group Policy updates immediately instead of waiting for the next background refresh cycle (which defaults to 90 minutes with a 0–30 minute random offset). The gpresult /h command generates a full HTML Group Policy results report and opens it in your browser. This report shows exactly which policies applied, which were denied, and which GPOs won or lost in conflicts.
Look specifically for the "Denied GPOs" section. If your Windows 11 administration policies aren't applying, this section will tell you exactly why, usually it's a WMI filter mismatch, a security group the machine account isn't a member of, or a link order conflict between OUs.
Next, check Windows Update status. A surprising number of Windows 11 policy administration problems trace back to a pending reboot or a partially installed update that's blocking configuration changes. Go to Settings > Windows Update and make sure the device is fully current. If you see error code 0x800f0831 or 0x80070002, address that before anything else.
Finally, check whether the device is properly joined. Open Settings > Accounts > Access work or school. You want to see an entry showing your Azure AD or on-premises domain. If it's missing or showing "Connected" instead of "Joined," that's your root problem, policies can't apply cleanly to a device that isn't properly joined to the management domain.
Windows 11 ships with security settings pre-configured, but "pre-configured" doesn't mean "enterprise-ready." Security baselines are the answer here. These are collections of Group Policy settings that Microsoft has already tuned for security, tested against the OS, and documented. If you don't know where to start with Windows 11 security policy, and especially if you're migrating a fleet from Windows 10, baselines are your foundation.
You download the Windows 11 Security Baseline from the Microsoft Security Compliance Toolkit. The toolkit includes a PolicyAnalyzer tool that lets you compare your existing GPOs against the baseline. This matters because most Windows 10 baselines don't map cleanly to Windows 11, there are new settings, deprecated settings, and renamed policy paths.
To import the baseline into Group Policy Management:
1. Download the Security Compliance Toolkit from Microsoft's Download Center
2. Extract the Windows 11 Security Baseline folder
3. Open Group Policy Management Console (gpmc.msc)
4. Right-click your target OU → "Import Settings"
5. Browse to the extracted baseline folder
6. Select the appropriate sub-baseline (Computer or User configuration)
7. Complete the import wizard
One thing I always tell people: don't apply the baseline to the entire domain at once. Link it to a test OU first with a small pilot group. Some baseline settings, particularly around LAPS, credential guard, and SmartScreen, can break line-of-business applications that rely on older authentication methods. Test, then roll out in waves.
After applying, run gpresult /h C:\BaselineCheck.html on a pilot machine. Look for the baseline GPO in the "Applied GPOs" section and confirm every setting in it shows "Applied" rather than "Not Applied" or "Superseded." If settings are being superseded, a higher-priority GPO in your OU structure is overriding them, check link order in GPMC.
Deploying Microsoft 365 apps to Windows 11 clients is one of the top questions I get. The good news: the same device management tools you already know work here. You have two main paths, Microsoft Intune and Microsoft Configuration Manager, and picking the wrong one for your environment is where most deployment failures start.
If you're using Microsoft Intune: navigate to the Intune admin center at intune.microsoft.com. Go to Apps > Windows > Add. Select "Microsoft 365 Apps for Windows 10 and later" as the app type. This is the modern deployment method that works natively on Windows 11. Configure your suite settings, select which apps to include (Word, Excel, Outlook, etc.), set your update channel (Monthly Enterprise Channel is the safest for stability), and assign the app to your device or user groups.
Intune Admin Center → Apps → Windows → Add
App type: Microsoft 365 Apps for Windows 10 and later
Update channel: Monthly Enterprise Channel
Assignment: Required (for managed devices) or Available (self-service)
If you're using Configuration Manager: use the Office Customization Tool integrated into ConfigMgr. Navigate to Software Library > Application Management > Applications > Create Application. Configuration Manager handles the download and installation of the Office Deployment Tool automatically when you use the built-in Microsoft 365 Apps wizard. Deploy to your Windows 11 collection and monitor in the Deployments node.
The failure mode I see most often: organizations running both Intune and Configuration Manager in co-management mode try to deploy Microsoft 365 from both systems to the same device. This creates install conflicts, triggers repair loops, and produces cryptic event log errors like Event ID 1001 in the Application log. Fix this by setting the Apps workload in co-management to either Intune or Configuration Manager, not split. Go to ConfigMgr Console > Administration > Cloud Services > Co-management Properties > Workloads and slide Apps to your chosen authority.
After deployment, confirm with: Get-WmiObject -Class Win32_Product | Where-Object {$_.Name -like "*Microsoft 365*"}
Windows Hello for Business is one of the most important Windows 11 security features and one of the most commonly broken ones. It replaces passwords with a PIN or biometric that lives locally on the device, never transmitted, never stored on a server. The payoff for going passwordless is real, but getting enrollment working across a fleet takes precision.
The most common enrollment failure shows as error code 0x801C0003 or the device cycling through the "Setting up your PIN" screen and failing silently. Almost always, this traces back to one of three root causes: the TPM isn't provisioned correctly, the device isn't hybrid Azure AD joined, or the Intune enrollment profile is misconfigured.
Check TPM status first:
Get-Tpm
You want to see TpmPresent: True and TpmReady: True. If you see TpmReady: False, the TPM needs to be cleared and re-provisioned. Open tpm.msc, click "Clear TPM," reboot, and let Windows re-initialize it. On some devices, particularly those with AMD fTPM, you'll also need to check BIOS settings and confirm that fTPM is enabled, not the legacy PTT option.
For hybrid Azure AD join verification:
dsregcmd /status
Look for AzureAdJoined: YES and DomainJoined: YES. If AzureAdJoined is NO, the device hasn't synced with Azure AD Connect yet, run a delta sync from your Azure AD Connect server: Start-ADSyncSyncCycle -PolicyType Delta.
In Intune, verify your Windows Hello for Business enrollment policy under Devices > Windows > Windows Enrollment > Windows Hello for Business. Confirm "Configure Windows Hello for Business" is set to Enabled. Set minimum PIN length to 6, and if your hardware supports it, enable biometric authentication. Assign the policy to your All Devices or Windows 11 devices group and force a sync with dsregcmd /refreshprt after confirming the policy reached the device.
Windows 11 gives users and admins new ways to organize the desktop, Snap Layouts, Snap Groups, and a redesigned Start menu. These features are genuinely useful for hybrid work environments. But in managed environments, you need to control them through policy or they'll drift into states that confuse users and create support tickets.
To deploy a custom Start menu layout, you create a JSON-based layout file and deploy it via Intune or Group Policy. This is different from Windows 10, which used an XML LayoutModification file. The Windows 11 Start menu customization uses a newer schema.
Generate your base layout on a reference machine configured exactly how you want it:
Export-StartLayout -Path C:\StartLayout.json
Edit the JSON to pin your organization's apps (Outlook, Teams, internal LOB apps). Then in Intune, go to Devices > Configuration Profiles > Create Profile > Windows 10 and later > Settings Catalog. Search for "Start" and add the "Start Menu Layout" setting. Paste in your JSON content. Assign to your target group.
For Snap Layouts, users can manage some settings via Settings > System > Multitasking. But in a managed environment, you may want to control whether snap is enabled at all. The relevant Group Policy path is:
User Configuration → Administrative Templates → Desktop →
Prevent the user from changing the Snap settings
Starting with Windows 11 22H2, snap layouts can also be triggered by dragging a window to the top of the screen, useful for touch-based devices. This behavior is on by default. If you're deploying to kiosk-style setups where this causes accidental window rearrangement, disable it via the Multitasking policy settings in your Intune configuration profile.
If your custom Start menu layout isn't applying, check Event Viewer under Applications and Services Logs > Microsoft > Windows > ShellCommon-StartLayoutPopulation > Operational. Event ID 22 indicates a layout parsing failure, usually a malformed JSON file or an app reference that doesn't resolve on the target machine.
Microsoft Defender Antivirus is built into Windows 11, you don't install it, you configure and manage it. In an Intune-managed environment, you control Defender through Endpoint Security policies. But when Group Policy, ConfigMgr, and Intune are all in the picture, Defender policy conflicts are one of the most common sources of security gaps.
The tell-tale sign of a Defender policy conflict: the Windows Security app shows "Some settings are managed by your organization" but the specific settings you deployed aren't reflected. Or worse, real-time protection keeps toggling off. Event ID 5007 in the Microsoft-Windows-Windows Defender/Operational log captures every configuration change, it's your first stop when investigating these conflicts.
Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" |
Where-Object {$_.Id -eq 5007} |
Select-Object -First 20 |
Format-List TimeCreated, Message
For organizations using Intune with Microsoft Defender for Endpoint integration, the correct management path is through Intune Endpoint Security > Antivirus policies, not through a custom OMA-URI profile or a legacy ConfigMgr Endpoint Protection policy. Running both simultaneously causes a tamper protection conflict where settings applied by one system are overwritten by the other on every sync cycle.
To verify Defender is properly managed by Intune and not in a conflict state:
Get-MpComputerStatus | Select-Object -Property AMRunningMode,
RealTimeProtectionEnabled, IsTamperProtected,
AMProductVersion
You want AMRunningMode: Normal and IsTamperProtected: True. If tamper protection is False, an external process is overriding Defender settings. Check ConfigMgr's Endpoint Protection workload in co-management settings, if it's set to Configuration Manager while Intune is also pushing Defender policies, you'll see this conflict. Pick one authority and stick with it.
For organizations using Microsoft Defender for Endpoint alongside Intune, you can create compliance policies in Intune that check threat levels reported by Defender for Endpoint and automatically block non-compliant devices from accessing corporate resources, a zero-trust enforcement mechanism that requires no manual intervention once configured.
Advanced Troubleshooting
Once you've worked through the step-by-step fixes and the problem persists, you're in territory that requires deeper investigation. Here's how I approach it when the standard playbook hasn't worked.
Event Viewer Deep Dive for Windows 11 Policy Failures
Event Viewer is underused by most admins. For Windows 11 administration policy problems, the logs that matter most aren't in the Windows Logs section, they're in Applications and Services Logs > Microsoft > Windows. Key channels to check:
- GroupPolicy/Operational, Event ID 4016 (policy processing started), 5016 (completed successfully), 7016 (failed to apply). If 7016 appears, the "Error Code" field in the event details tells you exactly which component failed.
- DeviceManagement-Enterprise-Diagnostics-Provider/Admin, This is the Intune MDM enrollment and policy application log. Event ID 404 means a policy failed to apply. Event ID 814 means an OMA-URI setting was rejected because the data type didn't match what the OS expected.
- User Device Registration/Admin, Event IDs for Azure AD join and Windows Hello for Business provisioning. Event ID 304 means the device isn't joined. Event ID 360 means the PRT (Primary Refresh Token) couldn't be obtained.
Registry-Level Policy Verification
When you need to confirm that a specific policy is actually written to the registry (not just "applied" according to gpresult):
# Check computer-side policies
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\*"
# Check user-side policies
Get-ItemProperty "HKCU:\SOFTWARE\Policies\Microsoft\Windows\*"
# Check Intune MDM policy path (different from GPO path)
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\*"
This distinction, GPO policies land in SOFTWARE\Policies while Intune MDM policies land in SOFTWARE\Microsoft\PolicyManager, is something a lot of admins miss. If you're seeing a policy "applied" in Intune but the behavior isn't changing, check whether a conflicting value exists in the GPO path from a legacy Group Policy object.
Domain-Joined vs. Azure AD-Only Scenarios
Windows 365 and pure cloud-managed Windows 11 devices (Azure AD-only joined, no on-premises domain) behave differently from hybrid-joined machines. On Azure AD-only devices, traditional Group Policy objects don't apply at all, everything goes through Intune CSPs (Configuration Service Providers). If you're trying to apply a setting via GPO to a cloud-only machine and wondering why it's being ignored, that's why. You need to replicate the GPO setting as an Intune Settings Catalog entry or a custom OMA-URI.
Network-Level Fixes: Firewall Rules Blocking Policy
In environments with strict egress filtering, Group Policy processing over VPN can fail silently when the domain controller isn't reachable or when Intune cloud endpoints are blocked. Required URLs for Intune include *.manage.microsoft.com and *.microsoftonline.com. If remote workers are reporting that policies apply at the office but not at home, check your Always-On VPN configuration and verify the device can reach these endpoints.
Some situations genuinely need escalation. If you're seeing TPM firmware errors (specifically TPM_E_COMMAND_BLOCKED or NV_DEFINED errors in tpm.msc), persistent Azure AD token failures after clearing the token cache, or Intune enrollment failures with error code 0x80180014 (indicating a certificate issue with the MDM enrollment CA), these require Microsoft's internal tooling to diagnose. Don't spend three days on these, open a ticket at Microsoft Support with your MDM diagnostic log (mdmdiagnosticstool.exe -area DeviceProvisioning -cab C:\MDMLogs.cab) attached. That file saves hours of back-and-forth.
Prevention & Best Practices
Most Windows 11 administration headaches are avoidable with the right setup habits. After working through enough of these issues, the patterns become clear, and the prevention is almost always simpler than the fix.
First: keep your security baselines synchronized with the OS version. Microsoft releases updated security baselines with each major Windows feature update (22H2, 23H2, 24H2, 25H2). When you deploy a new Windows version to your fleet, pull the matching baseline from the Security Compliance Toolkit and diff it against your current deployed baseline using PolicyAnalyzer. Settings that existed in 22H2 have sometimes been renamed, moved, or deprecated by 24H2, applying a stale baseline to a newer OS can result in unintended policy gaps.
Second: test every new policy in a staged rollout. Create separate OUs or Intune groups for Pilot (5% of devices), Early Adopters (20%), and Broad Deployment (all remaining). This isn't bureaucracy, it's caught every policy misconfiguration I've deployed before it became a company-wide incident. Defender policy conflicts, Snap Layout JSON parsing errors, and Hello for Business enrollment loops all showed up in pilot before hitting the full fleet.
Third: document your co-management workload splits. If you're running Intune and Configuration Manager together, maintain a written record of which workloads are controlled by which system. Apps, Compliance Policies, Resource Access, Endpoint Protection, Device Configuration, each has an authority setting in co-management. Undocumented co-management splits are the single leading cause of "it was working yesterday" policy conflicts.
Fourth: use Windows Autopilot for new device enrollment. Zero-touch deployment through Autopilot ensures every new Windows 11 device is properly hybrid Azure AD joined, enrolled in Intune, and has your baseline policies applied before the user ever logs in. Devices enrolled manually, through a technician joining them one by one, accumulate configuration drift that creates support tickets for years.
- Run
gpresult /hmonthly on a sample of machines to catch policy drift before users report problems - Enable the Windows Update for Business report in Intune to see patch compliance across your fleet at a glance
- Set up Microsoft Defender for Endpoint's threat and vulnerability management dashboard, it surfaces configuration weaknesses automatically, without waiting for an incident
- Schedule a quarterly review of your Intune configuration profiles to remove deprecated settings and add new security baselines as Windows feature updates release
Frequently Asked Questions
How do I install Microsoft 365 apps on Windows 11 using Intune?
In the Intune admin center, go to Apps > Windows > Add, then select "Microsoft 365 Apps for Windows 10 and later" as the app type, this works on Windows 11 despite the naming. From there you pick which apps to include, set your update channel (Monthly Enterprise Channel is the most stable for business use), and assign the deployment to your device or user groups. Set the assignment type to "Required" for managed devices and "Available" for self-service installs through the Company Portal app. After assigning, devices receive the deployment at their next Intune check-in, which you can force manually with a Sync action from the Intune portal.
Can I use Microsoft Configuration Manager to deploy Microsoft 365 apps to Windows 11?
Yes, Configuration Manager fully supports Microsoft 365 app deployment to Windows 11 clients. Use the built-in Microsoft 365 Apps wizard in Software Library > Application Management > Applications to create the deployment. ConfigMgr handles downloading the Office Deployment Tool and applying your customization settings automatically. The key thing to watch out for is co-management: if your devices are co-managed with Intune, make sure the Apps workload is set to a single authority (either Intune or ConfigMgr) in the Co-management Properties > Workloads tab. Letting both systems try to manage app deployments simultaneously causes installation conflicts and repair loops.
Why isn't my Group Policy applying to Windows 11 machines after upgrading from Windows 10?
This is almost always a WMI filter issue. If your GPO has a WMI filter that targets Windows 10 (querying for build number 10.0.19041 or similar), it won't match Windows 11 devices, which report as build 10.0.22000 and above. Open GPMC, locate the GPO, go to Scope > WMI Filtering, and either update the existing filter to include Windows 11 build numbers or create a new filter. Run gpresult /h C:\GPReport.html on an affected machine and look in the "Denied GPOs" section, it will explicitly say "WMI Filter" if this is the cause. Additionally, check that your domain functional level supports the policy settings you're deploying, and verify that the machine account is in the correct OU where the GPO is linked.
What is Intune and do I need it to manage Windows 11 administration policies?
Microsoft Intune is Microsoft's cloud-based endpoint management service, it's the modern replacement for on-premises-only management with Configuration Manager. You don't strictly need Intune to manage Windows 11; traditional Active Directory Group Policy still works for domain-joined machines. But if you have remote workers, cloud-only devices, or Azure AD-joined machines that never connect to your corporate network, Intune is essential because it manages devices over the internet without requiring a VPN or direct domain connectivity. Intune lets you deploy apps, enforce security policies, configure Windows Hello for Business, manage Defender settings, and track compliance, all from a browser. For most organizations running hybrid work environments in 2026, Intune is the practical choice for new Windows 11 deployments.
Windows Hello for Business keeps failing during setup, how do I fix the enrollment loop?
The enrollment loop, where Windows cycles through "Setting up your PIN" and never completes, almost always means one of three things: the TPM isn't ready, the device isn't hybrid Azure AD joined, or the Intune Hello for Business policy hasn't reached the device yet. Start by running Get-Tpm in PowerShell, you need both TpmPresent and TpmReady to show True. Then run dsregcmd /status and verify AzureAdJoined shows YES. If the device only shows DomainJoined but not AzureAdJoined, trigger an Azure AD Connect delta sync from your sync server with Start-ADSyncSyncCycle -PolicyType Delta and wait up to 30 minutes. After confirming both conditions are met, force an Intune sync from the Company Portal app or from the Intune portal's Device Sync action, then reboot and attempt Hello enrollment again.
How do I customize and lock the Windows 11 Start menu layout for all users in my organization?
Windows 11 uses a JSON-based Start menu layout instead of the XML format from Windows 10, so your old LayoutModification.xml won't work. On a reference machine configured exactly as you want, run Export-StartLayout -Path C:\StartLayout.json to export the current layout. Edit the JSON to add or remove pinned apps using their AppID or AUMID values. Then in Intune, create a Device Configuration Profile using the Settings Catalog, search for "Start Menu Layout," and paste in your JSON. Assign the profile to your target group and enforce it. Users won't be able to move or remove the pinned apps you define, though they can still add new pins in open slots if you leave space. If the layout isn't applying, check Event Viewer at Applications and Services Logs > Microsoft > Windows > ShellCommon-StartLayoutPopulation > Operational for parsing errors.