Create a WMI Filter on a PDC with PowerShell
- Tenaka

- 30 minutes ago
- 5 min read
While building automation for domain deployment, OU structure, and delegation, I experienced one of those, too hard to do now, which nearly slipped past me, scripting the creation of a WMI filter for the PDC Emulator role.
Time Source
The goal is to make sure the PDC, and only the PDC, manages authoritative time. This particular GPO includes a root NTP server setting, whether that’s an IP address, a local atomic clock, or an external internet time source, and it’s vital that only the PDC syncs with it. Every other domain controller should, in turn, sync from the PDC, maintaining a proper hierarchy and preventing clock chaos.
Not Keen on WMI Filters
I’ll be honest, I don’t generally like WMI filters in GPO. They introduce performance hits and slow down policy processing, especially in larger environments. But in this case, it’s a pragmatic exception.
The filter ensures that only the PDC receives and applies the external time configuration, keeping time consistent across the domain and preventing catastrophic drift when an upstream time source fails spectacularly.
Prevent death and destruction
I’ve experienced this first-hand, the time source collapsed in a heap, and the PDC leapt forward a full 24 hours in an instant. The aftermath was... memorable. It's hard to believe the chaos inflicted when time goes awry.
MaxPhaseCorrention - Thank MS's Default value
To guard against that kind of chaos, the GPO settings MaxPosPhaseCorrection and MaxNegPhaseCorrection limit how far the system clock is allowed to jump forward or backward during synchronization. The issue is that Microsoft's default value is 86400 seconds or 24 hours, these overly generous settings have the potential to lead to carnage. The recommendation is to set both POS and NEG settings to 3600 or 1 hour.
These settings and the WMI filter ensure the domain’s time stays sane, stable, and immune to upstream meltdowns.
GPO Settings - Prevent the Meltdown
These are the current settings provided from GitHub, with the annex at the end of the blog providing the technical details.
Computer Configuration/Policies/Administrative Templates/System/Windows Time Service:
Global Configuration Settings
MaxNegPhaseCorrection = 3600
MaxPosPhaseCorrection = 3600
Computer Configuration/Policies/Administrative Templates/System/Windows Time Service/Time Providers:
Configure Windows NTP Client = Enabled
NTPServer = 192.168.30.1,0x8
Type = NTP
CrossSiteSyncFlags = 2
ResolverPeerBackoffMinutes = 15
ResolverPeerBackoffMaxTimes = 7
SpeicalPollInterval = 1024
EventLogFlags = 0
Enable Windows NTP Client = Enabled
Enable Windows NTP Server = Enabled
Script Prep
Download both the script and the zip file from GitHub.
Copy the files to the PDC into the 'C:\ADBackups\PDCNTP\' directory.
Don’t use another domain controller.
Running GPO scripts from a secondary DC introduces extra latency when connecting back to the PDC, which can cause failures.
Extract the zip file, ensuring the GUID directory is nested within the 'PDCNTP' directory.
C:\ADBackups\PDCNTP\{A5214940-95CC-4E93-837D-5D64CA58935C}\
If you prefer to use your own GPO export, that’s fine, as long as the path is correct, the script will automatically resolve the appropriate GUID and BackupID.
Execution of the Script
With Domain Admin privileges, open an elevated PowerShell window and execute the following commands
CD to C:\ADBackups\PDCNTP\ ; .\Create_WMI_NTP_PDC.ps1
Open Group Policy Management.
Confirm that the GPO has been created and linked to the Domain Controller OU
Update the IP Address for the NTP Server, it's unlikely we share the same time server IP.

