Migrating to the SCCM UDI for OSD, part 1: Introduction

This post if the first installation in a series on migrating to Configuration Manager UDI from MDT “LiteTouch”.  Don’t know what I am talking about?  Well then, this blog series is likely of little interest to you.  (Hint:  This is all about deploying Windows operating systems using Microsoft’s own deployment technologies.)

“SCCM UDI for OSD”… sounds really cool, right?  Such snappy product names that we Windows Sys Admins get to work with!  For those not already bored to death, we are talking about the System Center Configuration Manager 2012 R2 User-Driven Installation for Operating System Deployment.  UDI is an optional extension to SCCM that is included in with free Microsoft “Solution Accelerator” called “MDT 2013” (The Microsoft Deployment Toolkit, 2013 edition).

Here at UVM, we have been using MDT in “LTI”, or “Lite Touch Installation” mode for many years (for those in the know, we used LTI back when MDT was called “BDD”, or the “Microsoft Solution Accelerator for Business Desktop Deployment”).  LTI has served up well for a long time.  We used MDT throughout the XP, Vista and Windows 7 lifecycle.  But since at least 2012 we have been wanting to migrate to the SCCM/UDI platform.  The initial driver for this migration was a desire to reduce the number of application installation packages that we need to maintain.  Currently we need to maintain packages in SCCM and in LTI.  By migrating to UDI, we can drop all of the LTI work.

In recent months, some additional pressures have come about which make this migration a bit more pressing:

  1. We would like to ensure that the SCCM management agent gets installed on all new computers at deployment time.  We have received complaints about the failure of LTI to configure the SCCM management agent.  While we feel that our current system is reliable, there still is a perception that SCCM agents are not getting installed on new computers.  The SCCM agent installation steps that are built into UDI task sequences should address this problem.
  2. OS Images in LTI often are out-of-date by 3-6 months.  In an effort to speed deployment times, we defer the application of OS updates at install time, and instead rely on the management agent to install updates in its own good time.  However, many support staff in the field do not like to release new computers without all updates already in place.  Using SCCM with UDI will help to address this problem in two ways:
    1. We can use SCCM to apply regular OS updates to our system images while they are offline.  This greatly reduces the number of updates that need to be applied to newly deployed computers.
    2. We then can force any remaining updates to run at deployment time without greatly increasing deployment time.

While all of this sounds very appealing, we also have a great deal of custom logic built into our current MDT/LTI environment.  Remapping our current workflows into UDI land is a difficult and time consuming task.

Additionally, while it is true that MDT/LTI and SCCM/UDI share a great deal of code, it is important to understand that they are very different things.  Many task sequence steps found in these tools look very similar and share nearly identical names.  However, these steps often are radicaly different in implementation.  Most notably, injection of drivers, installation of applications, and application of operating system images are handled in ways that utterly shattered our exiting task sequence logic.

The whole process of adapting MDT/LTI to SCCM/UDI was, at the very least, educational. I now know a lot more about programming SCCM than I ever wanted to know. I just wish that the techniques used here were useful elsewhere. I don’t work with any other Windows products that are so thoroughly rooted in WMI, so I have my doubts.

Lessons learned about programming in SCCM:

  1. Don’t even think about using the PowerShell cmdlets included with SCCM 2012 R2 (RTW-CU4). They are very buggy and feature incomplete.
  2. If you are an experienced C# programmer, you might consider using SCCM managed code to do your scripting work, but be forewarned that the aforementioned buggy cmdlets work off of these same managed code DLLs, so you might not have the best experience with them.
  3. For everyone else, you probably should stick to straight WMI calls using VBScript or PowerShell. I am trying to wean myself off of VBScript, so I chose to blaze new territory in programming SCCM using WMI programming with PowerShell. Call me crazy, but it was the only way I could get this stuff to work and stay sane (for a given value of sane).
  4. SCCM WMI objects that are not called using a fully-qualified object path do not have all object attributes exposed. Microsoft calls this “loose binding” in their documentation, but this is a misnomer. “Loose binding” should mean that the attributes are not exposed until they are used. In this case, it means that the attributes are totally empty and never will contain any data until you call a new version of the object using its $_.__PATH attribute.
  5. In order to update many/most SCCM objects, you need to call a generic WMI CLASS object for that object, and use the generic class to manipulate the actual WMI object. Confusing? Yes!

In the coming posts, I will document the scripts and procedures that I developed to remap our LTI logic into UDI logic.  It is going to be a bumpy road, so grab a fresh cup-o-joe in a spill-proof cup, put on your padded shorts, and fasten your seat belts.

Series Index:

2 thoughts on “Migrating to the SCCM UDI for OSD, part 1: Introduction

  1. Pingback: Migrating to the SCCM UDI for OSD, Part 2d: Driver Handling (continued) | J. Greg's Brain Corral

  2. Pingback: Migrating to the SCCM UDI for OSD, Part 2a: Driver Handling | J. Greg's Brain Corral

Comments are closed.