Welcome to the second post in my three-part series on Operating System Deployment Frontends. In the first blog, I explained how frontends work and covered task sequence variables. In this post, we move on to how to use a frontend and more implementation advice.
How To Use a Frontend
Frontends in ConfigMgr OSD can be launched in three different ways; each of course has its pros and cons.
Figure 1 shows a very basic frontend written in VBScript that is used as an example in the upcoming sections of this article. This basic frontend asks a single question and populates a single task sequence variable named PlayGame.
Figure 1: A Basic Frontend
Run as a Task
This is the most obvious way to run a frontend. You simply create a package for the frontend’s source files then using a Run Command-line task within the task sequence, you initiate the frontend with the proper command-line. You could also use a program and an Install Package task; however, this is a bit less flexible and since it’s not actually installing anything, could be a bit misleading.
Because the frontend is soliciting input from the user, you want to place this task as close to the beginning of the task sequence as is possible. Figure 1 shows calling the basic frontend from within a task sequence.
The first challenge with running a frontend as a task is that the content for the package must be downloaded to the local disk. This is generally no big deal; however, if the system being deployed is brand new, has a new drive, or for whatever reason the drive is not formatted, then downloading the content will fail and so will the task sequence. Thus, unless you can otherwise guarantee that the task executes only a system where the local disk is already formatted, you will have to place the task after a Format and Partition task in the task sequence. This isn’t a terrible issue, but it does slightly delay the display of the GUI portion of a frontend which if unexpected may cause issues.
The second challenge is that while in Windows, a task sequence cannot display any UI. The primary scenario where this limitation is a factor is the refresh scenario. This display limitation isn’t entirely accurate though. The UI is actually displayed, it’s just displayed on a hidden desktop. This happens because the task sequence is run as the local System account which is attached to a hidden desktop. This can be overcome by using tool that injects a window onto another desktop. This more or less violates a security boundary, but hey, sometimes you’ve got to do what you’ve got to do. The primary tool used to accomplish this task is called ServiceUI and it is part of the User Driver Installation (UDI) which is part of MDT. For more info on this tool, see https://blogs.technet.microsoft.com/deploymentguys/2015/07/06/script-to-make-serviceui-exe-easier-to-use-for-osd-custom-user-interfaces/.
The only other challenge with running a frontend as a task is that this isn’t soon enough to actually choose a task sequence itself. This may or may not be an actual challenge depending upon how your task sequences are configured and deployed though.
Prestart Command
Running a frontend as a prestart command ensures that it is run at the very beginning of the OSD process. This works out quite well if the frontend will drive the task sequence that will be used by setting the SMSTSPreferredAdvertID task sequence variable – for complete how-to and example on using the SMSTSPreferredAdvertID task sequence variable, see https://www.niallbrady.com/2014/04/15/how-can-i-make-multiple-hidden-task-sequences-available-on-demand-in-configuration-manager-2012-r2/. Figure 4 shows a prestart command added to a boot image. This method is mainly only applicable to the new computer scenario because it only executes the prestart command when the system boots into the boot image.
Figure 3: Adding a Prestart Command to a Boot Image
There are of course a couple of challenges with this approach as well. First, you have to customize the boot image to call the frontend. ConfigMgr 2012 made this much easier, but it does mean that if you ever change anything, you must update your boot images instead of just a single package – this can be logistically challenging in a larger or distributed environment. Next, the client’s identity is not known at the time the prestart command is executed. This means that if you need to know the current name of the system for any reason, this information is simply not available.
Run First Program
The final way to execute a frontend is as a run first program. This method is only valid if the task sequence is started from within Windows on a currently managed system and thus is primarily for refresh scenarios. It enables the frontend to run before the task sequence is ever executed and also overcomes the challenge of showing the UI since ConfigMgr can automatically display UI on the current interactive desktop even if the program is executed as the local System.
The main challenge with this approach is that the task sequence variable COM object is not available. Thus, the frontend needs to provide a way to save the variables and the values that it sets and reload them at the beginning of the execution of the task sequence. Figure 2 shows running a frontend using this option.
Figure 4: Using Run Another Program First
