CloudLabs Decades of server expertise
Available · remote-firstBeschikbaar · remote

Time Drift in Hyper-V Clusters: The Silent Killer of Kerberos and CSV

By Hans Vredevoort · 28 May 2026 · 13 minute read · Time Service

A Hyper-V cluster with clock skew between nodes is a time bomb. Not figuratively, literally. When clocks on cluster nodes drift more than five minutes apart, Kerberos breaks. From fifty seconds, cluster heartbeats lose their synchronisation. And the moment a Hyper-V host loses its time reference, domain-joined VMs running on that host can no longer maintain authentication to AD.

In most Hyper-V Cluster Health Checks CloudLabs runs, we find time issues. Not always dramatic, often still below the threshold where something fails outright, but clearly out of balance. And it is exactly the kind of problem monitoring tools miss until it is too late, because a few seconds of skew never triggers an alert.

This article explains why time service on a Hyper-V cluster works differently from a standalone server, which configurations we treat as best practice in 2026, and how to detect drift before the first Kerberos failure.

In this article
  1. Why time drift in Hyper-V clusters is specifically risky
  2. The Microsoft time hierarchy and where Hyper-V hosts fit
  3. The Hyper-V Time Synchronization Integration Service, and when to disable it
  4. PDC emulator configuration, the root of all time
  5. Cluster node configuration, w32time settings that actually matter
  6. Detecting drift before it fails
  7. Three common misconfiguration patterns
  8. Remediation playbook

1. Why time drift in Hyper-V clusters is specifically risky

On a standalone server, clock drift is an annoyance. On a Hyper-V cluster, it is a cascade trigger.

Kerberos. Active Directory uses Kerberos for authentication, and Kerberos has a default clock tolerance of five minutes. Difference more than that between client and KDC, and all new authentication fails with KRB_AP_ERR_SKEW. Existing sessions keep working until their ticket expires, so the first symptoms appear 8 to 10 hours after the drift and look like they have no cause. We have seen this on customer site: Monday morning nobody can log in, everything points to DNS, and the real cause is a Hyper-V host that lost its NTP source on Saturday.

Cluster heartbeats. Failover Clustering expects all nodes to sit within reasonable time tolerance to correctly track heartbeat events. With large skew, nodes report events in the wrong order, and the Cluster Service may decide a node is out of cluster while that node is running fine.

CSV coordinator arbitration. Cluster Shared Volume coordinator role transfers are logged with timestamps. Skew between nodes makes log analysis impossible, and in rare cases it can put CSV rebalancing into a loop where the balancer interprets its own actions as concurrent with the other node.

Live Migration timing. The live migration handshake uses timestamps for sequence validation. Large skew between source and target host can abort migrations without a clear error, or worse, report the migration complete while memory pages were skipped.

VM clocks that drift. Domain-joined VMs sync with their PDC emulator. If that PDC emulator in turn depends on a Hyper-V host not managing its own time well, you get drift in two layers, and the solution becomes much more complex than "fix the NTP source".

2. The Microsoft time hierarchy and where Hyper-V hosts fit

The correct time architecture on a domain environment:

  • The top level. One DC with the PDC emulator FSMO role synchronises with an external, reliable time source. Preferably time.windows.com, pool.ntp.org, or a hardware stratum-1 source. Configuration: Type = NTP, NtpServer = <source>,0x9.
  • All other DCs. Synchronise with the PDC emulator through the domain hierarchy. Configuration: Type = NT5DS.
  • All domain-joined servers, including Hyper-V hosts. Synchronise with the domain hierarchy. Configuration: Type = NT5DS.
  • All domain-joined VMs. Synchronise with the domain hierarchy through their own w32time service. Configuration: Type = NT5DS. And critically: the Hyper-V Time Synchronization Integration Service must be off for these VMs. See section 3.
  • Non-domain VMs or isolated clusters. Sync directly with an external NTP source or with an NTP source in the management network. Configuration: Type = NTP.

What we find in a typical Hyper-V Cluster Health Check is that this hierarchy is broken somewhere mid-stream. The PDC emulator sits on Type = NT5DS (syncs with itself, effectively with the hardware clock), the Hyper-V hosts sit on Type = NTP (each pointing to a different source), and the VMs have their Hyper-V Time Sync IS enabled while also trying to do NT5DS. Result: three time sources each pulling in a different direction.

3. The Hyper-V Time Synchronization Integration Service, and when to disable it

