Prompting for Input During a Task Sequence

Sometimes when running an SCCM task sequence, you want to prompt for input, for example to populate a Task Sequence variable that you will use later.  In this example, I am encrypting a laptop HDD (SED) using Wave ERAS, and I’m using a command-line tool that populates the pre-boot authentication screen with the AD account of the laptop end-user. This runs during a post-deployment task sequence that provisions the encryption.   As each laptop is prepared for a different end user, I needed to prompt for the user account during the task sequence, then pass the input to a script that adds the account to the encryption pre-boot.

To accomplish this I decided to use a Powershell script with ServiceUI.exe to prompt for and set the TS variable, then pass this variable to the encryption script as a parameter.  I tested it using SCCM 2012R2 integrated with MDT2013, but I can’t see why it wouldn’t work in older versions that support ServiceUI.exe.

Here’s the ‘how to’:

Create a Package

First, create a package in SCCM that contains the Powershell script below, and the ServiceUI.exe.  ServiceUI.exe comes with MDT and allows you to break out of the TS session into the user session, where you can interact.  Since I still deploy some x86 OS’s at times, I decided to include both the x86 and x64 version of the executable in the same package, and rename them accordingly, although the x86 version will probably work for both architectures.  Then I use a TS condition to create separate steps for x86 and x64.

package

You can find the ServiceUI.exe here:

C:\Program Files\Microsoft Deployment Toolkit\Templates\Distribution\Tools\x64, or
C:\Program Files\Microsoft Deployment Toolkit\Templates\Distribution\Tools\x86

PromptForUsername.ps1

<#
PromptForUsername v1
-----------------
This script prompts for input during a task sequence, and sets the input as a TS variable.
#>

# Close the TS UI temporarily
$TSProgressUI = New-Object -COMObject Microsoft.SMS.TSProgressUI
$TSProgressUI.CloseProgressDialog()

