I posted a few weeks ago about bringing a WSUS machine down to Haiti as a sort of proxy – unfortunately, this project turned out to be a bust.
Conceptually, it worked. Machines were getting updates, and everything was great… until it started blowing out the CMOS settings and bluescreening a couple times a day. I suspect it’s probably power-related, but in any case, it was far from stable enough to leave unattended.
When I leave for my trip to Haiti in a few weeks, one of the things I’ll be doing is bringing multiple computers up to current patches. There are a few ways to do that:
One is to bring some sort of removable media (optical or flash stick) down and apply them manually. The problem with this is that once I leave, the machines stay in their current state until the next geek can come down and apply the next batch of patches. Downloading patches for multiple machines over developing-world internet connections can easily run into daily bandwidth caps, and Windows Update doesn’t cache very well through a normal proxy server such as Squid.
Another is to use Windows Server Update Services (WSUS). I initially considered setting up a Windows Server VM on my laptop, syncing up the updates stateside and temporarily configuring the machines down there to pull from my impromptu update server. Then I got the idea that a lightweight appliance-type server that lived down there permanently would be a useful solution that would download the patches once and distribute them over the LAN. Since we’re planning on using Microsoft Security Essentials for anti-malware, this solves the problem of definition updates. Daily patch sync would happen in the wee hours of the morning when the oversubscribed connections in Haiti are generally pretty clear.
I rummaged around the office and found a Dell FX160 thin client that we got as a demo unit from Dell (I have a number of blog posts on the topic of this device). It has been gathering dust for some time as it’s hobbled with a 1GB SATA flash disk and limited RAM. After checking on hardware requirements for both Windows Server and WSUS, I went out and picked up a 120GB SSD and a pair of 2GB RAM sticks and put them in. The choice of an SSD wasn’t so much for performance reasons (although it can’t hurt), but for the machine to be entirely solid-state. It’s going to live in a fairly harsh environment where mechanical failures are likely.
Once I got the hardware put together, I hooked up a USB optical drive and loaded Windows Server 2003 R2, and then installed WSUS and performed an update sync. The whole process went mostly smoothly.
Here are a few of the gotchas in installing Windows 2003 on an FX160 thin client, a job it was NEVER meant to do:
The SSD I used for this is an OCZ Agility 3, 120GB. Disk performance on large writes is almost 100MB/sec, which is about twice as fast as my 7200RPM spindle drive in my laptop. Windows performs very well with 4GB, a SSD, and a 1.6GHz Atom processor.
The next step was to configure the clients to update from the server for testing. I still have one of the Asus netbooks that we deployed to Haiti in a previous trip. This is where I discovered that Windows Home and Windows Starter don’t include the policy editor (gpedit.msc) that I’m used to finding on Pro/Enterprise/Ultimate versions of windows. This is understandable, your average home user doesn’t (and shouldn’t) normally jack with system policy. Fortunately, all the policy editor does is manipulate registry keys, and the process of configuring Windows Update via the registry is well documented. This actually simplifies things, since all I have to do is create a .reg file that I can import on all the target machines.
Next post: Installing Squid. Not content to use this box for mere update caching, we’re gonna have it be our web proxy as well.
Yesterday, for reasons unknown, our entire network dragged to a crawl around midday. Those reasons became quite clear this morning when word hit the blogosphere (here, here, and here, among others) that Microsoft had pulled another fast one on us network admins and rammed a patch down our throats, bypassing the normal WSUS approval process. Apparently, the Windows Installer update pushed out a few weeks ago makes this possible
The patch in question was a major version relese to Windows Desktop Search, which is categorized in WSUS as an “Update”. Our WSUS machine is configured to auto-approve critical patches, but not routine updates. Imagine my surprise when I find that it is already in the “approved” category and has installed itself on all of our machines. Between the time it synced and the time it pushed out to the machines, I hadn’t gone near the WSUS machine to approve it…
And Microsoft’s PR flacks are telling us that those of us who did get the patch had already approved it. Nice try, Microsoft. I and hundreds of other admins have a far different story to tell.
The least they could do is warn us this was coming, so that we could test it. Instead, we had 200 machines sitting there, reindexing themselves while people were trying to get things done.
I like WSUS, generally, it makes my job a lot easier when it comes to managing the patches that Microsoft constantly needs to issue – but it really ticks me off when they abuse the system for their own self-serving goals.
I’d be willing to bet a donut that this somehow breaks Google Desktop. Micrsoft has a long track record of dirty tricks when they feel squeezed by the competition… anyone remember Win32 v1.32? the patch from 1.31 did very little, except for one key thing… it completely broke OS/2 compatibility with 32-bit Windows applications. Any 32-bit app written with 1.32 or later was unable to function with the 1.31 libraries that you could install on OS/2.