The only remaining task for me is to integrate the NTP GPO into the fully automated Domain deployment script. Enjoy and thanks for your time.
ANNEX - Breakdown of GPO Settings
Computer Configuration > Policies > Administrative Templates > System > Windows Time Service > Global Configuration Settings
MaxNegPhaseCorrection
Current value: 3600 (1 hour)
Purpose: Defines the maximum number of seconds the clock can be moved backward when synchronizing time. If the correction exceeds this, Windows logs an event instead of applying the adjustment.
Relevance: Prevents the PDC from winding time back too far due to an erratic NTP source, which can break Kerberos authentication and replication.
Alternative values:
0 — disables large backward corrections entirely.
300 — 5 minutes (useful for high-availability or sensitive environments).
86400 — 24 hours (default Microsoft value, overly generous for a PDC).
4294967295 (0xFFFFFFFF) — disables the limit completely (not recommended).
MaxPosPhaseCorrection
Current value: 3600 (1 hour)
Purpose: Defines the maximum number of seconds the clock can be moved forward.
Relevance: Protects against catastrophic jumps when an upstream NTP server malfunctions.
This provides a 1-hour safety window in either direction, preventing massive jumps while still allowing normal synchronization drift to be corrected automatically.
Alternative values:
300 — a conservative 5-minute correction limit.
900 — 15 minutes (a good balance for stable networks).
86400 — 24 hours (default).
4294967295 — disables the limit (unsafe on domain controllers).
Computer Configuration > Policies > Administrative Templates > System > Windows Time Service > Time Providers
Configure Windows NTP Client = Enabled
Enables policy control of NTP client behaviour to enforce the following parameters.
NTPServer = 192.168.30.1,0x8
Purpose: Defines the external NTP source the PDC syncs with. The ,0x8 flag tells Windows to use client mode.
Alternative formats and examples:
pool.ntp.org,0x8 — public NTP pool.
time.google.com,0x8 — Google’s NTP service.
ntp.nist.gov,0x8 — US NIST time source.
gps-clock.local,0x8 — local GPS or atomic reference.
Relevance: This should be a reliable and stratum-1 or stratum-2 source. The PDC is the only domain controller that should query an external NTP server.
Type = NTP
Purpose: Forces synchronization using the NTP protocol with the specified NTPServer.
Other valid values:
NT5DS — Default for domain-joined machines (syncs from domain hierarchy).
AllSync — Uses all available sync mechanisms (rarely needed).
NoSync — Disables synchronization entirely.
Relevance: For the PDC, NTP ensures it pulls time from the defined external source, not from another DC.
CrossSiteSyncFlags = 2
Purpose: Controls cross-site time synchronization.
Value meanings:
0 — Allow synchronization across all sites.
1 — Only sync from DCs in the same site.
2 — Never sync from DCs in other sites (recommended for PDC).
Relevance: Keeps the PDC isolated as the domain’s root time authority, avoiding cross-site time loops.
ResolverPeerBackoffMinutes = 15
Purpose: Specifies how long the service waits before retrying after a failed NTP sync.
Alternatives:
5 — More aggressive retry.
30 — More relaxed retry, suitable for unreliable WANs.
ResolverPeerBackoffMaxTimes = 7
Purpose: Defines the maximum number of exponential backoff attempts before giving up.
Alternatives:
3 — Faster failover (good for testing).
10 — More patient retry window.
SpecialPollInterval = 1024
Purpose: Sets how often (in seconds) the PDC polls the NTP source — roughly every 17 minutes.
Alternatives:
3600 — Once per hour (lighter network load).
900 — Every 15 minutes (more aggressive for accuracy).
86400 — Once per day (not advised for volatile networks).
Relevance: Frequent polling maintains accurate time and compensates for drift.
EventLogFlags = 0
Purpose: Controls event logging verbosity.
Values:
0 — Only critical errors.
1 — Informational and error events.
2 — All events, including debugging.
Relevance: On a PDC, 0 keeps logs clean while still alerting to serious time issues.
Enable Windows NTP Client = Enabled
Purpose: Ensures the time service actively synchronizes with the defined NTP source.
Relevance: Essential for keeping the PDC accurate and stable.
Enable Windows NTP Server = Enabled
Purpose: Turns the PDC into an NTP server for the domain.
Relevance: Other DCs and domain members sync from the PDC rather than directly from the external NTP source, maintaining a clean and authoritative time hierarchy.



Comments