An accurate time is crucial for a smooth working IT environment. For example authentication via Kerberos isn’t possible if the time isn’t in sync (if the difference is too high) or it isn’t possible to compare log files to identify a problem if the time is different on systems. There are some points you have to concern about when running AD DCs in a virtual Environment. You have to decide which is your organization-wide time source, how to handle the possibilities you’ve get from the virtualization provider and how to sync the time. First I’ll start with some basics: Time synchronization in a network is done by NTP (Network Time Protocol) and uses UDP 123. You can use a public NTP-Server as time source for your internal or even attach a Radio Clock to a server. NTP is easier to implement because you need just an internet access and no additional hard ÔÇô or software. But you have to deal with the network delay and you should choose an NTP-Source you can really trust. A dedicated radio clock attached to a host is the best and ‘safest’ solution you can get, but you need special hardware (the radio clock). In our example we’ll use external NTP-Servers. First because it’s easier and second because I never used an direct attached radio clock 😉 You’ll find a near NTP-Server for your location at http://support.ntp.org/bin/view/Servers/WebHome It’s important that the time source is near your location so the network delay is as less as possible.
Stratum ÔÇô Levels: There exist 4 Stratum-Levels which define the preciseness of your time source:
- Stratum 0: An atomic or radio clock which is direct attached to a host
- Stratum 1: A host which directly synchronize with a Stratum 0 source (some public NTP-Servers or your own host if you’re using a radio clock)
- Stratum 2: The 2nd level of a sync hierarchy. Stratum 2 servers gets their time from Stratum 1
- Stratum 3: Not too hard to guess I think 😉 Stratum 3 servers get their time from Stratum 2 sources.
NTP in an Active Directory Environment: Every domain controller in your AD is also an NTP-Server. By default every DC get it’s time from the PDC-Emulator. If you don’t know which DC is your PDC-Emulator you should study your AD more 😉 Or alternatively you can execute “netdom query fsmo” on a command prompt.
In the above screenshot we see that W2K8SRV1.bluesky.local is my PDC (and holds also the other FSMO-Roles, which is normal in an AD with just one DC 😉 ) So, now get familiar with w32tm.exe, your main config tool in Windows for NTP. So, first of all let’s check what your current time source is by running “w32tm /monitor”
What does this information mean?
- Line 1 tells use the time source for this host is W2K8SRV1, that this host is the PDC of the domain and it’s IP-Address (an IPv6 Address in my lab).
- Line 2: The Network-Delay we have to this host measured by ICMP. We have currently no delay because our time source is the local host.
- Line 3: The time offset between the local host and the NTP-Server.
-
Line 4: Here will be the source of our time server displayed. Because we haven’t yet configured a NTP-Server the source is LOCL. If you’re unsure what a former admin has configured or basically want to start from scratch you can set your time settings to default values by executing:
sc stop w32time & w32tm /unregister & w32tm /register & sc start w32time
This command stops the Windows Time Service (w32time), removes it as service, reinstalls the service and then starts it again.
Now you can configure your external NTP-Sources with the following command:
Explanation of the parameters:
- /config => we’are configure something /update => It’s an update, so the time services is notified about that
- /manualpeerlist => we provide a manual list of NTP-Servers to sync from
- /syncfromflags:manual => we explicitly want to sync from the manual peer list
- /reliable:yes => this is a ‘good’, a reliable time source for our domain controllers. Other DC’s will sync with this time source.
Now you can check if the external servers are used correctly by executing w32tm /query /peers
As shown in the output I’ve specified two peers. One Stratum 1 server (the first one) and a Stratum 2 server. As we will see in the following screenshot Windows will always try to sync the most accurate time source, in our case the NTP-Server with the .net ÔÇô TLD.
To control that your config works you can execute “w32tm /monitor“. This command will check the time offset of all your Domain Controllers with the PDC.
OK, but what is now the difference between a physical or a virtual Domain Controller?
From the normal operation perspective => Nothing 😉 But there is one huge difference with the time sync.
In every virtualization software (at least all I know like VMWare, HyperV, Citrix Xen, Xen Source, KVM, OpenVZ, Virtuozzo) the Guests are getting their time by default from the Host.
So if the time on the Host isn’t accurate, all the guests are running with a wrong time. Furthermore normally the time sync from the virtualization environment takes precedence over a (maybe) configured NTP Daemon inside the Guest.
So what happens when you run your PDC as a VM-Guest and syncing all your VM-Hosts with one of your Domain Controllers?
You’ve created a loop and you’ll never get the right time. Even when you configured an external time source the VM-Host time will overwrite any change with it’s own time. So one resolution for that would be to run an physical domain controller too (which would be a good decision) and move the PDC-Emulator FSMO-Role to this DC. If you have no possibility to run a physical DC (Damn IT Budgets L ) you have still another option.
Simply disable the time sync between the Guest and the Host!
On Hyper-V just edit the Settings the of the desired VM and within the option “Integration Services” disable “Time synchronization”
With VirtualInfrastructure from VMWare you have also to edit the properties for the Guest. Within the “Options“-Tab select “VMware Tools” and uncheck “Synchronize guest time with host”
After these changes the NTP Daemon inside the Guest will be responsible again for the time sync. Ff everything is configured correctly you should have an accurate time on all AD-Computers.
Hope this post was a little helpful. Please let me know if anything is missing or not clearly described.
Cheers
_Hans
Leave a Reply