Field Notes: Where GCC High Diverges From the Documentation
Every item below was found during a real deployment, not derived from documentation. Each one shares a signature: it fails quietly. The job reports success, the portal shows green, the query returns zero rows, the device says it is managed. Nothing raises an error that names the actual cause.
That is what makes them expensive. A loud failure costs an hour. These cost days.
In some cases Microsoft's documentation is simply wrong. More often it is correct somewhere and contradicted or omitted on the page you would naturally reach for first, which has the same practical effect. Where that is the situation, the entry says so and links every relevant page, because knowing the answer exists three clicks away is worth as much as the answer.
Each entry gives the symptom as you will actually encounter it, the mechanism, and the fix. Follow the link at the end for the full procedure.
Findings: 27. Verified against the 2026.09.30 release of Securing GCC High. Individual verification dates appear on entries where the claim is about the current state of Microsoft's documentation.
Application control
Intune App Control blocks the Azure VM guest agent: Run command returns nothing, Service Control Manager event 7000
You see: Azure Run command completes with no output. The VM reports Agent status: Not ready. VM extensions stop deploying. The System log shows Service Control Manager event 7000 for RdAgent and WindowsAzureGuestAgent: "An Application Control policy has blocked this file." The identical commands work over RDP inside the session.
Why: Intune's App Control Built-in controls are hard-wired to the DefaultWindows base policy, which trusts Windows components, third-party kernel drivers, and Store-signed apps. It does not trust everything Microsoft signs. The Azure VM guest agent is signed under the Microsoft product root rather than as a Windows component, so an enforced DefaultWindows policy blocks it.
Fix: Build custom App Control XML on AllowMicrosoft.xml instead of using Built-in controls. Note the recovery trap: setting an enforced policy to Not Configured or unassigning it leaves enforcement in place. You must explicitly set the mode to Audit only and restart.
The event-7000 check is readable by a standard user, which matters because Run command is dead and you may not have local admin:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'} -MaxEvents 60 |
Where-Object { $_.Message -match 'RdAgent|WindowsAzureGuestAgent' }
Azure Backup reports success while silently degrading to crash-consistent snapshots
You see: Azure Backup jobs succeed. In the job detail, UserErrorBackupTookCrashConsistentSnapshot. No alert, no failure, and no indication that application-consistent recovery is gone.
Why: VMSnapshot cannot coordinate VSS without a working Azure VM guest agent. When App Control blocks the agent, backup falls back to crash-consistent and still reports the job as successful.
Fix: Treat Azure VM guest agent health as a backup prerequisite. Confirm the agent reads Ready before signing off a Recovery Services vault.
App Control Allow Microsoft Mode starts the Azure guest agent, then Run command still fails
You see: Services start, the VM reports Ready, and Azure Run command still returns nothing.
Why: A Microsoft-signed base policy authorizes the guest agent's own binaries but not the code the agent executes. The Run command extension ships third-party Newtonsoft.Json.dll. Microsoft Defender for Endpoint's data-collection and live-response scripts have generated names and run through powershell.exe. The AVD RD Agent boot loader is an unsigned .ps1.
Fix: Four file path rules, scoped by fleet type:
| Path | Needed on | Covers |
|---|---|---|
C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\DataCollection\* | Any fleet running Defender for Endpoint | Live-response and data-collection scripts. Blocking these silently degrades incident response |
C:\WindowsAzure\* | Azure VMs | Guest agent helpers: CollectGuestLogs.exe, FindVolume.exe, WaSecAgentProv.exe |
C:\Packages\Plugins\* | Azure VMs | VM extensions, including the third-party DLL that breaks Run command |
C:\Program Files\Microsoft RDInfra\* | AVD session hosts | StartRDAgentBootLoader.ps1 |
The trailing \* is mandatory, since these folders are version-numbered. All four are admin-writable only, so path rules are appropriate here; App Control silently ignores a path rule for a directory that standard users can write to.
Note that the Defender row applies to any fleet running Defender for Endpoint, Azure or not. It is the one rule on this list that is not an Azure-specific concern.
App Control audit evidence is swamped by AppControlCodeIntegrityOriginBlocked 3092 and .ni.dll native images
You see: Thousands of AppControlCodeIntegrityOriginBlocked (3092) events referencing .ni.dll files, burying the real signal in Advanced Hunting.
Why: Event 3092 is context about a blocked file, not a block decision. A .ni.dll is compiled locally and carries no publisher signature, so App Control trusts it through an NTFS extended attribute that .NET writes after confirming the original IL file passes the active policies. That attribute is scoped to those policies, so any policy change invalidates every one at once, which is why a single change produces thousands of events.
Microsoft classes the blocks as functionally benign and self-healing, meaning two things: .NET falls back to the original IL and JIT-compiles it, so nothing breaks beyond a small startup cost, and the fallback schedules regeneration of all native images at the next maintenance window. That window is deferred to idle time, so on a session host that never idles it can be a long wait.
Fix: Filter to AppControlCodeIntegrityPolicyBlocked (3077) and AppControlCIScriptBlocked (8029), the only real block decisions. To regenerate now instead of waiting, run ngen update from both $env:WINDIR\Microsoft.NET\Framework\v4.0.30319 and Framework64; the 32-bit and 64-bit caches are separate. That stops new events but does not remove those already logged, so the count falls only as old entries age out.
Sovereign cloud endpoints
Intune enrollment fails with 0x80192efd in a GCC High tenant
You see: Autopilot or AADLoginForWindows enrollment fails with 0x80192efd. Everything else about the tenant looks correct.
Why: The Microsoft Entra Mobility blade ships commercial .com MDM URLs by default even in a GCC High tenant. The device tries to reach a cloud it is not in.
Fix: Set the MDM terms of use, discovery, and compliance URLs to their .us equivalents. Do not click "Restore default MDM URLs", which resets a sovereign tenant back to commercial endpoints and reintroduces the failure.
Cloud-only deployment checklist
Windows activation fails with 0xC004F074 on Azure Government behind Azure Firewall
You see: Session hosts fail to activate with 0xC004F074. Azure Firewall network rules for the AzureCloud service tag are in place and everything else works.
Why: The Azure Government KMS endpoints resolve to the Internet service tag, not AzureCloud. A network rule scoped to AzureCloud will never match them.
Fix: Add explicit IP allowances for the Azure Government KMS addresses on port 1688.
Microsoft Defender Antivirus cloud protection calls commercial endpoints from GCC High
You see: Defender Antivirus cloud-delivered protection is degraded or unreachable despite the MicrosoftActiveProtectionService FQDN tag being allowed.
Why: Defender Antivirus cloud protection calls commercial wdcp, wdcpalt, and wd.microsoft.com endpoints even on GCC High. The .us endpoints and the FQDN tag do not cover them.
Fix: Allow the commercial MAPS FQDNs explicitly. This one surprises people because nearly every other Defender component honors the sovereign boundary.
Azure Firewall and networking
Azure Firewall wildcard FQDN rules do not match the domain apex
You see: Intune check-ins fail intermittently behind Azure Firewall despite a wildcard rule that visibly covers the domain.
Why: An Azure Firewall rule for *.domain.com does not match the domain.com apex. Microsoft hosts services directly on the apex for manage.microsoft.us and dm.microsoft.us, so the wildcard silently misses exactly those calls.
Fix: Add the apex where something is actually served there (manage.microsoft.us, dm.microsoft.us, checkappexec.microsoft.com); most wildcards cover subdomain-only namespaces and need none.
SmartScreen says it "can't be reached right now" on every download: not an outage, a firewall block that fails open
You see: Every downloaded executable stalls for a few seconds at launch, then Microsoft Defender SmartScreen reports it can't be reached right now and offers a Run button. It reads as a SmartScreen service outage, and because Run works, people click through and stop reporting it.
Why: SmartScreen's app-reputation check calls checkappexec.microsoft.com, served at the apex. Microsoft's endpoint documentation lists the wildcard form *.checkappexec.microsoft.com, and an Azure Firewall wildcard never matches the apex, so a rule built faithfully from the documentation blocks the exact host the documentation is describing. The check fails open: reputation silently degrades to the Run prompt instead of raising anything that names a block, so every launch pays the timeout and nobody files a ticket the firewall team would recognize.
Fix: Allow the apex checkappexec.microsoft.com explicitly alongside the documented SmartScreen wildcards. The denies are visible in the firewall log under the apex FQDN.
Field-verified 2026-08-05; Microsoft's endpoint list carried only the wildcard form on that date.
Azure Firewall FQDN tags do not reliably cover Azure Government endpoints
You see: Traffic denied for a service whose Azure Firewall FQDN tag is explicitly allowed.
Why: FQDN tags are maintained against commercial endpoint lists. Coverage of .us equivalents is inconsistent and undocumented per tag.
Fix: Treat every FQDN tag in Azure Government as best-effort and pair it with explicit FQDN fallbacks.
Firewall reference: FQDN tag content gaps
Azure Firewall policy deploys successfully but no rules take effect
You see: Everything is denied, including NTP. The firewall policy deployment reported success.
Why: Deploying an Azure Firewall policy does not bind it to the firewall. A firewall still in classic rules mode ignores the policy entirely.
Fix: Associate the policy through Firewall Manager. The tell that a policy is actually live is a Deny-All-Log rule collection appearing in the firewall's effective rules; if you do not see it, the policy is not bound.
AVD session hosts fail the DSC extension on a storage blob FQDN that Azure Firewall already allows
You see: The AVD DSC extension fails during provisioning. The blob host it needs is allowed in an Azure Firewall application rule.
Why: Application rules match on TLS SNI at layer 7, which does not work for the AVD Configuration.zip and agent blob fetches.
Fix: Allow wvdportalstorageblob and mrsglobalst through a Storage service-tag network rule, not an application rule.
Install-Module fails with "Source Location is not valid" because the Gallery's download host is a separate FQDN
You see: Install-Module resolves a specific package version, then fails:
WARNING: Source Location 'https://www.powershellgallery.com/api/v2/package/Microsoft.Graph.Authentication/2.39.0' is not valid.
PackageManagement\Install-Package : Package 'Microsoft.Graph.Authentication' failed to download.
It reads as a broken or untrusted repository, which sends you to Set-PSRepository and -Force flags instead of the firewall log.
Why: discovery and download are different hosts. The API at www.powershellgallery.com resolves the package version, then redirects to cdn.powershellgallery.com for the actual .nupkg. An allowlist carrying only the API host lets discovery succeed and download fail.
Compounding it, the endpoints most firewall guides list are retired. Microsoft states that "the old endpoints that ended with azureedge.net are no longer supported" (network access to the PowerShell Gallery), yet psg-prod-eastus.azureedge.net and onegetcdn.azureedge.net still appear in other current Microsoft pages such as the SAP deployment planning guide. An allowlist built from those pages fails on a rule that looks correct.
The tell: the error names a specific resolved version. That only happens if the API call succeeded, so the block is downstream at the CDN, not at the gallery.
Fix: allow cdn.powershellgallery.com and cdn.oneget.org for discovery and download, *.powershellgallery.com for the site and API, and go.microsoft.com plus aka.ms as the redirection services Microsoft lists. Remove any azureedge.net gallery entries; they no longer resolve to anything.
Rule out TLS first, since PowerShell 5.1 does not always negotiate 1.2 and the failure looks identical:
[Net.ServicePointManager]::SecurityProtocol =
[Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
Test-NetConnection cdn.powershellgallery.com -Port 443
If cdn.powershellgallery.com fails and www.powershellgallery.com succeeds, that confirms it without touching a log.
Verified against Microsoft Learn 2026-08-04.
Firewall reference: PowerShell-Gallery rule
az deployment fails with SSLEOFError UNEXPECTED_EOF_WHILE_READING: the Azure CLI fetches Bicep from an endpoint Microsoft does not document
You see: The first az deployment group create --template-file <file>.bicep on a machine dies in a Python TLS traceback ending SSLEOFError ... UNEXPECTED_EOF_WHILE_READING. Deploying compiled ARM JSON works. It reads as a proxy or TLS-inspection problem.
Why: The Azure CLI downloads the Bicep CLI on first use from downloads.bicep.azure.com, an endpoint that appears nowhere in Microsoft's documentation; the air-gapped-cloud guidance still routes Bicep acquisition through GitHub. Azure Firewall answers the denied HTTPS connection by cutting it mid-handshake, which Python surfaces as an SSL EOF rather than anything naming a block.
Fix: Allow downloads.bicep.azure.com. Bicep then installs itself on first use: no GitHub access, no manual staging, no separate install step.
Field-verified 2026-08-05; the endpoint was absent from Microsoft's Bicep and air-gapped documentation on that date.
Firewall reference: Azure CLI on a session host
Your NTANetAnalytics flow-log query returns zero rows: FlowStatus is "Denied", not "D"
You see: A KQL query filtering FlowStatus == "D" returns nothing. You conclude the NSG is innocent and go looking elsewhere. This is the worst kind of wrong answer, because an empty result set is indistinguishable from a clean one.
Why: Two Microsoft pages disagree, and the wrong one is the one you would naturally reach for. The traffic analytics schema page documents, under its Virtual network flow logs heading, FlowStatus as A = Allowed / D = Denied and FlowDirection as I = Inbound / O = Outbound. Those are the encodings of the retired AzureNetworkAnalytics_CL table, which that same page's own footnote acknowledges NTANetAnalytics replaced.
Microsoft's query examples for the table use the spelled-out values: FlowDirection == "Outbound", FlowDirection == "Inbound".
Fix: In NTANetAnalytics, FlowStatus is Allowed / Denied and FlowDirection is Inbound / Outbound. Also note that NSG flow logs can no longer be created; the current path is virtual network flow logs with traffic analytics.
Verified against Microsoft Learn 2026-08-03. The schema page still carried the single-letter values on that date.
Identity and authentication
Entra phishing-resistant authentication strength fails on Windows desktop apps with an all-zeros AAGUID
You see: An AAGUID-restricted authentication strength blocks users in desktop applications while working correctly in the browser. Sign-in logs show an all-zeros AAGUID.
Why: The Primary Refresh Token carries the MFA claim at method level, with no field for WebAuthn attestation metadata, so the AAGUID arrives as all zeros. Microsoft Support confirmed the limitation in writing in April 2026, and it remains absent from public documentation.
Fix: Swap the grant control to the built-in Phishing-resistant authentication strength. The two-field sign-in log fingerprint is the all-zeros AAGUID plus incomingTokenType, where primaryRefreshToken fails and none works.
Three things look like fixes and are not: adding AAGUIDs to the strength, dropping to Require MFA, and allowlisting the all-zeros AAGUID itself. The portal accepts the last one, but it acts as a silent wildcard for any attestation-absent credential rather than the make-and-model enforcement you intended.
Entra External Authentication Methods satisfy Require MFA but never an authentication strength
You see: A compliance requirement for phishing-resistant authentication cannot be closed despite a fully deployed third-party MFA provider.
Why: External authentication methods (EAM), the GA replacement for retiring Conditional Access custom controls, work only with the Require multifactor authentication grant control. They satisfy no authentication strength at all, not merely the phishing-resistant one: Microsoft's wording is "Grant controls based on authentication strengths, including the built-in MFA strength, aren't satisfied by the external MFA method" (external MFA provider), and the authentication-strength guidance calls them "currently incompatible with authentication strength" (authentication strength).
Fix: No configuration closes this, however strong the provider's own method is. Only native FIDO2, Windows Hello for Business, or Entra certificate-based authentication satisfy the built-in Phishing-resistant MFA strength, so plan a cohort migration rather than a policy change. Custom controls stop accepting new or edited configurations in September 2026 and retire fully in early 2027 (custom controls), which sets the outside date.
Verified against Microsoft Learn 2026-08-04.
Microsoft Entra adds Global Administrators as local admins on every joined device by default
You see: Nothing. That is the problem.
Why: The device setting "Global administrator role is added as local administrator on the device during Microsoft Entra join" defaults to on, corresponding to the Graph property azureADJoin.localAdmins.enableGlobalAdmins = true.
Fix: Actively disable it. It is not off by default and nothing prompts you about it during tenant setup.
Copilot and Purview
Copilot DLP blocks a web search silently: no banner, no policy tip, only a line in the reasoning summary
You see: A requirement that Microsoft 365 Copilot keep web grounding on but never send CUI to the public internet. The DLP for Copilot documentation describes label-based exclusion, which stops Copilot reading labeled files; nothing on that page is an egress control for what a user types.
Why: The Copilot location carries three distinct gates, and Learn documents only the first as the headline feature. A sensitivity label condition with Prevent Copilot from processing content is the reading gate: files and emails the label covers never inform an answer, so they cannot inform a web query either. A sensitive information type condition on the Performing web searches activity is the egress gate: it evaluates the typed prompt only. A sensitive information type condition on Processing prompts (preview) refuses the prompt entirely. Label and sensitive-information-type conditions cannot share a rule (separate rules in one policy is fine), and policy changes take up to four hours to reach the Copilot experience, with detection and audit lighting up before runtime enforcement does. The tenant setting Allow web search in Copilot sits above all three.
Fix: Build all three gates, and test the egress gate from the chat box, not from a file. When the egress rule fires there is no DLP banner and no policy tip: with the reasoning summary expanded, Copilot reports that the web search tool is not providing results and answers from internal files instead. That line is the immediate tell; Activity explorer catches up hours later. In the audit trail the interaction carries AISystemPlugin.Id = BingWebSearch with DLPEvaluationDeferred: 0. DLP never inspects a file uploaded directly into a prompt, only typed text and tenant-stored content.
Verified in a GCC High reference tenant, 2026-09-07 and 2026-09-21: the egress gate blocks web grounding in both Work and Web modes.
A line-anchored marking classifier catches files but never fires on a typed Copilot prompt
You see: A custom sensitive information type that matches a CUI banner line, such as (^|\n)\s*CONTROLLED\s*(\n|$), blocks Copilot from reading marked files, but the web-search egress rule never fires when the same marking is pasted into a prompt. Activity explorer shows the match sourced from a referenced file rather than the prompt, and the Prompt field shows the line break collapsed to a space. The audit record has AISystemPlugin.Id = BingWebSearch and DLPEvaluationDeferred: 0, so this is not the evaluation race.
Why: The Copilot chat box flattens a pasted prompt to a single line before sensitive-information-type evaluation. Newlines survive in files, so the reading gate works and the egress gate silently does not. Microsoft's documentation does not mention it.
Fix: Use word-boundary patterns, \b(CONTROLLED|CUI)\b, with String match; the \b supplies the boundaries, and Word match is the portal's equivalent, so do not combine them. The regular expression engine is case-sensitive by default, so an all-caps literal matches only the marking and never the ordinary word. The custom classifier validator rejects ^ and $ and more than one top-level capturing group, which is why the banner-line pattern looked like the only option.
Verified in a GCC High reference tenant, 2026-09-07.
Blocking labeled files from specific SharePoint sites at upload reads as impossible; Endpoint DLP does it
You see: A requirement that files carrying a given label never land in particular SharePoint sites. SharePoint and Teams have no upload-time label gate, SharePoint DLP acts only after the file arrives, and every product-scoped answer says the requirement is not achievable.
Why: Endpoint DLP sensitive service domain groups accept your own tenant's SharePoint site URLs, which gives a true pre-upload block in the browser. Learn presents the feature only for third-party and shadow-AI egress; the own-tenant use is implied by the URL syntax and never shown as a scenario. A URL entered without a trailing slash covers the site and every deeper path, which is where library uploads live. Limits: 100 URLs per group, 150 groups, browser path only (Edge natively; Chrome and Firefox through the Purview extension; other browsers are redirected), onboarded devices only. The current wizard label is Manage protected files access from unallowed browsers and uploads to restricted cloud service domains.
Fix: Build the group from the site URLs, attach it to the Endpoint DLP rule for the label, and keep the post-upload SharePoint DLP block as the backstop for the paths the endpoint cannot see: the sync client, the Teams client, and Office Save As. The method lesson is the finding: a verdict has to be scoped to the requirement, not the product, and "not achievable" is not shipped until every control plane (service, endpoint, browser, network, identity) has been swept.
Validated in a commercial reference tenant, September 2026; the wizard and settings are the same in GCC High.
Defender for Endpoint
Defender for Endpoint shows "Managed by: MDE" while delivering no policy at all
You see: The device reports Managed by: MDE. No policy ever arrives.
Why: MDE-channel policy reaches a device through its Microsoft Entra device object. Two degraded states keep the label while breaking delivery:
- Registration never completed (SCP or Entra Connect misconfiguration). Diagnose at
HKLM\SOFTWARE\Microsoft\SenseCM\EnrollmentStatus. - Registration completed, then the Entra object was deleted (an OU moved out of sync scope, or stale-device cleanup).
dsregcmd /statusshowsAzureAdJoined: YESbutDeviceAuthStatus: FAILED, and sign-ins fail withAADSTS50155.
Fix: Fix sync scope first, then re-register. Deleted device objects cannot be restored. In either state only the GPO half and sensor-based assessment still operate, so treat the device as unmanaged for audit evidence purposes.
Conditional Access fails with AADSTS53001 after onboarding Defender before hybrid join
You see: AADSTS53001 or AADSTS53000 on devices that appear correctly joined.
Why: Onboarding Defender for Endpoint before Microsoft Entra hybrid join completes leaves a synthetic Entra device object, and Conditional Access then resolves against it rather than against the real one.
Fix: Gate MDE onboarding on hybrid join completion. Remediation for already-duplicated fleets is a separate procedure.
Configuration Manager tenant attach is supported in Azure Government, despite what the setup page tells you
You see: You are scoping tenant attach for a US Government tenant, read that Azure Government is not supported, and drop it from the design.
Why: It has been supported since Configuration Manager current branch 2107. The problem is that Microsoft's documentation says both things in different places, and the discouraging version is on the setup page:
- Configure tenant attach to support endpoint security policies from Intune states "Azure Government cloud isn't supported" with no version qualifier at all.
- Enable Microsoft Intune tenant attach: Device sync and device actions repeats the blanket denial, then reverses it in the sub-bullet immediately beneath: "Starting in version 2107, US Government customers can select AzureUSGovernmentCloud."
- Tenant attach: Prerequisites is the page that gets it right, and enumerates what US Government actually gets at 2107: account onboarding, tenant sync, device sync, and device actions in the Intune admin center.
Fix: Proceed on 2107 or later. Exploit Protection is deliverable to Windows Server through tenant attach, which narrows the ConfigMgr-managed server gap to LAPS, Local Group Membership, and Device Control.
Verified against Microsoft Learn 2026-08-03.
A device moved to a new tenant is refused by Defender or lands in "Tenant mismatch" because it was never offboarded from the old one
You see: A device retired from one tenant and joined to another enrolls in the new Intune cleanly, but Defender onboarding never completes, or the new tenant's Security Settings Management shows enrollment status 15, Tenant mismatch. In the old tenant the device still shows as an active sensor for a week, then quietly goes Inactive, which looks like success. Running an offboarding package later fails with Event ID 70, "Offboarding script is for a different organization."
Why: Defender for Endpoint offboarding is a separate, tenant-specific action that nothing else performs for you. Intune Retire, Intune Wipe, Autopilot deregistration, dsregcmd /leave, and even a factory reset from the device do not offboard the sensor's registration in the old tenant's service. The retirement and tear-down runbooks people actually follow start at Intune, so the step is skipped, and the device arrives in the new tenant with its sensor still bound to the old one. The offboarding package must be downloaded from the tenant the device currently reports to (Event ID 70 is what a wrong-tenant package produces), and it expires within days of download: three per the portal's help text, seven per Learn, with the real date in the filename.
Fix: Offboard first, always: it is the opening step of the retirement order, of both single-device tear-down procedures, and of any tenant move. If the device has already left the old tenant, an administrator there downloads a fresh offboarding package (the Defender deployment tool's Offboard button for one device; short validity, date in the filename) and it is run on the device before the new tenant's onboarding is attempted; never target a device with onboarding and offboarding at the same time. Expect the old tenant to show the device Inactive after seven days with its history retained under the retention period; that is the correct end state, not a failure.
Verified against Microsoft Learn 2026-09-02.
Offboarding · Moving a device to another tenant
Operations, evidence, and reporting
The Intune SharedPC CSP tattoos: removing the policy does not remove the configuration
You see: Un-assigning the Shared PC policy, or un-enrolling the device entirely, leaves Shared PC behavior in place.
Why: The SharedPC CSP's registry writes survive policy removal. This is not a sync delay, it is permanent.
Fix: Treat removal as a first-class scripted procedure rather than an un-assignment. Teardown and restore scripts are provided.
An Intune Device Control "Excluded Devices" entry opens removable media to every user
You see: A removable-media exclusion intended for one user grants access to all users.
Why: An entry's Sid scopes the action it is attached to, so a Deny entry carrying a Sid denies that user only. Excluded Devices carries no such scoping.
Fix: Use the two-rule Block-then-Allow pattern rather than exclusions.
Found something that belongs here, or something that has since changed? Securing GCC High is versioned monthly and corrections are welcome. The full book is free at docs.mindline.com.
📩 Don't Miss the Next Solution
Join the list to see the real-time solutions I'm delivering to my GCC High clients.