Creating a System Center – ready Windows Embedded Standard image
**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.]
The Microsoft System Center Configuration management system is built on a client-server architecture. This means that every system participating in this environment needs to install a client application to connect to the System Center back-end for acquiring updates, delivering inventory reports, getting management commands, etc.
These client applications normally run as Windows Services, to be started automatically when a system boots, as well as making them easier to control.
There are two fundamental ways to get such a client service into the Standard operating system image. The first one is to include the service as a component during build; the second is to install the client service later on in the field or factory, after the image has been deployed to the target device.
System Center Client Component
For quite some time Microsoft favored the first approach, offering a dedicated XP embedded version of the SMS 2003 Advanced Client (XP embedded and SMS are the old names of Windows Embedded Standard and System Center Configuration Manager). The client component is still provided as a separate download and is not included in the Windows Embedded Studio toolkit. Therefore it needs to be installed in the component database before being available in the component catalog. After successfully importing the SMS component it can simply be added to a Windows Embedded image.
While including the service in the image seems to be quite a good idea, e.g. reducing installation problems in-field, it comes with a major drawback-the client service cannot be uninstalled via the Windows Installer functionality, because the componentized version does not include the setup application, which Windows Installer could use. This leads to kind of a cul-de-sac- as soon as the client service itself needs to be updated (for example, when upgrading the management back-end from SMS 2003 to System Center Configuration Manager 2007). In this scenario, an automatic installation of the new client will fail, because the old one cannot be uninstalled.
System Center Client Prerequisites
The best way to solve such a problem would be either to roll out a completely new image with the new client installed or include the System Center prerequisites macro component that guarantees that everything needed by the client and its service setup routine is included into the image. There are two pre-requisite macro components included in the Standard database, one for supporting the System Center Configuration Manager (SCCM) client and one supporting the System Center Operations Manager (SCOM) client.
The prerequisite macros do not install an SCCM or SCOM client. They only pull in the required OS functionality via component dependencies.
Reducing in-field installation risks
Including the macro components solves the update problem described above, but does not come for free. An in-field client installation adds higher risk as well as requires more resources during installation time of the client. An SCCM client installation for example requires about 350 MB of additional storage space during setup, which might not be available on a Compact Flash card. The best way to reduce this type of risk is to add the prerequisites macro and the current SCCM client during factory installation and to plan on having enough storage for upgrade scenarios.
Due to the fact that Configuration Manager Client setup can be run unattended, it is possible to integrate it into the FBA process as a custom component to automate this step.
Configuring the prerequisite macros
As stated before, the macro components need to be added to the OS image to prepare it for participating in a system center environment. System Center macro components pull in all dependencies required to satisfy the needs of the SC client service and, at the same time, offer optional components to include on purpose.
Looking at a SCCM client, including .NET Framework 2.0 is required if devices want to support the desired configuration feature of SCCM and Sysprep should be included if the image needs to be distributed via the OSD (Operating System Deployment) functionality. Domain participation very often is required for enterprise scenarios and should be used whenever possible to leverage the security and authentication mechanisms of this infrastructure.
The rest of the configuration options offers additional options for operating the client but are not necessarily required.
The SCOM client macro component offers fewer configurable options, which, with the exception of domain participation, provide more options during operation and are not essential.
As soon as one or both of the SCCM macro components are included in a Standard image, the minimum image footprint will be between 200 and 300 MB. Therefore, considering upgrade scenarios, at least 1-2 GB of storage space should be available on CF card or disk. Please be aware that hibernation or page files might have an impact on the available free storage space in these cases, as well.
Get things up and running
After the Windows Embedded Standard image has been configured with the System Center macros and built, it runs through FBA on the device and then can be tested in the target environment. For testing purposes, it is good to know that normally systems do not get discovered by SCCM or SCOM immediately. Depending on the back-end’s discovery settings it can take a while until the systems are detected by the back-end server and clients get installed. This sometimes requires patience!
A healthy client shows, in its Control Panel applet, a list of “installed” and “enabled” client functionalities. If you see only “installed” client functionalities, the system has not yet been discovered or something has gone wrong. Of course the discovery test for SCCM site in the client applet should work, too.
Troubleshooting
If the devices do not get discovered, there are several things you can check:
· Windows Firewall should be turned off or configured for SCCM /SCOM, because ports are required to be open in order to the client
· Try to ping the SCCM/SCOM site- the device should be connecting to
· DNS name resolution in the network
· Client installation log if the client gets downloaded but its setup fails
· Windows event log for related errors
· SCCM client event logs
· Back-end discovery settings
Normally these locations provide more information and hints about has gone wrong with the client. If these do not help, advanced Windows Embedded Standard troubleshooting techniques using e.g. FileMon or RegMon can, of course, be applied in this case, as well.
Alexander Wechsler
Wechsler Consulting
Technorati Tags: XPe,embedded. SCCM,SCOM