The Hyper-V Time Sync Integration Service syncs the VM clock with the Hyper-V host's clock. That sounds useful, and for non-domain-joined VMs it is. For domain-joined VMs it is harmful and should be disabled.

Why off for domain-joined VMs:

A domain-joined VM should get its time from AD through w32time NT5DS. If the Hyper-V Time Sync IS is also active, you get two competing time sources: the host (with its own time state) and the domain. The moment host and domain disagree (which happens more often than you think), the VM clock starts ping-ponging between both.

The Microsoft guidance:

Microsoft's documentation has said this explicitly since Windows Server 2012 R2: for domain-joined VMs, Time Sync should only be active for the "Time Synchronization" sub-service during save/restore operations, not for regular clock sync. Practically that means the integration service itself off, or the specific sync component off.

Check per VM:

# Per VM, on the Hyper-V host
Get-VMIntegrationService -VMName 'MyVM' |
    Where-Object Name -eq 'Time Synchronization' |
    Select-Object VMName, Name, Enabled

Disable for domain-joined VMs:

# For one VM
Disable-VMIntegrationService -VMName 'MyVM' -Name 'Time Synchronization'

# For all VMs on a host (filter by name, OS type, or simply all)
Get-VM | Disable-VMIntegrationService -Name 'Time Synchronization'

In a Health Check we report this per VM, with a flag on every domain-joined VM that still has Time Sync enabled.

4. PDC emulator configuration, the root of all time

Everything starts at the PDC emulator. If that is wrong, the error propagates through the entire domain.

Which node holds the PDC emulator role:

# From any domain-joined machine
Get-ADDomain | Select-Object PDCEmulator

Configure the PDC emulator with an external time source:

# On the PDC emulator itself
w32tm /config /manualpeerlist:"time.windows.com,0x9 pool.ntp.org,0x9" `
    /syncfromflags:manual /reliable:yes /update

# Stop and restart w32time
Restart-Service w32time

# Force a sync and check status
w32tm /resync /rediscover
w32tm /query /status
w32tm /query /source

Tolerance settings we set as standard:

# Maximum 5 minutes in both directions (default is far higher)
w32tm /config /computer:<PDC> `
    /maxposphasecorrection:300 `
    /maxnegphasecorrection:300 `
    /update

Restart-Service w32time

The MaxPosPhaseCorrection and MaxNegPhaseCorrection values determine how large a time adjustment may be before w32time rejects it. Default values in older Windows versions are absurd (54 years), which means a corrupted NTP source can yank your clock wide open without w32time complaining. 300 seconds (5 minutes) is a safe threshold that forces manual intervention on large drift.

Verify that the PDC emulator actually syncs externally:

w32tm /query /source
# Expected: <external NTP source>, not "Local CMOS Clock" or "Free-running System Clock"

If we do not find this, the PDC emulator is effectively running on its own hardware clock, and all other DCs and servers in the domain cheerfully sync with that drifting clock.

5. Cluster node configuration, w32time settings that actually matter

Cluster nodes as domain-joined servers belong on Type = NT5DS. That is usually the default after domain join. But several settings deserve specific attention on Hyper-V hosts.

Verify per cluster node:

Invoke-Command -ComputerName (Get-ClusterNode).Name {
    [PSCustomObject]@{
        Node              = $env:COMPUTERNAME
        Type              = (w32tm /query /configuration | Select-String 'Type:').Line.Trim()
        Source            = (w32tm /query /source)
        LastSync          = (w32tm /query /status | Select-String 'Last Successful').Line.Trim()
        Stratum           = (w32tm /query /status | Select-String 'Stratum').Line.Trim()
        MaxPosPhaseCorr   = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config').MaxPosPhaseCorrection
        MaxNegPhaseCorr   = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config').MaxNegPhaseCorrection
    }
} | Format-Table -AutoSize

What the output should show:

  • Type must be NT5DS on every cluster node. NTP on a node that is not a DC or PDC is a misconfiguration.
  • Source must be a domain controller in the same domain. "Local CMOS Clock" or "Free-running System Clock" is a symptom of a w32time service that has lost its source.
  • LastSync must be recent, within the last sync interval (default 64 to 1024 seconds depending on stability).
  • Stratum must be one higher than the PDC emulator's. If the PDC is stratum 2 (syncing with external stratum-1), then all other DCs are stratum 3, and cluster nodes are stratum 4.
  • MaxPosPhaseCorrection and MaxNegPhaseCorrection we set as standard to 300 seconds, same as the PDC emulator. This prevents a corrupted sync source from suddenly shifting the clock by hours.

