NTP tips

Checking your time against a reference NTP server

w32tm /stripchart /computer:pool.ntp.org /samples:5 /dataonly

Checking time across multiple systems using ‘psexec’ (from Sysinternals.com)

psexec \\computer1,computer2,computer2 w32tm /stripchart /computer:pool.ntp.org /samples:5 /dataonly

Setting the time services to use NTP and server NTP requests (for all AD servers).

Step 1:

 W32tm /config /syncfromflags:manual /manualpeerlist:pool.ntp.org /reliable:yes /update
W32tm /resync

Step 2:

 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config]
“AnnounceFlags”=dword:00000005
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters]
“Type”=”NTP”
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer]
“Enabled”=dword:00000001

If a guest VM, it is best NOT to sync with the Hyper-V host server …

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t reg_dword /d 0

Step 3:

Net stop w32time
Net start w32time

Checking time accross all DCs:
w32tm /monitor

Checking time configuration on a DC:

w32tm /query /configuration

Core versus Full – Initial install quick stats

Created two VM’s with identical resources. On the first VM, Windows 2012 R2 Core Installation was chosen. On the second VM, Windows 2012 R2 Server with a GUI (Full) was chosen. After installation of both, I also ran updates on both until no more Windows updates were found.

Here are the quick stats:

    Core has more free disk space: 32,077,897,728 bytes to 26,787,229,696 bytes

Core uses less memory: 335 MB to 438 MB

    Core required less updates: 117 fixes to 153 fixes

    Full 2012 R2 initial installCore 2012 R2 initial install

    No surprises at this point. Core has no GUI, so it uses a sliver less memory, about 5GB less drive space, and there is less surface area to patch. Observed (not measured) that Server Core installed faster and completed patching faster too. But we’re only at step one in the life of a new server and saving a few minutes during an the install is probably not the reason Server Core is recommended.

    The fewer number of patches, though, does already start to show how Server Core is going to benefit in patch maintenance over the server lifecycle.

    So, do you reboot a server to apply some critical IE security fix? Hey, admins shouldn’t be browsing the web from servers anyway. But then why is it that IESC is so often found disabled on the servers? Besides that missing patch is going to keep showing up on vulnerability scans, and we do have to rescan until clean, right? Ever have these debates? By incurring less GUI related patches, it seems to me that Server Core also reduces the number of these time wasting debates over the administrator lifecycle.

    So where to go from here? I’m thinking SQL Server installation next then using HammerDB to benchmark a core SQL versus a full SQL. Another scenario I’d also like to try is perhaps creating an IIS farm behind a load balancer using least queue depth to see which server handles more traffic as another benchmark. Hmm, could create some How-to posts with either of those too … stay tuned …