I noticed tonight that my domain controller’s clock had creeped ahead by about 15 minutes.  Inconsistent time, especially time that differs between servers, clients, and a domain controller can throw applications like Exchange, who depend upon Active Directory for information, for a loop. 

In Windows 2008 R2 (and Windows 7), the /setsntp and /querysntp switches of NET TIME are deprecated.  W32TM.exe provides similar functionality that NET TIME provided when it came to configuring domain controllers as a primary time source.

W32TM is not terribly intuitive, but I did get enough information to get my Windows 2008 R2 domain controller updated and again updating the time of the resources in my domain.

If you are wondering how to set this up – here are a few steps to help you out.

1. Use W32TM to configure the peer list and then update the configuration.  In this case, I am using a “set” of public servers to get my time information.  From a command prompt, type (on a single line):

w32tm /config /manualpeerlist:”server 0.north-america.pool.ntp.org”,0×8 /syncfromflags:MANUAL /reliable:yes /update

2. I’m not entirely sure that this is required, but we’ll restart the Windows Time Service for good measure.  From a command prompt, type:

net stop w32time

then restart the service:

net start w32time

3. Then we’ll initiate the time resynchronization and rediscovery of the peer list time sources that we specified in Step #1.  From a command prompt, type:

w32tm /resync /rediscover

There.  You should be all set.  If you want to update the time on a client (or a server) ahead of the regular interval at which is checks with a domain controller for the correct time, you can go to a command prompt and type:

net time /domain<domain name> /set /yes 

This will force an update of the time on the current system from your local domain.

This week I was in Las Vegas for the Exchange Connections Conference.  Traveling usually isn’t too much of a hindrance anymore of the availability of a wireless Internet connection just about everywhere you go.  The only downfall is that most public places, particularly hotels, tend to provide Internet access but block non-HTTP traffic in a lot of cases.  For VPN users, this can be a problem and prevent you from accessing the resources that would normal require you to be connected directly to your corporate network.

With Windows 2008, the Routing and Remote Access service can now be used as a means for providing access via VPN to corporate resources.  Since SSL is a common protocol and just as common as it’s HTTP counterpart, it is usually accessible.

I spent a couple of hours tonight working on creating a SSL VPN solution for my network.  I did get it up and running and wanted to provide some of the resources that helped make this process a lot easier. 

The IT Consulting Blog had a good amount of information that got me through some of the pitfalls.

This IT Technology Blog helped a lot when it came to troubleshooting.

I was able to get connected and everything is working great – but – one thing I did have problems with was when the SSTP Client in Windows 7 connects to the VPN Server, it has to make contact with the Certificate Revocation List to check and make sure that the certificate used for the VPN communication hasn’t been revoked.  I am using ISA which may or may not add a layer of complexity, but I did have to disable the CRL check.  At first, I thought the registry edit that disabled that was made on the VPN server, but in fact, it is actually made on the client machine.  You probably don’t want to disable CRL in a production environment – so just keep that in mind.

Microsoft has a section in this article that talks about the registry key required to disable or enable the CRL check.

Finally, Tom Shinder, one of the great ISA experts out there wrote a series on implementing a Windows 2008 VPN behind ISA infrastructure.  This walks you through the entire process from start to finish.  You can find that three part series here.