I once consulted for a medical-records company that was rolling out thin clients to nearly 50 offices around the United States. The goal was to build a large Citrix MetaFrame farm over WAN links to the main datacenter, which was located outside Boston, providing a Windows desktop for every user without dealing with hardware problems at each site.

I had designed the MetaFrame farm myself, and the implementation was built alongside the existing infrastructure. The client purchased 400 Wyse terminals based on EmbeddedNT, we created an image that contained all the necessary applications and tools, and the process of converting each site began.

The first dozen sites converted quickly and easily. Outside the Eastern time zone, however, problems lurked. MetaFrame allows you to set the clock on any given session to either the time local to the server or the time local to the client. In this fashion, servers located in one time zone can host a session from users in another time zone, as long as the client time is correct. But when we converted the first few offices in the Central time zone, users began noticing that their session time was off by one hour. That meant every record they entered or modified was time-stamped incorrectly. Given that these were medical records, this presented a very significant problem. We halted the rollout.

As it turned out, the time sync application in the client couldn’t set a time zone dynamically based on any external data. What’s more, the DHCP client in EmbeddedNT doesn’t pay attention to the time-offset option that controls time zone information, so that wasn’t an option. Developing and maintaining separate client images for each time zone entailed far too much overhead to be practical.

Time was of the essence in more ways than one. Luckily, after a little thought and even less coding, I had a solution.

Using ActiveState ActivePerl for Windows, I wrote a CGI containing a list of subnets categorized by time zone. If a WAN subnet of 10.8.0.0/16 was assigned to a site in the Central time zone, for example, the script knew that. All the script would do when called via HTTP was determine the correct time zone of the requesting IP address and return a single corresponding digit.

All thin clients could receive image updates via Wyse’s Rapport tool, so we made an image with a few changes. First, we placed a Win32 version of curl, a command-line HTTP client, in the Windows system directory. We also added a small tool called settz.exe, which sets the time zone of the system based on a single-digit argument that would be supplied by the CGI. A single-line entry in the autoexec.bat file used both tools to retrieve and set the correct time zone every time the client booted. As a result, clients could be shipped from site-to-site without worrying about image versions or other compatibility issues.

Shortly after we restarted the thin-client rollout, another problem arose. Some of the users would be working from home, using the thin clients and an SSL connection to access the MetaFrame farm. Luckily, the groundwork was already laid for the solution. With a few more tweaks (and a subscription to MaxMind’s IP Geolocation database), the same script could correctly determine a client’s time zone whether it was inside or outside the network.

These problems weren’t anything that could have reasonably been predicted during the planning stages, but as a little luck and some clever coding would have it, the solution was fast, cheap, and reliable.