Creating SCCM software update packages
**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.]
There is no fundamental difference between creating software deployment packages for a normal Windows XP Professional or a Windows Embedded Standard system. If you are new to this, Microsoft Technet, with its documentation and whitepapers, is a very valuable resource to get things started. However, especially when Embedded Enabling Features (EEF’s) or the limitations of embedded devices come into play, deployment packages for embedded devices need to be created with a slightly different mind set than those for enterprise scenarios.
SCCM packages – the basics
Configuration Manager should simply be regarded as a transport infrastructure. It just provides the means to distribute packages to a targeted set of devices in a reliable, bandwidth optimized, robust and scheduled way.
The installation logic that is required for a software update must not have any dependencies on this infrastructure as it needs be able to work self-sufficiently to deliver reliable and robust patches. This means the deployment package should be able, for example, to check for prerequisites, run the installation absolutely unattended and do a rollback if something goes wrong or if an uninstall is requested. With this in mind, it is pretty evident that creating such a setup routine yourself is a demanding task. The “rescue vessel” in this case is the installation framework built into Windows - Windows Installer. This piece of infrastructure satisfies all local installation requirements requiring reasonable effort to customize and is supported by many 3rd party development tools such as Install Shield or Wise (to name just a few) and provides additional ease of use and features when creating update packages (.msi files).
To create a simple deployment package, copy all the required files/.msi-Packages to a folder directory on the SCCM server or a network share. Then use the “New Package Wizard” to create the package (refer to the SCCM documentation for more details).
Configuration Manager requires four main settings to configure the deployment package correctly:
- The source files in the directory
- A distribution point, to serve as download location to the clients
- A program entry to start the installation process – Important, if this is not present nothing will happen!
- Security settings about the user and access context the package is running
Having done this configuration task, the package is ready for deployment once an advertisement specifying further deployment details and settings has been created.
Getting packages out to devices - advertisements
An advertisement specifies the target group of devices (collection) that will consume a package, as well as the time the package should be deployed. It offers sophisticated scheduling options that help, for example, to target specific maintenance windows in industrial automation scenarios. Advertisements in SCCM are created in a similar way that packages are created, with the help of a “New advertisement” wizard.
To create robust update scenarios, all package content must always be downloaded first and then executed. Never run a package from the server, as there would be a high chance that something goes wrong during the installation. This setting can be configured in the wizard as well, as shown below.
If the package and the advertisement are configured correctly, the software update will be delivered to the embedded device, and run. The OS installation subsystem (Windows Installer) jumps in at this point to install the package locally. The SCCM infrastructure reports the fail or success results back during the next software inventory cycle.
Write filters
As stated before, when deploying to embedded devices there are a few things to keep in mind.
If write filters (EWF or FBWF) are part of the image and the software update needs to be persisted to a protected partition, it is important to turn off the filter before installing the update.
One should always choose a reboot before applying the update, if running EWF in RAM or RAM/Reg overlay or running FBWF, to clean the overlay from data that also could include malware or viruses.
To do this you can leverage the write filter manager console utilities, for example in batch files, or directly target the corresponding write filter API from the setup application. I have described some of the write filter management scenarios in one of my previous posts.
Write filters bring in additional complexity to change management scenarios, because the necessary reboots require extended client side state handling.
Custom shells
If the embedded device is running a custom shell, it is very important to test the setup routines against this setup.
3rd party installation packages are normally tested on XP Professional and might rely on functionality implemented in the explorer shell. This functionality is not available as soon as the embedded device is running a custom shell and therefore these packages quite often fail.
When running into this type of problem, the best way is to repackage the update in a way that errors are prevented. With the help of the package development tools, even 3rd party .msi-files normally can be edited.
Remember space
It is pretty common that an update package requires more than twice the amount of space during the installation as its normal image footprint does. This is due to the fact that the package gets downloaded, extracted and then installed. Quite often the installation routine is kept for de-installation and repair purposes, as well. On an embedded device this can lead to storage problems when running, for example, on a small size CF card, or when log files are not truncated for some time on a system in field.
To avoid installation disasters, specify the required space size when creating the program. This enables the SCCM client agent to check if an installation is possible by looking at free storage space up front.
Additionally it is recommended that you limit the program to X86 Windows XP systems to prevent unintended installation attempts on other systems. Unfortunately neither XPe nor Windows Embedded Standard is available as option in this SCCM dialog.
Reporting and troubleshooting
To find out if an installation was successful for a collection of Windows Embedded devices, refer to the “Advertisement Status” folder in the SCCM management console. The advertisement status shows detailed information on success as well as failure of the package installation in combination with errors that might have occurred.
Other valuable troubleshooting information can be derived locally on the device from event viewer or setup log files written during installation.
Alexander Wechsler
Wechsler Consulting