Measure clock skew between nodes:

$nodes = (Get-ClusterNode).Name
foreach ($node in $nodes) {
    foreach ($peer in $nodes) {
        if ($node -ne $peer) {
            $offset = w32tm /stripchart /computer:$peer /dataonly /samples:1 |
                Select-String '^\d' | Select-Object -First 1
            Write-Host "$node <-> $peer : $offset"
        }
    }
}

Acceptable skew between cluster nodes: under 1 second in steady state, under 5 seconds during a patch round or node reboot. Above 30 seconds is an urgent remediation topic.

6. Detecting drift before it fails

Monitoring tools typically alert only on clock skew that has already caused damage. We add a simple drift monitor to customer environments during Health Check remediation:

# Drift detection script, run on a management host or via scheduled task
$threshold = 30  # seconds

$cluster = Get-Cluster
$nodes = (Get-ClusterNode -Cluster $cluster).Name
$baseline = $nodes[0]

foreach ($peer in $nodes | Where-Object {$_ -ne $baseline}) {
    $output = w32tm /stripchart /computer:$peer /dataonly /samples:1 2>&1
    $offsetLine = $output | Where-Object {$_ -match '^\d'} | Select-Object -First 1
    if ($offsetLine -match '([\d\.\-]+)s') {
        $offset = [math]::Abs([double]$matches[1])
        if ($offset -gt $threshold) {
            Write-Warning "Drift between $baseline and $peer: $offset seconds"
            # Hook to SIEM, Teams webhook, or monitoring stack here
        }
    }
}

Schedule this every 15 minutes on a management host. The value of a dedicated drift monitor is that it catches issues hours before the first Kerberos failure, at a point where remediation is still non-disruptive.

Time service configuration is one of those topics every administrator thinks is in order, and where during a Health Check we find something off in 7 out of 10 environments.

A CloudLabs Hyper-V Cluster Health Check checks time hierarchy, PDC emulator configuration, per-node settings, and Hyper-V Time Sync IS state per VM, and includes a remediation script with the report.

Schedule a Health Check intro call →

7. Three common misconfiguration patterns

Pattern 1: PDC emulator on Type = NT5DS

Classic configuration error. The PDC emulator names itself as source through NT5DS, which effectively means: I sync with myself, I use my own hardware clock. Works until the hardware clock drifts, and then the entire domain drifts with it.

Fix: set the PDC emulator to Type = NTP with an external peer list and /reliable:yes. See section 4.

Pattern 2: Hyper-V host on Type = NTP to an external source

A Hyper-V host syncing independently to time.windows.com instead of to the domain hierarchy. Sounds logical ("closer to the source"), but breaks the entire principle of a domain hierarchy and produces inconsistent time across hosts.

Fix: set the host to Type = NT5DS. The host then syncs with a DC, which syncs with the PDC emulator, which syncs with external NTP.

Pattern 3: VMs with Hyper-V Time Sync IS enabled plus NT5DS

Domain-joined VM trying to sync from both the Hyper-V host and the domain hierarchy. The clock ping-pongs, especially when host and domain disagree by a fraction of a second.

Fix: disable Hyper-V Time Sync IS per VM for all domain-joined VMs. See section 3.

8. Remediation playbook

The order we use as standard in a CloudLabs remediation engagement:

Step 1, identify the PDC emulator:

Get-ADDomain | Select-Object PDCEmulator

Step 2, fix the PDC emulator:

Configure external NTP sources, set /reliable:yes, set MaxPosPhaseCorrection and MaxNegPhaseCorrection to 300 seconds, restart w32time. Verify that w32tm /query /source actually shows an external source.

Step 3, fix all other DCs:

Set them to Type = NT5DS, verify their source is a DC in the domain. No external NTP sources on non-PDC DCs.

Step 4, fix all Hyper-V hosts and domain-joined member servers:

Set them to Type = NT5DS. Adjust MaxPosPhaseCorrection and MaxNegPhaseCorrection. Restart w32time. Verify sync.

Step 5, fix VMs:

For all domain-joined VMs: disable Hyper-V Time Synchronization Integration Service. Verify the VMs show a DC in the domain as source through w32tm /query /source.

Step 6, monitor:

Schedule the drift detection script from section 6 every 15 minutes. Hook it into existing monitoring or SIEM. Set a threshold at 30 seconds for early warning.

