Monday, January 24, 2011

32 bit DSN on 64 bit Windows Server


Synchronize the Time Server for the Domain Controller with an External Source

Original article: Synchronize the Time Server for the Domain Controller with an External Source
Updated: March 28, 2003

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

By default, the primary domain controller (PDC) emulator gets its time from the BIOS clock. In a network with a single DC, that DC automatically has this role.

The PDC emulator establishes the time and date settings for all computers within its domain. If the time is not accurately set in the PDC emulator’s BIOS, all computers in the domain have incorrect time and date settings.

To prevent this, you can synchronize the domain controller with an external time source such as the time servers provided by the National Institute of Standards and Technology (NIST). For a list of the names and IP addresses of NIST time servers for your area, see the National Institute of Standards and Technology (NIST) Internet Time Servers link on the Web Resources page at


* Be aware that the Network Time Protocol (NTP) is unauthenticated, and unencrypted, and it is possible for an intruder to spoof the time root source, causing the wrong time to be set on the DC. You can avoid this possibility by using IPSec to secure the transmission, by accessing the time root source by its IP address rather than its fully qualified domain name, or by purchasing an NTP-capable hardware clock for your DC time synchronization.

To synchronize the domain controller with an external time source

1. Click Start, and then click Command Prompt.

2. In the Command Prompt window, type the following line, where peers is a comma-separated list of IP addresses of the appropriate time sources, and press ENTER:
w32tm /config /manualpeerlist:peers /syncfromflags:MANUAL
The time sources you choose depend on your time zone. For example, if your domain controller is located in the Pacific Time zone, this line might read:
w32tm /config /manualpeerlist: /syncfromflags:MANUAL
In this example, the IP address of the timeserver is used instead of the fully qualified domain name for security purposes.

3. Press ENTER. You should get a message that the command completed successfully.

4. Type w32tm /config /update

5. Press ENTER. You should get a message that the command completed successfully.

W32time uses a variable poll interval based on the quality of timesync with the server. On DCs, this interval defaults to between 64 and 1024 seconds.

6. To immediately synchronize with the external time server, type w32tm /resync and press ENTER. You should get a message that the command completed successfully.

7. Type Exit and press ENTER.

Here is quick batch for Czech NTP servers provided by CESNET.
 w32tm /config /manualpeerlist:"" /syncfromflags:MANUAL  
 w32tm /config /update  
 w32tm /resync  

Virtual Machine - Disabling Time Synchronization 

If you are running your Active Directory domain controllers (more specifically PDC emulator) as a virtual machine in VMware vSphere another recommendation is to completely disable VM time synchronization with ESXi host. It is explained in VMware KB 1189 - Disabling Time Synchronization (1189). This will help you to mitigate the problem of Active Directory time issues after several VM operations (vMotion, snapshot, etc.) in case of ESXi host bad time. AD tolerance for time skew is 15 minutes max, at which point things start to fall over. For example during the vMotion operation, the PDC-E's time is adjusted to match the host's time (even though the "synchronize guest time with host" option is not checked on the PDC-E VM). This is a default behavior in ESX, and it should be changed as instructed in VMware KB 1189.

In a nutshell following VM configuration options has to be set to 0.

 tools.syncTime = "0"  
 time.synchronize.continue = "0"  
 time.synchronize.restore = "0"  
 time.synchronize.resume.disk = "0"  
 time.synchronize.shrink = "0" = "0" = "0" = "0"   
Note: The value of setting can be 0, false, FALSE, False. All these value have the same effect - not synchronize time after particular VM operation.

You can use following PowerCLI script to set these VM options to particular VMs.

 $o = Add-PSSnapin VMware.VimAutomation.Core  
 $o = Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false  
 # Connect to vCenter  
 Write-Host "Connecting to vCenter ..."  
 $VC = Read-Host "Enter one vCentre Server or multiple vCenter servers delimted by comma."  
 Write-Host "Enter vCenter credentials ..."  
 $CRED = Get-Credential  
 Connect-VIServer -Server $VC -Credential $CRED -ErrorAction Stop | Out-Null  
 # Array of virtual machine names   
 #$vm_names = "W2K8R2-test1","W2K8R2-test2"  
 $vm_names = "W2K8R2-test"  
 foreach ($vm_name in $vm_names) {  
  Write-Host "VM: [$vm_name]"  
  try {  
   $vm = get-vm -Name $vm_name -ErrorAction Stop  
   New-AdvancedSetting -Entity $vm -Name tools.syncTime -Value 0 -Confirm:$false -Force:$true  
   New-AdvancedSetting -Entity $vm -Name time.synchronize.continue -Value 0 -Confirm:$false -Force:$true  
   New-AdvancedSetting -Entity $vm -Name time.synchronize.restore -Value 0 -Confirm:$false -Force:$true  
   New-AdvancedSetting -Entity $vm -Name time.synchronize.resume.disk -Value 0 -Confirm:$false -Force:$true  
   New-AdvancedSetting -Entity $vm -Name time.synchronize.shrink -Value 0 -Confirm:$false -Force:$true  
   New-AdvancedSetting -Entity $vm -Name -Value 0 -Confirm:$false -Force:$true  
   New-AdvancedSetting -Entity $vm -Name -Value 0 -Confirm:$false -Force:$true  
   New-AdvancedSetting -Entity $vm -Name -Value 0 -Confirm:$false -Force:$true  
  } catch {  
   Write-Warning -Message "VM doesn't exist";  
 Disconnect-VIserver -Server $VC -Force -Confirm:$false  

Current version of PowerCLI script is available on GitHub here.

Thursday, January 06, 2011

Comparison of Cisco UCS Service profiles vs HP BladeSystem to manage user interface settings


This post is based on article at

Here’s a simple guide to setting up a VPN server on FreeBSD so that Windows clients can connect using their built-in VPN clients…

First, make sure your ports collection is up-to-date, then build poptop in /usr/ports/net/poptop:

# cd /usr/ports/net/poptop/
# make
# make install

Next we need to create a config file for poptop… create the file /usr/local/etc/pptpd.conf as follows:

pidfile /var/run/

Next we need to create a PPP configuration file called /etc/ppp/ppp.conf (overwrite the existing file) as follows (edit the IPs to suit your network requirements):

set timeout 0
set log phase chat connect lcp ipcp command
set device localhost:pptp
set dial
set login
# Server (local) IP address, Range for Clients, and Netmask
set ifaddr
set server /tmp/vpn-in-%d “” 0177

set timeout 0
set log phase lcp ipcp command
allow mode direct

load loop
disable pap
disable passwdauth
disable ipv6cp
accept dns
enable MSChapV2
enable mppe
disable deflate pred1
deny deflate pred1
set device !/etc/ppp/secure

Every line above except those ending with a colon(:) should be indented or ppp.conf will not work.

Next we need to create a file called /etc/ppp/secure with the following contents:

exec /usr/sbin/ppp -direct loop-in

And set it to be executable with chmod 0755 /etc/ppp/secure – this script will be run automatically during the VPN setup process.

Now we need to add a login for the VPN (you can have multiple username/passwords in this file) called /etc/ppp/ppp.secret like so:

user1 pass1
user2 pass2
user3 pass3

And finally set the VPN server to start on bootup automatically by adding the following into /etc/rc.conf:


Now startup the VPN server by running:

/usr/local/etc/rc.d/pptpd start

Your VPN server is now ready on your FreeBSD server and you’re ready to configure your Windows clients to connect to it.