Ask the Directory Services Team articles

The End is Nigh for DES and an Update for hunting down RC4

Chris_Cartwright — Fri, 08 May 2026 15:45:53 GMT

Note: 3/5/2026 The Event Forwarding methods mentioned here is not yet compatible with Server 2025. This post will be updated when it is no longer the case. This blog was originally posted last year, but got "lost." It has been updated a little to reflect recent events and will likely have some overlap.

Hello again all, Chris Cartwright here from the Directory Services support team. We released the plan to remove DES as an encryption type for Kerberos completely. We also released identification scripts to assist with this at microsoft/Kerberos-Crypto: Tools and information regarding Windows Kerberos cryptography. We have also released Beyond RC4 for Windows authentication | Microsoft Windows Server Blog and then the first patching efforts in support of RC4 deprecation in How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 - Microsoft Support.

I wanted to provide a brief update for XML filtering that was illustrated in the previous blog post, So, you think you’re ready for enforcing AES for Kerberos?. I will reference this blog post quite a bit. While I don’t expect readers of this blog to be using DES, I still wanted to make sure that the information was out there. Additionally, the Events 4768 and 4769 have been updated with additional information when issuing tickets. The XML here is also modified to support that.

XML Filters

Here are the XML filters you can leverage to find specific events.

Hunting down DES tickets issued

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[EventData[Data[@Name='TicketEncryptionType']='0x1']]
</Select>
  </Query>
  <Query Id="1" Path="Security">
    <Select Path="Security">
*[EventData[Data[@Name='TicketEncryptionType']='0x2']]
</Select>
  </Query>
  <Query Id="2" Path="Security">
    <Select Path="Security">
*[EventData[Data[@Name='TicketEncryptionType']='0x3']]
</Select>
  </Query>
</QueryList>

Hunting down only legacy keys available:

There will be more information on this in a later blog post.

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[EventData[Data[@Name='AccountAvailableKeys']='RC4, DES']]
</Select>
  </Query>
  <Query Id="1" Path="Security">
    <Select Path="Security">
*[EventData[Data[@Name='ServiceAvailableKeys']='RC4, DES']]
</Select>
  </Query>
  <Query Id="3" Path="Security">
    <Select Path="Security">
*[EventData[Data[@Name='DCAvailableKeys']='RC4, DES']]
</Select>
  </Query>
  <Query Id="4" Path="Security">
    <Select Path="Security">
*[EventData[Data[@Name='AccountAvailableKeys']='RC4']]
</Select>
  </Query>
  <Query Id="5" Path="Security">
    <Select Path="Security">
*[EventData[Data[@Name='ServiceAvailableKeys']='RC4']]
</Select>
  </Query>
  <Query Id="6" Path="Security">
    <Select Path="Security">
*[EventData[Data[@Name='DCAvailableKeys']='RC4']]
</Select>
  </Query>
</QueryList>

Hunting down RC4 Tickets issued:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[EventData[
        Data[@Name='TicketEncryptionType']='0x17' or
        Data[@Name='SessionKeyEncryptionType']='0x17'
      ]]
    </Select>
  </Query>
</QueryList>

Custom Event Forwarder targets

If you choose to, you can leverage this XML file (or create your own) for Event forwarding described in the previous blog and get this for targets:

Manifest text

<?xml version="1.0"?>
<instrumentationManifest xsi:schemaLocation="http://schemas.microsoft.com/win/2004/08/events eventman.xsd" xmlns="http://schemas.microsoft.com/win/2004/08/events" xmlns:win="http://manifests.microsoft.com/win/2004/08/windows/events" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:trace="http://schemas.microsoft.com/win/2004/08/events/trace">
              <instrumentation>
                           <events>
                                         <provider name="WEC-Legacy Hunter" guid="{8D8635E8-3573-49B6-A5CE-A91601E1B5D9}" symbol="EvtFwdLegHunt" resourceFileName="C:\Windows\system32\Legacy-Hunter-WEC.dll" messageFileName="C:\Windows\system32\Legacy-Hunter-WEC.dll">
                                                       <channels>
                                                                     <channel name="RC4 Keys Only" chid="RC4 Keys Only" symbol="RC4KeysOnly" type="Operational" enabled="true" message="$(string.WEC-Legacy-Hunter.channel.RC4KeysOnly.message)"></channel>
                                                                     <channel name="RC4 Used" chid="RC4 Used" symbol="RC4Used" type="Operational" enabled="true" message="$(string.WEC-Legacy-Hunter.channel.RC4Used.message)"></channel>
                                                                     <channel name="DES Used" chid="DES Used" symbol="DESUsed" type="Operational" enabled="true" message="$(string.WEC-Legacy-Hunter.channel.DESUsed.message)"></channel>
                                                       </channels>
                                         </provider>
                           </events>
              </instrumentation>
              <localization>
                           <resources culture="en-US">
                                         <stringTable>
                                                       <string id="WEC-Legacy-Hunter.channel.RC4Used.message" value="RC4 Ticket issued"></string>
                                                       <string id="WEC-Legacy-Hunter.channel.RC4KeysOnly.message" value="RC4 Keys Only"></string>
                                                       <string id="WEC-Legacy-Hunter.channel.DESUsed.message" value="DES Ticket issued"></string>
                                         </stringTable>
                           </resources>
              </localization>
</instrumentationManifest>

Visual Studio

Previous steps for configuring Visual Studio are in the previous blog post referred to earlier. In order to get the WEC-Legacy-Hunter event logs as shown above, create a New Windows Desktop Wizard Project

Click Create, and choose Dynamic Link Library as Application type. Make sure Empty Project is checked.

Right click on the right side and choose Add Existing Item

Select the .rc and .h files.

You should see the files showing in the project as shown below:

On the top Menu bar, select Project->Properties, and set /NOENTRY under Linker\Advanced.

Then, in the top Menu bar, click Build->Build Solution. In your project folder, there will be a dll file under .\x64\Debug.

You can leverage the steps from the previous blog to install the manifest and point each subscription to the intended destination event log like so:

See previous blog for more details on configuring Event Forwarding.

Once again, good hunting!

Troubleshooting TPM Certificate: How to Fix the "Missing Stored Keyset" Error

mdhabibnawaz — Thu, 30 Apr 2026 15:18:25 GMT

Understanding the "Missing Stored Keyset" Error

The "missing stored keyset" error typically appears when an application or service cannot find a necessary key within the system's Key Storage Provider (KSP). This can result from various underlying causes, including corrupted registry keys, improper configurations, or expired certificates. Below are some potential causes of this error:

Corrupted Registry Entries: Sometimes, entries related to certificate keys might become corrupt, causing access issues.

Permissions Issues: Inadequate permissions can prevent the necessary access to retrieve or manage keys.

Software Bugs or Misconfiguration: System or application-specific bugs or incorrect configurations might cause improper handling of the TPM-stored certificates.

Step-by-Step Guide to Fix "Missing Stored Keyset"

Here's a troubleshooting process to resolve this error. Ensure you have administrative privileges on the system.

Step 1: Windows Update and TPM Firmware

Ensure Latest Windows Updates:

Access Settings by pressing Windows Key + I and click Update & Security.

Ensure the system is up to date as newer patches often resolve TPM issues.

Firmware Update:

Check the manufacturer’s site for the latest TPM firmware and BIOS updates specific to your model, especially for addressing known issues and bugs.

Step 2: Verify TPM Initialization and Ownership

Before diving deeper, ensure that the TPM is initialized, and the system has clear ownership of it:

Open the TPM Management Console by typing tpm.msc in the Run dialog.

Verify that the status states: "The TPM is ready for use."

Step 3: Verify Certificate Keysets or Store

To verify the Platform cryptographic provider certificate using cmd.exe, use the following steps:

Open cmd.exe as Administrator.

Run the command: CertUtil -CSP "Microsoft Platform Crypto Provider" -Key

To verify the local machine certificate using cmd, use the following steps:

Open Cmd as Administrator.

Execute the command: CertUtil -v -VerifyStore MY

Step 4: Repair Certificate Keysets

If registry or keyset corruption is suspected, follow these steps:

Open Cmd as Administrator.

Execute the command: CertUtil -RepairStore MY "SerialNumber"

Step 5: Check and Reset Permissions

Correct any permissions related problems:

Open the Certificates MMC Snap-in for the local computer (certlm.msc).

Locate the specific certificate.

Right-click and select All Tasks > Manage Private Keys.

Ensure that necessary accounts (such as SYSTEM, Service or application account, and the user account) have Full Control.

Step 6: Re-enroll Certificates if Necessary

Certificate reports “Missing stored Keyset”

CertUtil RepairStore command fails.

If reports for "Missing stored keyset" persist and repair fails, certificates may need to be restored or re-enrolled:

Request and issue new certificates using your organizational procedures.

Conclusion

Encountering a "missing stored keyset" error with a TPM can be frustrating but can usually be resolved with a methodical approach. By ensuring that the TPM is functional, managing security permissions correctly, checking certificate validity, and keeping systems up to date, this issue can be mitigated. If these steps do not resolve the problem, reaching out to Microsoft Support or consulting the device manufacturer's guidelines may provide additional assistance. For more detailed documentation on troubleshooting TPM errors, please visit Microsoft’s official TPM Technology Documentation. Trusted Platform Module Technology Overview | Microsoft Learn

Remember, always ensure a data backup strategy when dealing with cryptographic components to avoid unexpected data loss. These steps can help guide you through fixing the “missing stored keyset” error for TPM certificates effectively. As always, stay informed and backed up. Proper understanding and manipulation of TPM can bolster the security and trustworthiness of your systems. Keep striving for a more secure enterprise environment, and feel free to comment below if you have additional questions or suggestions from your experiences. Until next time, happy troubleshooting!

So, You’ve disabled Windows Hello for Business, but the User can still Sign-in using a PIN

BrentCrummey — Mon, 27 Apr 2026 22:14:57 GMT

Hi, it’s Brent from the Windows Directory Services team. I recently worked a case concerning a user who had the Windows Hello for Business (“WHfB”) policy disabled, but the user could still sign-in to the computer using their PIN. As you may have guessed, the Windows admin team of the Active Directory domain for this user wanted to know how this could be and how they could remove this sign-in option from the user.

Let’s Talk About the Problem

The user retaining the ability to sign-in using their PIN wasn’t the only issue the admin team encountered. After requesting the user to remove the WHfB PIN sign-in, they discovered the option to remove the Windows Hello PIN sign-in was greyed out:

Now, it seemed there wasn’t a way to remove the user’s ability to sign-in with their WHfB PIN.

How Did We Get Here?

A Microsoft Intune policy or Windows Active Directory Group Policy Object (“GPO”) was originally enabled for this user to provision Windows Hello for Business sign-in. Sometime after the user was provisioned and using their PIN to sign-in, the Windows admin team determined this user should no longer use WHfB credentials. To remove the user’s ability to do so, they configured the Intune and/or GPO policy to disable Windows Hello for Business. After refreshing the policy to the user’s computer successfully, they confirmed the PassportforWork registry key was set to disabled as follows:

HKLM\SOFTWARE\Policies\Microsoft\PassportForWork

Enabled REG_DWORD 0x0

The actions performed above will not remove the ability of an already provisioned user from using Windows Hello for Business PIN to sign-in to the Windows computer. To better understand the issue, the following details are provided to clarify the use of policies such as Intune and GPOs in relation to the Windows Hello for Business credential provider.

When either an Intune policy or Windows GPO is configured for a user to enable WHfB, the policy is only enabling the user to enroll for provisioning to use Windows Hello for Business. The provisioning process and authentication process for Windows Hello for Business are two separate components within the Windows Hello for Business feature.

Since the policy only enables the ability for a user to activate the provisioning process to enroll for Windows Hello for Business, the policy becomes irrelevant after the user successfully provisions. Once a user is provisioned, they will be able to continue using the Windows Hello for Business PIN sign-in even when the policy has been set to disabled.

This behavior is expected and by design, which is documented in the following published article: Manage Windows Hello in your organization - Windows Security | Microsoft Learn

However, by setting the policy to disabled, the user no longer has the ability to activate the provisioning process. The remove button under the Windows Hello PIN sign-in option is used to activate provisioning, which would allow the user to un-enroll for Windows Hello for Business. Therefore, the inability to select the remove button is also expected and by design in this configuration.

How will the PIN Sign-in be Removed if Provisioning is Disabled?

To disable Windows Hello for Business in this situation, the Windows Hello container will need to be deleted for the user. To do so, the user will perform the following steps under their user context on each Windows computer they were successfully provisioned prior to the policy being disabled:

Have the user sign-in to the Windows computer using their username and password.
Open a command prompt under the user’s context (not admin) and run the following command:

certutil.exe -deleteHelloContainer

Close the command prompt and restart the computer.

With the policy set to disabled, the user will no longer be able to activate the provisioning process on this or any other Windows computer going forward. We wouldn’t want the user to enroll for Windows Hello for Business again after we removed it, right?

I hope you found this information helpful in your understanding of Windows Hello for Business administration. Until next time.

Brent Crummey

Related Registry Keys

Computer registry - HKLM\SOFTWARE\Policies\Microsoft\PassportForWork

User registry - HKCU\SOFTWARE\Policies\Microsoft\PassportForWork

References

Windows Hello for Business Frequently Asked Questions (FAQ) - Windows Security | Microsoft Learn

certutil | Microsoft Learn

Assigning Process Accountability to Group Policy Refreshes

itaysarig — Mon, 09 Mar 2026 15:20:17 GMT

Hey All,

Gaurav and Itay here with some updates to the Group Policy Service debug logging.

What if you one day noticed that you had machines excessively reprocessing group policy? For a long time, GPSVC logging told you that a GP Refresh happened… but to many admins it was not clear why, not by whom, and not what process triggered it. Today we're going to talk about an update that addresses exactly that.

We are adding several pieces of attribution data that make the logs dramatically more useful:

Full Timestamps (now prints the date as well)
Trigger Type (Command Line, API, etc.)
Parent Process Path + PID
GPUpdate PID (PID of GPUpdate.exe)
Session ID
User Account Context

This behavior currently applies to Windows 11 versions 24H2 and 25H2, starting with the February 2026 preview updates or later.

Note: When the Server operating system update becomes available, we will update this article accordingly.

Next, let's go through some scenarios with examples!

Scenario 1: Manual Group Policy Refresh
Scenario 2: Background (Periodic) Group Policy Refresh
Scenario 3: Programmatic Group Policy Refresh via the GP API
Scenario 4: Scheduled Task / Remote GP Refresh (GPMC) / PowerShell 'Invoke-GPUpdate'
Scenario 5: Audit Policy modifications via SecPol

Scenario 1: Manual Group Policy Refresh

In this scenario, someone has run gpupdate from command line or Run.

Current Logging

GPSVC.LOG:

GPSVC(3650.36a0) 2026-01-01 07:01:02:493 RefreshPolicyForPrincipal: Entering with bMachine = 1, SID = null, options: 1, dwTimeout = 600000, currentProcessId = 13904, processImageName = C:\Windows\System32\gpupdate.exe
GPSVC(377c.29f8) 2026-01-01 07:01:02:495 Server_ProcessRefresh:: bMachine = 1, SID = null, bForceRefresh = 1, bRefreshAllUsers = 0, dwTimeout = 600000
GPSVC(377c.29f8) 2026-01-01 07:01:02:501 CGPApplicationService::RefreshEvent fired.
GPSVC(377c.29f8) 2026-01-01 07:01:02:501 CGPApplicationService::RefreshEvent for Machine.
GPSVC(377c.29f8) 2026-01-01 07:01:02:501 CGPApplicationService::RefreshEvent Force Refresh = 1.
GPSVC(377c.29f8) 2026-01-01 07:01:02:503 CGPApplicationService::RefreshEvent Refresh all users = 0.
GPSVC(377c.29f8) 2026-01-01 07:01:02:503 CGPApplicationService::RefreshEvent Timeout = 600000.
GPSVC(377c.29f8) 2026-01-01 07:01:02:503 User SID = <S-1-5-21-869282409-3425305577-2907120315-7716>

Microsoft-Windows-GroupPolicy/OperationalLog:

Log Name:      Microsoft-Windows-GroupPolicy/Operational
Source:        Microsoft-Windows-GroupPolicy
Date:          1/1/2026 7:01:02 AM
Event ID:      4004
Task Category: None
Level:         Information
Keywords:     
User:          SYSTEM
Computer:      CONT-WIN11-1.CONTOSO.local
Description:
Starting manual processing of policy for computer CONTOSO\CONT-WIN11-1$.

New Logging

GPSVC.LOG:

GPSVC(1690.820) 2026-01-01 07:02:23:286 RefreshPolicyForPrincipal: Entering with bMachine = 1, SID = null, options: 1, dwTimeout = 600000, currentProcessId = 5776, processImageName = C:\Windows\System32\gpupdate.exe
GPSVC(214c.2550) 2026-01-01 07:02:23:286 Server_ProcessRefresh:: bMachine = 1, SID = null, bForceRefresh = 1, bRefreshAllUsers = 0, dwTimeout = 600000
GPSVC(214c.2550) 2026-01-01 07:02:23:296 GP Refresh Attribution: Target=Machine ParentProcess="C:\Windows\System32\cmd.exe" ParentPID=2832 GPUpdatePID=5776 SessionID=2 Account="CONTOSO\Admin1"
GPSVC(214c.2550) 2026-01-01 07:02:23:296 CGPApplicationService::RefreshEvent fired.
GPSVC(214c.2550) 2026-01-01 07:02:23:296 CGPApplicationService::RefreshEvent for Machine.
GPSVC(214c.2550) 2026-01-01 07:02:23:296 CGPApplicationService::RefreshEvent Force Refresh = 1.
GPSVC(214c.2550) 2026-01-01 07:02:23:296 CGPApplicationService::RefreshEvent Refresh all users = 0.
GPSVC(214c.2550) 2026-01-01 07:02:23:296 CGPApplicationService::RefreshEvent Timeout = 600000.
GPSVC(214c.2550) 2026-01-01 07:02:23:296 User SID = <S-1-5-21-869282409-3425305577-2907120315-7716>

We now have a new GP Operational (Microsoft-Windows-GroupPolicy provider) event that logs the caller attribution data regardless of whether the debug logging is enabled or not. This is logged in combination with the pre-existing Event ID 4004 event:

Microsoft-Windows-GroupPolicy/OperationalLog:

Log Name:      Microsoft-Windows-GroupPolicy/Operational
Source:        Microsoft-Windows-GroupPolicy
Date:          1/1/2026 7:02:23 AM
Event ID:      5321
Task Category: None
Level:         Information
Keywords:     
User:          SYSTEM
Computer:      CONT-WIN11-2.CONTOSO.local
Description:
GP Refresh Attribution Parameter: Group Policy refresh. Target=Machine ParentProcess="C:\Windows\System32\cmd.exe" ParentPID=2832 GPUpdatePID=5776 SessionID=2 Account="CONTOSO\Admin1"

Log Name:      Microsoft-Windows-GroupPolicy/Operational
Source:        Microsoft-Windows-GroupPolicy
Date:          1/1/2026 7:02:23 AM
Event ID:      4004
Task Category: None
Level:         Information
Keywords:     
User:          SYSTEM
Computer:      CONT-WIN11-2.CONTOSO.local
Description:
Starting manual processing of policy for computer CONTOSO\CONT-WIN11-2$

Scenario 2: Background (Periodic) Group Policy Refresh

By default, the Group Policy engine periodically refreshes every 5 minutes on DCs and every 90-120 minutes on everything else. This is an example of one of those unattended refreshes. Gpupdate is also the responsible process here.

Current Logging

GPSVC.LOG:

GPSVC(c6c.1f70) 2026-01-01 01:31:10:614 Server_ProcessRefresh:: bMachine = 1, SID = null, bForceRefresh = 0, bRefreshAllUsers = 0, dwTimeout = 600000
GPSVC(c6c.1f70) 2026-01-01 01:31:10:614 CGPApplicationService::RefreshEvent fired.
GPSVC(c6c.1f70) 2026-01-01 01:31:10:614 CGPApplicationService::RefreshEvent for Machine.
GPSVC(c6c.1f70) 2026-01-01 01:31:10:614 CGPApplicationService::RefreshEvent Force Refresh = 0.
GPSVC(c6c.1f70) 2026-01-01 01:31:10:614 CGPApplicationService::RefreshEvent Refresh all users = 0.
GPSVC(c6c.1f70) 2026-01-01 01:31:10:618 CGPApplicationService::RefreshEvent Timeout = 600000.
GPSVC(c6c.1f70) 2026-01-01 01:31:10:618 User SID = <S-1-5-20>

New Logging

GPSVC.LOG:

GPSVC(1aa0.1a44) 2026-01-01 00:34:59:855 Server_ProcessRefresh:: bMachine = 1, SID = null, bForceRefresh = 0, bRefreshAllUsers = 0, dwTimeout = 600000
GPSVC(1aa0.1a44) 2026-01-01 00:34:59:866 GP Refresh Attribution: Target=Machine ParentProcess="C:\Windows\System32\svchost.exe" ParentPID=1904 GPUpdatePID=8616 SessionID=0 Account="NT AUTHORITY\NETWORK SERVICE"
GPSVC(1aa0.1a44) 2026-01-01 00:34:59:867 CGPApplicationService::RefreshEvent fired.
GPSVC(1aa0.1a44) 2026-01-01 00:34:59:867 CGPApplicationService::RefreshEvent for Machine.
GPSVC(1aa0.1a44) 2026-01-01 00:34:59:867 CGPApplicationService::RefreshEvent Force Refresh = 0.
GPSVC(1aa0.1a44) 2026-01-01 00:34:59:867 CGPApplicationService::RefreshEvent Refresh all users = 0.
GPSVC(1aa0.1a44) 2026-01-01 00:34:59:867 CGPApplicationService::RefreshEvent Timeout = 600000.
GPSVC(1aa0.1a44) 2026-01-01 00:34:59:867 User SID = <S-1-5-20>

Background GP Refreshes leverage Scheduled Tasks to trigger the gpupdate.exe, so you can follow the steps in Scenario 4  to establish a correlation between the Task Scheduler and the GP refresh activity.

Scenario 3: Programmatic Group Policy Refresh via the GP API

This scenario covers applications that use APIs directly to cause refreshes to occur.

Current Logging

GPSVC.LOG:

