OSD SMSTSDownloadProgram Option

Had an interesting scenario recently while working with a large customer with a LOT of locations. The challenge was that they needed to stage imaging content on local servers at each location to facilitate imaging without overloading the network links. OK, easy – right? The twist was that they could not make the local servers distribution points in any way. For various reasons they also were not able to implement BranchCache or third party equivalents. They were also not on ConfigMgr Current Branch which would at least give them Windows PE caching. Thankfully ConfigMgr 2012 was in place!

ConfigMgr 2012 SP1 introduced the SMSTSDownloadProgram variable which I had overlooked completely. It is easy to overlook something until you need it!

The SMSTSDownloadProgram variable introduces a user configurable alternate content provider – a way to specify an alternative process for downloading content when needed by the task sequence instead of using ConfigMgr’s built in mechanism. The only concern with using the alternate content provider is that doing so means the user takes on full responsibility for ensuring content is available when needed. Also note that the alternate content provider only supports download and execute scenarios. But when engineered well the alternate content provider can bring forward some great flexibility during the imaging process. In fact, this variable and the alternative content provider approach is the method used by third party vendors to ‘intercept’ and obtain content using their tools during a task sequence.

A quick glance at the documentation for this variable leaves a big question though. How exactly is this variable used and how does it actually work? To test a demo of the approach was created. After a bit of trial and error it actually worked! The hardest part about this was getting the full concept. Implementing is very easy. Read on to see how this was accomplished but be aware that there could be several other ways in which the alternate content provider could be effectively implemented. The example is just one of them.

When the SMSTSDownloadProgram variable is set the task sequence will use whatever detail is stored in the variable when it needs content during task sequence execution. The value name suggests the kind of detail stored in SMSTSDownloadProgram – a program. The program can be anything – an EXE, a script, etc. The key is ensuring the referenced program is able to effectively access and download the content needed by the task sequence.

At the point the task sequence engine needs content it will attempt to look it up. Normally this would be through standard content lookup mechanisms. If the SMSTSDownloadProgram variable is defined the task sequence believes the alternate content provider is configured and will ignore normal content lookup processes and, instead, will hand off content acquisition to the alternative content provider by pass the program defined in SMSTSDownloadProgram two variables – the content ID and the location to store the content on the imaging system. The program referenced by SMSTSDownloadProgram will need to be able to handles these passed variables. The example shown shortly simply uses XCOPY.EXE as the executable. It’s simple but it works and is available in all builds of Windows.

The best way to illustrate using the alternative content provider is by an example.

Staging Content
Using the alternate content provider typically means that content will be retrieved without the use of ConfigMgr distribution points. In some cases it might be of interest to implement the alternate content provider for other purposes and still use the ConfigMgr distribution points for a content source. If there is such a scenario accessing content from the ConfigMgr distribution points will need to be managed by the alternate content provider and with effective use of the related ConfigMgr API’s.

The example assumes a complete separate source of content will be used during the task sequence. As such, that source needs to be created by building a share to store the content. In the example the share is called TSContent. Immediately in the share a folder called Packages is created and then, inside Packages, the content needed by the imaging process is staged. Building and maintaining the share used by the alternate content provider is a completely manual process. Note that the folder names of the content follow the ConfigMgr content ID format. The task sequence engine will reference the content by ID when it is requested from the alternate content provider.

The share is just a storage location. To make use of the share the task sequence needs to reference a program which will make use of the content. To hook this all up only a couple of steps are needed in the task sequence, as shown.

That’s it. Really easy.

The first step is simply to map a known drive letter to the network share OF THE PROGRAM, not the content share.

This step may or may not actually be needed depending on how the alternate content provider is actually implemented. In the example the alternate content provider code is stored on a network share instead of embedding in the imaging process directly (by adding to Windows PE, etc.)

It might also be noticed that the share being connected is NOT the one referenced above where the content is actually stored. Instead, this share is the location that contains the code which is the alternate content provider. The contents of the share are shown.

The code used by the alternate content provider can be anything. Here the code is simply a batch file named ACP for alternate content provider with 1 added to indicate the first alternate content provider. Ah, interesting. What is meant by the FIRST alternate content provider. Typically, only one alternate content provider is needed but it would be possible to have more than one and have then change during the course of the task sequence just by resetting the SMSTSDownloadProgram variable as needed.

The contents of ACP1.cmd are really simple. As already mentioned, for the example XCOPY.EXE is being used so the cmd file simply calls it.

xcopy \\cm12prisql\TSContent\Packages\%2\* %3\* /cherkyfs

A couple of questions might be front of mind at this point.

· If the cmd file is simply calling xcopy why not just store xcopy in SMSTSDownloadProgram instead of wrapping it in a cmd file?

That is a great question. A couple of reasons come to mind.

o The task sequence engine makes use of the alternate content provider by passing variables to whatever is stored in SMSTSDownloadProgram. While it may be possible to do this with xcopy directly (don’t know, haven’t tried) it certainly is easier to conceptualize passing variables to a program – even if that program is just a cmd file.
o Leveraging a cmd file – or VBscript – or PowerShell – or EXE - or whatever – gives more flexibility. It’s possible to start really simple but expand later as needed.

An example to illustrate. After the sample described to this point was built a tweak was needed. Some systems being imaged had really small disks so there was not enough room to store all of the content needed during imaging. Using the alternate content provider script, it was possible to clear the cache on the imaging system at each step to remove any content remaining there since it was no longer needed. The ACP1.cmd was tweaked to accomplish this.

rd c:\_SMSTaskSequence\Packages\ /S /Q
md c:\_SMSTaskSequence\Packages
md c:\_SMSTaskSequence\Packages\%3
xcopy \\cm12prisql\TSContent\Packages\%2\* %3\* /cherkyfs

· What are these %’s for in the command line?

o As mentioned the task sequence engine will invoke the alternate content provider by passing a couple of variables. The % represents where those variables will be inserted and are unique to batch programming. If other languages are used the representation will be different but the concept is the same. The task sequence engine passing the variables will be shown shortly.

The second step in the process is to actually create and populate the SMSTSDownloadProgram variable which flags the task sequence to use the alternate content provider stored here instead of standard content lookup processes.

With all of this in place is it possible to confirm the task sequence is using the alternate content provider? Yes. One obvious way is that if the alternate content provider is configured but isn’t fully working the task sequence will fail. Assuming the task sequence is working validating that the alternate content provider is being leveraged is really easy. Open the SMSTS.log and check for a couple of entries.

An entry similar to the following will be seen if the alternate content provider is being used:

Using download program z:\ACP1.cmd

An entry similar to the following will be seen each time the alternate content provider is called:

Set command line: “a:\ACP1.cmd” X:\windows\TEMP\SMSTSDownload.INI PS100004 C:\_SMSTaskSquence
Executing command line “z:\ACP1.cmd” X:\Windows\Temp\SMSTSDownload.INI PS100004 C:\_SMSTaskSquence

That’s it. Yet another way that imaging with OSD offers more flexibility and unique use cases.