Step 7, document:

Write down which settings live where, which external NTP sources are used, and what the procedure is on a PDC emulator failover. This is exactly the kind of knowledge that gets lost during staff changes, and where Health Checks two years later find drift in the same environment again.

The bottom line

Time service in a Hyper-V cluster is not "set and forget". The interaction between w32time, AD replication, cluster heartbeats, Live Migration handshake, and Hyper-V Time Sync IS is complex enough that a wrong assumption on one layer surfaces as a symptom on another layer. When Kerberos fails, everyone looks at AD. When cluster heartbeats flap, everyone looks at the network. The actual cause often sits two layers deeper, in a w32time configuration nobody has touched in the last three years.

A CloudLabs Hyper-V Cluster Health Check includes time service analysis as standard. Findings are reported with severity that scales with actual skew and blast radius. Remediation scripts are idempotent and can be applied by the customer team themselves.

Schedule a Hyper-V Cluster Health Check intro call →

Frequently asked questions

My cluster has worked fine for years, why should I worry about time service?

Drift accumulates slowly. Until the moment a PDC emulator fails or a Hyper-V host is patched, a misconfiguration can stay hidden for years. We regularly see that a planned maintenance action is the first time drift becomes visible, and that is an unfortunate moment for surprises.

Does this work the same on Azure Local and Azure Stack HCI?

Largely yes. Azure Local nodes are domain-joined and follow the same w32time hierarchy. However, for Arc-managed Azure Local clusters there is an additional layer, because the Arc agent also does its own time validation toward Azure. The threshold there is stricter (five minutes max), so drift becomes visible sooner.

What if I am not allowed to use an external NTP source due to security policy?

Then a hardware stratum-1 source in the management network is the solution. Devices from Meinberg, Microsemi, or a GPS-disciplined Linux server can serve as an internal NTP source. The PDC emulator then points to that hardware instead of time.windows.com. For strict air-gapped environments this is the standard approach.

How much clock skew is acceptable between cluster nodes?

Under 1 second in steady state. Up to 5 seconds during a patch round or node reboot. Above 30 seconds is an urgent remediation topic. Above 5 minutes is already an active incident, because Kerberos will refuse new authentication.

What is /reliable:yes and when do you use it?

/reliable:yes marks a time source as "reliable", which allows other w32time clients to sync with it. It is a required setting on the PDC emulator (without it, it is not a valid time source for the rest of the domain). On a DC that is not PDC, /reliable:no or no setting is correct.

Time drift in Hyper-V clusters: de stille killer van Kerberos en CSV

Door Hans Vredevoort · 28 mei 2026 · 13 minuten leestijd · Time Service

Een Hyper-V cluster met klok-skew tussen nodes is een tijdbom. Niet figuurlijk, maar letterlijk. Wanneer de klokken op cluster-nodes meer dan vijf minuten uit elkaar lopen, valt Kerberos om. Vanaf vijftig seconden raken cluster-heartbeats hun synchronisatie kwijt. En zodra een Hyper-V host zijn tijd-referentie verliest, kunnen domain-joined VM's die op die host draaien hun authenticatie naar AD niet meer onderhouden.

In de meeste Hyper-V Cluster Health Checks die CloudLabs uitvoert, vinden we klok-issues. Niet altijd dramatisch, vaak nog onder de drempel waarop iets faalt, maar wel duidelijk uit balans. En het is precies het soort probleem dat monitoring tools missen tot het te laat is, omdat een paar seconden afwijking nergens een alarm triggert.

Dit artikel legt uit waarom time service op een Hyper-V cluster anders werkt dan op een standalone server, welke configuraties wij in 2026 als best practice hanteren, en hoe je drift detecteert vóór de eerste Kerberos-failure.

In dit artikel
  1. Waarom time drift in Hyper-V clusters specifiek riskant is
  2. De Microsoft tijd-hiërarchie en waar Hyper-V hosts in passen
  3. De Hyper-V Time Synchronization Integration Service, en wanneer hem uit te zetten
  4. PDC emulator-configuratie, de root van alle tijd
  5. Cluster-node configuratie, w32time settings die er werkelijk toe doen
  6. Drift detecteren vóór het faalt
  7. Drie veelvoorkomende fout-patronen
  8. Remediation playbook

1. Waarom time drift in Hyper-V clusters specifiek riskant is

Op een standalone server is klok-drift een irritatie. Op een Hyper-V cluster is het een cascade-trigger.