GPSVC(2068.2348) 2026-01-01 14:39:51:302 RefreshPolicyForPrincipal: Entering with bMachine = 1, SID = null, options: 0, dwTimeout = 0, currentProcessId = 8296, processImageName = C:\Temp\gprefresh.exe
GPSVC(15d0.b30) 2026-01-01 14:39:51:304 Server_ProcessRefresh:: bMachine = 1, SID = null, bForceRefresh = 0, bRefreshAllUsers = 0, dwTimeout = 0
GPSVC(15d0.b30) 2026-01-01 14:39:51:304 CGPApplicationService::RefreshEvent fired.
GPSVC(15d0.b30) 2026-01-01 14:39:51:304 CGPApplicationService::RefreshEvent for Machine.
GPSVC(15d0.b30) 2026-01-01 14:39:51:304 CGPApplicationService::RefreshEvent Force Refresh = 0.
GPSVC(15d0.b30) 2026-01-01 14:39:51:304 CGPApplicationService::RefreshEvent Refresh all users = 0.
GPSVC(15d0.b30) 2026-01-01 14:39:51:304 CGPApplicationService::RefreshEvent Timeout = 0.
GPSVC(15d0.b30) 2026-01-01 14:39:51:304 User SID = <S-1-5-21-869282409-3425305577-2907120315-7716>

New Logging

GPSVC.LOG:

GPSVC(834.15e0) 2026-01-01 14:39:40:244 RefreshPolicyForPrincipal: Entering with bMachine = 1, SID = null, options: 0, dwTimeout = 0, currentProcessId = 2100, processImageName = C:\Temp\gprefresh.exe
GPSVC(26ac.874) 2026-01-01 14:39:40:244 Server_ProcessRefresh:: bMachine = 1, SID = null, bForceRefresh = 0, bRefreshAllUsers = 0, dwTimeout = 0
GPSVC(26ac.874) 2026-01-01 14:39:40:253 RPC Call Attribution: Target=Machine ParentProcess="C:\Windows\System32\cmd.exe" ParentPID=2328 RpcClient="C:\Temp\gprefresh.exe" RpcClientPID=2100 SessionID=2 Account="CONTOSO\Admin1"
GPSVC(26ac.874) 2026-01-01 14:39:40:253 CGPApplicationService::RefreshEvent fired.
GPSVC(26ac.874) 2026-01-01 14:39:40:253 CGPApplicationService::RefreshEvent for Machine.
GPSVC(26ac.874) 2026-01-01 14:39:40:253 CGPApplicationService::RefreshEvent Force Refresh = 0.
GPSVC(26ac.874) 2026-01-01 14:39:40:253 CGPApplicationService::RefreshEvent Refresh all users = 0.
GPSVC(26ac.874) 2026-01-01 14:39:40:253 CGPApplicationService::RefreshEvent Timeout = 0.
GPSVC(26ac.874) 2026-01-01 14:39:40:253 User SID = <S-1-5-21-869282409-3425305577-2907120315-7716>

Scenario 4: Scheduled Task / Remote GP Refresh (GPMC) / PowerShell 'Invoke-GPUpdate'

Remote GP Update through GPMC and Invoke-GPUpdate, both leverage Scheduled Tasks to trigger a policy refresh on the target machine(s).

Current Logging

GPSVC.LOG:

GPSVC(2ab0.206c) 2026-01-01 17:16:07:563 Server_ProcessRefresh:: bMachine = 1, SID = null, bForceRefresh = 1, bRefreshAllUsers = 0, dwTimeout = 600000
GPSVC(2ab0.206c) 2026-01-01 17:16:07:563 CGPApplicationService::RefreshEvent fired.
GPSVC(2ab0.206c) 2026-01-01 17:16:07:563 CGPApplicationService::RefreshEvent for Machine.
GPSVC(2ab0.206c) 2026-01-01 17:16:07:563 CGPApplicationService::RefreshEvent Force Refresh = 1.
GPSVC(2ab0.206c) 2026-01-01 17:16:07:563 CGPApplicationService::RefreshEvent Refresh all users = 0.
GPSVC(2ab0.206c) 2026-01-01 17:16:07:563 CGPApplicationService::RefreshEvent Timeout = 600000.
GPSVC(2ab0.206c) 2026-01-01 17:16:07:563 User SID = <S-1-5-20>

New Logging

GPSVC.LOG:

GPSVC(51c.10d0) 2026-01-01 17:28:44:566 Server_ProcessRefresh:: bMachine = 1, SID = null, bForceRefresh = 1, bRefreshAllUsers = 0, dwTimeout = 600000
GPSVC(51c.10d0) 2026-01-01 17:28:44:573 GP Refresh Attribution: Target=Machine ParentProcess="C:\Windows\System32\svchost.exe" ParentPID=1904 GPUpdatePID=204 SessionID=0 Account="NT AUTHORITY\NETWORK SERVICE"
GPSVC(51c.10d0) 2026-01-01 17:28:44:573 CGPApplicationService::RefreshEvent fired.
GPSVC(51c.10d0) 2026-01-01 17:28:44:573 CGPApplicationService::RefreshEvent for Machine.
GPSVC(51c.10d0) 2026-01-01 17:28:44:575 CGPApplicationService::RefreshEvent Force Refresh = 1.
GPSVC(51c.10d0) 2026-01-01 17:28:44:575 CGPApplicationService::RefreshEvent Refresh all users = 0.
GPSVC(51c.10d0) 2026-01-01 17:28:44:575 CGPApplicationService::RefreshEvent Timeout = 600000.
GPSVC(51c.10d0) 2026-01-01 17:28:44:575 User SID = <S-1-5-20>

The refresh activity can be corroborated by this Task Scheduler event:

Microsoft-Windows-TaskScheduler/Operational:

Log Name: Microsoft-Windows-TaskScheduler/Operational
Source: Microsoft-Windows-TaskScheduler
Date: 1/1/2026 5:28:44 PM
Event ID: 129
Task Category: Created Task Process
Level: Information
Keywords:
User: SYSTEM
Computer: CONT-WIN11-2.CONTOSO.local
Description:
Task Scheduler launch task "\Microsoft\Windows\GroupPolicy\GPUpdate" , instance "gpupdate.exe" with process ID 204.

Scenario 5: Audit Policy modifications via SecPol

Modifications to the Advanced Audit Policy configuration via the Local Security Policy console (SecPol) also triggers a GP Refresh.

Current Logging

GPSVC.LOG:

GPSVC(360.193c) 2026-01-01 16:09:36:594 RefreshPolicyForPrincipal: Entering with bMachine = 1, SID = null, options: 0, dwTimeout = 0, currentProcessId = 864, processImageName = C:\Windows\System32\mmc.exe
GPSVC(aa0.904) 2026-01-01 16:09:36:594 Server_ProcessRefresh:: bMachine = 1, SID = null, bForceRefresh = 0, bRefreshAllUsers = 0, dwTimeout = 0
GPSVC(aa0.904) 2026-01-01 16:09:36:606 CGPApplicationService::RefreshEvent fired.
GPSVC(aa0.904) 2026-01-01 16:09:36:608 CGPApplicationService::RefreshEvent for Machine.
GPSVC(aa0.904) 2026-01-01 16:09:36:608 CGPApplicationService::RefreshEvent Force Refresh = 0.
GPSVC(aa0.904) 2026-01-01 16:09:36:608 CGPApplicationService::RefreshEvent Refresh all users = 0.
GPSVC(aa0.904) 2026-01-01 16:09:36:608 CGPApplicationService::RefreshEvent Timeout = 0.
GPSVC(aa0.904) 2026-01-01 16:09:36:608 User SID = <S-1-5-21-869282409-3425305577-2907120315-7716>

New Logging

GPSVC.LOG:

GPSVC(1cb4.1d2c) 2026-01-01 16:09:49:240 RefreshPolicyForPrincipal: Entering with bMachine = 1, SID = null, options: 0, dwTimeout = 0, currentProcessId = 7348, processImageName = C:\Windows\System32\mmc.exe
GPSVC(1f94.1fe4) 2026-01-01 16:09:49:240 Server_ProcessRefresh:: bMachine = 1, SID = null, bForceRefresh = 0, bRefreshAllUsers = 0, dwTimeout = 0
GPSVC(1f94.1fe4) 2026-01-01 16:09:49:327 RPC Call Attribution: Target=Machine ParentProcess="C:\Windows\System32\cmd.exe" ParentPID=2328 RpcClient="C:\Windows\System32\mmc.exe [SECPOL.MSC]" RpcClientPID=7348 SessionID=2 Account="CONTOSO\Admin1"
GPSVC(1f94.1fe4) 2026-01-01 16:09:49:334 CGPApplicationService::RefreshEvent fired.
GPSVC(1f94.1fe4) 2026-01-01 16:09:49:334 CGPApplicationService::RefreshEvent for Machine.
GPSVC(1f94.1fe4) 2026-01-01 16:09:49:334 CGPApplicationService::RefreshEvent Force Refresh = 0.
GPSVC(1f94.1fe4) 2026-01-01 16:09:49:334 CGPApplicationService::RefreshEvent Refresh all users = 0.
GPSVC(1f94.1fe4) 2026-01-01 16:09:49:334 CGPApplicationService::RefreshEvent Timeout = 0.
GPSVC(1f94.1fe4) 2026-01-01 16:09:49:334 User SID = <S-1-5-21-869282409-3425305577-2907120315-7716>

If you haven't already, make sure to have a read of A Treatise on Group Policy Troubleshooting – now with GPSVC Log Analysis 

Hope these changes will make your troubleshooting just a little easier. As always — let us know what you want to see next and keep the feedback coming.

Happy debugging!

Signing out.
Gaurav and Itay.

From Guesswork to Clarity: GPP Diagnostics Improve in Windows Server 2025 and Windows 11 24H2

SagiVa — Wed, 04 Mar 2026 23:23:21 GMT

Hello AskDS readers!

Sagi and Adesh here. Today we’re excited to talk about a change that finally closes one of the longest‑standing troubleshooting gaps in Group Policy Preferences (GPP).
GPP has always been a powerful way to manage Files, Folders, Drive Maps, Registry, local users and groups, and more.
Unfortunately, when something fails, diagnostics often boil down to a single event:

Event ID 4098.

If you’ve spent time troubleshooting GPP, you already know what that meant:

An error code
No object name
No path
No indication of which preference item failed

So you enabled debugging, searched logs, ran ProcMon, and guessed.

That experience is now officially behind us.
For background on how Group Policy Preferences work and what each setting is designed for, review the following Microsoft documentation:
Group Policy preferences in Windows | Microsoft Learn

Working with Windows Settings Preference Items Using the GPMC | Microsoft Learn

With this context in mind, the diagnostic improvements introduced in newer Windows versions make it far easier to identify why a specific preference item did not apply.

What Changed and When

Starting with the January 2026 update rollup for Windows 11 24H2 and Windows 11 25 H2, Group Policy Preferences now provide much richer diagnostics.
Note: When the Server operating system update becomes available, we will update this article accordingly.  

These improvements introduce a new event:

Event ID 4117 – Group Policy Preferences Diagnostic Data

Event ID 4117 is logged in addition to the legacy Event ID 4098.
While 4098 remains for compatibility, 4117 provides the missing context admins have needed for years.
Importantly, this update does not change how GPP processes policies-it only improves visibility when something goes wrong.
There is no need to set any additional configuration to get the extended information.

Scenario 1 – File Does Not Exist

(“We swear it was there yesterday”)

A GPP File preference item attempt to copy a file from SYSVOL to a local destination, but the source file is missing.

Before: Event ID 4098
With the old behavior, Event ID 4098 told you something failed-but not much else.
The screenshot below shows a legacy 4098 event for a missing file.

Log Name:      Application
Source:        Group Policy Files
Event ID:      4098
Description:
The computer 'Contoso_ScreenSaver.jpg' preference item in the 'GPP_Logging {66178DEE-6071-48D1-9B26-F7388733255D}' Group Policy Object did not apply because it failed with error code '0x80070002 The system cannot find the file specified.' This error was suppressed.

Which specific file? at which specific path? No idea.

Now: Event ID 4117

Event ID 4117 makes the failure explicit.
The screenshot below shows Event ID 4117 identifying the missing source file and destination.

Log Name:      Application
Source:        Group Policy Files
Event ID:      4117
Level:         Warning
Description:

Group Policy Preferences Diagnostic Data: Source file '\\contoso.com\SYSVOL\contoso.com\Wallpaper\Contoso_ScreenSaver.jpg' was not found when copying to 'C:\Temp\Contoso_ScreenSaver.jpg'. Error: 0x00000002 (HRESULT: 0x80070002).

How to proceed

Verify the exact source path in the event. Does the file exist there?
Correct or restore the file or update the GPP item if the setting is no longer required.

Scenario 2 – File Exists, but Access Is Denied

The file is present, but permissions prevent GPP from copying it.

Before: Event ID 4098

The screenshot below shows how Event 4098 reported only “Access is denied.”

Log Name:      Application
Source:        Group Policy Files
Event ID:      4098
Level:         Warning
Description:

The computer 'Contoso_ScreenSaver.jpg' preference item in the 'GPP_Logging {66178DEE-6071-48D1-9B26-F7388733255D}' Group Policy Object did not apply because it failed with error code '0x80070005 Access is denied.' This error was suppressed.

Where exactly is this file, again? Source or destination? Still unknown.

Now: Event ID 4117

Event ID 4117 identifies the file and operation.
The screenshot below illustrates Event ID 4117 showing a permission failure during a file copy.

Log Name:      Application
Source:        Group Policy Files
Event ID:      4117
Level:         Warning
Description:

Group Policy Preferences Diagnostic Data: Access denied when copying '\\contoso.com\SYSVOL\contoso.com\Wallpaper\Contoso_ScreenSaver.jpg' to 'C:\Temp\Contoso_ScreenSaver.jpg'. Check file permissions. Error: 0x00000005 (HRESULT: 0x80070005).

How to proceed

Identify whether the policy runs as SYSTEM or user by identifying if it is in the Computer Configuration or User Configuration section, respectively.
Validate NTFS and share permissions of the corresponding file.

Scenario 3 – Folder Delete Fails Due to Permissions

A GPP Folder preference item attempt to delete C:\temp1.

Before: Event ID 4098

Event ID 4098 reported a failure but did not identify which folder caused it.
Legacy events provided no target folder information.

Log Name: Application
Source: Group Policy Folders
Event ID: 4098
Description:
The computer 'temp1' preference item in the 'GPP_Logging {66178DEE-6071-48D1-9B26-F7388733255D}' Group Policy Object did not apply because it failed with error code '0x80070005 Access is denied.' This error was suppressed.

Now: Event ID 4117

The screenshot below shows Event ID 4117 identifying the exact folder that failed deletion.

Log Name:      Application
Source:        Group Policy Folders
Event ID:      4117
Level:         Warning
Description:
Group Policy Preferences Diagnostic Data: Access denied to folder 'c:\temp1' during delete. Check permissions. Error: 0x00000005 (HRESULT: 0x80070005).

How to proceed

Check NTFS permissions and ownership
Confirm no locks or AV interference

Scenario 4 – Drive Map with Invalid Network Path

A GPP Drive Map attempts to map a drive to an invalid UNC path.

Before: Event ID 4098

The screenshot below shows Event 4098 reporting only a network error.

Log Name:      Application
Source:        Group Policy Drive Maps
Event ID:      4098
Level:         Warning
Description:

The user 'H:' preference item in the 'GPP_Logging {66178DEE-6071-48D1-9B26-F7388733255D}' Group Policy Object did not apply because it failed with error code '0x80070043 The network name cannot be found.' This error was suppressed.

Which path? Still unclear.

Now: Event ID 4117

Event ID 4117 removes all ambiguity.

The screenshot below shows Event ID 4117 identifying the invalid UNC path and drive letter.

Log Name:      Application
Source:        Group Policy Drive Maps
Event ID:      4117
Level:         Warning
Description:
Group Policy Preferences Diagnostic Data: Network name '\\Server1\BogusShare' is invalid for 'h:'. Error: 0x00000043 (HRESULT: 0x80070043).

How to proceed

Test the UNC path from the client
Validate DNS and name resolution

Summary: Event ID → Action Decision Table

Legacy Event	New Event	Diagnostic Meaning	Recommended Action
4098	4117	Source file missing	Make sure the file exist and match the name and path as in the GPP settings
4098	4117	Access denied (file)	Fix NTFS/share permissions for policy context
4098	4117	Folder delete failed	Correct permissions, ownership, or locks
4098	4117	Drive Map path invalid	Fix UNC, DNS, targeting, or remove obsolete map

Why This Is a Big Deal

Previously:

4098 told you something failed
Determining details on the failure was sometimes difficult

Now:

4117 tells you exactly what, where, and why
Troubleshooting becomes deterministic
Resolution time may decrease in situations where clarity is needed.

Final Thoughts

Event ID 4117 finally brings Group Policy Preferences diagnostics in line with modern troubleshooting expectations-without changing how policies apply.

If you’ve ever stared at Event 4098 wondering “Which one?”, this update is for you.

The silence is officially over.

This is not the end of the story. (Yes - even GPP gets a character development arc.)

If you love these changes, drop us a comment below on how this helped you or if you have additional ideas.

Happy troubleshooting-and as always, we’ll see you in the logs.

-Sagi Vahabi and Adesh Prabhu

Resources

What are Permissions? | Microsoft Learn

What’s New in Windows Group Policy Preferences Debug Logging

TagoreN — Fri, 27 Feb 2026 13:36:57 GMT

Hello again — this is Potti Tagore Nadh from Directory Services team.

When troubleshooting Windows components, administrators often rely on enhanced logging to diagnose issues quickly and accurately. Group Policy Preferences (GPP) provide verbose debug logging capabilities for each client-side extension (CSE). Traditionally, these settings were available only through domain-based Group Policy Objects (GPOs).

With the release of February 2026 preview updates on Windows 11 24H2 and 25H2, this is changing—and it’s becoming much easier.
Note: When the Server operating system update becomes available, we will update this article accordingly.

What’s New in Windows 11 24H2, 25H2?

GPP Debug Logging Now Available in Local Group Policy

Starting with:

Windows 11 24H2
Windows 11 25H2
And via Windows Updates from February 2026 Preview onward

Administrators can now enable Group Policy Preferences debug logging directly from Local Group Policy—not just domain GPOs.

This enhancement allows troubleshooting directly on client devices without relying on domain controllers, centralized GPO administration or manually moving Administrative Template files.

This is a major quality-of-life improvement for IT pros who frequently debug GPP issues.

Group Policy Preferences Debug Logging – Visual Overview

First, let's start off with some examples of the settings we are talking about.

Figure 1. Group Policy Preferences Debug Logging using Local Group Policy

How to Enable Group Policy Preferences Logging and Tracing using Local Group Policy Editor (Gpedit.msc)

You can enable logging and tracing for each individual preference CSE. These settings allow you to configure:

What level of events are logged (Informational, Warnings, Errors, or All) (Typically, the most Verbose logging helps pin down difficult issues.)
Whether trace logging is enabled
Where trace logs are saved
Maximum trace file size

Steps to Configure GPP Logging and Tracing

Open Local Group Policy Editor using gpedit.msc.
Navigate to:
Computer Configuration → Policies → Administrative Templates → System → Group Policy → Logging and Tracing
Select the desired Preference CSE (e.g., Drive Maps, Files, Shortcuts, Printers).
Set the policy to Enabled.
Configure:

Event logging: Informational, Warnings, and Errors
Tracing: Enabled
User trace path:
%COMMONAPPDATA%\GroupPolicy\Preference\Trace\User.log
Maximum file size: 1024 KB (increase if logs roll over too quickly)
Computer trace path:
%COMMONAPPDATA%\GroupPolicy\Preference\Trace\Computer.log

Click Apply and OK.

Figure 2. Preference Logging and Tracing Policy Settings

Understanding Trace File Locations

The default trace directory for all GPP CSEs is:

%COMMONAPPDATA%\GroupPolicy\Preference\Trace

While %COMMONAPPDATA% is not a standard Windows environment variable, it is recognized and expanded internally by the GPP CSEs.

Equivalent physical path:

%SYSTEMDRIVE%\ProgramData\Microsoft\

Note: This folder is hidden by default. You can type the path directly into File Explorer.

If you choose a custom folder, Windows requires:

Full access permissions for the SYSTEM account
No restrictive ACLs that block service-level writes

Figure 3. Required Permissions for Custom Log Folder

When configuring a custom trace log folder for Group Policy Preferences (GPP) Client‑Side Extensions (CSEs), the SYSTEM account must have Full Control on the directory.

GPP CSEs run under Local System, not the user context.
If SYSTEM lacks permissions:

Trace files will not be created
Logging will silently fail

Conclusion

The introduction of Group Policy Preferences CSE logging to client-side Local Group Policy in Windows 11 24H2/25H2 and later is a meaningful upgrade for administrators.

This enhancement:

Simplifies troubleshooting
Reduces dependency on domain or GPO administrators
Provides a more flexible and scalable diagnostic workflow
Brings client, server-level policy debugging features directly to client devices

If you’re working with Group Policy Preferences regularly, this update will help you analyze issues faster and more independently.

Article for original release of Preference Debug Logging:

Enabling Group Policy Preferences Debug Logging using the RSAT | Microsoft Community Hub

Reading GPSVC Like a Crime Novel

Chris_Cartwright — Wed, 25 Feb 2026 18:02:28 GMT

Hello again — this is Adesh Prabhu from Directory Services team.

A long time ago (and we mean a long time ago), we published a deep dive explaining how to troubleshoot Group Policy by reading the Group Policy Client Service (GPSVC) debug log. That post, A Treatise on Group Policy Troubleshooting–now with GPSVC Log Analysis! | Microsoft Community Hub, became one of the most bookmarked resources we’ve ever written, both inside and outside Microsoft.

However, the Group Policy service debug logging lacked date information, making deep‑dive troubleshooting far more difficult than it needed to be with only timestamps.

This made it difficult to correlate to networking information or even events, if days had passed and for some reason the log file last modified date was changed, making it very difficult to correlate.

That limitation is gone.

Modern versions of Windows 11 24H2 and 25 H2 since November 2025 Preview updates include both date and time on most Group policy related logs, and while that may sound trivial, it fundamentally changes how useful this log is in real environments.

Note: When the Server operating system update becomes available, we will update this article accordingly.

In this post, we’re going to revisit the blog post, keep all the architectural detail, and walk through how Group Policy actually works on the wire, what each phase looks like in the log, and how to read gpsvc output without guessing.

Before we touch the logs: what GPSVC really is

We still see this misunderstanding, so let’s start here.