# Prompt for input
[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.VisualBasic') | Out-Null
$TSUsername = [Microsoft.VisualBasic.Interaction]::InputBox("Enter the username of the end user", "Username prompt", "eg tjones")

# Set the TS variable
$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment
$tsenv.Value("TSUsername") = $TSUsername

Distribute your package to your DPs, no program is required for it.

What does the script do?

First, it hides the task sequence UI while the prompt is displayed, otherwise it will appear behind the UI.  Second, we prompt for the input.  Lastly we pass the input into a new TS variable called %TSUsername%.

Add Task Sequence Steps

Next, we will add a step to the task sequence that prompts for the username.  Add a ‘Run Command Line’ step and use the package you created.  Call the ServiceUI_x86.exe with the following parameters:

ServiceUI_x86.exe -process:TSProgressUI.exe %SYSTEMROOT%\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -File PromptForUsername.ps1

TS1

Do the same for the x64 version of ServiceUI, if you are using both versions.  You can set a simple OS version condition on each task to determine the architecture:

TS2

Next I update my ‘add user’ step passing the %TSUsername% variable into the parameters of the command:

TS3

The result

When the task sequence runs, it will prompt for the username:

TS Prompt

It then adds the user into the preboot authentication via the script.  We can see from the SMSTS.log that it correctly substitutes the variable when running the command:

log1

This example uses a non-deployment task sequence; it should also work during a deployment, although I didn’t test it yet 🙂  To work during the WinPE phase, you will need to add Powershell support to your boot image.  For OS deployment there are more elegant ways of getting input during the WinPE Phase, such as Jason Sandys’ OSD++, or by using an HTA, but that may seem a bit much if just one or two inputs are required, so this is an excellent and easily implemented alternative that can be used during any task sequence.

More info:

http://social.technet.microsoft.com/Forums/systemcenter/en-US/22118e37-1a66-43cd-a1e4-12b50de0ee5c/powershell-script-needs-to-display-message-box-to-user
http://www.scconfigmgr.com/2013/10/02/prompt-for-computer-name-during-osd-with-powershell/
http://blogs.technet.com/b/mniehaus/archive/2009/09/22/running-powershell-scripts-as-part-of-a-task-sequence.aspx
http://www.vroege.biz/?p=417

Re-running a Task Sequence

What happens if your SCCM task sequence fails?  Well you troubleshoot it, fix the problem, and rerun it.  Easy to do if the task sequence is an ‘available’ deployment.  You just refresh the machine policy on the computer, go the Software Center, or Run Advertised Programs, and run it again.   And if your task sequence rerun behaviour is set to ‘Rerun if failed previous attempt’ it will run again anyway.

But what if it’s a required deployment?  There seems to be no easy ‘out-of-the-box’ way to manually rerun a task sequence.  Powershell to the rescue!

This little script will rerun the task sequence by connecting to the remote machine, deleting the TS schedule from WMI, and restarting the SMS Agent Host service.  After a few seconds, the TS will run again.

You need the Task Sequence Package ID, which you can get easily from the SCCM Console, and you should have Powershell remoting configured in your environment.  You can of course run the script on a local machine by removing the ‘PSSession’ commands.

<#
ReRunTaskSequence v1
-----------------

This script reruns a task sequence on a remote computer.

Tested on: SCCM2012R2

-Prereqs:-
> You need the PackageID of the Task Sequence which you can get from the SCCM Console
> Powershell remoting must be permitted on the remote computer
> You should have local admin rights on the remote computer to restart the ccmexec service
> Variables, enter the $ComputerName and $TSID (PackageID) variables
#>

# Enter remote computername
$ComputerName = "remotecomputer"

# Start a remote PSSession
$s = New-PSSession -ComputerName $ComputerName

# Main script
Invoke-Command -Session $s -ScriptBlock `
{
$TSID = "SMS000B1"
Get-WmiObject -Namespace "root\ccm\scheduler" -Class ccm_scheduler_history | where {$_.ScheduleID -like "*$TSID*"} | ft ScheduleID # Outputs the Schedule ID
Get-WmiObject -Namespace "root\ccm\scheduler" -Class ccm_scheduler_history | where {$_.ScheduleID -like "*$TSID*"} | Remove-WmiObject # Deletes the Schedule
Get-WmiObject -Namespace "root\ccm\scheduler" -Class ccm_scheduler_history | where {$_.ScheduleID -like "*$TSID*"} | ft ScheduleID # No output confirms the deletion
Get-Service | where {$_.Name -eq "CCMExec"} | Restart-Service # Restart the SMS Agent Host service
}
Remove-PSSession $s

More info:

http://www.scconfigmgr.com/2012/11/21/re-run-task-sequence-with-powershell/
http://blogs.msdn.com/b/steverac/archive/2009/11/06/sccm-forcing-a-task-sequence-to-rerun.aspx

Installing Intel Rapid Storage Technology During a Task Sequence

With our SCCM OS deployments, I like to install some of the ‘driver apps’ that come with our Dell machines, such as the Intel Management Engine Components (AMT), Bluetooth, and Rapid Storage Technology.  But for a long time the Rapid Storage Technology always bugged me because I couldn’t install it during a task sequence, either during deployment or after.  It would give some ‘fatal error during installation’ message that wasn’t very helpful.  Since it wasn’t critical to include it, I didn’t investigate too much further, but with the new Dell 7000 series laptops, it’s a requirement to install the Intel RST version 12.8 in order for the encryption software we use to work.  So I decided to dig around a bit to get this working.

I used the ServiceUI tool from MDT to create an interactive installation during a task sequence, and then I discovered it was trying to log to a folder in the user profile area, which it couldn’t do for some reason, even though it could when installing outside of a task sequence.

It turns out there is a simple fix, and I can’t believe I didn’t think of it earlier!  I extracted the SetupRST.exe file using 7Zip, and inside were 2 msi files, one each for x86 and x64.  These can be deployed successfully during a task sequence using the standard unattended program that SCCM creates for MSI packages.

extracted

It does however force a reboot, because it updates the storage controller driver, so if you don’t want that to happen during the task sequence, be sure to add the ‘REBOOT=ReallySuppress’ switch to the msiexec command, eg:

msiexec.exe /q ALLUSERS=2 /m MSIDTJBS /i “RST_x64.msi” REBOOT=ReallySuppress

Problem solved 🙂