Kerberos. Active Directory gebruikt Kerberos voor authenticatie, en Kerberos heeft een standaard klok-tolerantie van vijf minuten. Verschil meer dan dat tussen client en KDC, en alle nieuwe authenticatie faalt met KRB_AP_ERR_SKEW. Bestaande sessies blijven werken tot hun ticket verloopt, dus de eerste symptomen komen 8 tot 10 uur na de drift en lijken zonder oorzaak. We hebben dit op klantsite zien gebeuren: maandagochtend kan niemand inloggen, alles wijst naar DNS, en de werkelijke oorzaak is een Hyper-V host die zaterdag zijn NTP-bron verloor.

Cluster heartbeats. Failover Clustering verwacht dat alle nodes binnen redelijke tijd-tolerantie zitten om heartbeat-events correct te volgen. Bij grote skew gaan nodes evenementen in verkeerde volgorde rapporteren, en kan de Cluster Service besluiten dat een node uit het cluster is terwijl die node prima draait.

CSV coordinator-arbitratie. Cluster Shared Volume coordinator-rol overdrachten worden gelogd met timestamps. Skew tussen nodes maakt log-analyse onmogelijk, en in zeldzame gevallen kan het CSV-rebalancing in een loop brengen waar de balancer eigen acties als concurrent met de andere node interpreteert.

Live Migration timing. De live-migration handshake gebruikt timestamps voor sequence-validatie. Grote skew tussen bron en doel-host kan migraties afbreken zonder duidelijke foutmelding, of erger, de migratie compleet rapporteren terwijl er memory pages zijn overgeslagen.

VM clocks die afdwalen. Domain-joined VM's syncen met hun PDC emulator. Als die PDC emulator op zijn beurt afhankelijk is van een Hyper-V host die zijn eigen tijd niet goed beheert, krijg je drift in twee lagen, en de oplossing wordt veel ingewikkelder dan "fix de NTP-bron".

2. De Microsoft tijd-hiërarchie en waar Hyper-V hosts in passen

De juiste tijd-architectuur op een domein-omgeving:

  • Het top-level. Eén DC met de PDC emulator FSMO-rol synchroniseert met een externe, betrouwbare tijdbron. Bij voorkeur time.windows.com, pool.ntp.org, of een hardware-stratum-1-bron. Configuratie: Type = NTP, NtpServer = <bron>,0x9.
  • Alle andere DC's. Synchroniseren met de PDC emulator via de domein-hiërarchie. Configuratie: Type = NT5DS.
  • Alle domain-joined servers, inclusief Hyper-V hosts. Synchroniseren met de domein-hiërarchie. Configuratie: Type = NT5DS.
  • Alle domain-joined VM's. Synchroniseren met de domein-hiërarchie via hun eigen w32time-service. Configuratie: Type = NT5DS. En cruciaal: de Hyper-V Time Synchronization Integration Service moet uit staan voor deze VM's. Zie sectie 3.
  • Non-domain VM's of geïsoleerde clusters. Direct synchroniseren met een externe NTP-bron of met een NTP-bron in het managementnetwerk. Configuratie: Type = NTP.

Wat we in een typische Hyper-V Cluster Health Check vinden, is dat deze hiërarchie ergens halverwege is gebroken. De PDC emulator staat op Type = NT5DS (synct met zichzelf, in feite met de hardware-klok), de Hyper-V hosts staan op Type = NTP (en wijzen elk naar een andere bron), en de VM's hebben hun Hyper-V Time Sync IS aan staan terwijl ze ook NT5DS proberen te doen. Resultaat: drie tijd-bronnen die elk in een andere richting trekken.

3. De Hyper-V Time Synchronization Integration Service, en wanneer hem uit te zetten

De Hyper-V Time Sync Integration Service synchroniseert de VM-klok met die van de Hyper-V host. Dat klinkt nuttig, en voor non-domain-joined VM's is het dat ook. Voor domain-joined VM's is het schadelijk en hoort het uit te staan.

Waarom uit voor domain-joined VM's:

Een domain-joined VM hoort zijn tijd uit AD te halen via w32time NT5DS. Als de Hyper-V Time Sync IS ook actief is, krijg je twee competing-time-sources: de host (die zijn eigen tijd-staat heeft) en het domein. Op het moment dat host en domein van elkaar afwijken (en dat gebeurt vaker dan je denkt), gaat de VM-klok pingpongen tussen beide.

Het Microsoft-advies:

Microsoft's documentatie zegt dit expliciet sinds Windows Server 2012 R2: voor domain-joined VM's hoort Time Sync alleen actief te zijn voor de "Time Synchronization" sub-service tijdens save/restore-operaties, niet voor reguliere klok-sync. Praktisch betekent dat de integration service zelf uit, of de specifieke sync-component uit.

Controleer per VM:

# Per VM, op de Hyper-V host
Get-VMIntegrationService -VMName 'MyVM' |
    Where-Object Name -eq 'Time Synchronization' |
    Select-Object VMName, Name, Enabled

Uitschakelen voor domain-joined VM's:

# Voor één VM
Disable-VMIntegrationService -VMName 'MyVM' -Name 'Time Synchronization'

# Voor alle VM's op een host (filter op naam, OS-type, of gewoon allemaal)
Get-VM | Disable-VMIntegrationService -Name 'Time Synchronization'

In een Health Check rapporteren we dit per VM, met een vlag voor elke domain-joined VM die Time Sync nog aan heeft staan.

4. PDC emulator-configuratie, de root van alle tijd

Alles begint bij de PDC emulator. Als die niet goed staat, propageert de fout door het hele domein.

Welke node heeft de PDC emulator-rol:

# Vanaf elke domain-joined machine
Get-ADDomain | Select-Object PDCEmulator

Configureer de PDC emulator met een externe tijdbron:

# Op de PDC emulator zelf
w32tm /config /manualpeerlist:"time.windows.com,0x9 pool.ntp.org,0x9" `
    /syncfromflags:manual /reliable:yes /update

# Stop en herstart w32time
Restart-Service w32time

# Forceer een sync en check status
w32tm /resync /rediscover
w32tm /query /status
w32tm /query /source

Tolerantie-instellingen die we standaard zetten:

# Maximum 5 minuten in beide richtingen (default is veel hoger)
w32tm /config /computer:<PDC> `
    /maxposphasecorrection:300 `
    /maxnegphasecorrection:300 `
    /update

Restart-Service w32time

De MaxPosPhaseCorrection en MaxNegPhaseCorrection waarden bepalen hoe groot een tijd-aanpassing mag zijn voordat w32time hem weigert. Default-waarden zijn in oudere Windows-versies absurd hoog (54 jaar), wat betekent dat een corrupte NTP-bron je klok wagenwijd kan verzetten zonder dat w32time klaagt. 300 seconden (5 minuten) is een veilige drempel die handmatige tussenkomst forceert bij grote drift.

Verifieer dat de PDC emulator daadwerkelijk extern synct:

w32tm /query /source
# Verwacht: <externe NTP-bron>, niet "Local CMOS Clock" of "Free-running System Clock"

Vinden we dit niet, dan staat de PDC emulator effectief op zijn eigen hardware-klok, en alle andere DC's en servers in het domein syncen vrolijk met die drifting klok.

5. Cluster-node configuratie, w32time settings die er werkelijk toe doen

Cluster-nodes als domain-joined servers horen op Type = NT5DS. Dat is meestal de default na domain-join. Maar er zijn een paar settings die op Hyper-V hosts specifieke aandacht verdienen.

Verifieer per cluster-node:

Invoke-Command -ComputerName (Get-ClusterNode).Name {
    [PSCustomObject]@{
        Node              = $env:COMPUTERNAME
        Type              = (w32tm /query /configuration | Select-String 'Type:').Line.Trim()
        Source            = (w32tm /query /source)
        LastSync          = (w32tm /query /status | Select-String 'Last Successful').Line.Trim()
        Stratum           = (w32tm /query /status | Select-String 'Stratum').Line.Trim()
        MaxPosPhaseCorr   = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config').MaxPosPhaseCorrection
        MaxNegPhaseCorr   = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config').MaxNegPhaseCorrection
    }
} | Format-Table -AutoSize

Wat de output moet laten zien:

  • Type moet NT5DS zijn op elke cluster-node. NTP op een node die geen DC of PDC is, is een fout-configuratie.
  • Source moet een domain controller in het zelfde domein zijn. "Local CMOS Clock" of "Free-running System Clock" is een symptoom van een w32time-service die zijn bron kwijt is.
  • LastSync moet recent zijn, binnen het laatste sync-interval (default elke 64 tot 1024 seconden afhankelijk van stabiliteit).
  • Stratum moet één hoger zijn dan dat van de PDC emulator. Als de PDC stratum 2 is (sync met extern stratum-1), dan zijn alle andere DC's stratum 3, en zijn cluster-nodes stratum 4.
  • MaxPosPhaseCorrection en MaxNegPhaseCorrection zetten we standaard op 300 seconden, zelfde als op de PDC emulator. Dit voorkomt dat een corrupte sync-bron de klok ineens uren verzet.