The Group Policy Client service (GPSVC) is not optional. It is the service responsible for applying Group Policy on every Windows system, client, and server.

A few important facts:

GPSVC runs in its own svchost instance
It does not run inside Winlogon
If GPSVC is not running, Group Policy does not apply

The service startup type is Automatic (Trigger Start). That does not mean it’s on‑demand in the casual sense — it means Windows starts it exactly when policy processing is required, lets it do its work, and then allows it to idle.

If GPSVC cannot start or crashes, nothing else in this article matters.

Group Policy always runs in two phases (always)

Every Group Policy refresh happens in two distinct phases. Miss this distinction and the gpsvc log will never fully make sense.

Phase 1: Core Group Policy processing

This is the discovery phase. During this phase, GPSVC:

Locates a domain controller
Determines the user’s or computer’s distinguished name
Walks the OU hierarchy for linked GPOs
Identifies applicable GPOs
Builds the ordered policy list

No settings are applied here.
No registry. No scripts. No software installs. That doesn’t come until the next phase.

If you’re troubleshooting why a GPO never even shows up in the Group Policy Operational log or a gpresult, this is the phase you care about.

Phase 2: Client‑Side Extension (CSE) processing

Once GPSVC knows what should apply, it moves on to how it applies.

In this phase, GPSVC:

Checks version numbers (GPC vs GPT)
Evaluates security and WMI filtering
Invokes each Client‑Side Extension
Commits policy-based configuration settings to the system

If Phase 1 succeeded but the expected GPO settings were not applied, your issue is almost certainly here.

Enabling GPSVC debug logging

GPSVC logging is still enabled through the registry and is still extremely verbose — by design.

Create the following key and value:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
DWORD: GPSvcDebugLevel = 0x30002

Make sure this folder exists:
%windir%\Debug\Usermode

If that directory does not exist, gpsvc.log will not be created.

Trigger Group Policy processing using:

gpupdate /force /target:computer
gpupdate /force /target:user

Processing user and computer policies separately reduces log interleaving and makes analysis easier.

First rule of reading gpsvc.log: follow the thread

GPSVC is multi‑threaded. This means multiple operations happen at the same time, and if you don’t follow the correct thread, the log quickly turns into noise.

A modern log entry looks like this:

GPSVC(4b4.5dc) 2026-1-30 07:43:27:860 ProcessGPO(Machine):

Here’s how to read it:

4b4 → Process ID (PID)
5dc → Thread ID (TID)
Date & Time → finally present
Machine/User → processing context

You will typically see two primary threads:

One for Machine policy
One for User policy

Pick the context you care about and ignore the rest. Mixing threads is the fastest way to get lost.

Machine policy processing: what it looks like in the log

Machine policy always runs first.

Early in the log, you’ll see confirmation of machine context:

User SID = MACHINE SID
bMachine = 1

From here, GPSVC:

Starts the service engine
Waits for critical dependencies
Verifies network connectivity
Discovers applicable GPOs
Evaluates filters and versions
Saves data to local cache
Calls CSEs

Note that Phase 1 is 1-4, and Phase 2 is 5-7.

Dependency and startup signatures

GroupPolicyClientServiceMain
CGPService::Start
InitializeRPCServer starting RPCServer
Detected that this is machine Startup

This is GPSVC making sure prerequisites (RPC, COM, core subsystems) are ready before proceeding.

Connectivity waits (these matter more than people think)

A large number of “slow boot” complaints are explained right here.

Waiting for connectivity before applying policies
Waiting for SamSs with timeout 120000
Waiting for MUP with timeout 113672
Waiting for DS with timeout 109625
We have network connectivity... proceeding to apply policy.

This is expected behavior.

GPSVC will not apply policy until it believes the system is in a usable network state. The addition of more detailed timestamps makes it easy to see exactly how long these waits lasted and correlate them with NLA, Netlogon, or network traces.

OU walk and policy discovery (LSDOU)

GPSVC evaluates policies in LSDOU order.

