Updating Windows Embedded Standard systems using WSUS
**Updated 3/26/09 with preface
[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
Embedded devices quite often have special footprint requirements that have direct effects on the way these devices can be managed. Small footprint, for example, may mean fewer management capabilities available on the device. This leads to different management scenarios.
Device Update Agent
The most footprint-aware technology currently available is Device Update Agent (DUA). DUA is just a plain windows service that runs as a client in the Standard runtime image. It regularly polls an update location on a web server or folder share to get the newest patches or updates. This works great, but has some drawbacks if you want to deploy more complex updates, as creating the DUA script files requires quite a bit of development and test effort .
There are already a lot of blog posts and articles on DUA to be recommended as a great resource on this topic. This is why I will not go into depth with DUA and focus on WSUS in this post.
Windows Server Update Services - Architecture
A few years ago Microsoft faced the problem that when they rolled out security or functionality patches via Windows Update, quite a few administrators complained that these updates broke business-relevant applications in their company. This was quite a dilemma, because no one is able to test a new patch against all possible applications out in field. Microsoft’s solution was SUS (System Update Services) or, as it later was renamed, WSUS. WSUS works as a proxy server between the original Microsoft Windows Update back-end and client computers in a company.
The WSUS server syncs with Windows Update to get all available updates, which are then stored on the WSUS server and not immediately pushed onto the company’s computers. The updates can be tested by an administrator against the company-specific configurations to avoid problems on production machines.
If there are problems, the IT operations team is able to roll out patches selectively. This means they are able to target just the machines that do not have problems with the update. The machines that have a problem can be staged until either a workaround or fix for the application having problems with the patch can be found. But during this time they are still operational.
The WSUS approach is implemented using a special Windows Update client service running on the computers , which connects via the intranet to an available WSUS server to get instructions and binaries from. All information about, for example, which patches are rolled out to which machines, is stored by the WSUS server in a SQL Server database and is managed via either a web based UI (WSUS 2.0) or an MMC application (WSUS 3.0).
A WSUS server is able to handle about 20,000 clients on a dedicated network and, additionally, those servers can be part of a cascading architecture, for example, when replicating fixes across different subs or locations.
This provides the capability of scaling up to millions of devices.
Yes, but that is not embedded
Right, I have been describing an enterprise scenario, but this scenario is perfectly valid for Windows Embedded Standard devices participating in a company’s infrastructure as well.
There are already a lot of thin clients, ATM machines, cash registers and industrial automation controllers working in WSUS environments, leveraging the benefits of a common change management infrastructure for embedded, desktop and server systems.
Of course, there are drawbacks if the infrastructure is not in place yet, because there are setup and maintenance costs for the required back-end. Additionally, there are dependencies on other enterprise-specific services, such as Active Directory, that need to be satisfied.
But even then, depending on the number of clients as well as the overall project requirements, it may make sense to set WSUS up or, even better, re-use it for embedded devices if it is already there.
Preparing the Windows Embedded Standard Image
To make an OS image “WSUS ready” the Windows Update Agent component needs to be included. Looking at the newest release you should choose version 3.0, if the back-end is not running an earlier version of the WSUS service.
The Windows Update Agent requires a number of components to support the infrastructure- it pulls in about 140 MB of dependencies, including Internet Explorer, Terminal Services, BITS, Direct Draw and a lot of Win32 APIs.
It is therefore pretty obvious that WSUS is not a solution for small footprint devices but rather for devices that already offer high functionality. In the latter case, the addition of the Windows Update Agent component has a much lower impact on the overall image size, because most probably a lot of the required components already are in the high functional image.
In the component itself, there is not much to configure. Only the behavior for notifications on updates can be set.
And that is it. All the client needs is a correctly setup WSUS server on the intranet and it will connect automatically.
Custom Patches
Even in version 3.0, WSUS is designed to roll out only Microsoft updates. This must be stated, although it has got a new feature called “Local Publishing” with which it is theoretically possible to deploy one’s custom patches as well. But in reality this is very complex and should only be done by people with very good development and system management skills.
Local Publishing is also not supported in the WSUS UI and therefore, at least in my eyes, cannot to be recommended as a good and effective way to manage devices.
Having no practical ability to roll out custom patches is still the largest drawback of using the WSUS infrastructure. It requires device operators to have another change management system available for these applications or to roll a custom solution.
Deploying only required patches
How do you know that the new patch is required on your embedded device? This was a topic I discussed in my last post too.
Well, there are different approaches. You could have a look at the accompanying documentation (rtf file) to see if there are subsystems involved that can be found in your custom Standard image. Or, and sometimes more pragmatic, you can extract the Windows Update package to look at the included files and registry keys.
This can be done using the /X command line switch e.g.
KB1223xxxx_update.exe /X
If there are binaries and registry keys in the patch that exist in your custom image, too, the patch might well be required.
Alexander Wechsler
Wechsler Consulting
**Updated 12/29/08 (added graphics)