**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.
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.
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.