Mar 24 2009
The Build Disc – Part 3a (Windows Updates)
In previous articles, I looked at the overall concept behind the build disc, it’s aims and goals. Then, in part 2, it was Windows service packs. Now, in this installment it’s time to look at Windows Updates.
Why does it matter? As previously discussed, a fresh install of Windows might need hundreds of megabytes of downloads before it’s fully updated. Also, unless you take precautions, the time it takes you to download and install those updates might be all the time needed for your computer to be compromised.
For me, running a busy workshop, the final consideration is that downloading updates for every repair on every computer would mean a significant increase in our Internet needs.
The choices?
Transparent Proxy/Cache: It’s possible to use a cache engine (e.g. squid, ISA, etc) as a transparent proxy. Every download from the Internet gets cached the first time and then just loaded from that cache each subsequent time it’s needed. For me, the down sides to this are that Microsoft (and others) work on preventing caching of their updates. There’s reasons for this and I don’t disagree with all of them. However, it does mean that you’ve got to take additional steps to make caching like this work effectively. Because it’s largely transparent, you don’t really know if it’s working properly without checking logs regularly. Lastly, it means running another computer on my network (or beefing up a server already on my network) to fulfil this task. I wasn’t happy with this so, for me, this isn’t an ideal solution.
Windows Software Update Service (WSUS): This is the Microsoft solution. It works pretty well for Microsoft software, but, for this solution to work you have to tell computers to talk to your WSUS server instead of going direct to Microsoft. This is a relatively simple process (can be done just with a registry hack) but then you also have to remember to remove that registry hack of a customer’s computer may not be able to obtain updates in future. Again, not an ideal solution in a busy workshop.
Offline Updates: A process where all relevant updates are downloaded to a local computer together with some supporting software. You run that supporting software on a computer that needs updates, it figures out which updates are relevant and installs them. As far as I know, there are two main choices for this type of software at the moment. The first is AutoPatcher; this used to be my personal choice until Microsoft sent them a cease and desist on the process they were using. They’re still around but the new approach they’re implementing is taking a while to become stable. My need was more immediate so, while I’m keeping an eye on what they’re up to I needed a more immediate solution.
The second is Heise Offline Update; it works as advertised and my only real complaint at the moment is that updates aren’t all that frequenty. In reality, this is a minor issue because as long as it can get you within a few months of current you can then download the rest without a huge impact on your Internet access.
In the next installment, I’ll look at how I’ve actually put Heise Offline Update to use in my workshop.
