How to configure an NTP server on Microsoft Server 2008 R2

Time is essentially very important to any IT infrastructure but in particular for a Microsoft domain environment. If a domain member server has drifted more than 5 minutes off a domain controller then it wont be able to authenticate domain users.

Usually a domain controller, or more specifically the PDC holder will synchronize its clock by default through an internet connection if it has one. In other environments – like the ones I am working in at the moment – does not provide the domain controllers with an internet connection.

In this article I will go through the steps I have taken to properly configure an NTP server as time source for a vSphere environment consisting of a Microsoft domain.

• How to configure an NTP server on Microsoft Server 2008 R2
• How to configure the time source on an ESXi host

Commands to be used:

netdom /query fsmo

W32tm /query /status

W32tm /config /syncfromflags:manual /manualpeerlist:”0.dk.pool.ntp.org,1.dk.pool.ntp.org,2.dk.pool.ntp.org”

W32tm /config /reliable:yes

W32tm /config /syncfromflags:manual /manualpeerlist:192.168.xxx.xxx (NTP server)

W32tm /query /configuration

W32tm /resync

Type netdom /query fsmo in an elevated command prompt to locate the PDC holder if you do not know which DC holds it. Login to the server and execute w32tm /query /status

The default NTP source for this DC is the CMOS clock because it does not have an internet connection. If a server cannot sync its clock with the default setting or a configured time source then it will switch to the CMOS clock.

Click the picture below to enlarge;

Excellent link for verifying NTP on an ESXi host: http://www.vmwarebits.com/Verifying-NTP-onESXi

The SQL Transaction Log

A Simple recovery model will allow the transaction log to truncate previous transactions once it has reached a checkpoint. This means it will free up space for another run. One could say that a man with muddy shoes walk backwards and mobs the floor at the same time to clean up after himself. A Simple recovery model can still leave a transaction log full – perhaps if the SQL is being hammered upon and a transaction never ends.

Shrinking a log is generally not a good idea because it can cause fragmentation. Shrinking the log means it will ’format’ the space up untill where the log is in the process. So depending on where the transaction log is in the process it might not free up much space when doing a shrink, and the log has to ask Windows for space allocation from scratch.

A Full recovery model does not truncate transactions and needs to do a backup in order to do so. This however allows one to recover from disaster right up to the minute.