SearchDSObject: Searching <OU=Workstations,OU=Bangalore,DC=contoso,DC=com>
Found GPO(s): <[LDAP://cn={9266...},cn=policies,cn=system,DC=contoso,DC=com;0]>
...
SearchDSObject: Searching <DC=contoso,DC=com>
Found GPO(s): <[LDAP://CN={31B2...},CN=Policies,CN=System,DC=contoso,DC=com;0]>
...
SearchDSObject: Searching <CN=Default-First-Site-Name,...>

The GUID identifies the GPO.
The trailing number after the semicolon indicates state:

0 = Enabled
1 = Disabled
2 = Enforced

Versioning, filtering, and replication health

Once a GPO is identified, GPSVC validates it:

Machine has access to this GPO.
GPO passes the filter check.
Found functionality version of: 2
Found file system path of: \\contoso.com\sysvol\contoso.com\Policies\{31B2...}
Found display name of: <Default Domain Policy>
Found machine version of: GPC is 3, GPT is 3

If GPC and GPT do not match, you have a replication problem, either in SYSVOL or in AD.
It’s that simple.

Machine account needs read access on all user policies too in addition to user (Read & Apply)

Group Policy caching (what it actually looks like)

Caching improves synchronous processing by reusing locally stored policy data.

When caching is involved, look for these signatures:

CanStartFromLocalDataStore:++
CanLoadGPOsFromLocalCache:++
SaveGPOsToLocalCache: Saving values to local cache.
SaveGPOsToLocalCache(Machine): Successfully flip active bit of current data store.

Reading this in English:

Cache eligibility evaluated
Local policy data written
Active cache store committed

If you expect caching and don’t see these lines, it isn’t participating — usually because an administrator has disabled caching via the “Configure Group Policy Caching” setting.

Slow link detection (log‑driven, not event‑driven)

Slow link evaluation happens only during synchronous policy processing.

GetBandwidthThreshold: Bandwidth Threshold (WINLOGON) = 500.
GetBandwidthEstimate returned Bandwidth = 4294967.
IsSlowLink: Current Bandwidth >= Bandwidth Threshold.

GPSVC compares measured bandwidth against policy thresholds. If evaluation fails, it uses the last known state recorded in policy history.

CSE processing: the business end of Group Policy

Once discovery and validation are complete, GPSVC calls Client‑Side Extensions.

Registry CSE example

ProcessGPOs(Machine): Processing extension Registry
SetRegistryValue: Wallpaper => C:\Temp\Wallpaper\Wallpaper.jpg [OK]
LogRegistryRsopData: Successfully logged registry Rsop data

Each CSE:

Acquires locks
Applies changes
Reports success or failure
Updates RSOP data

Understanding which CSE applied which setting is often the key to resolving conflicts.

Registry CSE logging for administrative template settings is always logged in GPSVC.log, all other CSEs have its own debug logging as described in A Treatise on Group Policy Troubleshooting–now with GPSVC Log Analysis! | Microsoft Community Hub.

User policy processing

After machine policy completes, GPSVC starts the user thread:

ProcessGPO(User):

From here, the same phases repeat:

OU walk
Filter evaluation
Version checks
CSE execution

Foreground processing mode may temporarily switch to synchronous during first logon:

gpSetFgPolicyRefreshInfo (... info.mode: Synchronous)
gpSetFgPolicyRefreshInfo (... info.mode: Asynchronous)

This is expected.

When gpsvc.log isn’t enough: use TSS

For complex issues involving authentication, replication, or drivers, collect unified traces using TSS (Troubleshooting Script). TSS directory has GUI version called TSGUI.ps1 which you can use to explore different options/switches to get additional tracing capabilities. Not all of the files will be readable, but you may find clues in the text and log files to self resolve certain issues that you may run into. If the issue cannot be resolved, Microsoft Support can read some of the other files. Note: always test this before executing them in production.in production.

md C:\TSS
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned -Force
Start-BitsTransfer https://aka.ms/getTSS -Destination C:\TSS\TSS.zip
Expand-Archive C:\TSS\TSS.zip -DestinationPath C:\TSS -Force
C:\TSS\TSS.ps1 -Scenario ADS_GPOEx

Full date and time are available now in all group policy debug log files, here are sample log entries that look like with date and time:

To troubleshoot group policy core engine issues:

Gpsvc.log:

GPSVC(188c.25d8) 2026-01-30 11:13:17:216 ProcessGPOs(Machine): Send a network activate for AOAC. GPSVC(188c.25d8) 2026-01-30 11:13:17:216 Passive Network activated.
GPSVC(188c.25d8) 2026-01-30 11:13:17:218 ProcessGPOs(Machine): Verbose output to eventlog requested.
GPSVC(188c.25d8) 2026-01-30 11:13:17:230 Opened Existing Registry key
GPSVC(188c.25d8) 2026-01-30 11:13:17:230 UncPath :'\\contoso.com\SYSVOL'
GPSVC(188c.25d8) 2026-01-30 11:13:17:230 UncPath :'\\contoso.com\NETLOGON'
GPSVC(188c.25d8) 2026-01-30 11:13:17:254 GetDomainControllerConnectionInfo: Enabling bandwidth estimate.
GPSVC(188c.25d8) 2026-01-30 11:13:17:278 Started bandwidth estimation successfully
GPSVC(188c.25d8) 2026-01-30 11:13:17:278 GetDomainControllerConnectionInfo: Getting Ldap Handles. GPSVC(188c.25d8) 2026-01-30 11:13:17:278 GetLdapHandle: Getting ldap handle for host: DC1.contoso.com in domain: contoso.com.
GPSVC(188c.25d8) 2026-01-30 11:13:17:289 GetLdapHandle: Server connection established. GPSVC(188c.25d8) 2026-01-30 11:13:17:300 GetLdapHandle: Binding using only kerberos. GPSVC(188c.25d8) 2026-01-30 11:13:17:324 GetLdapHandle: Bound successfully.

To troubleshoot GPMC snap-in related errors:

Gpmc.log

GPMC(5ac.8f0) 2026-01-30 11:13:47:878 Created semaphore with handle 0000000000000A84
GPMC(5ac.8f0) 2026-01-30 11:13:47:878 In Object 0x00000000029AA6C0, initializing semaphore handle to 0000000000000A84 for report 0x00000000029AEB08
GPMC(5ac.8f0) 2026-01-30 11:13:47:884 Wait on semaphore 0000000000000A84 called
GPMC(5ac.8f0) 2026-01-30 11:13:47:884 Wait on semaphore 0000000000000A84 called
GPMC(5ac.e30) 2026-01-30 11:13:49:801 CReportImpl::SetReportAsync Calling set report with 0x00000000029a2610 and 0x000000000671EE20
GPMC(5ac.e30) 2026-01-30 11:13:49:803 CCookieCutter::SetReport SetReport called with cookie 0x29a2610 and nodedeletedflag 000000000671EE20
GPMC(5ac.e30) 2026-01-30 11:13:49:803 In object 0x00000000029AA6C0, Releasing semaphore 0000000000000A84
GPMC(5ac.8f0) 2026-01-30 11:13:57:222 Clearing out 0 SIDs GPMC(5ac.8f0) 2026-01-30 11:13:58:126 In Object 0x00000000029A9EC0, initializing semaphore handle to 0000000000000A84 for report 0x00000000029AEB08 GPMC(5ac.8f0) 2026-01-30 11:13:58:126 Wait on semaphore 0000000000000A84 called
GPMC(5ac.8f0) 2026-01-30 11:13:58:126 Wait on semaphore 0000000000000A84 called
GPMC(5ac.5f0) 2026-01-30 11:13:58:418 CReportImpl::SetReportAsync Calling set report with 0x00000000029a2610 and 0x0000000003EA9920
GPMC(5ac.5f0) 2026-01-30 11:13:58:418 CCookieCutter::SetReport SetReport called with cookie 0x29a2610 and nodedeletedflag 0000000003EA9920
GPMC(5ac.5f0) 2026-01-30 11:13:58:418 In object 0x00000000029A9EC0, Releasing semaphore 0000000000000A84

GPmgmt log:

[5ac.8f0] 2026-01-30 15:56:36:269 [VERBOSE] GETADSIHandle: successfully bound to ds object escaped <LDAP://DC1.contoso.com/DC=contoso,DC=com>
[5ac.8f0] 2026-01-30 15:56:36:269 [VERBOSE] CForest::GetTrustedDomains was called for contoso.com forest and contoso.com domain
[5ac.8f0] 2026-01-30 15:56:36:269 [VERBOSE] CForest::GetForestAndDomain was called for CONTOSO.COM [5ac.8f0] 2026-01-30 15:56:36:273 [VERBOSE] CForest::GetForestAndDomain::DsGetDcName Forest: contoso.com Domain: contoso.com
[5ac.8f0] 2026-01-30 15:56:36:275 [VERBOSE] CForest::GetForestAndDomain was called for contoso.com [5ac.8f0] 2026-01-30 15:56:36:277 [VERBOSE] CForest::GetForestAndDomain::DsGetDcName Forest: contoso.com Domain: contoso.com
[5ac.8f0] 2026-01-30 15:56:36:277 [VERBOSE] CForest::CheckForestAndDomainTrust same forest: contoso.com [5ac.8f0] 2026-01-30 15:56:36:279 [VERBOSE] GetDomainDN: Domain FQDN of domain contoso.com = DC=contoso,DC=com

gpmgmtManaged.log:

Reporting(3620.1) 2026-01-30 15:11:26:961 Rsop::Initialize:----------------------------------------------
Reporting(3620.1) 2026-01-30 15:11:26:961 Rsop::Initialize:Namespace= root\rsop\ns7406d980_1c36_4aad_b4c9_a0942f9894dc
Reporting(3620.1) 2026-01-30 15:11:26:963 Rsop::Initialize:----------------------------------------------
Reporting(3620.1) 2026-01-30 15:11:26:963 Rsop::Initialize:Initialising computer RSOP data
Reporting(3620.1) 2026-01-30 15:11:27:073 RsopTargetResults::.ctor:Name = CONTOSO\Client1$
Reporting(3620.1) 2026-01-30 15:11:27:073 Rsop::Initialize:Initialising user RSOP data
Reporting(3620.1) 2026-01-30 15:11:27:079 RsopTargetResults::.ctor:Name = CONTOSO\policy
Reporting(3620.1) 2026-01-30 15:11:27:081 CrimsonEvtLogConsumer::.ctor:MachineName is either null or empty Reporting(3620.1) 2026-01-30 15:11:27:083 Rsop::Initialize:Namespace is of LoggedData type

To troubleshoot Group policy editor related issues:

Gpedit.log

GPEDIT(5ac.8f0) 2026-01-30 15:57:08:243 CGroupPolicyObject::New: Entering with: GPEDIT(5ac.8f0) 2026-01-30 15:57:08:245 CGroupPolicyObject::New: Domain Name: LDAP://DC1.contoso.com/DC=contoso,DC=com GPEDIT(5ac.8f0) 2026-01-30 15:57:08:247 CGroupPolicyObject::New: Flags: 0x0 GPEDIT(5ac.8f0) 2026-01-30 15:57:08:247 CGroupPolicyObject::New: Checking if DC (DC1.contoso.com) is read-only. GPEDIT(5ac.8f0) 2026-01-30 15:57:08:294 CGroupPolicyObject::New: DC (DC1.contoso.com) is NOT read-only.

To troubleshoot ADMX or ADML parsing issues:

AdmTmpl.log:

Group Policy Editor ADMX/ADML

The Group Policy Editor for Administrative Templates Registry Policy has logging on its work. It allows for example to understand in detail why it fails parsing the set of ADMX/ADML files. One example would be if files have mismatched versions that lead to:

Extension ADMX refer to OS release tags that Windows.Admx does not have.

ADMX files define policies twice as ADMX files got renamed and customer incorrectly merged sets of files.

Registry Configuration

Value Path: HKLM\SOFTWARE\Microsoft\Group Policy
Value Name: AdmTmplDebugLevel
Value Type: REG_DWORD
Value Data: 10002 (hex)

Output: %temp%\AdmTmpl.log

AdmTmpl(5f0.518) 2026-01-30 12:44:23:684 CPolicyComponentData::CreateComponent: Entering.
AdmTmpl(5f0.518) 2026-01-30 12:44:23:688 CPolicySnapIn::Initialize: Entering ... AdmTmpl(5f0.518) 2026-01-30 12:44:23:694 CPolicySnapIn::Initialize: Creating editor manager.
AdmTmpl(5f0.518) 2026-01-30 12:44:23:874 CPolicySnapIn::Initialize: Exiting AdmTmpl(5f0.2054) 2026-01-30 12:44:23:894 CPolicyComponentData::LoadTemplates: Entering for Machine AdmTmpl(5f0.2054) 2026-01-30 12:44:23:896 File does not exist: '\\contoso.com\sysvol\contoso.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\comment.cmtx'.
AdmTmpl(5f0.2054) 2026-01-30 12:44:23:942 PDX parser: Parsing file 'C:\Windows\PolicyDefinitions\AccountNotifications.admx'.
AdmTmpl(5f0.2054) 2026-01-30 12:44:23:985 PDX parser: Obtained appropriate PDX resource file 'C:\Windows\PolicyDefinitions\en-US\AccountNotifications.adml' for language 'en-US'. AdmTmpl(5f0.2054) 2026-01-30 12:44:23:987 PDX parser: Parsing resource file 'C:\Windows\PolicyDefinitions\en-US\AccountNotifications.adml'. AdmTmpl(5f0.2054) 2026-01-30 12:44:24:006 PDX parser: Parsing resource file completed successfully. 
AdmTmpl(5f0.2054) 2026-01-30 12:44:24:008 PDX parser: Successfully parsed file.
AdmTmpl(5f0.2054) 2026-01-30 12:44:24:008 PDX parser: Parsing file 'C:\Windows\PolicyDefinitions\ActiveXInstallService.admx'. AdmTmpl(5f0.2054) 2026-01-30 12:44:24:010 PDX parser: Obtained appropriate PDX resource file 'C:\Windows\PolicyDefinitions\en-US\ActiveXInstallService.adml' for language 'en-US'.
AdmTmpl(5f0.2054) 2026-01-30 12:44:24:010 PDX parser: Parsing resource file 'C:\Windows\PolicyDefinitions\en-US\ActiveXInstallService.adml'. AdmTmpl(5f0.2054) 2026-01-30 12:44:24:012 PDX parser: Parsing resource file completed successfully.
AdmTmpl(5f0.2054) 2026-01-30 12:44:24:014 PDX parser: Successfully parsed file.
AdmTmpl(5f0.2054) 2026-01-30 12:44:24:014 PDX parser: Parsing file 'C:\Windows\PolicyDefinitions\AddRemovePrograms.admx'. AdmTmpl(5f0.2054) 2026-01-30 12:44:24:016 PDX parser: Obtained appropriate PDX resource file 'C:\Windows\PolicyDefinitions\en-US\AddRemovePrograms.adml' for language 'en-US'. AdmTmpl(5f0.2054) 2026-01-30 12:44:24:016 PDX parser: Parsing resource file 'C:\Windows\PolicyDefinitions\en-US\AddRemovePrograms.adml'. AdmTmpl(5f0.2054) 2026-01-30 12:44:24:024 PDX parser: Parsing resource file completed successfully. AdmTmpl(5f0.2054) 2026-01-30 12:44:24:024 PDX parser: Successfully parsed file.

Final thoughts

Group Policy hasn’t gotten simpler — but the tools to understand it have improved.

With full timestamps now present in gpsvc.log, you can finally correlate Group Policy behavior with the rest of the system instead of guessing.

If you:

Follow one thread
Respect the two‑phase model
Read discovery before execution

The gpsvc log will tell you exactly what happened — and why.

And yes, this is still one of the best troubleshooting tools in Windows.

Additional resources:

Troubleshooting Group Policy Using Event Logs | Microsoft Learn

Introduction to TroubleShootingScript toolset (TSS) - Windows Client | Microsoft Learn

When Group Policy Goes Haywire: Spotting registry.pol Corruption Fast (and other problems too)

Rhesa-S — Tue, 24 Feb 2026 21:14:18 GMT

If you’re in charge of Group Policy settings, you know how critical the local registry.pol file is and how nerve-wracking it can be when things go awry. This post focuses on Local Group Policy’s registry.pol (not SYSVOL-hosted domain policy files), though corruption in the local registry.pol can derail Group Policy processing and ultimately prevent domain GPOs from applying. Luckily, Windows now provides much more actionable insight when corruption is detected in this vital file. Rather than introducing a new event or log, the existing Group Policy error, Event ID 1096 in the System event log, now includes more specific and informative details in the event’s Details tab. It is like having a trusty sidekick that does not just raise an alarm but tells you exactly what went wrong, helping you identify and address Group Policy inconsistencies before they ripple through your environment. Dive in to see how this improvement makes troubleshooting Group Policy issues more transparent and far less stressful. 

Operating System Note
This behavior currently applies to Windows 11 versions 24H2 and 25H2, starting with the February Cumulative Update 2026 or later. When the Server operating system update becomes available, we will update this article accordingly.  

Scenarios/Examples 

The local registry.pol corruption can occur in several scenarios, such as accidental manual edits, invalid entries by 3rd party software, gpsvc crashes/failures, and unexpected disk errors. Local registry-based policy errors can be persistent and problematic, and if the local Group Policy Object (GPO) registry.pol file is corrupted and unable to apply, it will stop domain group policy registry settings from applying too. Windows’ improved event logging mechanism acts as an early warning system, instantly alerting administrators to issues and providing detailed insights in the Event 1096 Details tab for a swift resolution. No more chasing shadows, just clear and actionable information for a smoother Group Policy experience! 

The locations of the local registry.pol files can be found in C:\Windows\System32\GroupPolicy\User\registry.pol, for the user registry.pol, and C:\Windows\System32\GroupPolicy\Machine\registry.pol for the machine.

Example 1: Manually modified the contents of registry.pol with invalid data.

For the examples below, please note that, for the purpose of the blog, we intentionally manually modified the registry.pol to corrupt it. This file should never be modified outside of group policy.

In this case, we opened the C:\Windows\System32\GroupPolicy\User\registry.pol file and inserted a string of text such as "test wrong text” which cannot be processed by Group Policy.

Before February Cumulative Update 2026

After  February Cumulative update 2026 

Command Prompt Output 

The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LocalGPO. Group Policy settings will not be resolved until this event is resolved. View the event details for more information on the file name and path that caused the failure. 

Command Prompt Output 

System Event Log 

Error      12/4/2025 7:15:09 AM GroupPolicy (Microsoft-Windows-GroupPolicy) 1096 None 

ErrorCode		13
ErrorDescription	The data is invalid.
DCName		\\ConteMumDCC.contoso.com
GPOCNName		LocalGPO
FilePath		C:\WINDOWS\System32\GroupPolicy\User\registry.pol

System Event Log 

Error      12/4/2025 7:15:09 AM GroupPolicy (Microsoft-Windows-GroupPolicy) 1096 None 

ErrorCode	13
ErrorDescription	Error during registry file parsing: Invalid file signature
DCName	\\ConteMumDCC.contoso.com
GPOCNName	LocalGPO
FilePath	C:\WINDOWS\System32\GroupPolicy\User\registry.pol

GPSVC Log  - The GPSVC log does not experience any changes after the update and will continue to show details like below:

GPSVC(4f4.19d0) 07:20:07:546 ParseRegistryFile: Entering with <C:\WINDOWS\System32\GroupPolicy\User\registry.pol>. 

GPSVC(4f4.19d0) 07:20:07:548 ParseRegistryFile: Invalid file signature 

GPSVC(4f4.19d0) 07:20:07:548 ParseRegistryFile: Leaving. 

GPSVC(4f4.19d0) 07:20:07:548 ProcessGPORegistryPolicy: ParseRegistryFile failed. 

Example 2: Missing permissions for SYSTEM on registry.pol 

In this example, we incorrectly modify the ACL on the file to prevent it from being read properly.

Before February Cumulative Update 2026 

After February Cumulative Update 2026 

Command Prompt Output 

System Event Log 

Error      01/06/2026 4:55:19 PM GroupPolicy (Microsoft-Windows-GroupPolicy) 1096 None 

ErrorCode	5
ErrorDescription	Access is denied.
DCName	\\ContosoDC2.contoso.com
GPOCNName	LocalGPO
FilePath	C:\Windows\System32\GroupPolicy\Machine\registry.pol>

System Event Log 

Error      01/06/2026 4:55:19 PM GroupPolicy (Microsoft-Windows-GroupPolicy) 1096 None 

ErrorCode	5
ErrorDescription	Error during registry file parsing: CreateFile failed with 5
DCName	\\ContDC1.contoso.com
GPOCNName	LocalGPO
FilePath	C:\Windows\System32\GroupPolicy\Machine\registry.pol>

GPSVC Log  - The GPSVC log does not experience any changes after the update and will continue to show details like below:

 GPSVC(840.1ea4) 2026-01-06 16:55:18:580 ParseRegistryFile: Entering with <C:\Windows\System32\GroupPolicy\Machine\registry.pol>.
GPSVC(840.1ea4) 2026-01-06 16:55:18:582 Error during registry file parsing: CreateFile failed with 5
GPSVC(840.1ea4) 2026-01-06 16:55:18:582 ParseRegistryFile: Leaving.
GPSVC(840.1ea4) 2026-01-06 16:55:18:582 ProcessGPORegistryPolicy: ParseRegistryFile failed.
GPSVC(840.1ea4) 2026-01-06 16:55:18:584 ProcessGPORegistryPolicy: Resetting policies set in the current processing cycle.
GPSVC(840.1ea4) 2026-01-06 16:55:18:584 ResetPolicies: Entering.

Prior to this update, administrators could identify registry-based policy update failures using Event ID 1096. However, the information provided was often limited and amounted to little more than a generic “something went wrong” message. With this improvement, the same 1096 event now delivers far more descriptive details in the event data, clearly indicating what caused Group Policy processing to fail. Administrators can now see messages such as “Error during registry file parsing: CreateFile failed with 5,” making it significantly easier to troubleshoot issues without guesswork. It is like upgrading from a cryptic fortune cookie to a full detective briefing. 

Summary 

When the local registry.pol corruption, or a common lookalike, (in the blog example, problematic permissions) occurs, the existing event logging mechanism springs into action by recording event 1096 in the system event log, along with more informative text in the “Details” tab, which can be viewed simply using Event Viewer. While previous event logs already included important details such as the error code, the name of the affected Group Policy Object (GPO), and the domain controller (DC) your system was communicating with, the new update goes a step further by providing a much more descriptive error message. This enhanced information now clearly outlines the underlying cause of the issue, empowering administrators to troubleshoot with ease and accuracy.  

This added clarity removes much of the guesswork that historically surrounded local registry.pol corruption and represents a meaningful step forward in Group Policy troubleshooting. We look forward to seeing administrators take advantage of this improvement to diagnose issues faster and with greater accuracy.  

Until next time,  

Ralu and Rhesa  

Cross Forest Enrollment – PKISync.PS1

Manuel_Alvarez_V — Thu, 19 Feb 2026 21:27:00 GMT

Here is the link: Cross Forest - Certificate Enrollment | Microsoft Community Hub

PKIsync.ps1 script

At this time, we’re going to keep things simple.

The goal is to create an Active Directory resource Forest (Source Forest) that will host an Enterprise CA; it will be responsible for issuing all certificates.

This approach should allow us to get everything up and running quickly, so those certificates can be requested and issued from a target Active Directory Forest.

With that said, let’s take a closer look at how the PKIsync.ps1 script works and its flow.

Understanding the flow of PKIsync.PS1 script

The PowerShell script is designed to synchronize certificate templates and PKI configuration information between multiple forests ensure consistency across forests.

1. Locate the DC on the target forest or server on the target forest and Run PKISync.PS1

Locate the Domain Controller or member server where the script is located to start copying the Active Directory objects from the Source Forest to the Target Forest. In this scenario, the source forest is “Contoso.com” to target forest “Fabrikam.com” We then run the “PKISync.PS1” script on the “Fabrikam.com”.

PKISYNC.PS1 Run over .NET classes, this means that we only need an account that belongs to the Enterprise Admins group and run it on any server on the target forest.

2. Copying AD Objects

The script will start copying (Or Sync) the following AD objects: “pKICertificateTemplate, pKIEnrollmentService, and msPKI-Enterprise-Oid” to the target forest.

3. Objects Copied/synced and Ready for the Computers/Users.

After some time is allowed for AD replication to converge, “Fabrikam.com” will have these PKI AD objects Sync’d into its AD database on every domain controller thus allowing “Users or Computers” in the target forest to enroll for certificates from the CA in the Source Forest. Then we will want to wait until computer certificate autoenrollment has ran. This is going to be upwards of 8 hours before all systems in the forest will have the updated certification authority objects.

4. Windows Client Does a Request to the DC

Now, imagine a Windows Client in “Fabrikam.com” that needs to enroll a certificate using “Certlm.msc”. The client will perform an LDAP lookup on a Domain Controller in the Fabrikam.com domain to discover all the PKI-related AD objects that were previously Sync’d over to the target forest.

It’s important to note that any changes made to the CA of the Source Forest “Contoso.com” will only be reflected after running the script again or scheduling a task, which I'll cover at the end of this article.

5. Windows Client sends a Request to Source Forest CA

With the information gathered from the “Fabrikam.com” Domain Controller through an LDAP query, the Windows client uses TCP port 135 (RPC endpoint mapper) to connect to the CA and obtain the location of the CA’s iCertRequest DCOM interface. After the endpoint mapper provides the dynamic port for the iCertRequest DCOM interface, the client establishes a TCP connection to that interface on the CA in the source forest.

6. Template configuration

If a template is configured with “Build from Active Directory”, the CA will immediately look up the user’s or computer’s domain specified in the request. If the requester belongs to a different AD forest, Kerberos tickets must be obtained from each domain in the trust path, which is why a Forest Trust is required. A Forest Trust is the only trust type that fully supports Kerberos. Once the CA validates the information with the “Fabrikam.com” Domain Controller, it signs the certificate request and returns the signed certificate to the Windows client. The certificate is then placed in the user’s Certificate Store.

Configure the environment for cross forest enrollment

Choose a Source Forest and Target Forest.

The Source Forest will be the forest where the Certification Authority exists and where all the certificate templates are configured. The Target Forest will be where the users and computers that need to enroll for certificates exist.

Two-way forest trust between the Source Forest and Target forests

It is required to have a Two-Way Forest Trust in place (See Create a two-way, forest trust for both sides of the trust for additional guidance). To limit clients from either forest to only certain resources in the other Selective authentication can be enabled to limit the scope of the cross-forest authentication that is allowed. Selective authentication is administratively intensive and requires careful consideration for configuration before implementation.

Configure your Certificate Authority

Before we can enroll for certificates from across the forest, a certificate authority needs to exist in the Source Forest.

If you would like guidance on installing a two-tier PKI hierarchy, see this wiki content: AD CS Step by Step Guide: Two Tier PKI Hierarchy Deployment

Enable LDAP referral support on Enterprise CA from Source Forest

After setting up the Certificate Authority, we need to allow configure AD CS to “chase the LDAP referrals”. This allows the AD CS Service to traverse the forest trust to look up user or computer information to build the certificate. The steps to enable LDAP referral on an Enterprise issuing CA check below.

Steps to enable LDAP referral

Run the command as administrator:

CertUtil -SetReg Policy\EditFlags +EDITF_ENABLELDAPREFERRALS
After modifying the LDAP referral setting, the Certificate Services service needs to be stopped and started:

Net Stop CertSvc & Net Start CertSvc
To view the current value run the command below, If the value is not shown then it is not enabled.

CertUtil -GetReg Policy\EditFlags

Add the Enterprise CA computer account to the Cert Publishers group in each target domain

Add the Enterprise CA computer to the Cert Publishers group in each target domain. This allows the CA to write certificates to each user’s account in those domains if the User certificate template is configured for this.

Launch: dsa.msc
Click on the Users container.
Double click on the Cert Publishers group.
Click on Add…
Click on Locations… and select the Source Domain and click on OK.
Click on Object Types… and select the computer checkbox and click on OK.
On Enter the object names to select (examples): enter the name of the Enterprise CA from the Source Forest.
Click on OK.

Make sure that AIA and CDP locations on the source Forest are available.

Now, ensure that the AIA and CDP locations are properly configured and reachable. This means that workstations, member servers, domain controllers, and other devices that will enroll certificates must be able to access these AIA and CDP locations.

Open the PKIview.msc on the source forest.
PKIview.msc is an Enterprise PKI tool for checking PKI health. You can find more information about this tool at the following ADCS Health Using Enterprise PKI Tool (PKIVIEW)
Locate the CDP and AIA Locations make sure that the status of each is on “OK”.
Test from the target forest that the locations mentioned are reachable if you are using LDAP locations or HTTP location make sure that this is working, if you are having issues on this section refer to Configure the CDP and AIA Extensions on CA1 | Microsoft Learn
I tested access to the web service on my CA www.contoso.com/certenroll/contoso-content-ca01.crl from the target forest make sure is reachable.

LDAP URIs for AIA and CDP locations are not going to work in the target forest, so please make sure that you have an HTTP-based URI as well.

Export and Publish the Root CA and the Enterprise CA certificate from the Source Forest to the Target Forest.

The certificate chain needs to be deployed to the target forest computers. Therefore, we need to export these certificates and publish them to the AD database of the target forest. If we have a two-tier hierarchy, both CA certificates need to be exported Root CA and Enterprise CA. On this case I used cmdlets, but you just need to make sure to export CA certificate and publish it in the Target Forest.

Connect to my Offline Root CA and export the certificate using the command below:
certutil -ca.cert <c:\root-ca-cert-filename.cer>
Connect to my Enterprise CA and export the certificate using the same command:
certutil -ca.cert <c:\Enterprise-ca-cert-filename.cer>
Copy the certificates “root-ca-cert-filename.cer” and “Enterprise-ca-cert-filename.cer” over RDP, SMB, Robocopy… to a domain controller in the target forest I save it on “C:\“ drive.
Login into a Target Forest domain controller as an Enterprise Admin account, then launch and elevated command prompt, and run the following commands to publish the PKI hierarchy chain to Active Directory.

RootCA

certutil -dspublish -f < c:\root-ca-cert-filename.cer> RootCA

Publishes the certificate into the Certification Authorities container in Active Directory, which is used to distribute trusted root CA certificates to domain-joined machines.
NTAuthCA

certutil -dspublish -f < c:\enterprise-ca-cert-filename.cer> NTAuthCA

Places the certificate in the NTAuthCertificates store in Active Directory. This store is used to confirm certificate-based authentication, such as smart card logon.
SubCA

certutil -dspublish -f < c:\enterprise-ca-cert-filename.cer> SubCA

Places the certificate in the Certification Authorities container under the Subordinate CA section.

Please keep in mind that the above commands have added the certificates to the “Active Directory Enterprise store”.

Over the next 8 hours if computer certificate autoenrollment is enabled in the forest, domain joined computers will pull down the Root CA certificate and add it to the Enterprise Trusted Root store, and the Issuing CA certificate will be added to the Enterprise NTAuth and Enterprise CA stores. When the computer autoenrollment runs it also checks to see if it needs to update certificates maintained in the “Enterprise” store.

⚠️ If you need to test this before the 8-hour window you can run the below CertUtil command to have the computer “Pulse” its autoenrollment code.

certutil -pulse

Understanding how clients enroll certificates

After setting up the environment, it's important to understand the PKISync method thoroughly, especially considering it is a legacy enrollment approach. In simple terms, PKISync involves copying a predefined set of configurations from the source forest to the target forest. This method relies on the following objects being copied as explained above:

pKICertificateTemplate objects (Certificate Templates):
These contain which certificate templates are available and their associated permissions. Anytime a change happens to a certificate template (including permissions) this object type will need to be ‘synced’ over to the target forest.
pKIEnrollmentService objects (Enterprise CAs):
These specify the Enterprise Certificate Authorities (CAs) that manage enrollment requests. These objects could reference an Enterprise Root or an Enterprise Issuing certification authority. Anytime permissions on the CA change, a certificate template is added or removed from the CA to issue, Key Recovery Agent configuration is changed, or the CA’s certificate has been renewed this object type will need to be ‘synced’ over to the target forest.
msPKI-Enterprise-Oid objects:
These have intended purposes values for certificates. Anytime a new certificate template is created, a new Application Policy is created or a new Issuance Policy, this object type will also need to be ‘synced’ over to the target forest.

Once these objects are copied to the target forest, clients needing enrollment do an LDAP query to their local forest domain controllers configuration partition to look up these three AD object types. With this information, clients can directly communicate with the Certificate Authority in the source forest using RPC/DCOM protocols.

This PKISYNC activity ensures that the necessary configurations are replicated to the target forest, enabling the cross-forest enrollment interaction between clients and the source forest's Certificate Authority.

Legacy enrollment flow on the same forest

Cross forest enrollment – Client simplified flow when the ADObjects are already downloaded

PKISYNC.PS1 Script Overview

Microsoft has documented the script at the link below. You may simply copy and paste it.
The plain text script can be found on: AD CS: PKISync.ps1 Script for Cross-forest Certificate Enrollment | Microsoft Learn
Official Microsoft Documentation: AD CS: Deploying Cross-forest Certificate Enrollment | Microsoft Learn

Copy Command:

.\PKISync.ps1 -sourceforest <SourceForestDNS> -targetforest <TargetForestDNS> [-sourceDC <SourceDCDNS>] [-targetDC <TargetDCDNS>] [-type <CA|Template|OID> [-cn <ObjectCN>]] [-f] [-whatif]

Delete Command:

.\PKISync.ps1 -targetforest <TargetForestDNS> [-targetDC <TargetDCDNS>] [-type <CA|Template|OID> [-cn <ObjectCN>]] [-deleteOnly] [-whatif]

Arguments Explained:

sourceforest Specifies the DNS name of the forest from which objects will be processed
targetforest Specifies the DNS name of the forest to which objects will be processed.
sourcedc Specifies the DNS name of the Domain Controller (DC) in the source forest responsible for processing objects.
targetdc Specifies the DNS name of the Domain Controller (DC) in the target forest responsible for receiving processed objects.
type Specifies the type of object to process. Valid options are:
CA: Process Certificate Authority objects.
Template: Process Certificate Template objects.
OID: Process OID (Object Identifier) objects.

- cn Specifies the common name of the specific object to process. Do not include "cn=" in the name.

This choice is only valid when -type is specified and is used to process a specific object within that type.

- f Forces the overwrite of existing objects in the target forest during the copying process. This choice is ignored if objects are being removed

- whatif Displays a preview of objects that will be processed without performing any actions.

- deleteOnly Delete objects in the target forest if they already exist, without copying new objects.

Examples of how to use PKISync.PS1

Example 1: Copy all templates

Copy all templates from the source forest to the target forest, with the "-F" option forcing overwrite if templates already exist. It includes copying the Enrollment Services Container, Certificate Templates Container, and OID Container from the source forest to the target forest.

Command:

.\PKISync.ps1 -sourceforest contoso.com -targetforest Fabrikam.com -f

If we want to make sure that all these distinguished names were copied from the Source Forest to the Target Forest and we can use the ADSIedit.msc console to see this by opening the configuration partition and going to CN=Public Key Services,CN=Services,CN=Configuration,DC=Fabrikam,DC=com.

Figure: Illustration of the Objects copied from the Source Forest to the Target Forest.

Example 2: Copy specific templates

If you are looking to update a particular "Certificate template" use the following command to copy the template from the source forest using its specific Common Name (CN). If a template with the Canonical Name "User" already exists in the target forest, it will not be copied. To overwrite an existing template, append the”-F” argument at the end of the command.

Note: it is important to run in this command with argument to copy the OID if we are planning to copy a duplicate template.

Command:

.\PKISync.ps1 -sourceforest contoso.com -targetforest Fabrikam.com –type template –cn user

Example 3: Copy AD Object Containers

This example will copy the AD Containers from the source forest to the target forest with all the AD objects into the selected one. In this example copy of all Enterprise-OID objects from the existence will not be completed however if we need to add the "-F" argument.

Command:

.\PKISync.ps1 -sourceforest contoso.com -targetforest Fabrikam.com –type oid

Best practice

As discussed, the recommendation is to use the CEP/CES method due to its advantages: enhanced security and scalability. This method aligns with current best practices, even though PKISync was designed for Windows Server 2003/XP and is considered outdated. However, if you choose to go ahead with PKISync, here are some recommended guidelines to follow:

Automate the synchronization process by creating a Scheduled task that runs the PKISync script. But this also comes with a significant risk as by default writing these objects in the target Forest the account running the script MUST be an Enterprise Admin level account. This can be mitigated to some extent by giving a lower-level admin account permission to create and delete objects at the “CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRoot” container level and below.

The simplest method for keeping updated AD objects is to run the PKISync.ps1 script in a scheduled task. To have the best results the task should be run often.

Schedule Task Automatization

To automate the script, create a scheduled task on the target domain controller. For example, configure it to run every hour

Program/Script: Powershell.exe

Arguments: -file C:\Users\Administrator\Desktop\.\PKISync.ps1 -sourceforest contoso.com -targetforest Fabrikam.com -f

Once configured, the task will run automatically.

Depending on the PowerShell execution policy settings in your forest, you may need to adjust the execution policy before the script will be allowed to run, since this is not a signed script file.

For more details, see: AD CS: Managing Cross-forest Certificate Enrollment | Microsoft Learn

And the Schedule task should be done; I hope this information were helpful for you.

Conclusion

The PKISync.ps1 script might be old, but it still does what it’s supposed to syncing PKI objects across forests so clients in the target forest can grab certificates from the source forest. It’s not fancy, and it’s definitely considered legacy, but if you set it up right and automate it, it works.

That being said, for new or long-term environments I’d recommend looking at CEP/CES since it’s the modern and more secure way forward. Still, PKISync can save the day in certain cases where you just need something simple that works.

At the end of the day, the key is keeping your configs updated, making sure the right trusts are in place, and staying mindful of security. If you’ve made it this far thanks for reading, and good luck with your own PKI adventures! 🚀

👉 Stay tuned for the third part, where I’ll dive into CEP/CES.!

What is going on with RC4 in Kerberos?

WillAftring — Mon, 26 Jan 2026 19:34:08 GMT

Howdy everyone! The cat is out of the bag when it comes to Microsoft’s forward outlook on RC4 usage in Kerberos. In the past few months, we have published the following.

As you can see, the writing is on the wall for RC4. However, we also understand that many folks still have dependencies on RC4 for one reason or another. My goal with this blog post is to help clarify things for those folks.

I know that not everyone is interested in the nitty gritty of how everything works and just want quick answers, so I am going to start with those.

Frequently Asked Questions (FAQ)

If this FAQ does not answer your questions about RC4 dependencies in your environment, please feel free to reach out to stillneedrc4@microsoft.com with your question and information on how you are still leveraging RC4.

Is RC4 being removed from Windows?

As of January 2026, there are currently no plans to remove RC4 from Windows. However, DES has been removed from Windows Server 2025 and Windows 11 24H2 and newer versions. For additional information please see Removal of DES in Kerberos for Windows Server and Client | Microsoft Community Hub

I have a machine running a mission critical service that only supports RC4. What do I do?

If you have defined the DefaultDomainSupportedEncTypes registry key on all relevant Windows Key Distribution Centers (KDCs), then you should not expect any breaking changes. Alternatively, if you have defined the msds-SupportedEncryptionTypes  attribute for the service account and the bitmask includes RC4 then no action needs to be taken.

I have a Windows Server 2003 deployment that we are working to migrate away from, but I need them to work in the meantime. What do I do?

As I'm sure you already know Windows Server 2003 left end of life in 2015 . The highest priority should be migrating to a version of Windows that is currently receiving security updates. Thus, this machine is treated the same as any other machine that needs RC4 as Windows Server 2003 does not support AES-SHA1.

I am seeing RC4 usage in my environment through Event Id 4768 and Event Id 4769 in the Security Event Logs on my KDC. Will I be broken by these changes?

The existence of Event Id 4768 and Event Id 4769 in the Security Event Log is not necessarily an indication that things will break in isolation. While in the initial deployment phase of the 2026 January Cumulative updates (often referred to as audit mode), I recommend looking in the Windows System Event Log for the newly added Event Id 201, 202, 206, and 207. We specifically created these new events to identify interactions that are at risk as part of the RC4 default disablement plan. If you see any of those new events generated in the Windows System Event Log, then you are at risk for breaking changes upon moving to enforcement mode.

I have an old service account that doesn't have AES-SHA1 keys. Will I be broken?

Maybe. At-risk service accounts will be referenced in Windows System Event Log with Event Id 202, or Event Id 207. As for remediation, there are a few options available to this specific problem.

The best recommendation would be to reset the account password on a modern Windows KDC. During a password change, new keys are generated automatically with all the available Kerberos Encryption Types.

If that is not possible, then either defining the DefaultDomainSupportedEncTypes or configuring the msds-SupportedEncryptionTypes on the target service account to include RC4 would be your best bet.

How does DefaultDomainSupportedEncTypes work?

When making a service ticket request, the KDC will search for the target service accounts msds-SupportedEncryptionTypes Active Directory (AD) attribute on the target service account. If that attribute is either 0 or undefined, then the assumed encryption type value will be applied. The assumed encryption type is what the KDC assumes that all accounts running supported Windows versions in an AD domain support.

The DefaultDomainSupportedEncTypes registry key controls what the KDC will apply as the assumed encryption types. By default, the assumed encryption types are 0x27 (DES, RC4 and AES-SHA1 session keys). On Windows Server 2025, this default value is 0x24 (RC4, and AES-SHA1 session keys) because DES has been removed from Windows Server 2025. If you would like to define the assumed encryption types, you MUST ensure that all accounts within the domain support the configured value. While reviewing this configuration, it's worth investigating if DES is necessary in your environment. For additional information, please see: DES Detection · microsoft/Kerberos-Crypto Wiki.

The configuration of the supported Kerberos encryption types through the DefaultDomainSupportedEncTypes registry keys is almost identical to the msds-SupportedEncryptionTypes bitmask.

For example:

0x18 in msds-SupportedEncryptionTypes means AES128-CTS-HMAC-SHA1-96 and AES256-CTS-HMAC-SHA1-96
0x18 in DefaultDomainSupportedEncTypes means AES128-CTS-HMAC-SHA1-96 and AES256-CTS-HMAC-SHA1-96

CAVEAT: The bitmask of 0x20 is ONLY honored when applied to DefaultDomainSupportedEncTypes.

More additional details on the Supported Encryption Type bitmask please see [MS-KILE]: Supported Encryption Types Bit Flags | Microsoft Learn

What is happening with the January 2026 Cumulative Updates?

With the January 2026 Cumulative Updates, we are beginning to change the default behavior of the assumed encryption types on a KDC. We will be removing RC4 as one of the assumed encryption types.

We have added new auditing to help detect RC4 usage that is currently permitted through unconfigured assumed encryption types.

On installing the April 2026 Windows Cumulative Updates on supported DCs, we will be moving to an enforcement phase where usage of RC4 through the assumed encryption types will now be blocked. Enforcement mode can be rolled back to audit mode.

On installing the July 2026 Windows Cumulative Updates, the behavior will be identical to April 2026, however you will no longer roll back to audit mode.

For additional reading I recommend reading the How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 - Microsoft Support in its entirety.

Closing things out

Security hardening is never easy, and we empathize with the IT professionals who are working to harden their environment. Migration and upgrades are not always an easy process, and we at Microsoft want to help make this process as smooth as possible. As mentioned in other blog posts, we have a few Kerberos RC4 identification scripts that are available on GitHub at Microsoft/Kerberos-Crypto. And to help us understand your RC4 dependencies please feel free to drop us a mail at stillneedrc4@microsoft.com.

How to search for deleted memberships of a group in Active Directory

dcascante — Mon, 01 Dec 2025 22:28:55 GMT

Have you ever seen a user suddenly lose access to a resource, only to discover they were removed from a group—but with no record of when or how it happened? Tracking deleted group memberships in Active Directory (AD) can be challenging, especially when auditing is not enabled or the logs don’t capture which users were removed. If someone deletes multiple memberships from a Security Group, the Active Directory Recycle Bin won’t help, since it only retains deleted objects—not the details of which accounts were stripped from the group.

In other to obtain a list of the user's memberships that were deleted, you will need to look for them on the Group's object metadata. There are 2 methods:

With the repadmin object metadata:

You can run the command repadmin /showobjtmeta * <DN OF THE GROUP> for example: repadmin /showobjmeta * "CN=Test Group,OU=Users,OU=Test OU,OU=Contoso,DC=Contoso,DC=com" > TestGroup.txt

This will give you all the object's metadata, and we can look at the "Member" attribute:

The ones under "Present" are the users that are still part of the group. And the ones under "Absent" are the ones that have been removed.

Using the Get-ADReplicationAttributeMetadata command in PowerShell:

You can use the Get-ADReplicationAttributeMetadata command in PowerShell with the following parameters to obtain all the "LastOriginating-DeleteTime" value, which will show you all the deleted users based on their deletion date and time.

get-ADReplicationAttributeMetadata 'DN OF THE GROUP' -Server <SERVER WHERE THE LAST CHANGE WAS DETECTED> -ShowAllLinkedValues | Select-Object LastOriginatingDeleteTime, attributevalue

When reviewing group membership, the presence of a valid date indicates that the user was deleted from the group. For example, the Test-Deletion account shows an actual deletion date, confirming it was removed. In contrast, if the metadata displays an impossible value such as 12/31/1600, it means no deletion date exists. This is the case for the Test User account, which shows the impossible date, signaling that the user is still part of the group and has not been removed.

Cross Forest - Certificate Enrollment

Manuel_Alvarez_V — Wed, 22 Oct 2025 15:17:20 GMT

Welcome to part one of my blog series on Cross Forest Certificate Enrollment. Nowadays, businesses often run across multiple Forests for distinct reasons. You would like to ensure secure authentication using certificates spanning Active Directory Forests within your enterprise. Cross Forest Certificate Enrollment is one solution that can be leveraged to enable the centralized management of digital certificates while maintaining security.

In this blog, we will dive into Cross Forest Certificate Enrollment. We will explore its functionality, configuration, and best practice for companies of all sizes. We will also assess which of the available solutions can best suit your company's needs.

You will find everything you need to correctly configure Cross Forest Enrollment, including:
• Types of methodologies and requirements.
• Pros & Cons of each solution type.
• Best practice and recommendations.

An important reference that should also be reviewed with this blog is on the AD CS: Deploying Cross-forest Certificate Enrollment | Microsoft Learn

Types of methods

Cross-forest certificate enrollment offers two methods: The preferred choice involves using the “CEP & CES roles” in Windows Server's Active Directory Certificate Services, while the alternative method uses a “PowerShell script called PKISync (PKISync.ps1).”

NOTE:

PKISync.ps1: It was created originally to support Windows XP/Vista and Windows Server 2003/2008 clients to be able to support Cross Forest certificate enrollment and is considered a legacy solution but is still valid for newer operating systems.
CEP & CES: It was released with Windows 7/2008 R2 and is the preferred method to support Cross Forest certificate enrollment going forward. Please understand that CEP & CES is NOT Certificate Services Web Enrollment. For more on this role see the following - Certification Authority Web Enrollment Role Service in Windows Server | Microsoft Learn

Certificate Enrollment Policy (CEP) and Certificate Enrollment Service (CES)

Requirements

Have at least “Windows 7 / Windows Server 2008 R2” or later as certificate enrollment clients.
Have Windows server 2008 R2 (Currently supported Windows Server 2016) or higher Certification Authority.
Set up and create AD CS environment in at least one of the forests to issue certificates.
CEP and CES web service roles can be installed on the Certification Authority or on another member server in the same forest as the certification authority.
Do not place AIA or CDP locations on LDAP; they must be available via HTTP.
DNS name resolution should be correctly configured for resolution between forests and CEP/CES servers.
Kerberos authentication cross forest boundaries REQUIRES a two-way forest trust.

High level overview of how CEP CES works:

The client begins by connecting with the Certificate Enrollment Policy (CEP) web service over HTTPS, which is configured to run on port 443 (it can be changed later), allowing certificate enrollment.
The CEP servers URI can be configured through either local or group policy. The CEP web service then queries the domain controller via LDAP for certificate templates (pKICertificateTemplate objects), enterprise CA services (pKIEnrollmentServices objects), and other relevant objects (msPKI-Enterprise-Oid objects). The collected data informs the client of the templates it can enroll for and the enterprise CAs available.
The client then connects to the Certificate Enrollment web service (CES) specified by the CA.
The CES impersonates the client's security context, requests a certificate from the certification authority via DCOM.
The issued certificate is returned to the client securely.

Representations of this functionality.

⚠️Note: While the image suggests that the CEP/CES roles run on different servers, it is common to have both roles installed on the same server.

Pros and Cons of CEP CES

Pros

Efficiency and Synchronization of certificates: All certificate template, and certification authority management tasks can be done from the Active Directory Forest where the CA – CEP/CES servers exist. When a change is made to a certificate template it does not require any more action to get the template configuration change synchronized to the other forest.
Web-Based technology: CEP and CES are web-based services, making them accessible over HTTPS. This can simplify cross-forest enrollment by only needing to have https-based ports opened between the forests.
Certificate renewal enrollment CEP/CES can be used for certificate key-based renewal, reducing the need for manual certificate requests. This is particularly useful for large organizations with many users and devices.
Scalability: These services are scalable and can manage a high volume of enrollment requests, making them perfect for large companies with multiple forests.
Allow Non-Domain Joined Devices to enroll certificates: The CEP/CES method allows non-domain joined machines to enroll certificates. See the following for more information - Enabling CEP and CES for enrolling non-domain joined computers for certificates - Microsoft Community Hub
Troubleshooting: For more precise troubleshooting within CEPCES, we can collect granular information from multiple logging sources—such as Event Viewer logs for the EnrollmentPolicyWebService and the EnrollmentWebService, along with CEP logs, CES logs, IIS logs, and other available debug logs—to identify and resolve issues more effectively.
Security: Since communication is over HTTPS this method is secure, and the user never communicates directly either to a DC or the CA.

Cons

Complexity: The configuration and management of CEP and CES can be complex, especially for administrators who are not familiar with PKI implementations.
Authentication: If there are Cross Forest enrollment implications, CEP & CES configured for Kerberos Authentication can only be used over a two-way forest trust.

PKI Sync Script (PKIsync.PS1)

Requirements

It has been around since Windows Server 2003. Windows Server 2016 and newer operating systems are currently supported.
Two-way Forest trust is MANDATORY between the source forest and target forest.
ADCS environment configured with at least with one Enterprise CA on the source forest assigned.
Uses PowerShell to synchronize the PKI objects between the source forest (Where CA exists) and the target forest (where the users/computers exist). Uses an Enterprise AD account to run the script, which interacts with Active Directory to synchronize certificates and templates. This requires permissions to access AD partitions on both the source forest and target forest. If we would like to automate the script, this would require task scheduler rules.

How it works:

It is a Script that synchronizes the PKI AD objects below from the source forest to the target forests:

Certificate templates (pKICertificateTemplate).
PKI enrollment Services objects (Enterprise CA objects) that are available (pKIEnrollmentService).
Enterprise OID objects (msPKI-Enterprise-Oid).

The script copies the required Active Directory Certificate Services objects from one forest to another forest and will modify the number of objects underneath the Public Key Services container in the forest-wide configuration partition. This does require an elevated administrator account that is a member of the Enterprise Admins group in the target forest as this group is by default is allowed to write in the configuration partition.

Representations of this functionality and enrollment.

Here shows how does it works, to understand how it works in detail visit my other blog of PKIsync.ps1.

Representation of his flow

Pros and Cons of PKISync Script

Pros

Simplified Deployment: It is a script that copies the necessary PKI AD objects from the source AD forest that has the CA to the target forest.
Does not require extra servers/services: PKISync uses PowerShell scripting, which might save money and time at first compared to setting up CEP/CES, especially for smaller organizations with limited resources.
Flexible: PKISync is a script that copies certificate-related information between forests. It does not require dedicated server roles.

Cons

Lack of Authentication and impersonation: Since it is a script, it does not impersonate the client’s security context during the certificate enrollment process. This can lead to improper authentication and a failure to properly update the PKI objects.
Logging: The script may not integrate with the normal logging and auditing features. There may be issues with success and failure logging into event viewer unless AD Object Auditing is enabled specifically.
Management Issues: We have seen cases where PKISync has been used and the PKI Administrators have changed the CA settings, such as adding or removing a certificate template that the CA should issue. Or they have made a new certificate template, altered the settings of an existing one, or updated the permissions on the certificate template. Then the PKI Admin may not run the PKISync.ps1 file for all forests to apply the new configuration to them. This will cause inconsistencies and enrollment failures leading to case creation with Microsoft.
Less Security: PKISync may not provide the same security as the CEP/CES does, since PKISync requires permanent two-way trust, with a manual or scheduled synchronization in between using the password of an elevated administrator account that runs periodically. This may be viewed as a potential security concern.
Port Requirements: The script requires several ports to be opened to support communication between forests. The port requirements are client to domain controller and client to the AD CS Certificate Authority.

See this article for general ports required for clients to communicate with Domain Controllers: Configure firewall for AD domain and trusts - Windows Server | Microsoft Learn

See this article for general ports required for clients to communicate with Certificate Services: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-netwo…

Conclusion CEP/CES vs PKISync

In conclusion, cross-forest certificate enrollment is an important solution for modern businesses operating across multiple forests, ensuring centralized management and secure authentication. There are two main approaches:

The CEP & CES solution – the preferred method, offering greater efficiency, scalability, and security via HTTPS.
The legacy PKISync.ps1 script – while it may appear simpler to deploy, it presents significant security and management challenges and is generally not recommended in any scenario, including smaller environments (since they, too, must manage more than one forest).

Although both methods exist, the reality is that CEP & CES remains the better choice for organizations of all sizes, delivering robust security, efficient enrollment, and centralized oversight.

Understanding and Troubleshooting - Strong Certificate Name Mapping in Active Directory

Chris_Cartwright — Fri, 05 Sep 2025 23:20:12 GMT

Hello team, Manuel here. In recent years, Microsoft has introduced Strong Certificate Name Mapping (Strong Mapping) as a requirement for certificate-based authentication in Active Directory environments. These changes were driven by security improvements to address vulnerabilities such as CVE-2022-26931, CVE-2022-26923, and CVE-2022-34691, as well as broader efforts to harden Kerberos and PKI authentication.

Starting with the September cumulative updates which will be released on September 9, 2025, compatibility mode will no longer be supported. Any domain controllers (DCs) running in compatibility mode via the StrongCertificateBindingEnforcement registry setting must transition to enforcement mode. Organizations must act now to prepare, validate, and re-issue certificates as needed if they haven’t already.

This article provides a deep technical overview, common errors, troubleshooting scenarios, and guidance for enterprise and government deployments.

TL;DR (at a glance)

If you don’t have Event ID 39,40, or 41 from the Kerberos Key Distribution Center in your System log, you’re probably ready for September, otherwise you’re likely to be in for a bumpy ride.
If you use Enterprise CA + templates → Using templates that are built from AD with the Automatic SID OID extension added is simplest.
If you use Supply in the Request / offline certs commonly found in SCEP implementations → SAN URI Mapping or Manual Mapping.
If you’re in a government/federated smart-card scenario with strict PKI controls → Strong name mapping via Group Policy.
Windows Server 2016 KDC does not support SAN URI strong mapping or Strong name mapping via Group Policy. Windows Server 2019 or higher operating system is required for these options.

Previous Guidance

There have been a few articles/posts released for these changes. The first that covers the hardening changes themselves and their timeline is found at KB5014754: Certificate-based authentication changes on Windows domain controllers - Microsoft Support.

SAN URI capabilities for SCEP based solutions were introduced in Preview of SAN URI for Certificate Strong Mapping for KB5014754 | Microsoft Community Hub. This was designed to ease the administrative burden in MDM environments.

Strong Name Mapping via Group Policy, also known as Tuples, is documented at Enable strong name-based mapping in government scenarios | Microsoft Community Hub. This was introduced to provide a way for group policy

Registry Behavior Changes

I know that we were talking about these changes frequently but here’s a short summary of the timeline this year.

After installing the February 2025 Cumulative updates, domain controllers behave as follows:

Registry Path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc\StrongCertificateBindingEnforcement

Registry setting	Old Behavior	New Behavior
Not configured (default)	Compatibility mode	Enforcement mode
StrongCertificateBindingEnforcement = 2	Enforcement mode	Enforcement mode
StrongCertificateBindingEnforcement = 1	Compatibility mode	Compatibility mode

⚠️Important: Restart of the DC or KDC service is NOT required when applying this registry value.

Once the September 9, 2025 cumulative update is installed, the registry value will no longer be honored. Enforcement mode will be the only supported mode. If you are still getting Event IDs 39, 40, and 41 from the Kerberos Key Distribution Center in your System log, you’re likely to have some issues once you patch your DCs, and you need to immediately investigate strong mapping solutions.

The Options for Strong Mapping

Automatic SID OID Extension

This option has been available since May 2022. It uses OID 1.3.6.1.4.1.311.25.2 to embed the requester’s SID directly in the certificate. If you’re leveraging an Enterprise CA with online templates (Build from This Active Directory Information), you’re already configuring certificates with this OID.
Build from This Active Directory Information option

Certificates Issued with Build from This Active Directory Information option, and how automatically populate the SID of the requester to the certificate.

Requirements:

Microsoft Enterprise CA (AD domain member).
Certificates issued from templates that automatically populate AD attributes.
KB5014754 or later installed on both CA (for certificate issuance) and DC (for reading the new OID).
Certificates that were issued prior to this patch being installed on the CA would have to be reissued to get it.
Limitation: Not available for manually crafted requests where attributes are supplied in the CSR.

Explicit Manual Mapping

At this stage, you might be wondering how things work when using Supply in the Request templates. Beginning with the May 2022 update, Microsoft introduced categorizations of strengths for the options for explicit/manual mapping of a certificate to its corresponding Active Directory identity (this applies to both computer and user objects). Notably, we recommended explicit mappings be implemented by associating a certificate with an AD object by using the Issuer Name of the CA together with the Serial Number of the certificate that you want to assign. That is our recommended Strong Mapping method.

The official documentation details all supported methods of explicit/manual mapping. Starting in February 2024, the Active Directory Users and Computers (ADUC) console defaults to using X509IssuerSerialNumber for manual mapping.

Active Directory User and Computer method (X509IssuerSerialNumber):

When a certificate must be strongly bound to a specific identity, you can use the ADUC console. Simply right-click the object, select “Name mappings…”, and ADUC will automatically convert the certificate properties into a strong mapping. The resulting data is written to the altSecurityIdentities attribute, ensuring the identity is strongly mapped.

Open ADUC and locate the identity

Open Active Directory Users and Computers (ADUC).
Navigate to the user or computer object that will own the certificate.
Right-click the object ▸ Name Mappings… (matches your “Name Mappings…”).

Add the certificate and choose strong mapping

In Name Mappings, go to the X.509 Certificates tab → click Add…
Browse to the exported .cer file and select it.
In Add Certificate, confirm the parsed values for Subject, Issuer, and Serial
Ensure both boxes are checked:

Use Issuer for alternate security identity
Use Serial Number for alternate security identity

Click OK, then Close.

Verify the strong mapping was written

Open the object’s Properties → Attribute Editor tab.
Confirm altSecurityIdentities now contains an entry with the issuer and serial (your first screenshot).

Example of what you’ll see (format varies by issuer DN length):

X509:<I>DC=com,DC=contoso,CN=EntCA<SR>150000000000001af17557b8634e501500000053

Manually generating mapping values for explicit mapping

In most cases, the best option is to re-issue certificates with the new SID OID extension (1.3.6.1.4.1.311.25.2). However, if re-issuing is not possible, you can still achieve compliance by creating a manual strong mapping in Active Directory.

This works by adding a mapping string into the user’s or computer’s altSecurityIdentities attribute. The mapping tells Active Directory exactly which certificate belongs to which identity.

How it works

Take the Issuer and Serial Number fields from the certificate you want to map.
Example from a cert:

o Issuer: CN=CONTOSO-DC-CA, DC=contoso, DC=com

o SerialNumber: 2B0000000011AC0000000012

Convert both values into the reverse format required by AD:

The Issuer DN must be reversed (so CN=… , DC=contoso, DC=com becomes DC=com,DC=contoso,CN=…).
The Serial Number must also be reversed by byte order (e.g., A1B2C3 → C3B2A1).

Build the final mapping string:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>1200000000AC11000000002B

Add that mapping string to the account’s altSecurityIdentities attribute.
Example PowerShell:

Set-ADUser 'DomainUser' -Replace @{altSecurityIdentities= "X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>1200000000AC11000000002B"}

PowerShell Functions that you could use for automation:

Flip the Issuer (FQDN)

function Flip-FQDN {
    param([String] $FQDN)
    $arr = $FQDN.Split(',').Trim()
    [array]::Reverse($arr)
    return $arr -join ','
}

$originalFQDN = "CN=EntCA,DC=contoso,DC=com"
$flippedFQDN = Flip-FQDN -FQDN $originalFQDN
Write-Output "Flipped FQDN: $flippedFQDN"

Flip the Serial Number (byte order)

function Flip-ByteOrder {
    param([String] $byteString)
    if ($byteString.Length % 2 -ne 0) { throw "Error: byte string is expected to have even length" }
    $length = $byteString.Length
    $newstr = ''

    for ($i = $length - 1; $i -gt 0; $i -= 2) {
        $newstr += $byteString[$i - 1] + $byteString[$i]
    }
    return $newstr
}
$serialNumber = "5300000015504e638b5775f11a000000000015"
$flippedSerialNumber = Flip-ByteOrder -byteString $serialNumber
Write-Output "Flipped Serial Number: $flippedSerialNumber"

SAN URI Mapping

There is also the possibility of mapping a SID manually inside the certificate and associating it with a specific identity. This approach is highly useful in scenarios where offline certificates are required and deployed in large numbers, or where you want a more persistent binding. For more details, refer to Matthew’s blog post.

Preview of SAN URI for Certificate Strong Mapping for KB5014754 | Microsoft Community Hub

This capability was added to Intune in November 2024. Uses SAN tag format:tag:microsoft.com,2022-09-14:sid:<OnPremisesObjectSIDValue>

Support:

Windows Server 2019 and Newer versions (after March 12, 2024 patches).
Not supported on Windows Server 2016, if the KDC is this Windows server needs to migrate his DCs to 2019 to make it work.

Requires Intune configuration and testing.

For more information you can refer to the link: Support tip: Implementing strong mapping in Microsoft Intune certificates | Microsoft Community Hub

Other third party MDMs have also incorporated this capability in their products as well and have their own Configuration documentation to support it. Organizations should leverage these third parties’ support services for configuration guidance.

Strong name mapping via Group Policy (Tuples)

This method is designed primarily for government and smart card federated authentication environments, where traditional strong mappings (SID OID, Issuer + Serial) may not be practical due to large numbers of externally issued certificates (Not built from AD). This option has been available since January of 2025.

It lets you treat certain “weak” mappings (such as Issuer/Subject AltSecID or UPN mappings) as if they were strong mappings, provided your PKI meets specific security guarantees. When both conditions match (correct CA + correct Issuance Policy OID), the DC upgrades those weak mappings to strong mappings.

How to configure Strong Name-Based Mapping (Tuples)

Enable and configure:

Confirm that there are issuance policy OID(s) added to certs
GPO on DCs →
Computer Configuration > Administrative Templates > System > KDC > Allow name-based strong mappings for certificates → Enable.
Add policy tuples (one per CA/thumbprint as needed):

 <IssuerCAThumbprint>;<IssuancePolicyOID(s)>;<IssuerSubject/UPNSuffix=corp.contoso.com>

Examples:

FFE06....20E67;2.16.840.1.101.3.2.1.3.45;IssuerSubject
EC526....D6556;2.16.840.1.101.3.2.1.3.45;UPNSuffix=corp.contoso.com
7972D....B7736;2.16.840.1.101.3.2.1.3.45,2.16.840...3.44;UPNSuffix=corp.contoso.com,UPNSuffix=my.corp.contoso.com,IssuerSubject

Note: You cannot repeat thumbprints. CA thumbprints with multiple UPN Suffixes or OIDs are listed once with OIDs and Suffixes/IssuerSubject separated by commas

If IssuerSubject was configured, then you still must populate the altsecurityidentities in this format:
```
X509:<I>IssuerName<S>SubjectName
```
Example:
Issuing CA:
```
CN=Contoso Issuing CA 1,DC=contoso,DC=com
```
Subject:
```
CN=Bob,OU=Employess,OU=PKI
```
Altsecid attribute value on Bob’s account for this mapping method:
```
X509:<I>DC=com,DC=contoso,CN=Contoso Issuing CA 1<S>OU=PKI,OU=Employees,CN=Bob
```
(Due to this administrative overhead, we do not recommend IssuerSubject unless you need it, and the only reason to need it is if you have confirmed that software in you environment requires UseSubjectAltName set to 0 on your DCs)

Validate your configuration by ensuring that you do not have Event ID 313 in the Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational log.

⚠️ Use only when PKI and issuance processes truly meet the required guarantees

Another important note to add is that if you are using the GPO setting “Process even if the Group Policy objects have not changed” under “Computer Configuration > Administrative Templates > System > Group Policy > Configure registry policy processing” you may have intermittent authentication failures for all users relying on tuples across the environment. We recommend that you disable that policy or simply do not apply it.

Common pitfalls (and fixes)

Compatibility mode “not working”
- Move to enforcement now and complete strong mapping. Compatibility mode is going away.

UseSubjectAltName = 0
- Prevents UPNs in SAN from being used
- Should only be used where required
- Requires either explicit manual mappings or IssuerSubject Tuple configuration
SAN-URI and Tuples are not supported on Server 2016. Windows Server 2019 or higher operating system is required for these options.
Explicit Manual Mapping Gotchyas
- Use sparingly
- Reverse Issuer DN order and Serial byte order correctly.
- Map to the correct object type (user cert → user; device cert → computer).
- Avoid multiple conflicting mappings in altSecurityIdentities.
Certificate Renewals
- If using Issuer+Serial Explicit Manual mapping, a new serial means update the mapping.
- If using Build from this Active Directory, we won’t need to renew it because AD is building the Strong Name Mapping from the SID requestor.
Strong name-based mapping tuples
- CA thumbprints must be unique across all entries per tuple; OIDs must be present on the cert.
- UPNSuffix= must exactly match the SAN UPN suffix and requires SAN UPN (don’t set UseSubjectAltName=0).
- Invalid tuple → Event 313 (KDC Operational log).
- Do not use “Process even if the Group Policy objects have not changed” under the Group Policy object “Computer Configuration > Administrative Templates > System > Group Policy > Configure registry policy processing”

User migrations
- SidHistory is not checked
- Requires extra planning with options such as:
  - Users would need new certificates issued with the new SID signed into the certificate
  - Issuance policy could be added to the PKI to support tuples
  - Explicit manual mapping

Consuming the System event logs for events and automatically mapping certificates to accounts is not recommended as it is a security bypass.

Events:

Event ID 39 — No strong mapping

Where: System (Warning in Compatibility mode, Error in Enforcement mode)

Meaning: The KDC saw a valid certificate but could not map it strongly (no explicit mapping, key trust, SID OID, or other strong method).

Fields typically included: User, Certificate Subject, Issuer (FQDN), Serial Number, Thumbprint.

Action: Implement a strong mapping (e.g., Option 1 SID OID, Option 2 Issuer+Serial, Option 3/4 SAN URI on WS2019+, or Option 5 tuples), then retest.

Older OS note: On Windows Server 2008 R2 SP1 / 2008 SP2, the analogous event is ID 41 (see below).

Event ID 40 — Certificate predates account (Compatibility mode only)

Where: System (Error)

Meaning: The certificate was issued before the AD account existed and no strong mapping could be found, so it was rejected.

Fields typically included: User, Certificate Subject, Issuer (FQDN), Serial Number, Thumbprint, Certificate Issuance Time, Account Creation Time.

Action: Reissue with a strong mapping (or adjust Certificate Backdating policy if appropriate). Use one of the strong methods, then retest.

Older OS note: On Windows Server 2008 R2 SP1 / 2008 SP2, the analogous event is ID 48.

Event ID 41 — User SID does not match Certificate SID

Where: System (Error)

Meaning: The SID embedded in the certificate’s extension does not match the AD account’s SID → authentication fails.

Fields typically included: User, User SID, Certificate Subject, Issuer (FQDN), Serial Number, Thumbprint, Certificate SID.

Action: Replace the certificate with one that carries the correct SID (Option 1), or use another strong mapping (Option 2/3/4/5) that matches the intended identity.

Older OS note: On Windows Server 2008 R2 SP1 / 2008 SP2, the analogous event is ID 49.

Event ID 313 — Invalid Certificate Strong Name Match Policy

Where: Kerberos-Key-Distribution-Center\Operational (Error)

Meaning: Something went wrong when trying to read the Strong name mapping via Group Policy (Tuple)

Fields typically included: Faulting line: X

Action: Ensure that CA thumbprint is unique, the right amount of characters, no special characters, disable the setting “Process even if the Group Policy objects have not changed” from “Computer Configuration > Administrative Templates > System > Group Policy > Configure registry policy processing”

What's the deal with Kerb3961?

WillAftring — Tue, 03 Jun 2025 14:34:20 GMT

Howdy, everyone! I wanted to write this blog post to discuss the new Kerb3961 library introduced in Windows Server 2025 / Windows 11 24H2. It is (hopefully) making encryption type (etype) usage within Kerberos much easier to anticipate and understand.

Let's start with...

What is Kerb3961?

Kerb3961, named after RFC3961, is a refactor of the Kerberos cryptography engine in its own library. This library is now the authoritative source of:

Etype selection
Etype usage
Etype management

For the average IT administrator, the part that is going to be most interesting is #1.

The Kerb3961 policy engine is what will authoritatively determine what etypes are available given different Kerberos key usage scenarios. Whereas in previous Windows releases, there were instances of hard coded etype usage due to technical limitations at the time of implementation.

Kerb3961 still leverages existing Kerberos etype configuration group policy: Network security Configure encryption types allowed for Kerberos - Windows 10 | Microsoft Learn. However, it no longer honors the legacy registry key path of:

HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Lsa\Kerberos\Parameters
REG_DWORD SupportedEncryptionTypes

As a reminder, the group policy mentioned above is used to configure the supported encryption types for a machine account. The machine then propagates this information into Active Directory (AD) where it is stored in the msds-SupportedEncryptionType attribute for the account.

It has no effect on non-etype related Kerberos settings such as those outlined in Registry entries about Kerberos protocol and Key Distribution Center (KDC) with the exception of the DefaultDomainSupportedEncTypes registry key.

The biggest change is the reduction of hard-coded etype usage.

We have heard the frustrations of customers who are trying to eliminate RC4 usage, and the seemingly unexplainable instances of RC4 usage with their environments. This new library removes these hard-coded dependencies and aggregates all those decisions into one place.

With the goal of:

More secure Kerberos operations by default
More predictable Kerberos etype usage
More stable etype additions
More stable etype removals

For example, if we had not done this refactor, the DES deprecation and on-going work towards RC4 deprecation would not be possible.

Why did this need to happen?

Kerberos was added to Windows in the early 2000's as a part of beginning the move away from NTLM and into modern cipher usage. Over these decades, there have been incredible strides in security hardening that the original developers could not have foreseen. As a result, some of the design decisions made during that initial implementation impacted our ability to reliably change the way Kerberos operates.

This can be seen in things like:

Additionally, with the long tail of code in this area and the etype that has been historically used, it had become a near impossibility to add or remove a cipher due to how the etypes were directly associated in Kerberos.

What does this mean going forward?

The Kerb3961 library has key implications going forward. The biggest one is the removal of hard-coded cipher usage and a stronger adherence to the administrators’ configured encryption types.

The environment will operate as configured.

Meaning IT administrators can have a high degree of confidence that their configurations will be honored.

This increases the amount of knowledge required by administrators. Misconfigurations, previously hidden by loose adherence to the configured etypes, will now be exposed. For more information about Kerberos etype selection, refer to the Kerberos EType Calculator.

What needs to be done?

To configure an environment requires understanding what etypes are used within an environment. To help aid in this endeavor, we have improved Key Distribution Center (KDC) auditing.

We have also published two PowerShell helper scripts that leverage these new events. The goal of these scripts is to allow for easier identification of both etype usage and account key availability.

These scripts are published on the Microsoft Kerberos-Crypto GitHub repository, where, going forward, we will be using scripts and information published there to better interface with the community.

We acknowledge that substantial changes can introduce regressions and friction points for those with mature environments. It is our goal to allow for a smooth adoption of these new features and prevent any unnecessary pain for our already overworked and under-appreciated system administrators.

Please be sure to leverage Feedback Hub to share your experiences with us. If you would like to see any of these features early, we highly recommend leveraging the Windows Insider Program and opting into Continuous Innovation and sharing feedback directly with the development team.

We understand that this can be challenging, and Microsoft is committed to ensuring that the knowledge needed to make an informed decision about what is right for your environment.

Domain Join and Basic troubleshooting

SiyaoLi — Tue, 22 Apr 2025 22:39:14 GMT

In our tech-savvy age, networks are all the rage 🌐;

Joining a domain, though, can sometimes feel like a cage 🖥️.

It makes managing PCs a breeze, with security and ease 🔒,

But troubleshooting woes can bring you to your knees 😩.

I'm Siyao Li, aka Janet, here to lend a hand 🙋‍♀️ ,

With tips and tricks to make your network grand 💡 .

For IT pros and admins, it'll be worth your while 🧑‍💻,

Dive into the basics, and you'll soon smile! 😄🔐

Section 1: Prerequisites to Perform a Domain Join
Section 2: Understand The Workflow of Domain Join Process
Section 3: Frequent Causes of Domain Join Failures

Section 1: Prerequisites to Perform a Domain Join

(Note: These prerequisites primarily apply when performing a domain join over a network. For information on performing an offline domain join, please refer to this document: Offline Domain Join (Djoin.exe) Step-by-Step Guide | Microsoft Learn.)

1-1. Network Connectivity

The device should be capable of communicating with a Domain Controller over the network. If the device is remote, a VPN connection to the corporate network is necessary. The device must use the corporate DNS server, typically provided by the Domain Controller.

To test if you can discover a domain controller, run the following command:

nltest /dsgetdc:contoso.com /force

(replace “contoso.com” with the domain name the client wishes to join)

Working example

C:\Users\Administrator-W11>nltest /dsgetdc:contoso.com /force DC: \Cont-DC.contoso.com Address: \192.168.2.100 Dom Guid: 53fbff01-6803-43c1-ba6c-b5c288951db7 Dom Name: contoso.com Forest Name: contoso.com Dc Site Name: Default-First-Site-Name Our Site Name: Default-First-Site-Name Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9 DS_10 KEYLIST The command completed successfully

Explanation of Key Details:

DC: The domain controller that was found (Cont-DC.contoso.com). 
Address: The IP of the DC. 
Dom Guid: Unique identifier for the domain. 
Flags: Lists the DC’s capabilities (e.g., PDC = Primary Domain Controller, GC = Global Catalog, DS = Directory Services, etc.). 
Our Site Name: Shows which Active Directory site the client is in.

Non-working example

C:\Users\Administrator-W11>nltest /dsgetdc:contoso.com /force  
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

Ensure that firewall rules allow traffic to domain controllers. Additionally, Windows Defender or third-party antivirus software should not obstruct domain join requests. It is essential to confirm that the following ports are open: Configure firewall for AD domain and trusts - Windows Server | Microsoft Learn:

Port	Protocol	Application Protocol	System Service or Process
53	TCP	DNS	DNS Server
53	UDP	DNS	DNS Server
389	UDP	DC Locator	LSASS
389	TCP	LDAP Server	LSASS
88	TCP	Kerberos	Kerberos Key Distribution Server
135	TCP	RPC	RPC Endpoint Mapper
445	TCP	SMB	LanmanServer
1024-65535	TCP	RPC	RPC Endpoint Mapper for DSCrackNames, SAMR and Netlogon calls between Client and Domain Controller

1-2. Computer Name Requirements

- Adhere to Active Directory naming conventions for computers as outlined here.

- Assign a unique hostname to the device to prevent conflicts, otherwise, if there is an object with the same name already exist in active directory, domain join will fail or encounter problem (see section 3-2 for more details).

- Please be aware of the domain join hardening when reusing an existing computer account in the target domain KB5020276—Netjoin: Domain join hardening changes - Microsoft Support

1-3. User credentials

By default, Active domain allows authenticated users to join 10 machine accounts to the domain. This default was implemented to prevent misuse. But an administrator can make a change to an object in Active Directory to override it. Default workstation number a user can join to the domain - Windows Server | Microsoft Learn

The following users aren't restricted by this limitation:

- Users in the Administrators or Domain Administrators groups.

- Users who have delegated permissions on containers in Active Directory to create and delete computer accounts.

Please note: Windows Home editions cannot join a domain.

Section 2: Understand The Workflow of Domain Join Process

2-1. Domain Controller Discovery (Finding a DC)

Before a computer can join a domain, it must locate an available Domain Controller (DC). This is done using DNS because Active Directory (AD) relies heavily on DNS to locate resources.

The client queries its configured DNS server for a Service (SRV) record in the format:

  _ldap._tcp.dc._msdcs.<domain-name>

Network trace example

153 2025-01-06 16:47:52.116646 9.320329 192.168.2.106 192.168.2.100 92 DNS _ldap._tcp.dc._msdcs.contoso.com Standard query 0x4fbe SRV _ldap._tcp.dc._msdcs.contoso.com 154 2025-01-06 16:47:52.117503 0.000857 192.168.2.100 192.168.2.106 202 DNS _ldap._tcp.dc._msdcs.contoso.com Standard query response 0x4fbe SRV _ldap._tcp.dc._msdcs.contoso.com SRV 0 100 389 cont-dc.contoso.com SRV 0 100 389 Cont-DC.contoso.com A 192.168.2.100 A 192.168.2.100

This record points to all Domain Controllers within the domain. The DNS server returns a list of available DCs.

Network trace example

Queries _ldap._tcp.dc._msdcs.contoso.com: type SRV, class IN Name: _ldap._tcp.dc._msdcs.contoso.com [Name Length: 32] [Label Count: 6] Type: SRV (33) (Server Selection) Class: IN (0x0001) Answers _ldap._tcp.dc._msdcs.contoso.com: type SRV, class IN, priority 0, weight 100, port 389, target cont-dc.contoso.com Service: _ldap Protocol: _tcp Name: dc._msdcs.contoso.com Type: SRV (33) (Server Selection) Class: IN (0x0001) Time to live: 600 (10 minutes) Data length: 27 Priority: 0 Weight: 100 Port: 389 Target: cont-dc.contoso.com _ldap._tcp.dc._msdcs.contoso.com: type SRV, class IN, priority 0, weight 100, port 389, target Cont-DC.contoso.com Service: _ldap Protocol: _tcp Name: dc._msdcs.contoso.com Type: SRV (33) (Server Selection) Class: IN (0x0001) Time to live: 600 (10 minutes) Data length: 27 Priority: 0 Weight: 100 Port: 389 Target: Cont-DC2.contoso.com Additional records cont-dc.contoso.com: type A, class IN, addr 192.168.2.100 Name: cont-dc.contoso.com Type: A (1) (Host Address) Class: IN (0x0001) Time to live: 3600 (1 hour) Data length: 4 Address: 192.168.2.100 Cont-DC.contoso.com: type A, class IN, addr 192.168.2.101 Name: Cont-DC2.contoso.com Type: A (1) (Host Address) Class: IN (0x0001) Time to live: 3600 (1 hour) Data length: 4 Address: 192.168.2.101

The client selects a DC, The client attempts a lightweight connection (UDP 389 - LDAP Ping) to the selected DC to verify availability and in the DC’s response to obtain its capabilities and to discover the client site.

Network trace

370 2025-01-06 16:48:14.757398 0.000570 192.168.2.106 192.168.2.100 196 CLDAP searchRequest(22) "<ROOT>" baseObject 371 2025-01-06 16:48:14.757916 0.000518 192.168.2.100 192.168.2.106 214 CLDAP searchResEntry(22) "<ROOT>" searchResDone(22) success [1 result]

If the selected DC does not respond, the client tries another DC from the DNS response.

2-2. LDAP Binding & Machine Name Verification

The client initiates an LDAP Bind (using Kerberos authentication) to the DC. Then client performs an LDAP Search under the CN=Computers or another designated OU (Organizational Unit) to check if its computer name already exists in Active Directory. If a computer account with the same name already exists, the account will either be reused successfully or the domain join operation will fail (see section 3-2 for details). Once the operation is completed successfully, the process will continue.

2-3. Computer Account Creation in AD (LDAP Add/Modify Operation)

Once the machine name is verified, the DC must create or update the existing computer account in Active Directory.

The client initiates an LDAP Add or Modify request to create a computer account in the designated OU, defaulting to CN=Computers, <domain> unless otherwise specified by policy or administrative configuration. A unique Security Identifier (SID) is assigned to the new object, and the client generates a machine password, which is stored both locally in the registry of the workstation and the account in the Active Directory, with automatic rotation every 30 days by default. The client finalizes the process by updating its local registry.

Section 3: Frequent Causes of Domain Join Failures

Based on the experience working with customers who encounter domain join failures, the three major common issues are as follows:

3-1. Networking related issues

Numerous networking issues can lead to the failure of a domain join. Chief among these is the blockage of necessary ports between the client and the Domain Controller (DC). It is observed that more than 50% of domain join failure cases we have worked with are attributable to ports not being open between the client and the Domain Controller. A commonly blocked port is UDP 389, which is crucial for communication between the client and the selected DC to verify availability and obtain capabilities. Often, customers check TCP port 389 to ensure it is open but overlook UDP port 389, both of which are required during the domain join process. The client first sends an LDAP Ping via UDP port 389 to discover a Domain Controller. Once a DC responds, the client initiates a connection on TCP port 389 for authentication and LDAP queries.

For this type of issue, you will see domain join error like this: “The specified domain either does not exist or could not be contacted”

Blocked ports like TCP 445 (SMB), TCP 88 (Kerberos), and ephemeral ports can cause domain join failures. To prevent this type of issue, we should make sure the following ports are open before performing domain join .

Port	Protocol	Application Protocol
53	TCP	DNS
53	UDP	DNS
389	UDP	DC Locator
389	TCP	LDAP Server
88	TCP	Kerberos
135	TCP	RPC
445	TCP	SMB
1024-65535	TCP	RPC

To check if TCP port is open, you can run PowerShell command:

Test-netconnection con-dc.contoso.com -port number

Working Example

PS C:\Users\Administrator-W11> Test-netconnection Cont-DC.contoso.com -port 389 ComputerName : Cont-DC.contoso.com RemoteAddress : 192.168.2.100 RemotePort : 389 InterfaceAlias : Ethernet SourceAddress : 192.168.2.111 TcpTestSucceeded : True

Non-working Example :

PS C:\Users\Administrator> Test-netconnection Cont-DC.contoso.com -port 445 WARNING: TCP connect to (192.168.2.111 : 445) failed WARNING: Ping to 192.168.2.111 failed with status: TimedOut ComputerName : Cont-DC.contoso.com RemoteAddress : 192.168.2.100 RemotePort : 445 InterfaceAlias : Ethernet 2 SourceAddress : 192.168.2.111 PingSucceeded : False PingReplyDetails (RTT) : 0 ms TcpTestSucceeded : False

To test UDP ports, PowerShell's Test-NetConnection command is not suitable as it primarily supports TCP connections. Instead, we recommend using PortQryUI, which offers features specifically designed for querying UDP connections. This tool provides a more effective solution for testing and troubleshooting UDP connectivity. Download PortQryUI - User Interface for the PortQry Command Line Port Scanner from Official Microsoft Download Center

You can test using command:

portqry -n DC01 -p UDP -e 389 (replace DC01 to your DC’s FQDN)

For example,

C:\Users\Administrator>cd C:\PortQryUI C:\PortQryUI>portqry -n cont-dc.contoso.com -p UDP -e 389 Querying target system called: cont-dc.contoso.com Attempting to resolve name to IP address... Name resolved to 192.168.2.100 querying... UDP port 389 (unknown service): LISTENING or FILTERED Using ephemeral source port Sending LDAP query to UDP port 389... LDAP query response: domainFunctionality: 7 forestFunctionality: 7 domainControllerFunctionality: 7 rootDomainNamingContext: DC=contoso,DC=com ldapServiceName: contoso.com:cont-dc$@CONTOSO.COM isGlobalCatalogReady: TRUE supportedSASLMechanisms: GSSAPI supportedLDAPVersion: 3 supportedLDAPPolicies: MaxPoolThreads supportedControl: 1.2.840.113556.1.4.319 supportedCapabilities: 1.2.840.113556.1.4.800 subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=contoso,DC=com serverName: CN=CONT-DC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=contoso,DC=com schemaNamingContext: CN=Schema,CN=Configuration,DC=contoso,DC=com namingContexts: DC=contoso,DC=com isSynchronized: TRUE highestCommittedUSN: 329631 dsServiceName: CN=NTDS Settings,CN=CONT-DC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=contoso,DC=com dnsHostName: Cont-DC.contoso.com defaultNamingContext: DC=contoso,DC=com currentdate: 02/28/2025 18:14:50 (unadjusted GMT) configurationNamingContext: CN=Configuration,DC=contoso,DC=com ======== End of LDAP query response ======== UDP port 389 is LISTENING

For more networking related issue causing domain join fail, please visit Troubleshoot errors that occur when you join Windows-based computers to a domain - Windows Server | Microsoft Learn

3-2. Hostname of the client is not unique.

3-2-1. There is an existing computer account with the same name in the domain AND the account you used to join the domain is the one of the exempted users in domain join hardening.

For example:

A new workstation named Cont-W10 (referred to as computer A) has been provisioned, and you are using Domain Admin account who created this object attempting to join it to the domain contoso.com. There is another computer object also named Cont-W10 (referred to as Computer B) that currently exists in the active directory. If you try to join the domain, it will permit you to join the domain but will disrupt the secure channel between computer B (Cont-W10) and the Domain Controller (DC). Upon its next reboot, computer B will encounter an error: The trust relationship between this workstation and the primary domain failed.

This happens because when a client joins the domain, it generates a new machine password, which is then stored in the corresponding computer object in Active Directory. Since the existing Cont-W10 object is updated with the new password, the previous Computer B's locally stored password will no longer match the one in Active Directory, breaking its secure communication with the DC.

3-2-2. There is an existing computer account with the same name in the forest.

For example:

When attempting to join a workstation named Cont-Win11 (Computer C) to the domain child.contoso.com, the operation fails because another computer object, Cont-W11 (Computer D), already exists in the parent domain contoso.com. This results in the error: "The operation failed because SPN value provided for addition/modification is not unique forest wide." During the domain join process, the Netlogon service on the client registers Service Principal Names (SPNs) in Active Directory, including the HOST/ComputerName format. Since SPNs must be unique across the entire Active Directory Forest, the attempt to create HOST/Cont-Win11 fails due to the existing entry for Computer D in the parent domain, preventing the domain join from completing successfully.

To resolve this issue, you have two options:

- Delete the existing computer object in the parent domain (contoso.com) if it is no longer needed. This will remove the conflicting SPN, allowing the new workstation (Cont-Win11) to join the child domain successfully.
- Rename the new workstation before attempting the domain join again. Choosing a unique name will prevent SPN conflicts and allow the workstation to be added without issues.

To Prevent name conflict when joining the domain , you can search the computer name you plan to use in the global catalog

3-3. Domain Join Hardening Changes

KB5020276—Netjoin: Domain join hardening changes - Microsoft Support

KB5020276 introduces domain join hardening changes to improve security by preventing unauthorized or unintended computer account takeovers during domain join operations. Before this update, if a computer with the same name already existed in Active Directory, joining a new machine with the same name could overwrite the existing object, potentially breaking its secure channel with the Domain Controller (DC). With this update, additional validation is enforced to ensure that only users with the proper permissions can reset or reuse an existing computer account. If the required permissions are missing, the domain join will fail with an error: An account with the same name exists in Active Directory. Re-using the account was blocked by security policy.

To successfully join a machine to the domain, administrators must either delete the existing computer object, have the necessary permissions to reuse it, or use a different unique name for the new machine.

If you want to dive deep troubleshooting domain join failures, capture a network trace and examine the Netsetup.log file. Netsetup.log is an important resource for diagnosing domain join issues and can be found at C:\Windows\Debug\netsetup.log. Review the log to identify error messages and search the Microsoft website for relevant articles or known solutions. For more information: Active Directory domain join troubleshooting guidance - Windows Server | Microsoft Learn

Stop Worrying and Love the Outage, Vol IV: Preference items

Chris_Cartwright — Fri, 20 Feb 2026 16:41:04 GMT

This is the fourth article in a series:
Stop Worrying and Love the Outage, Vol I: Group Policy and Sharing Violations
Stop Worrying and Love the Outage, Vol II: DCs, custom ports, and Firewalls/ACLs
Stop Worrying and Love the Outage, Vol III: Cached Logons

Hello, Chris Cartwright here from the Directory Services support team, returning (after a brief hiatus) to try to provide the IT community with some tools and verbiage that will hopefully save you and your business many hours, dollars, and frustrations. Today, we will go over something we see sometimes: Group Policy Preference items conflicting with existing client-side extensions (CSE). This scenario can range from going completely unnoticed (or occurring intermittently) to causing full outages. The problem with predicting the impact here is that it is completely dependent on setting in question.

Suffice to say, today’s message is, “You should never* target a group policy registry location (including “Windows Settings\Local Policies\Security Options” settings) with a Preference item unless you want instability and an administrative nightmare.” We’ll get to that little disclaimer later. To illustrate this, we will go with Cipher Suite Ordering as an example, since a misconfiguration here can completely stop TLS connections to production services.

The setting

Here’s a view of gpresult from our example machine:

The result

This policy setting targets the Functions value seen here in HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002. Sometimes, it’s this:

C:\WINDOWS\system32>reg query HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002

Functions REG_SZ TLS_AES_256_GCM_SHA384

Sometimes…it’s this:

C:\WINDOWS\system32>reg query HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002

Functions REG_SZ TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_NULL_SHA256,TLS_RSA_WITH_NULL_SHA,TLS_PSK_WITH_AES_256_GCM_SHA384,TLS_PSK_WITH_AES_128_GCM_SHA256,TLS_PSK_WITH_AES_256_CBC_SHA384,TLS_PSK_WITH_AES_128_CBC_SHA256,TLS_PSK_WITH_NULL_SHA384,TLS_PSK_WITH_NULL_SHA256

These are some different Data for the same registry value. So…why is this happening? Well, if we had looked further down:

Here, we have two different GPOs targeting the same registry key. One, correctly uses an Administrative Template to modify a registry value under a SOFTWARE\Policies key. The other, a Preference item, inappropriatelytargets the same policy key. Why “inappropriately”? Because you should never* target a group policy registry location (including “Windows Settings\Local Policies\Security Options” settings) with a Preference item unless you want instability.

Now, that we’ve gotten that message out of the way... the weirdness:

This is a Procmon of several gpupdate commands. We see group policy behaving as expected here three times (seen in blue), calling the Registry CSE first (think Administrative Templates), writing some values and data, and then the Group Policy Registry CSE (think Registry preference items) comes along and replaces it. This is the order that these extensions are processed in.

At this point, who could tell what the intended data of this value was to begin with? Anyway, it does this three times (because I told it to refresh three times) and then doesn’t do it on the fourth refresh (single line in red). Instead, the Registry CSE applies and nothing else happens. Why?

To answer that, we need to turn on Group Policy debug logging.

Here is where Preference Items “wins” (significantly trimmed):

GPSVC(28c.fe0) 12:46:25:697 ProcessGPOs(Machine): -----------------------
GPSVC(28c.fe0) 12:46:25:697 ProcessGPOs(Machine): Processing extension Registry This is Admin Template Land
GPSVC(28c.fe0) 12:46:25:900 ParseRegistryFile: Entering with <\\contoso.com\SysVol\contoso.com\Policies\{9804AF19-19F6-4C96-AEB2-B97DD318F123}\Machine\registry.pol>.
GPSVC(28c.fe0) 12:46:25:916 SetRegistryValue: Functions => TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, <snip>...  [OK]
GPSVC(28c.fe0) 12:46:25:916 ParseRegistryFile: Leaving.
GPSVC(28c.fe0) 12:46:27:494 ProcessGPOs(Machine): Processing extension Group Policy Registry This is Preference Item Land
GPSVC(28c.fe0) 12:46:27:494 ReadStatus: Read Extension's Previous status successfully.
GPSVC(28c.fe0) 12:46:27:494 ReadGPOList:++
GPSVC(28c.fe0) 12:46:27:494 ReadGPOList: Read Key:0
GPSVC(28c.fe0) 12:46:27:494 ReadGPOList: Read Key:1
GPSVC(28c.fe0) 12:46:27:494 ReadGPOList:-- (Result:TRUE)
GPSVC(28c.fe0) 12:46:27:494 CheckGPOs: ReadGPOList count = 2
GPSVC(28c.fe0) 12:46:27:494 CompareGPOLists:  The lists are the same.
GPSVC(28c.fe0) 12:46:27:494 CheckGPOs: No GPO changes but called in force refresh flag or extension Group Policy Registry needs to run force refresh in foreground processing
GPSVC(28c.fe0) 12:46:27:494 GPLockPolicySection: Sid = (null), dwTimeout = 30000, dwFlags = 0x40
GPSVC(28c.fe0) 12:46:27:494 bMachine = 1
GPSVC(28c.fe0) 12:46:27:494 Global Sync Lock Called
GPSVC(28c.fe0) 12:46:27:494 Writer Lock got immediately.
GPSVC(28c.fe0) 12:46:27:494 Global Lock taken successfully
GPSVC(28c.fe0) 12:46:27:494 ProcessGPOList:++ Entering for extension Group Policy Registry
GPSVC(28c.fe0) 12:46:27:494 ProcessGPOList: Passing in the force refresh flag to Extension Group Policy Registry
GPSVC(28c.fe0) 12:46:27:494 LogExtSessionStatus: Successfully logged Extension Session data
GPSVC(28c.fe0) 12:46:27:494 ProcessGPOList: lpGPOInfo->lpGPInfoHandle->dwExtnCount is 2 for Group Policy Registry.
GPSVC(28c.fe0) 12:46:27:838 ProcessGPOList: Extension Group Policy Registry returned 0x0.

The above shows that the Administrative Template CSE executes first, and then Preference Items comes along.

And here is where the Administrative Template “wins” instead (significantly trimmed):

GPSVC(28c.fe0) 12:48:47:351 ProcessGPOs(Machine): -----------------------
GPSVC(28c.fe0) 12:48:47:351 ProcessGPOs(Machine): Processing extension Registry This is Admin Template Land
GPSVC(28c.fe0) 12:48:47:538 ParseRegistryFile: Entering with <\\contoso.com\SysVol\contoso.com\Policies\{9804AF19-19F6-4C96-AEB2-B97DD318F123}\Machine\registry.pol>.
GPSVC(28c.fe0) 12:48:47:554 SetRegistryValue: Functions => TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, <snip> ...[OK]
GPSVC(28c.fe0) 12:48:47:554 ParseRegistryFile: Leaving.
~~~~~~~~~~~Large jump here~~~~~~~
GPSVC(28c.fe0) 12:48:48:038 ProcessGPOs(Machine): Processing extension Group Policy Registry This is Preference Item Land
GPSVC(28c.fe0) 12:48:48:038 ReadStatus: Read Extension's Previous status successfully.
GPSVC(28c.fe0) 12:48:48:054 ReadGPOList:++
GPSVC(28c.fe0) 12:48:48:054 ReadGPOList: Read Key:0
GPSVC(28c.fe0) 12:48:48:054 ReadGPOList: Read Key:1
GPSVC(28c.fe0) 12:48:48:054 ReadGPOList:-- (Result:TRUE)
GPSVC(28c.fe0) 12:48:48:054 CheckGPOs: ReadGPOList count = 2
GPSVC(28c.fe0) 12:48:48:054 CompareGPOLists:  The lists are the same.
GPSVC(28c.fe0) 12:48:48:054 CheckGPOs: No GPO changes and no security group membership change and extension Group Policy Registry has NoGPOChanges set.

In this one, Registry runs, sets the value, and then Group Policy Registry starts and then says, “No GPO changes and no security group membership change and extension Group Policy Registry has NoGPOChanges set.”

So, what does that mean? I managed to salvage this from the ill-advised archival of Windows Server 2003 documentation:

NoGPOListChanges is a registry value that can be configured for CSEs. When NoGPOListChanges is set to 0, “GPO Changes” above effectively is always yes. Here, we can see the registry value is configured to be 1 for the Group Policy Registry CSE:

This means that if no changes are detected, we will skip processing. That came from this GPO (Thank you, Procmon):

Thus ends the mystery of the intermittency. Since the Force flag wasn’t set, and NoGPOListChanges is not enabled, the Preference value doesn’t get applied this time.

Remember, I’m not advising you how to make this work. By default, Group Policy Preferences would always reapply anyway unless ‘Apply once and do not reapply’ is enabled. I am just pointing out how you can have an unstable configuration by deploying preference items that you shouldn’t. In addition to this technical issue above, think about the administrative implications. Do you really want to have to constantly compare your list of 300 preference items to your admin templates every time you want to make a change? Friends don’t let friends target preference items at group policy settings.

-Chris “Prefer no conflict” Cartwright

* Okay. I did promise to talk about the disclaimer later. There are character limits to some settings. For example, the setting I used here, SSL Cipher Suite Order has a character limit of 1,023. In earlier, unsupported versions of Windows, it was not only possible, but likely, to have a list that went past this limit. In this case, the only Group Policy recourse would be to use this preference item. However, if you were to do this, you would also make sure that SSL Cipher Suite Order was not configured in Admin templates. Given that this is no longer a problem in supported OSes, it is not a valid excuse. I am unaware of any similar settings that exist on a supported OS at this time.

References:

https://learn.microsoft.com/en-us/previous-versions/windows/desktop/policy/creating-a-policy-callback-function

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/hey-dude-where-s-my-winlogon-log/ba-p/259042

Lost access to your Root CA in your 2-Tier PKI? Don’t worry, Use Cross Signing to Recover!

ByronHu_MS — Mon, 21 Apr 2025 19:17:39 GMT

Hello, this is Byron from the Microsoft Directory Services Support team. Today, I’d like to share information about an alternative recovery approach for Public Key Infrastructure (PKI) environments.

Consider a scenario where the Root Certification Authority (CA) is permanently lost—for example, due to accidental deletion of the Root CA virtual machine, or the system entering an unrecoverable no-boot state without a valid backup. In some cases, there may be no backup of the Root CA’s private key or database, leaving no traditional path to restoration.

In such cases, the supported and recommended recovery method is to rebuild the PKI hierarchy from scratch. However, for extremely rare and critical situations where this is not feasible, there is an alternate recovery method that may allow partial restoration and continuity. This approach is intended only as a last resort, and should only be considered when no supported recovery options remain.

While not a replacement for proper backup and disaster recovery practices, this fallback method may help reduce downtime and effort in extreme cases.

How

If it is a two-tier PKI, and the Intermediate CA Server is the one issuing certificates to the environment, and we still have access to the Intermediate CA Certificate with private key, we can build another Root CA, and “link” the Intermediate CA Server to the new Root CA. The steps are simple, just renew the Intermediate CA server with “Same Key pair” with this new Root CA.

A high-level diagram below:

In fact, this is like the Concept of “Cross Signing”; the newly issued Intermediate CA Certificate could be considered as a “Cross Certificate” as well. Cross Signing is typically used to make one PKI hierarchy chains up through another hierarchy, even when originally it was not configured that way. This technique is designed for a leaf certificate to build a different certificate verification chain, in case one of the chains fails, allowing certification verification to succeed. Cross signing is also used by public CA companies to start their business which we will discuss more in a later section.

Here are detailed steps on how to do this:

On the Intermediate CA Server. Open the Certification Authority Management Console.
Right click on the CA Name node -> All Tasks -> Renew CA Certificate.

Renew Intermediate CA server with “Same Key pair” to create the Certificate renewal request file:
Submit the certificate request file (.req) on the newly Deployed Root CA Server, issue it, and go to: Issued Certificates node-> Right click on issued Certificate -> All Taks -> Export Binary Data… -> Save as .cer file. Copy this .cer file to the Intermediate CA.

On the Intermediate CA Server. Install the newly issued Intermediate CA certificate issued by the new Root CA.
The existing issued Leaf Certificates verification should continue to work and chain up to the new Root CA.

We can use command Certutil -urlfetch -verify c:\certificate.cer > certificate.txt to export the certificate verification and chain build information.

Previous Chain:

Leaf certificate: 5700000006d907d38be599e05a000000000006

Issuer: CN=ContosoRootCA01,DC=contoso,DC=com (Previous corrupted Root CA)

Current Chain:

Leaf certificate: 5700000006d907d38be599e05a000000000006

Issuer: CN=ContosoRootCA02,DC=contoso,DC=com (New built Root CA)

How and Why

So exactly what is “Cross Signing”? Let’s see the following story (I found this story online):

A long time ago (maybe not that long 😊), there was a Certification Authority company called LetsEncrypt. When they started their business, they generated their own 'ISRG' Root CA Certificate (ISRG Root X1). However, it takes time for the industry to accept new Root Certification Authorities. They could not wait that long to start their business, as this might have taken years.

They deployed an Intermediate CAs first (LetsEncrypt X3 and LetsEncrypt X4) and used a popular public Certification Authority (DST Root X3) to sign those Intermediate CA Certificates. This allowed them to start their business immediately and issue Leaf Certificates to customers without waiting for the world to accept their own Root CA.

So, the Certificate Chain back then was DST Root X3 --> LetsEncrypt X3 / LetsEncrypt X4 --> Leaf Certificate.

After 5 years of hard work, the market accepted their Root CA (DST Root X3) and added it to all kinds of products’ Trusted Root. They signed their Intermediate CA certificates with their own Root CA.

Now, another chain is available: ISRG Root X1 --> LetsEncrypt X3 / LetsEncrypt X4 --> Leaf Certificate.

How come the same Intermediate CA can be chained up to different Root CAs? The magic trick is the Intermediate CA Certificate kept the “Same Asymmetric Key Pair” when it got signed by both DST Root X3 and ISRG Root X1.

As you can see from the above screenshots, the issuer is different, and they are two different intermediate CA certificates, but the trick here is the Same Key Pair, even though they were signed by different Root CA’s, aka “Cross Signing”.

Another key point here is not all Certificate Chains rely on the AIA path. Another common Certificate chain build method is Key match using AKI/SKI and PKCS#7 which means the server side sends both Leaf Certificate along with Intermediate CA to the client for verification, Client does not need to build chain to Intermediate using AIA.

You can refer to this document for more information about this story: https://scotthelme.co.uk/cross-signing-alternate-trust-paths-how-they-work/

There is another “Cross Sign” method targeting the Root CA Certificate itself. The concept is a little bit different: Using one Root CA Certificate to sign another Root CA Certificate.

What is the usage scenario? Why do we need this?

Scenario 1

Here is a story: In a large corporation, deploying Root CA certificate to all devices might be challenging. It could be time-consuming and might take a lot of administrative effort. Therefore, during the time periods when large corporations renew their Root CAs, they must find a way for newly issued Certificates under the renewed Root CA start to work as soon as possible. The idea is to sign the new Root CA certificate using the old Root CA Certificate, so the chain could be:

leaf Certificate --> Intermediate CA -> New Root CA (Signed by Old Root CA)--> Old Root CA.

Because devices should trust Old Root CA already, the new Leaf Certificate works immediately after renewal without waiting for new Root CA Deployed to all devices.

Scenario 2

Another scenario is once the New Root CA is deployed to the environment, the company wants to remove the old Root CA certificate from the Devices’ trusted Store for company policy reasons. How can the existing Certificate continue to work if they are not yet expired and issued by old Root CA Certificate? The solution is also Cross Certificate: Create a CA Certificate with old CA key pair but signed by the new Root CA Certificate. The chain build would be below:

Existing Issued Leaf Certificate --> Intermediate CA --> Old CA Certificate (cross signed by new Root CA) --> New Root CA.

In fact, Active Directory Certificate Service supports this and will generate Cross Certificates by default when renewing a Root CA with a new key.

Remember that when we renew the Root CA, there will be two additional CRT files called XXXXX (0-1).crt and XXXXX(1-0).crt. These certificates(.crt) are Cross CA Certificate’s. (0-1) is the New Root CA Certificate signed by Old Root CA Certificate. (1-0) is the old Root CA Certificate signed by new Root CA Certificate. They are used for the above Scenario 1 and Scenario 2

As you can see, the Root CA Certificate has an AKI (Authority Key Identifier), which means it was signed by a CA and an SKI (Subject Key Identifier) that matches it.

Of course, in Active Directory, we rarely see the deployment of the Cross Certificate, because for Windows devices, the Active Directory is sufficient to quickly deploy new Root CA Certificate to Windows domain members.

Summary

The common method to perform PKI disaster recovery when the CA private key and database cannot be restored involves rebuilding the entire PKI Hierarchy PKI from scratch, and replacing every single certificate used by applications and servers.

While the common method mentioned above is still valid, the “Cross Signing” method illustrated in this blog offers an alternative quick method to recover our PKI Hierarchy. This could potentially save us from spending a lot of disaster recovery time & administrative effort 😊.

Windows Scoping: The Secret Sauce to Squashing Windows Gremlins Faster!

TagoreN — Mon, 04 Nov 2024 19:31:18 GMT

Hello everyone, this is Tagore Nadh, a Sr. Technical Advisor on the Directory Services support team in Microsoft. In this article, I will explain why scoping is important with a couple of good examples.

Generic Scoping Questions:

What is your objective and the reason behind it?
Can you provide a detailed description of the issue?
What works and what does not?
When does it occur and when does it not?
Where is the issue observed and where is it not?
What is the extent of the issue?
Can you share details of the environment where the issue is occurring?
What error message is displayed?
How do you quantify the problem?
How are you notified of the problem?
What troubleshooting steps have you already undertaken?
What is the business impact of this issue?
Can you clarify what you aim to achieve by resolving this issue?

Next, Microsoft support engineer scopes the issue down to the specific component(s) causing the problem.

Scoping Example 1:

What is your objective and the reason behind it?

End users reported an incident in Bangalore location where they are unable to login using domain’s credentials into their client machines.

Can you provide a detailed description of the issue?

All users at the Bangalore site are unable to log in to their client computers using their domain credentials.

How long has the issue been occurring?

Since Sunday

What has changed?

Network hardware switch upgrade during the weekend

How frequently does the issue occur?

Consistent issue, users are unable to log in to their client machines using domain credentials.

What works and what does not?

Users are unable to log in to their domain from their client machines at the Bangalore site / They can log in using local admin credentials.

When does it occur and when does it not?

Since Sunday / Until Saturday, all users were able to log in to their client machines using domain credentials.

Where is the issue observed and where is it not?

Bangalore, India / All other sites aren’t impacted.

What is the extent of the issue?

All users in Bangalore, about 300, are impacted out of 10,000 users in the entire company.

Can you share details of the environment where the issue is occurring?

Production environment

1 forest / 1 domain – Contoso.com
10 AD Sites
Affected site name is Bangalore
Client OS: Windows 10 23H2 and Windows 11 23H2
How many domain controllers exist in that site? 4 Windows 2019 Operating System
Names of DCs: DC1, DC2, DC3 and DC4 with <IP address details here>
Is DNS Microsoft AD integrated or third party? Microsoft AD Integrated
Are clients pointing to the same site domain controllers for DNS? Yes, DC1 is Primary and DC2 alternate DNS.
Do they use DHCP? Yes

What error message is displayed?

No logon servers are available to service the request

How do you quantify the problem?

300 users are impacted.

How are you notified of the problem?

End users at the Bangalore site reported the issue.

What troubleshooting steps have you already undertaken?

Tried to login to client machine locally – works
Attempted to ping the domain name – doesn’t work, gets request timed out.
Does pinging domain controller ip address work? - yes
Does accessing resources using ip work? no, prompts for credentials

What is the business impact of this issue?

The issue is in the production environment.
300 users are unable to work.
As it is the month-end, loan requests can’t be completed in time, and other regular bank financial operations are impacted.
This could result in a $1 million business loss if requests are not processed in time.

Can you clarify what you aim to achieve by resolving this issue?

To address user logon issues using domain credentials on workstations at the Bangalore site.

Resolution: These scoping answers helped a Microsoft support engineer quickly focus on domain controllers. It was found that the E drive, where active directory database file (NTDS.DIT) resides over a network fiber channel in a different network segment via an upgraded Network hardware device. A quick reboot of the domain controllers re-established connectivity to the network drives hosting active directory database file, resolving the issue.

Note: It is important to follow the same approach when dealing with multiple sub-problems of a main issue. The cause for each issue may differ.

Scoping Example 2:

What is your objective and the reason behind it?

Working on a development server deployment, mitigating security vulnerabilities reported on existing and new servers as per Qualys scans. The project deadlines are close by, with just a week away.

Can you provide a detailed description of the issue?

Below SSL/TLS vulnerabilities are detected as per Qualys Scan on multiple newly installed and existing servers.

SSL Certificate Cannot Be Trusted
SSL Certificate Expiry
SSL Certificate Signed Using Weak Hashing Algorithm
SSL Certificate with Wrong Hostname
SSL Medium Strength Cipher Suites Supported (SWEET32)

How long have these vulnerabilities existed?

Vulnerabilities exist on 10 existing servers for the last 8 months and on new servers for a week.

How frequently does Qualys scan happen?

The scan is run once a month

Can you share details of the environment where the issue is occurring?

Development of non-prod environment
1 forest / 1 domain – Contoso.com
Number of impacted servers: 25
In-house or third-party applications running: Yes, several

What error message is displayed?

No error message

How do you quantify the problem?

25 servers are affected

How are you notified of the problem?

The security team suggested addressing vulnerabilities based on priority.

Qualys scan detected vulnerabilities.

What steps have you already undertaken and what help is needed?

Mitigation plans exist in the Qualys scan report. Need some advice from Microsoft on recommendations on how to implement?

What is the business impact due to this?

The security team reported non-compliance issues. If not addressed within a week, it could cause auto shutdown of these servers. This would impact developers, preventing them from testing their applications and thus delaying project timelines.

Can you clarify what you aim to achieve by resolving this issue?

What is the best way or approach to address reported vulnerabilities

Recommendation: On new servers, proceed to apply the suggested mitigation plans by Qualys. It isn’t simple to follow the same mitigations on old servers with in-house/third-party applications running without validating the compatibility of each mitigation plan. A phased approach is needed: apply one mitigation at a time and test to avoid any unexpected behaviors. Apply the same approach to one server at a time as they all host distinct applications with different configurations.

Note: It is important to follow the same approach when dealing with multiple sub-tasks of a main goal. The goal of each task may differ.

Conclusion: Scoping an issue is a fundamental step in problem-solving that ensures a thorough understanding and effective resolution. By systematically gathering detailed information and focusing on the core aspects of the problem, you can prioritize and address issues more efficiently. This approach not only helps in resolving the current problem but also prevents future occurrences, ultimately leading to a more stable and reliable environment for all CSS customers.

Secure Time Seeding on DCs: A Note from the Field

Chris_Cartwright — Mon, 26 Jan 2026 19:24:58 GMT

Update 4/30/2025:
Official recommendation to disable Secure Time Seeding on DCs can be found here:

Secure Time Seeding Recommendations for Windows Server - Windows Server | Microsoft Learn

Hello all, Chris from Directory Services here again. Lately, we’ve seen an increase in cases where DCs (Domain Controllers) suffer issues with time jumps, many times into the future. As everyone here knows, time synchronization is critical for Active Directory and other applications. As time has passed (hyuk hyuk), we’ve seen some interesting scenarios from simple misconfigurations to the Great Rollback. Regardless of the cause, these issues were capable of causing huge outages for customers, so in Server 2008, we released a new default value for w32Time’s protection configuration.

MaxPosPhaseCorrection and MaxNegPhaseCorrection defaults were changed from “take literally anything” to 48 hours. We’ve also released various guidance on configuring Domain Controllers for NTP:

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc773263(v=ws.10)

https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/support-boundary-high-accuracy-time

https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/configuring-your-pdce-with-alternate-time-sources/ba-p/394945

https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/configuring-an-authoritative-time-server-with-group-policy-using/ba-p/395806

So what brings us here?

Well, with Server 2016, came Secure Time Seeding (STS). Further commentary addressed this release as a more of a client solution and not as an accurate enough solution for Active Directory. However, Secure Time Seeding is enabled by default on all currently supported Windows Server OSes. Furthermore, it does not honor MaxPosPhaseCorrection or MaxNegPhaseCorrection. CSS has seen high production impact at customer sites due to STS setting an incorrect time when TLS connections are made to woefully misconfigured devices.

Wait, what?

You can probably see where this is going. We urge all Active Directory administrators out there to take this information and consider whether this is something you want or not. From the w32time blog post above:

If you would rather trust your system clock than time data generated from your SSL traffic and want to forgo any benefit this feature gives you, we got your back. Set the following registry value to 0 and reboot your machine and the Secure Time Seeding feature will be disabled. (Standard warning about exercising care while modifying registry applies here).

Registry Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

Value Name: UtilizeSslTimeData

Value Type: REG_DWORD

(Note that there is also a Group Policy that has an option to enable or disable UtilizeSslTimeData
Path: Computer Configuration\Administrative Templates\System\Windows Time Service
Group Policy: Global Configuration Settings

If configured, this will override the registry setting above.)

To compound the issue even further, there is no logging that will point to STS as having set the time. The only way to know that it made the change is to already have w32tm debug logging enabled before it happens where you would see something like this:

152929 22:35:45.3014352s - ClockDispln Discipline: *SET*SECURE*TIME*

Running w32tm debug logging 24/7 is not going to be something we would ever recommend unless we absolutely had to, similar to most other debug logging.

So, where do I stand?

Here’s a command that will allow you to see the value on all your DCs:


For /f %i IN ('dsquery server -o rdn') do REG QUERY \\%i\HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config /v UtilizeSslTimeData /t REG_DWORD

In conclusion, while Secure Time Seeding offers potential benefits, it is possible for issues to arise with Active Directory. Administrators must weigh these considerations carefully when deciding whether to disable this feature. Additionally, consider that this can impact non-DC servers in productions as well. The decision should be based on the specific needs and configurations of their environment.

Chris “All this Time” Cartwright

References:

https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/client-clock-reverts-to-previous-time

https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/configure-w32ime-against-huge-time-offset

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/fixing-when-your-domain-traveled-back-in-time-the-great-system/ba-p/255877

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/domain-time-synchronization-in-the-age-of-working-from-home/ba-p/1440820

https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/bg-p/AskDS/label-name/Time

https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/bg-p/AskDS/label-name/w32time

https://learn.microsoft.com/en-us/archive/blogs/w32time/secure-time-seeding-improving-time-keeping-in-windows

https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/client-clock-reverts-to-previous-time

Remote Desktop Services enrolling for TLS certificate from an Enterprise CA

Savannah_Greene — Mon, 02 Sep 2024 16:00:00 GMT

Hey! Rob Greene again. Been on a roll with all things crypto as of late, and you are not going to be disappointed with this one either!

Background

Many know that Remote Desktop Services uses a self-signed certificate for its TLS connection from the RDS Client to the RDS Server over the TCP 3389 connection by default. However, Remote Desktop Services can be configured to enroll for a certificate against an Enterprise CA, instead of continuing to use those annoying self-signed certificates everywhere.

I know there are other blogs out there that cover setting up the certificate template, and the group policy, but what if I told you most of the blogs that I have seen on this setup are incomplete, inaccurate, and do not explain what is happening with the enrollment and subsequent renewals of the RDS certificate!? I know… Shocker!!!

How this works

The Remote Desktop Service looks for a certificate, in the computer personal store, that has a specific Enhanced Key Usage with the Object Identifier (OID) of 1.3.6.1.4.1.311.54.1.2, which is typically named Remote Desktop Authentication, or Server Authentication. It prefers a certificate with the OID of Remote Desktop Authentication. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn781533(v=ws.11)

Sidebar:

If you are a pretty regular consumer of the AskDS blog content you know how we love to recommend using one certificate on the server for a specific Enhanced Key Usage (EKU), and make sure that you have all the information required on the certificate so that it works with all applications that need to use the certificate.

This certificate is no different. I would recommend that the certificate that is used ONLY has the EKU for Remote Desktop Authentication and DOES NOT have an EKU of Server Authentication at all. The reason for this is that this certificate should not be controlled / maintained via Autoenrollment/renewal behaviors. This needs to be maintained by the Remote Desktop Configuration service, and you do not want certificates being used by other applications being replaced by a service like this as it will cause an issue in the long run.

There is a group policy setting that can be enabled to configure the Remote Desktop Service to enroll for the specified certificate and gives the NT Authority\NetworkService account permission to the certificates private key which is a requirement for this to work.

The interesting thing about this is that you would think that the Remote Desktop Service service would be the service responsible for enrolling for this certificate, however it is the Remote Desktop Configuration (SessionEnv) service that is responsible for initial certificate requests as well as certificate renewals.

It is common to see the RDS Authentication Certificate template configured for autoenrollment, however this is one of the worse things you can do, and WILL cause issues with Remote Desktop Services once the certificate renewal timeframe comes in. Autoenrollment will archive the existing certificate causing RDS to no longer be able to find the existing certificate; then when you require TLS on the RDS Listener, users will fail to connect to the server. Then, at some point, Remote Desktop Configuration service will replace the newly issued certificate with a new one because it maintains the Thumbprint of the certificate that RDS should be using within WMI. When it tries to locate the original thumbprint and cannot find it, it will then attempt to enroll for a new one at the next service start. This is generally when we see the cases rolling in to the Windows Directory Services team because it appears to be a certificate issue even though this is a Remote Desktop Services configuration issue.

What we want to do is first make sure that all the steps are taken to properly configure the environment so that the Remote Desktop Configuration service is able to properly issue certificates.

The Steps

Like everything in IT (information technology), there is a list of steps that need to be completed to get this setup properly.

Configure the certificate template and add it to a Certification Authority to issue the template.
Configure the Group Policy setting.

Configuring the Certificate Template

The first step in the process is to create and configure the certificate template that we want to use:

Log on to a computer that has the Active Directory Certificate Services Tools Remote Server Administration Tools (RSAT) installed or a Certification Authority within the environment.
Launch: CertTmpl.msc (Certificate Template MMC)
Find the template named Computer, right click on it and select Duplicate Template.
On the Compatibility tab, select up to Windows Server 2012 R2 for Certification Authority and Certificate recipient. Going above this might cause issues with CEP / CES environments.
On the General tab, we need to give the template a name and validity period.
1. Type in a good descriptive name in the Template display name field.
2. If you would like to change the Validity period, you can do that as well.
3. You should NOT check the box Publish certificate in Active Directory.

NOTE: Make sure to copy the value in the Template name field, as this is the name that you will need to type in the group policy setting. Normally it will be the display name without any spaces in the name, but do not rely on this. Use the value you see during template creation or when looking back at the template later.

6. On the Extensions tab, the Enhanced Key Usage / Application Policies need to be modified.

a. Select Application Policies, and then click on the Edit button.

b. Multi select or select individually Client Authentication and Server Authentication and click the Remove button.

c. Click the Add button, and then click on the New button if you need to create the Application Policy for Remote Desktop Authentication. Otherwise find the Remote Desktop Authentication policy in the list and click the OK button.

d. If you need to create the Remote Desktop Authentication application policy, click the Add button, and then for the Name type in Remote Desktop Authentication, and type in 1.3.6.1.4.1.311.54.1.2 for the Object identifier value, and click the OK button.

e. Verify the newly created Remote Desktop Authentication application policy, and then click the OK button twice.

7. Remote Desktop service can use a Key Storage Provider (KSP). So, if you would like to change over from a Legacy Cryptographic Service Provider (CSP) to using a Key Storage Provider this can be done on the Cryptography tab.

8. Get the permissions set properly. To do this click on the Security tab.

a. Click the Add button and add any specific computer or computer groups you want to enroll for a certificate.

b. Then Make sure to ONLY select Allow Enroll permission. DO NOT select Autoenroll.

NOTE: Please keep in mind that Domain Controllers DO NOT belong to the Domain Computers group, so if you want all workstations, member server and Domain Controllers to enroll for this certificate, you will need Domain Computers and Enterprise Domain Controllers or Domain Controllers groups added with the security permission of Allow – Enroll.

9. When done making other changes to the template as needed, click the OK button to save the template.

Configure the Group Policy

After working through getting the certificate template created and configured to your liking, the next step in the process is to setup the Group Policy Object properly. The group policy setting that needs to be configured is located at: Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security

With the Policy "Server authentication certificate template"

When adding the template name to this group policy it will accept one of two things:

Certificate template name, again this is NOT the certificate template display name.
Certificate templates Object Identifier value. Using this is not common, however some engineers will recommend this over the template name.

If you use the certificate template display name, the Remote Desktop Configuration service (SessionEnv) will successfully enroll for the certificate, however the next time the policy applies it will enroll for a new certificate again. This causes enrollments to happen and can make a CA very busy.

Troubleshoot issues of certificate issuance

Troubleshooting problems with certificate issuance is usually easy once you have a good understanding of how Remote Desktop Services goes about doing the enrollment, and there are only a few things to check out.

Investigating what Certificate Remote Desktop Service is configured to use.

The first thing to investigate is figuring out what certificate, if any,the Remote Desktop Services is currently configured to use. This is done by running a WMI query and can be done via PowerShell or good’ol WMIC. (Note: WMIC is deprecated and will be removed at a future date.)

PowerShell:  Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace Root\cimv2\Terminalservices

WMIC: wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Get SSLCertificateSHA1Hash

We are interested in the SSLCertificateSHA1Hash value that is returned. This will tell us the thumbprint of the certificate it is attempting to load.

Keep in mind that if the Remote Desktop Service is still using the self-signed certificate, it can be found by:

launch the local computer certificate store (CertLM.msc).
Once the Computer store opened look for the store named: Certificates - Local Computer\Remote Desktop\Certificates.
We would then double click on the certificate, then click on the Details tab, and find the field named Thumbprint.
Then validate if this value matches the value of SSLCertificateSHA1Hash from the output.

If there is no certificate in the Remote Desktop store, or if the SSLCertificateSHA1Hash value does not match any of the certificates in the store Thumbprint field, then it would be best to visit the Certificates – Local Computer\Personal\Certificates store next. Look for a certificate that has the Thumbprint field matching the SSLCertificateSHA1Hash value.

Does the Remote Desktop Service have permission to the Certificate private key

Once the certificate has been tracked down, we then must figure out if the certificate has a private key and if so, does the account running the service have permission to the private key?

If you are using Group Policy to deploy the certificate template information and the computer has permissions to enroll for the certificate, then the permissions in theory should be configured properly for the private key and have the NT Authority\NetworkService with Allow – Read permissions to the private key.

If you are having this problem, then more than likely the environment is NOT configured to deploy the certificate template via the group policy setting, and it is just relying on computer certificate autoenrollment and a certificate that is valid for Server Authentication. Relying on certificate autoenrollment is not going to configure the correct permissions for the private key and add Network Service account permissions.

To check this, follow these steps:

launch the local computer certificate store (CertLM.msc).
Once the Computer store opened look for the store named: Certificates - Local Computer\Personal\Certificates.
Right click on the certificate that you are interested in, then select All Tasks, and click on Manage Private Keys.

4. Verify that Network Service account has Allow - Read Permissions. If not, then add it.

a. Click the Add button.

b. In the Select Users or Groups, click the Locations button, and select the local computer in the list.

c. Type in the name “Network Service”

d. Then click the Check Names button, and then click the OK button.

5. If the certificate does not appear to have a private key associated with it in via the Local Computer Certificate store snapin, then you may want to run the following CertUtil command to see if you can repair the association. CertUtil -RepairStore My [* / CertThumbprint].

How to change the certificate that Remote Desktop Services is using

If you have determined that Remote Desktop Services is using the wrong certificate, there are a couple of things that we can do to resolve this.

We can delete the certificate from the Computer Personal store and then cycle the Remote Desktop Configuration (SessionEnv) service. This would cause immediate enrollment of a certificate using the certificate template defined in the group policy.

PowerShell: 
     $RDPSettings = Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace Root\cimv2\Terminalservices -Filter "TerminalName='rdp-tcp'" 
     CertUtil -DelStore My $RDPSettings.SSLCertificateSHA1Hash 
     Net Stop SessionEnv 
     Net Start SessionEnv

2. We could update the Thumbprint value in WMI to reference another certificates thumbprint.

PowerShell: 
     $PATH = (Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices) 
     Set-WmiInstance -Path $PATH -argument @{SSLCertificateSHA1Hash="CERTIFICATETHUMBRPINT"}

WMIC:  wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash = "CERTIFICATETHUMBPRINT"

Conclusion

The first thing to remember is deploying certificates for Remote Desktop Services is best done by the Group Policy setting and to NOT setup the certificate template for autoenrollment. Setting the template up for autoenrollment will cause certificate issuance problems within the environment from multiple angles.

Unless you modify the certificate templates default Key Permissions setting found on the Request Handling tab, the account running the Remote Desktop Service will not have permission to the private key if the certificate is acquired via autoenrollment. This is not something that we would recommend.

This will cause a scenario where even if the SSLCertificateSHA1Hash value is correct, it will not be able to use the certificate because it will not have permission to use the private key. If you do have the template configured for custom Private Key permissions, you could again still have issues with the WMI SSLCertificateSHA1Hash value not being correct.

2. Configure the group policy setting properly as well as the certificate template. It is best to manage this configuration via group policy and you can ensure consistent experience for all RDS connections.

I know that a lot of you might have deeper questions about how the Remote Desktop Configuration service does this enrollment process, however, please keep in mind that the Remote Desktop Service is really owned by the Windows User Experience team in CSS, and so us Windows Directory Services engineers may not have that deeper level knowledge. We just get called in when the certificates do not work or fail to get issued. This is how we tend to know so much about the most common misconfigurations for this solution.

Rob “Why are RDS Certificates so complicated” Greene

Ask the Directory Services Team articles

The End is Nigh for DES and an Update for hunting down RC4

XML Filters

Hunting down DES tickets issued

Hunting down only legacy keys available:

Hunting down RC4 Tickets issued:

Custom Event Forwarder targets

Manifest text

Visual Studio

Troubleshooting TPM Certificate: How to Fix the "Missing Stored Keyset" Error

So, You’ve disabled Windows Hello for Business, but the User can still Sign-in using a PIN

Assigning Process Accountability to Group Policy Refreshes

Table of Contents

Scenario 1: Manual Group Policy Refresh

Current Logging

GPSVC.LOG:

Microsoft-Windows-GroupPolicy/OperationalLog:

New Logging

GPSVC.LOG:

Microsoft-Windows-GroupPolicy/OperationalLog:

Scenario 2: Background (Periodic) Group Policy Refresh

Current Logging

GPSVC.LOG:

New Logging

GPSVC.LOG:

Scenario 3: Programmatic Group Policy Refresh via the GP API

Current Logging

GPSVC.LOG:

New Logging

GPSVC.LOG:

Scenario 4: Scheduled Task / Remote GP Refresh (GPMC) / PowerShell 'Invoke-GPUpdate'

Current Logging

GPSVC.LOG:

New Logging

GPSVC.LOG:

Microsoft-Windows-TaskScheduler/Operational:

Scenario 5: Audit Policy modifications via SecPol

Current Logging

GPSVC.LOG:

New Logging

GPSVC.LOG:

From Guesswork to Clarity: GPP Diagnostics Improve in Windows Server 2025 and Windows 11 24H2

What Changed and When

Event ID 4117 – Group Policy Preferences Diagnostic Data

Scenario 1 – File Does Not Exist

Scenario 2 – File Exists, but Access Is Denied

Scenario 3 – Folder Delete Fails Due to Permissions

Scenario 4 – Drive Map with Invalid Network Path

Summary: Event ID → Action Decision Table

Why This Is a Big Deal

Final Thoughts

What’s New in Windows Group Policy Preferences Debug Logging

What’s New in Windows 11 24H2, 25H2?

Group Policy Preferences Debug Logging – Visual Overview

Figure 1. Group Policy Preferences Debug Logging using Local Group Policy

How to Enable Group Policy Preferences Logging and Tracing using Local Group Policy Editor (Gpedit.msc)

Steps to Configure GPP Logging and Tracing

Figure 2. Preference Logging and Tracing Policy Settings

Understanding Trace File Locations

Figure 3. Required Permissions for Custom Log Folder

Conclusion

Reading GPSVC Like a Crime Novel

Before we touch the logs: what GPSVC really is

Group Policy always runs in two phases (always)

Phase 1: Core Group Policy processing

Phase 2: Client‑Side Extension (CSE) processing

Enabling GPSVC debug logging

First rule of reading gpsvc.log: follow the thread

Machine policy processing: what it looks like in the log

Dependency and startup signatures

Connectivity waits (these matter more than people think)

OU walk and policy discovery (LSDOU)

Versioning, filtering, and replication health

Group Policy caching (what it actually looks like)

Slow link detection (log‑driven, not event‑driven)

CSE processing: the business end of Group Policy

Registry CSE example

User policy processing

When gpsvc.log isn’t enough: use TSS

Full date and time are available now in all group policy debug log files, here are sample log entries that look like with date and time:

When Group Policy Goes Haywire: Spotting registry.pol Corruption Fast (and other problems too)

Scenarios/Examples 

Example 1: Manually modified the contents of registry.pol with invalid data.

Example 2: Missing permissions for SYSTEM on registry.pol 

Summary 