Change Management for Windows Embedded Standard Devices using System Center Configuration Manager
**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.]
If there is one change management tool in the Microsoft platform that comes close to a Swiss army knife then it is System Center Configuration Manager (formerly known as SMS server). This piece of back-end infrastructure is capable of doing sophisticated, enterprise class device management, fulfilling most of the requirements administrators have in their daily business.
To mention just a few functionalities:
- You are able to group devices to view their properties,
- You can target these collections or groups with specific updates, in a scheduled maintenance window, for example.
- The clients can report back on whether updates or patches have been applied successfully or if something has gone wrong.
- Even complete OS Images can be distributed, which is one of the features new to Windows Embedded Standard.
- Additionally, there are hardware inventory capabilities, which recognize when components are removed or have stopped working. All this is accompanied by strong diagnostics and remote management functionality to give system administrators all the means to keep systems up and running.
In combination with Server 2008, SCCM actively participates in NAP (Network Access Protection) scenarios. This is a new protection technology for networks, which guarantees that only devices with a certain security level (such as having all required patches) are allowed full access to a network’s resources. The picture below shows the basic vision behind this.
Furthermore, all functionalities in SCCM are bandwidth aware and are scalable to the needs of very large enterprises.
WES / SCCM usage scenarios for embedded devices
SCCM offers a lot of functionality and shows a deep integration with many products in the Microsoft enterprise platform. At the same time it efficiently leverages a lot of the built-in Windows client-side building blocks such as WMI, Windows Installer, BITS (as well as all OS security and authentication features) to fulfill its tasks in field.
Not a minimal effort or low footprint solution
Considering all the dependencies SCCM has, it is pretty evident that a SCCM infrastructure requires significant effort to set up the back-end components, which include not only SCCM itself, but several additional Windows servers to carry the SCCM roles, a SQL Server to store data and changes in the Active Directory schema to enable device discovery.
Using SCCM leads to higher image footprints on the embedded client device. For Windows Embedded Standard the smallest possible image that includes all the SCCM’s dependent components is around 200 MB.
This means, that to use SCCM in an embedded project the number of clients that need to be managed should be either high enough to justify the investment in the SCCM back-end, or the devices should be integrated into an existing SCCM system that manages enterprise clients. The latter scenario is quite common. Today a lot of cash registers, ATM machines or kiosk systems running XP embedded or Windows Embedded Standard integrate very well into these systems. By doing this, they are providing additional value to administrators, who are able to leverage a single tool to manage the complete IT-environment.
Nevertheless, and I consider this a drawback from an embedded OEM perspective, SCCM is still enterprise-centric because of its dependencies on Active Directory and enterprise security mechanisms. Therefore it is currently not possible to manage a large number of deployed devices across several unrelated companies.
SCCM scales
SCCM scales pretty well due to its concept of functionality roles. This means that different pieces of functionality on an SCCM site can be set up on different physical servers. Having such a setup network traffic, as well as load, on these systems can be managed with much more precision and is able to scale up, if required. It is possible to cascade SCCM sites, having the primary site in a company’s headquarter and secondary site spread around the globe in subsidiaries, for example. All settings made to the primary site then replicate to the subs, which can be managed independently, if necessary.
On a single SCCM site (dependent on hardware and network environment, of course) about 100,000 clients can be hosted. This shows the scalability and robustness built into this change-management system.
In my next posts I want to drill a bit deeper into the integration of Windows Embedded Standard devices into an SCCM environment. And there are some dark secrets about using SCCM together with embedded systems I wanted to share with you.
Alexander Wechsler
Wechsler Consulting