Integration of Windows Embedded Standard systems into a System Center Configuration Manager infrastructure
**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.]
In my last post I focused on the client-side requirements that need to be satisfied when building a Windows Embedded Standard image that resides in a System Center Configuration Manager (SCCM) environment. This post takes a closer look at the back-end considerations and configurations to keep in mind when Standard systems are managed by SCCM. Note that all the statements are only valid for SCCM-ready images (as described in my previous post) and most probably will not work for any other custom images.
Discovering Windows Embedded Standard Clients
Devices only can be managed by SCCM, if they first have been discovered by the server. To discover devices, SCCM scans IP-address ranges and/or crawls the Active Directory database of a company’s domain. Discovery returns basic information on the type and OS of a device. After getting this information SCCM tries to install the appropriate client agent onto the device, if this is not already included in the OS image of the device, or if there is a newer client version available. With the help of the client’s services the back-end collects information (/HW and SW inventory) about all devices present on the network, and uses this information to group and maintain them.
SCCM uses so-called “Collections” as its main means of targeting devices for management and software distribution.
If Windows Embedded Standard devices are connected to a typical SCCM environment they are discovered just as XP Professional devices are, because they run the same binaries as the desktop system. This may not be desirable, as Windows Embedded Devices are different. It would be more appropriate to have a group or collection to manage only the Windows Embedded Standard devices or, even better, to manage different embedded devices differently.
Using dedicated Organizational Units in Active Directory
One best practice is to group similar Windows Embedded device types, e.g. cash registers, building controllers, gaming machines or automation controllers in their own Organizational Unit in Active Directory. This allows easy discovery and grouping of the devices into a collection that targets just the members of this OU. Additionally, it enables the administrator to use the very powerful Active Directory policy system for management. With the help of system policies, the use of USB Sticks, user rights and a lot of other settings can be controlled in a granular and secure way for all devices in this OU, even on a per-user basis.
SCCM efficiently discovers devices registered in AD. Very often this is faster than network discovery and also saves bandwidth, because no broadcasts are required. In addition, there is much more organizational information available, which helps to create sub-collections in SCCM for special purposes that normally cannot be derived from network information alone.
Configure SCCM to distinguish Windows Embedded Standard devices
There are environments where OU’s cannot be used or where you want to be sure that any Windows Embedded devices connected to the network gets discovered as an embedded system. To handle these scenarios, SCCM needs to be configured to include an additional WMI (Windows Management Instrumentation) property that is used to distinguish XP Pro systems from Windows Embedded Standard systems.
This is done by opening the control file called “SMS_def.mof” on the SCCM site server. This file contains the information about the properties reported back from the client that is being inventoried. It is normally located in the [SCCM main folder share]\inboxes\clifiles.src\hinv folder on the site server.
In the SMS_Def.mof file search for the string ”OSProductSuite”, which is the fastest way to get to the related SMS Report setting:
[SMS_Report (False) ]
uint32 OSProductSuite;
The default setting for SCCM is not to report this property. Therefore, this must be changed to
[SMS_Report (TRUE) ]
uint32 OSProductSuite;
Save the change and close the file. The SCCM main service needs to re-started to bring this setting into effect. Be careful, if running in a production environment, this ideally should be done during backend maintenance time!
After the restart, SCCM client agents will now report the “OSProductSuite” WMI property back and enable the detection of Windows Embedded Standard devices.
Creating a Windows Embedded Device Collection
To detect the embedded devices create a collection using the WMI property as selection criterion. This can be done using the new collection wizard, for example. The only item that is required to configure this collection is a single criterion targeting the “OSProductSuite” property.
If the value detected is 64, these systems are running XPe, Windows Embedded Standard or Embedded NT.
Other possible values for OSProductSuite are shown in the table below:
1 - Small Business Server
2 - Enterprise Server
4 - Back Office Server
8 - Communication Server
16 - Terminal Server
32 - Small Business Server (restricted)
64 - Embedded NT
128 - Data Center
With the help of this collection an administrator is able to see all Windows Embedded devices connected to the company’s network.
Alexander Wechsler
Wechsler Consulting