In order to test your time sync, you must first stop the w32time service. This is most easily done from the Command Prompt by issuing ‘net stop w32time’. Once that is done, you can run “w32tm –once”. This will cause the time service to query your Internet time standard and set the time. However, when running behind ISA, it will likely fail. You will see messages in your Event Log stating “The NTP server didn’t respond”. In fact, you may see a lot of these messages! For awhile I figured I’d just configured it to sync with either a bad or unfriendly time source. So I tried configuring it for different servers. No luck. I did find, however, that when I stopped all the ISA services on my server, I could connect and update the time fine! You can test this by setting the system clock ahead or behind by say 5 minutes. I tried to make it an easy time difference so I could easily reset it to the right time when my test failed. Then run “w32tm –once”. You will see it go through a script as it attempts to talk with the time source. If it works, the system time will be reset to the correct time at the end of the process. If not, it won’t. The script will also have a message in it to the effect that the time source failed to produce a valid time stamp.

Since my time sync did not work when I was running ISA server, and did when I stopped ISA, I figured, clever fellow that I am, that ISA must be where the problem was. Having just resolved the problem of updating Windows XP through ISA as discussed in last month’s column, I figured that might be the salvation. I also knew that the time service uses UPD port 123. So, I created a packet filter called ‘NTP’ (network time protocol) for UPD, port 123, with a “direction” of “Send receive”. I configured it for all local ports and port 123 on the remote host. Guess what! This didn’t do it. 

I then figured that perhaps I needed to set up a Protocol Rule in ISA similar to the one I set up to make Windows XP Update work. So I create one I called “SNTP” (Simple Network Time Protocol). I configured it to allow the selected protocol of NTP, always, and apply it to the specific client address set that included the server. This had worked with the Windows XP Update. However, it didn’t work with SNTP. Eventually I tried specifying “Any request” and it worked! I then set the system time back 5 minutes and ran w32tm — once. The time was corrected. Now the little annoying error messages in Event Log have gone and my time is set correctly. I immediately went to all my customers’ Windows 2000 servers  using Terminal Services over the Internet and configured them the same way. They all worked! 

Connecting to SBS over VPN
 Recently one of my SBS 2000 clients opened a branch office and wanted to connect the workstations there to the SBS server at the main office using VPN. This actually worked rather well. The clients are able to log on to the domain and get their e-mail, files, etc. However, there is one small problem we encountered. It has to do with the effective Internet connection speed experienced by the remote user. When running SBS and the remote is a client, all Internet access from the client actually goes through the server, just like it would if you were on the local network. This works fine except when the server is running on an ADSL connection to the Internet. ADSL typically allows for up to about 1.5 mbps (million bits per second) Download speed (usually less than 1 mbps is what I see). This gives you a really nice fast response when browsing the Internet. However, when the server sends to the Internet, its Upload speed is significantly lower, usually around 128 kbps. Since the user’s Internet requests are going to the server and the response to the user is coming from the server, it is coming at the lower speed. Therefore the user only experiences about 100 kbps instead of 1mbps. The workaround is to disconnect from the VPN connection when faster Internet speed is essential. Otherwise, 100kpbs sure is better than a modem.