Helpdesk: "Jordan can't sign in to LAPTOP-07 this morning. Domain credentials fail with 'The trust relationship between this workstation and the primary domain failed.' Local admin still works. IT restored the VM from a Friday snapshot over the weekend because a patch failed. Same error on two cloned lab PCs that share a name with production. Can you just rejoin them to the domain?"
Don't rejoin yet. "Trust relationship between this workstation and the primary domain failed" is rarely a random Windows glitch. It's usually one layer in a documented chain: the computer's secure channel with Active Directory is broken because the machine account password on the device and in AD no longer match → you can still reach a domain controller, or you can't (DNS, firewall, wrong LOGONSERVER) → Event 3210 from NETLOGON, Test-ComputerSecureChannel returning $false, and nltest /sc_query with ERROR_ACCESS_DENIED confirm the channel is the problem → comparing AD pwdLastSet (PasswordLastSet) with the local LSA CupdTime tells you which side is newer → AD newer than the client points at a snapshot, bare-metal restore, system restore, unexpected shutdown, or VDI/image rollback → client newer than AD points at replication lag, a DC restored from backup, or an authoritative restore of the computer object – fix AD first → a duplicate computer name or a disabled machine-password rotation policy can keep breaking the channel after you repair it. Test-ComputerSecureChannel, nltest /sc_query, Event 3210, Get-ADComputer ... PasswordLastSet, and the CupdTime registry value are the sources for that chain. Rejoining clears the symptom. It doesn't explain why the passwords diverged, which is why the same machine fails again after the next restore or clone.
If Group Policy never reaches the machine after it joins, start with Group Policy Not Applying. If a user password change never reaches AD or the cloud still accepts the old password, use Entra Connect Password Writeback Not Working or Entra Connect Password Hash Sync Not Working. This post covers "a domain-joined Windows workstation or member server shows 'The trust relationship between this workstation and the primary domain failed,' local or cached sign-in still works, and you need a read-first path to the secure channel and machine password before you repair, reset, or rejoin."
TL;DR
- The error means the secure channel is broken. Microsoft's Azure VM article says the machine can't establish secure communication with a domain controller because the secret password isn't the same value in the domain controller.
-
Confirm with three reads.
Test-ComputerSecureChannel(members only – false positives on DCs),nltest /sc_query:domainreturning Status = 5ERROR_ACCESS_DENIED, and System Event 3210 from NETLOGON. -
Compare timestamps, don't guess. AD
pwdLastSet(Get-ADComputer -Properties PasswordLastSet) versus the local LSACupdTimeunderHKLM\SECURITY\Policy\Secrets\$MACHINE.ACC\CupdTime. Which side is newer picks the scenario article. - AD newer than the client usually means a VM snapshot, bare-metal restore, system restore, unexpected shutdown, or a non-persistent VDI/image rollback on the device.
- Client newer than AD usually means AD replication problems, a domain controller recovered from backup, or an authoritative restore of the computer object – fix Active Directory first, then repair the channel.
-
Repair before rejoin. Microsoft's order:
Test-ComputerSecureChannel -Repair, thenReset-ComputerMachinePassword/nltest /sc_reset, and only then remove and re-add the computer to the domain.
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Exact error text, local vs domain sign-in, recent restore/clone/rename, one machine or many | "Can't log on" with no error text or restore history |
| 2. Reach a DC | DNS resolves a DC; LOGONSERVER is set; ICMP/RPC path works; ComputerName registry matches the short name |
Channel "broken" but the real problem is DNS or firewall |
| 3. Channel confirmed broken |
Test-ComputerSecureChannel is $false; nltest /sc_query is ACCESS_DENIED; Event 3210 present |
Skipping straight to rejoin with no confirmation |
| 4. Password timestamps | You've compared AD PasswordLastSet with local CupdTime (and Event 5823 if present) |
Repairing blindly when AD metadata disagrees across DCs |
| 5. AD newer causes | Snapshot, restore, system restore, dirty shutdown, VDI/image explained | Same VM fails every time someone reverts a checkpoint |
| 6. Client newer causes | Replication / DC restore / authoritative computer-object restore fixed on the AD side first | Repairing the client while a restored DC keeps rewriting an old password |
| 7. Duplicate name or policy | No second computer with the same name; machine password age not disabled domain-wide | Repair works for a day, then breaks again after imaging |
| 8. Change | Only after Steps 1–7 agree: Repair → reset password → rejoin last | Rejoined five times, still failing after the next snapshot |
Step 1: Capture the exact symptom (read-only)
Write these facts on the ticket before anyone removes the computer from the domain:
| Fact | Why it matters |
|---|---|
| Exact error text | "The trust relationship between this workstation and the primary domain failed" is the secure-channel message Microsoft documents. A wrong password, disabled account, or "no logon servers" is a different path |
| Domain sign-in fails; local or cached credentials work | Microsoft's broken-trust article lists exactly this pattern. If local admin also fails, you have a different problem (and no easy console for the reads below) |
| Computer name and OU | You'll query Get-ADComputer and repadmin /showobjmeta against that object |
| Recent snapshot, backup restore, system restore, or clone | Those are Microsoft's top causes when AD's password is newer than the client's |
| Long offline period or pre-built / shipped image | Machine account password age defaults to about 30 days; a laptop in a closet can diverge when it comes back |
| One machine or many | Many at once after a DC restore points at Step 6. Many clones with the same name point at Step 7 |
| Is it a domain controller? |
Test-ComputerSecureChannel is for domain members only. On DCs, Microsoft says use netdom or nltest
|
Then match the symptom:
| What you see | Likely layer |
|---|---|
| Error after a VM checkpoint / snapshot revert | AD newer than client (Step 5) |
| Error after bare-metal or image restore | AD newer than client (Step 5) |
| Error after a DC was restored from backup | Client newer than AD (Step 6) |
nltest /sc_query ACCESS_DENIED + Event 3210 |
Channel confirmed (Step 3) |
| Same name on two machines; Event 3210 mentions another computer using the same name | Duplicate name (Step 7) |
| Machine was offline for months, then fails on first domain sign-in | Password age / offline (Steps 4 and 7) |
| Can't resolve or reach any DC | Connectivity first (Step 2) – not a password mismatch yet |
Step 2: Can this machine reach a domain controller? (read-only)
A broken secure channel assumes the machine can talk to a DC. Microsoft's Azure troubleshooting starts with connectivity before the channel test.
# Read-only. Run on the affected member (local admin session)
$env:LOGONSERVER
Test-Connection -ComputerName ($env:LOGONSERVER -replace '^\\\\','') -Count 2
Resolve-DnsName -Name $env:USERDNSDOMAIN -Type SRV -ErrorAction SilentlyContinue |
Select-Object -First 5 Name, Type, NameTarget
Also confirm the short computer name Microsoft calls out in the broken-trust article. The registry values should hold the actual computer name, not the FQDN:
Reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName /v ComputerName
Reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters /v hostname
| Read | Healthy signal | If it fails |
|---|---|---|
LOGONSERVER |
A DC name (for example \\DC01) |
DNS or site coverage – fix name resolution before repairing the channel |
Test-Connection to that DC |
Replies | Firewall, routing, or the DC is down |
| ComputerName / hostname | Match the short NetBIOS name you expect | Rename leftovers after a clone; Microsoft lists this under "Other considerations" |
| SRV records for the domain |
_ldap._tcp... targets exist |
Domain DNS zone / client DNS suffix problems |
If the machine can't reach any DC, stop. Repairing the secure channel against a DC you can't contact won't help. Come back to Step 3 once connectivity is honest.
Step 3: Confirm the secure channel is broken (read-only)
Microsoft's member-server path is explicit: test the channel, then repair only if it isn't healthy.
# Read-only on a domain member. Requires an elevated PowerShell session on Vista and later
Test-ComputerSecureChannel -Verbose
$true with a verbose line that the channel is alive means the trust error may already be cleared, or you're looking at a different failure (credential, time skew elsewhere, or a transient DC). $false means the channel failed the test.
Cross-check with nltest. Microsoft's symptom sample when the channel is broken:
nltest /sc_query:contoso.com
Expected when broken (Microsoft's sample):
Flags: 0
Trusted DC Name
Trusted DC Connection Status Status = 5 0x5 ERROR_ACCESS_DENIED
The command completed successfully
And read System Event 3210 from NETLOGON. Microsoft's description says the computer could not authenticate with a DC, and the inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized.
If Netlogon debug logging is already on, Microsoft's sample shows lines like cannot I_NetServerAuthenticate 0xc0000022 and new password is bad, try old one before Event 3210 is written. Don't turn logging on yet – that's a change. Read what's already there.
Domain controllers: Microsoft's Test-ComputerSecureChannel notes say the cmdlet only works on domain member computers. On DCs it returns false-positive errors; verify and reset DC secure channels with netdom.exe or nltest.exe instead.
What "healthy" looks like on nltest
When the channel is working, nltest /sc_query:domain typically shows a trusted DC name and a success status (NERR_Success / 0x0), not ERROR_ACCESS_DENIED. Microsoft's Defender for Identity posture guidance uses nltest /SC_VERIFY:DomainName the same way when checking that a domain controller's computer password is in sync. Use verify/query as the read; use /sc_reset only in Step 8.
If Test-ComputerSecureChannel -Verbose says the channel is alive but domain sign-in still fails, step off this article's main path: you may be looking at a user lockout, a disabled computer object, time skew large enough to break Kerberos, or a Conditional Access / credential issue that only looks like trust. Re-read the exact error on the sign-in UI before you reset the machine password.
Step 4: Which password is newer – AD or the client? (read-only)
This is the branch Microsoft's secure-channel series is built around. Compare:
-
Active Directory
pwdLastSet– last time AD believes the computer password changed (PasswordLastSetin PowerShell). -
Local LSA
CupdTime– last time the client believes it updated the machine password secret ($MACHINE.ACC).
AD side
# Read-only. ActiveDirectory module (RSAT). Run from a working admin workstation
Get-ADComputer -Identity 'LAPTOP-07' -Properties PasswordLastSet, Enabled, DistinguishedName |
Format-List Name, Enabled, PasswordLastSet, DistinguishedName
For consistency across DCs, Microsoft also shows:
repadmin /showobjmeta * "CN=LAPTOP-07,OU=Computers,DC=contoso,DC=com" > C:\temp\LAPTOP-07_Metadata.txt
Open the file and compare pwdLastSet metadata from every DC. In a healthy domain the values agree. Divergence is a Step 6 problem.
Client side (CupdTime)
Microsoft's data-collection article: by default only SYSTEM can read HKLM\SECURITY. Use PsExec in the System context, or temporarily grant yourself rights and remove them when finished.
reg query "HKLM\SECURITY\Policy\Secrets\$MACHINE.ACC\CupdTime"
You get a hex value such as 26A38C1AA0F4DA01. Microsoft's conversion: reverse each byte pair (01DAF4A01A8CA326), convert hex to decimal, then:
w32tm /ntte 133688107438220070
The output is a readable local time you can compare with PasswordLastSet.
Optional: Event 5823
On the client, System Event 5823 from NETLOGON ("The system successfully changed its password on the domain controller ...") is Microsoft's reference for the last successful machine password change, if it hasn't scrolled out of the log. Netlogon logging, when enabled, shows NlChangePassword: Successful response from DC and a scavenger interval that matches Maximum machine account password age.
Reading the compare without over-trusting one DC
Get-ADComputer ... PasswordLastSet reflects whichever DC answered your query (or the one you pinned with -Server). Microsoft's data-collection article pushes repadmin /showobjmeta * on the computer object's DN so you see pwdLastSet from every DC. If half your DCs show Tuesday and half show last month, you do not have a single "AD timestamp" yet – you have a replication problem that Step 6 owns. Repairing the client against the "new" DC while a lagging DC still holds the old secret is how trust breaks again after the next DC locator pick.
Event 5823 on the client (successful machine password change) is optional evidence, not required. Logs wrap. Missing 5823 does not mean the password never changed; it means you need CupdTime and AD metadata instead.
| Comparison | Scenario Microsoft documents | Next step |
|---|---|---|
AD pwdLastSet newer than client CupdTime |
Client rolled back (snapshot, restore, VDI) | Step 5, then repair |
Client CupdTime newer than AD pwdLastSet |
AD side is stale (replication, DC restore, authoritative restore) | Step 6 first – fix AD, then repair |
| Timestamps match but channel still fails | Duplicate name, connectivity, or a DC you aren't reading | Steps 2 and 7 |
| Computer object missing or disabled | Object deleted, recycled, or disabled after a reimage | Recreate/enable carefully – often ends at rejoin |
Step 5: When Active Directory is newer than the client (read-only causes)
Microsoft's "AD has a newer password value than client device" article lists the usual reasons the client fell behind:
| Cause | What to look for (read-only) |
|---|---|
| VM reverted to an old snapshot / checkpoint | Time jumps in the System log (for example months of silence on a machine that should be busy). Event ID 12 (Kernel-General) for a recent OS start. Short uptime that the user didn't request |
| Bare-metal or full-machine backup restore | Backup product logs; same time-jump pattern and recent uptime |
| System restore to an earlier restore point | System Event 1208 (StartupRepair: restored to an earlier restore point) or Application Event 8202 (System Restore succeeded) |
| Unexpected shutdown / power loss after a password change | System Event 41 (Kernel-Power) or 6008 (unexpected shutdown). Microsoft notes Embedded / Regfdata cases where HKLM\SECURITY\Policy\Secrets\$MACHINE.ACC changes are lost |
| Non-persistent VDI / pooled desktop / golden image | Session ends → snapshot restore. Services that take a Netlogon dependency and interfere with secure-channel operations. Image brought online with obsolete secure-channel secrets versus AD |
Microsoft is clear: rejoining works, but if the failure is constant or repetitive, find the cause. A lab that reverts checkpoints every weekend will break trust every Monday until the snapshot process stops rolling the machine password backward – or until those VMs are excluded from domain password expectations the way Microsoft describes for pre-built / stored computers (a longer MaximumPasswordAge on a dedicated OU, used deliberately).
Step 6: When the client is newer than Active Directory (fix AD first)
Microsoft's "Client device has a newer password value than Active Directory" article flips the problem. Common causes:
| Cause | Why the client looks "ahead" |
|---|---|
| Active Directory replication issues | One DC has an old pwdLastSet; the client updated against another |
| A domain controller recovered from a backup | That DC reintroduces an older computer password |
| Authoritative restoration of the computer object | The restored object wins with a stale password |
Microsoft's resolution order here is important: resolve the AD-side problem first (replication health, DC health, network ports for AD). Data should be consistent across domain controllers. Only after AD agrees with itself do you reset the secure channel on the client (nltest /sc_reset:domain_name or Test-ComputerSecureChannel -Repair) and reboot.
# Read-only starting points on a working admin workstation
repadmin /replsummary
Get-ADDomainController -Filter * | Select-Object Name, Site, IsGlobalCatalog, OperatingSystem
Deep replication triage is its own topic. For this ticket, you need enough to know whether pwdLastSet matches on every DC for this computer. If it doesn't, repairing the laptop alone will fight the next DC that still holds the old secret.
Step 7: Duplicate names and machine-password policy (read-only)
Duplicate computer name
Event 3210's own text calls out another computer on the same network using the same name. Cloned VMs, imaged labs, and "I copied the VHD" desktops are the usual sources. Two machines authenticating as the same computer account will keep invalidating each other's secure channel.
# Read-only. From a working admin workstation
Get-ADComputer -Filter "Name -eq 'LAPTOP-07'" -Properties PasswordLastSet, Created, Modified, Enabled |
Format-List Name, Enabled, PasswordLastSet, Created, Modified, DistinguishedName
If you find unexpected duplicates (same name in different OUs, or a disabled leftover next to a live one), stop repairing until naming is unique. Repairing one clone while the other is still online just moves the break.
Machine account password age
By default, domain members automatically change their computer account password about every 30 days. Microsoft's policy reference Domain member: Maximum machine account password age (Security Options) documents that increasing the interval a lot, or setting it to 0 so computers no longer change passwords, gives an attacker more time for a brute-force guess against computer accounts. Microsoft often advises keeping it around 30 days. For pre-built machines that sit in storage or ship to remote sites, Microsoft suggests a dedicated OU with a longer age so stored computers don't expire before first use.
Related Netlogon parameters Microsoft documents:
| Setting | Default idea | Risk if mis-set |
|---|---|---|
| MaximumPasswordAge (Netlogon Parameters / GPO Maximum machine account password age) | 30 days | Too long or 0 → weaker computer-account hygiene; too aggressive for stored images without a special OU |
| DisablePasswordChange on the member | 0 (changes allowed) | Set to 1 → member stops sending automatic password changes |
| RefusePasswordChange on domain controllers | Not set | Set to 1 → DCs refuse workstation password changes (legacy guidance; can log Event 5722 if rolled out wrong) |
Read whether someone disabled rotation "to stop trust errors." That trades a recurring repair for a standing security exception. Microsoft's Defender for Identity posture guidance still expects DC computer passwords to rotate (DisablePasswordChange = 0 / absent, MaximumPasswordAge = 30) and suggests nltest /SC_VERIFY:DomainName showing NERR_Success.
Common false starts (read these before you rejoin)
| False start | Why it hurts | Read-first alternative |
|---|---|---|
| Rejoin as the first fix | Valid per Microsoft, but erases the evidence trail and often recreates a new computer object while an old one still fights clones | Confirm channel + timestamps; Repair → reset → rejoin last |
| Disabling machine password changes domain-wide | Microsoft warns this lengthens the brute-force window against computer accounts | Fix snapshot/clone process; optional longer age only on a pre-build OU |
Running Test-ComputerSecureChannel on a DC |
Cmdlet notes: false-positive errors on domain controllers |
nltest / netdom on DCs |
| Repairing while DNS is broken | -Repair needs a DC; Azure's flowchart checks connectivity first | Step 2 until LOGONSERVER and name resolution work |
| Resetting both clones "to be safe" | Two machines, one computer account – each reset invalidates the other | Rename or retire duplicates first (Step 7) |
| Ignoring a restored DC | Client-newer scenario says fix AD first |
repadmin / DC health before client repair |
Step 8: Change one layer, then watch (only after the read)
Pick the one change Steps 1–7 point at. Microsoft's Azure and secure-channel articles use this order:
- Connectivity and naming first (Step 2 / 7) if those failed.
- AD consistency first (Step 6) when the client is newer than AD.
- Repair the secure channel on the member:
- Reset the machine password if repair isn't enough.
- Remove and rejoin only as the last option.
- Reboot after a successful reset/repair when Microsoft's scenario article says to.
# Change (domain member, elevated). Prefer after Steps 1–7 agree
# 1) Repair the NetLogon channel
Test-ComputerSecureChannel -Repair -Credential (Get-Credential) -Verbose
# 2) If still broken, reset the machine account password (optionally pin a DC)
Reset-ComputerMachinePassword -Server 'DC01' -Credential (Get-Credential)
# Read-only confirm
Test-ComputerSecureChannel -Verbose
nltest /sc_query:contoso.com
Equivalent command-prompt reset Microsoft lists in the scenario articles:
nltest /sc_reset:contoso.com
Last resort – rejoin (Microsoft's Azure article):
# Change (last resort). Requires local admin + domain join rights
Remove-Computer -UnjoinDomainCredential (Get-Credential) -PassThru -Verbose -Restart
# After reboot, on a workgroup session:
Add-Computer -DomainName 'contoso.com' -Credential (Get-Credential) -Restart -Force
Watch one sign-in cycle: domain credentials succeed, Event 3210 stops, Test-ComputerSecureChannel returns $true, and – if this was a snapshot habit – the next checkpoint plan no longer rolls CupdTime backward while AD keeps the newer password.
On domain controllers, don't use Test-ComputerSecureChannel. Use nltest /sc_verify:domain / nltest /sc_reset:domain or netdom resetpwd patterns Microsoft documents for DC machine passwords, and treat parent/child secure-channel repairs as a DC operation with outage planning.
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
Channel $false, timestamps show AD newer after a snapshot |
Test-ComputerSecureChannel -Repair (then password reset), fix the snapshot habit |
Rejoining every Monday without changing the checkpoint process |
Client newer; pwdLastSet differs across DCs |
Fix replication / restored DC first, then repair the client | Repairing the laptop while a restored DC keeps serving the old secret |
| Duplicate computer name / cloned VHD | Rename or rebuild so only one object owns the name, then repair | Resetting the password on both clones in a loop |
| Stored / shipped image hits trust on first boot | Dedicated OU with a deliberate longer MaximumPasswordAge (Microsoft's pre-build guidance) | Setting MaximumPasswordAge to 0 domain-wide |
| Someone set DisablePasswordChange=1 "to stop trust errors" | Restore automatic rotation after fixing the real cause | Leaving computer passwords immortal |
| Trust error but no DC connectivity | Fix DNS / firewall / LOGONSERVER first | Running -Repair against a DC you can't reach |
| Domain controller secure channel |
nltest / netdom on the DC |
Test-ComputerSecureChannel on a DC (false positives) |
| One-off broken channel, timestamps agree after repair | Repair + reboot, document | Deleting and recreating the computer object as the first move |
FAQ
What does "The trust relationship between this workstation and the primary domain failed" mean?
The secure channel between the computer and Active Directory is broken. Microsoft's Azure article states the secret password isn't set to the same value in the domain controller, so the machine can't establish secure communication with a DC. Local or cached sign-in can still work.
How do I fix a broken trust relationship without rejoining the domain?
On a domain member, Microsoft's order is: confirm with Test-ComputerSecureChannel, repair with Test-ComputerSecureChannel -Repair, and if needed reset with Reset-ComputerMachinePassword or nltest /sc_reset:domain_name, then reboot. Rejoin (Remove-Computer / Add-Computer) is the last option in Microsoft's Azure flowchart.
Why does the trust relationship fail after a VM snapshot or restore?
Reverting a snapshot (or restoring bare metal / system restore / non-persistent VDI) rolls the local machine password secret backward while Active Directory still has the newer password. Microsoft's "AD has a newer password value than client device" article lists those causes. Repair the channel after the restore, and stop leaving domain-joined disks on checkpoints that predate the last password change.
What is Event ID 3210?
A System log error from NETLOGON: this computer could not authenticate with a domain controller. Microsoft's text says it might be another computer using the same name, or the password for this computer account is not recognized. Pair it with nltest /sc_query and the password-timestamp compare.
Should I disable machine account password changes to prevent trust failures?
Not as a general fix. Microsoft warns that increasing MaximumPasswordAge a lot or setting it to 0 (or DisablePasswordChange=1) gives attackers more time against computer accounts. Use a dedicated OU with a longer age only for deliberate pre-build / storage scenarios, and keep normal members on the ~30-day default unless a security owner documents an exception.
Related posts
- Group Policy Not Applying (when the machine joins cleanly but policy scope, filtering, or replication is the next failure)
- Entra Connect Password Hash Sync Not Working (user password sync to the cloud – different from the computer account secure channel)
- Entra Connect Password Writeback Not Working (SSPR writeback to AD – different from machine password rotation)
Free checklist
A broken trust relationship is often the first visible sign that a cloned, restored, or long-offline machine is out of sync with AD, and that's the afternoon someone wants to rush "require hybrid join" or "require compliant device" into Conditional Access for everyone. Before you enforce, the free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=trust-relationship-workstation-primary-domain-failed
Admin Pack Studio; not affiliated with Microsoft. Steps 1–7 favor read-only checks: Test-ComputerSecureChannel, nltest /sc_query, Event 3210 / 5823 / 12 / 41 / 6008 / 1208 / 8202, Get-ADComputer, repadmin /showobjmeta, repadmin /replsummary, reg query of ComputerName and (via SYSTEM) CupdTime, w32tm /ntte, and DNS / LOGONSERVER connectivity. Repairing or resetting the secure channel, resetting the machine password, changing MaximumPasswordAge / DisablePasswordChange / RefusePasswordChange, renaming computers, and removing/rejoining the domain are deliberate changes. Change one layer at a time, watch one sign-in cycle, and check current Microsoft Learn for policy values and console labels.
Top comments (0)