De klok-skew tussen nodes meten:

$nodes = (Get-ClusterNode).Name
foreach ($node in $nodes) {
    foreach ($peer in $nodes) {
        if ($node -ne $peer) {
            $offset = w32tm /stripchart /computer:$peer /dataonly /samples:1 |
                Select-String '^\d' | Select-Object -First 1
            Write-Host "$node <-> $peer : $offset"
        }
    }
}

Acceptabele skew tussen cluster-nodes: onder 1 seconde in steady state, onder 5 seconden gedurende een patch-ronde of node-reboot. Boven 30 seconden is een dringend remediation-onderwerp.

6. Drift detecteren vóór het faalt

Monitoring tools alarmeren meestal pas bij klok-skew die al schade veroorzaakt. Wij voegen tijdens Health Check remediation een eenvoudige drift-monitor toe aan klant-omgevingen:

# Drift-detection script, draaien op een management-host of via scheduled task
$threshold = 30  # seconden

$cluster = Get-Cluster
$nodes = (Get-ClusterNode -Cluster $cluster).Name
$baseline = $nodes[0]

foreach ($peer in $nodes | Where-Object {$_ -ne $baseline}) {
    $output = w32tm /stripchart /computer:$peer /dataonly /samples:1 2>&1
    $offsetLine = $output | Where-Object {$_ -match '^\d'} | Select-Object -First 1
    if ($offsetLine -match '([\d\.\-]+)s') {
        $offset = [math]::Abs([double]$matches[1])
        if ($offset -gt $threshold) {
            Write-Warning "Drift between $baseline and $peer: $offset seconds"
            # Naar SIEM, Teams webhook, of monitoring stack hier
        }
    }
}

Schedule dit elke 15 minuten op een management-host. De waarde van een dedicated drift-monitor is dat hij issues uren vóór de eerste Kerberos-failure oppikt, op een moment waarop remediation nog niet-disruptief is.

Time service-configuratie is een van die onderwerpen waar elke beheerder denkt dat het op orde is, en waar we tijdens een Health Check in 7 van de 10 omgevingen iets vinden dat niet klopt.

Een CloudLabs Hyper-V Cluster Health Check controleert tijd-hiërarchie, PDC emulator-configuratie, per-node settings en Hyper-V Time Sync IS-status per VM, en levert een remediation-script mee als onderdeel van het rapport.

Plan een Health Check kennismaking →

7. Drie veelvoorkomende fout-patronen

Patroon 1: PDC emulator op Type = NT5DS

Klassieke configuratiefout. De PDC emulator wijst zichzelf aan als bron via NT5DS, wat effectief betekent: ik sync met mezelf, ik gebruik mijn eigen hardware-klok. Werkt totdat de hardware-klok afdrijft, en dan drijft het hele domein mee.

Fix: zet de PDC emulator op Type = NTP met een externe peer-lijst en /reliable:yes. Zie sectie 4.

Patroon 2: Hyper-V host met Type = NTP naar een externe bron

Een Hyper-V host die zelfstandig naar time.windows.com syncet in plaats van naar de domein-hiërarchie. Klinkt logisch ("dichter bij de bron"), maar breekt het hele principe van een domein-hiërarchie en zorgt voor inconsistente tijd tussen hosts.

Fix: zet de host op Type = NT5DS. De host syncet dan met een DC, die met de PDC emulator syncet, die met externe NTP syncet.

Patroon 3: VM's met Hyper-V Time Sync IS aan plus NT5DS

Domain-joined VM die op zowel de Hyper-V host als de domein-hiërarchie probeert te syncen. De klok ping-pongt, zeker als host en domein een fractie van een seconde van elkaar verschillen.

Fix: zet Hyper-V Time Sync IS uit per VM voor alle domain-joined VM's. Zie sectie 3.

8. Remediation playbook

De volgorde die wij standaard hanteren in een CloudLabs remediation-opdracht:

Stap 1, identificeer de PDC emulator:

Get-ADDomain | Select-Object PDCEmulator

Stap 2, fix de PDC emulator:

