Advanced System Center Configuration Manager (SCCM) Software Deployment Scenarios
**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.]
Change management scenarios of embedded devices are sometimes much harder to handle than those of corporate desktops. This is especially true when you consider the way users interact with devices. System Center offers a control panel applet users and administrators can use for local interaction with the Configuration Manager infrastructure. This works fine for Windows Embedded Standard Devices as long as they run explorer shell the same way corporate desktops do. If embedded devices run their own shell these options are gone, because no access to the applets can be provided.
It is also common, that the entity controlling the embedded device is not a human but other machines feeding, for example, state information into the device.
Using a maintenance shell
Tricky? Yes. So how do you solve these challenges?
One solution could be to have a user-specific shell for the standard user, for example the one your custom application runs under, and a different, ideally explorer shell, for an administrative maintenance account. If the standard user is logged off, maintenance personnel will be able to log on using the administrative account. This gives them all the standard usability and comfort of explorer shell. Having this flexibility is very beneficial especially if unforeseen problems occur and you need the best possible troubleshooting infrastructure. There is a good article written by Sean Liming to be found in the MSDN Library, which explains how to set up “Different shells for different users”.
The major drawback of this approach is that it requires manual interaction in the field. In some scenarios this is too costly, for example if devices are located all over the world.
Accessing the Configuration Manager client programmatically
Another way to interact with the SCCM deployment system is to do this programmatically.
Nearly all functionality of the SCCM advanced client is exposed via a COM object, called UIResourcelib.dll. This COM object is installed and registered together with the rest of the client locally and can be found in C:\Windows\Sytem32\CCM. UIResousourcelib provides an API that can be accessed from native, as well as managed, applications. In addition, there are some samples available in the SCCM 2007 SDK that provide valuable information to get things started.
If you use a managed application, accessing the COM object is quite simple, because Visual Studio generates a COM interop proxy object for it automatically. All that is required is to set a reference from your C# or VB.Net project to UIResourcelib.dll.
SCCM Package Chooser- code sample
A little sample application I wrote for TechED North America last year can be accessed from my web site, which mimics the control panel “Run advertised programs” applet shown below. To download it click on this link (Note that this is not a Microsoft applet).
The sample is quite straightforward. It just reads all available programs during startup from the SCCM agent infrastructure using the API of the COM object and then starts a selected package for download and installation.
The application does this by instantiating a resource manager and some other objects provided by UIResourcelib.dll.
#region Define SCCM Advanced Client objects
//define required objects
private UIRESOURCELib.UIResourceMgr ResMan = new
UIRESOURCELib.UIResourceMgr();
private UIRESOURCELib.IPrograms AVProgsCol = new
UIRESOURCELib.Programs();
private UIRESOURCELib.IProgram AppSelected;
#endregion
With the help of the Resource Manager object, all available advertised programs are retrieved and placed into a collection during the loading of the application. The collection is then used to fill a list box in the UI to displaying them.
#region GetAppsfromSCCM
//Get all advertised applications for the collection(s)
the client is part of
AVProgsCol = ResMan.GetAvailableApplications();
//Loop through the collection to fill the display list
foreach (UIRESOURCELib.ProgramCls App in AVProgsCol)
{
this.listBox_DisplayPacks.Items.Add(App.PackageName.ToString());
#endregion
}
If one of the programs is selected and the install button is pressed, a corresponding method is called to run the package.
#region InstallPackage
//Get selected SCCM application package object
foreach (UIRESOURCELib.ProgramCls App in AVProgsCol)
{
if(App.PackageName == this.listBox_DisplayPacks.Items
[this.listBox_DisplayPacks.SelectedIndex].ToString())
{
AppSelected=App;
}
}
//Call to execute package from SCCM server
ResMan.ExecuteProgram(AppSelected.Id, AppSelected.PackageId, 1);
#endregion
Together with some UI coding, the result is that this dialog that could be integrated into any custom shell solution. Or, often an even better fit, the same functionality can be used to trigger updates automatically from an application.
Advanced custom scenarios
By using the SCCM infrastructure programmatically, one can go far beyond standard version-driven maintenance scenarios. Software or data packages that are available for the collection of embedded devices can be downloaded and installed on demand, as the environmental parameters of a single device require. This could even go as far as new or other application parts get downloaded, for example if the location of a device (which might be determined by GPS) changes or if the device mode is configured differently by a user, SCCM does not only deliver change management infrastructure, it also becomes a reliable and efficient part of the solution.
Alexander Wechsler
Wechsler Consulting