Configureer externe NTP-bronnen, zet /reliable:yes, zet MaxPosPhaseCorrection en MaxNegPhaseCorrection op 300 seconden, herstart w32time. Verifieer dat w32tm /query /source daadwerkelijk een externe bron toont.

Stap 3, fix alle andere DC's:

Zet ze op Type = NT5DS, verifieer dat hun source een DC in het domein is. Geen externe NTP-bronnen op niet-PDC DC's.

Stap 4, fix alle Hyper-V hosts en domain-joined member-servers:

Zet ze op Type = NT5DS. Pas MaxPosPhaseCorrection en MaxNegPhaseCorrection aan. Herstart w32time. Verifieer sync.

Stap 5, fix VM's:

Voor alle domain-joined VM's: zet Hyper-V Time Synchronization Integration Service uit. Verifieer dat de VM's via w32tm /query /source een DC in het domein als bron tonen.

Stap 6, monitor:

Schedule het drift-detection script uit sectie 6 elke 15 minuten. Hook het in op je bestaande monitoring of SIEM. Zet een drempel op 30 seconden voor early warning.

Stap 7, documenteer:

Schrijf op welke instellingen waar staan, welke externe NTP-bronnen worden gebruikt, en wat de procedure is bij een PDC emulator-failover. Dit is precies het soort kennis dat verloren gaat bij personeelswissels en waar Health Checks twee jaar later weer drift in dezelfde omgeving aantreffen.

De ondergrens

Time service in een Hyper-V cluster is niet "set and forget". De interactie tussen w32time, AD-replicatie, cluster-heartbeats, Live Migration handshake en Hyper-V Time Sync IS is complex genoeg dat een verkeerde aanname op één laag tot symptomen op een andere laag leidt. Wanneer Kerberos faalt, kijkt iedereen naar AD. Wanneer cluster-heartbeats vlokken, kijkt iedereen naar het netwerk. De werkelijke oorzaak zit vaak twee lagen dieper, in een w32time-configuratie die niemand de afgelopen drie jaar heeft aangeraakt.

Een CloudLabs Hyper-V Cluster Health Check bevat tijd-service analyse standaard. Bevindingen worden gerapporteerd met severity die schaalt met de werkelijke skew en de blast radius. Remediation-scripts zijn idempotent en kunnen door het klant-team zelf worden toegepast.

Plan een Hyper-V Cluster Health Check kennismaking →

Veelgestelde vragen

Mijn cluster werkt prima al jaren, waarom zou ik me zorgen maken over time service?

Drift bouwt langzaam op. Tot het moment dat een PDC emulator failed of een Hyper-V host wordt gepatcht, kan een misconfiguratie jarenlang verborgen blijven. We zien regelmatig dat een geplande maintenance-actie de eerste keer is dat de drift zichtbaar wordt, en dat is een ongelukkig moment voor verrassingen.

Werkt dit hetzelfde op Azure Local en Azure Stack HCI?

Grotendeels ja. Azure Local nodes zijn domain-joined en volgen dezelfde w32time-hiërarchie. Wel: voor Arc-managed Azure Local clusters zit er een aanvullende laag, omdat de Arc-agent ook zijn eigen tijd-validatie doet richting Azure. De drempel daar is strikter (vijf minuten max), dus drift wordt eerder zichtbaar.

Wat als ik geen externe NTP-bron mag gebruiken vanwege security-policy?

Dan is een hardware-stratum-1-bron in het managementnetwerk de oplossing. Apparaten als Meinberg, Microsemi of een GPS-disciplined Linux-server kunnen als interne NTP-bron dienen. De PDC emulator wijst dan naar die hardware in plaats van naar time.windows.com. Voor strict air-gapped omgevingen is dit de standaard-aanpak.

Hoeveel klok-skew is acceptabel tussen cluster-nodes?

Onder 1 seconde in steady state. Tot 5 seconden tijdens een patch-ronde of node-reboot. Boven 30 seconden is een dringend remediation-onderwerp. Boven 5 minuten is het al een actief incident, want Kerberos zal nieuwe authenticatie weigeren.

Wat is /reliable:yes en wanneer gebruik je het?

/reliable:yes markeert een tijd-bron als "betrouwbaar", wat andere w32time-clients toestaat om met hem te syncen. Het is een verplichte instelling op de PDC emulator (zonder is hij geen geldige tijd-bron voor de rest van het domein). Op een DC die geen PDC is, hoort /reliable:no of geen instelling.

Related articlesGerelateerde artikelen