Running the MDT Task Sequence as a Different User

When using MDT (Lite Touch) for your deployments the default behavior is to run every task sequence action as the local Administrator account. In addition to this, MDT also connects to the deployment share using the account you start the deployment with. Either typed in via MDT deployment wizard login dialog box, or automated via bootstrap.ini. But what if you want to run the task sequence, at least the last part of it, as a different user in order to access resources on other servers than the deployment server? Or simply to install applications as a different user.

Installing Applications as a different user

In a scenario where you want to access resources that are on a different server than the deployment server, or just install the install application as a different user, you have a few options. You can do it by adding a Run Command Line action in MDT, and specify a different user account to run the action. Or by adding a command line or script that maps a network drive to the resource before installing the app. The ZTIConnect.wsf script built-in to MDT is a good example.

Running the Task Sequence as a different user

In the scenario where you have a bunch of tasks that needs to be run as a different user, you can also configure the entire task sequence to run in different user context. This is typically done by either hacking the unattend.xml template in MDT to use that account, or by adding a script to the task sequence that configures it to run as a different user. Since the latter example can be dynamic, and you can use CustomSettings.ini to configure it, that's what I'm recommend using here.

First, the user account that you use to run a task sequence, must be a local administrator on the machine during the deployment. That can be achieved in a number of different ways too: For example using restricted group feature in group policy, or group policy preferences, or a script, or why not simply by using the built-in feature in MDT that does it: The Administrators list property.

Secondly, because how MDT Lite Touch works, when running the task sequence as a domain user (but still a local admin), you also need to temporarily disable UAC. Otherwise the task sequence will never continue after the reboot (and you will see an error in the BDD.LOG about Regsvr32 failing to register the Microsoft.BDD.Utility.dll file). Disabling UAC temporarily can be done by simply setting a registry via the task sequence, and then of course you enable UAC back again when the task sequence is done. You should also add a FinishAction=REBOOT to your CustomSettings.ini to make sure the installation is rebooted after enabling UAC.

This is what you need to add to your CustomSettings.ini file

In this example the task sequence will run as the user Frank in the VIAMONSTRA domain (Anyone that have seen the Swedish Tele2 commercials knows where the name Frank came from 🙂 ).

[Settings]
Priority=AppInstallAsDifferentUser,Default
Properties=APPINSTALLDOMAIN, APPINSTALLACCOUNT, APPINSTALLPASSWORD

[AppInstallAsDifferentUser]
APPINSTALLACCOUNT=Frank
APPINSTALLPASSWORD=P@ssw0rd
APPINSTALLDOMAIN=VIAMONSTRA

[Default]
Administrators001=%APPINSTALLDOMAIN%\%APPINSTALLACCOUNT%
FinishAction=REBOOT

Create the Configure – Set Autologon in Domain application

The next step is to create the Configure – Set Autologon in Domain application, which is really just a VBScript that configures the Autologon settings in the registry, using the variables from the CustomSettings.ini file. The reason I recommend to add it as an application (you can just add it to the scripts folder) is because of portability. It's easy to just copy and paste applications in between deployment shares, and it also makes it visible in the Deployment Workbench.

Here is the Configure-SetAutologonInDomain.wsf script:
https://github.com/DeploymentResearch/DRFiles/blob/master/Scripts/Configure-SetAutologonInDomain.wsf

Import the script as an application to MDT. The command line for the application is the following:
cscript.exe Configure-SetAutologonInDomain.wsf

Edit the task sequence

After modifying the CustomSettings.ini file, and creating the application in MDT, you only need to modify the task sequence. In this example I created a group named Prepare for running TS as different user and added the following actions:

Run Command Line
Name: Add Administrator001 user to local admin group
Command line: cscript.exe "%SCRIPTROOT%\ZTIGroups.wsf" /restore

Run Command Line
Name: Disable UAC temporarily
Command line: reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f

Install Application
Name: Configure – Set Autologon in Domain
Install a single application: Configure – Set Autologon in Domain

Restart Computer

Then, in the end of the task sequence, typically after the Apply Local GPO Package where the should be no more reboots, you enable UAC again by adding this action:

Run Command Line
Name: Enable UAC
Command line: reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 1 /f

That's it, now you have a task sequence that will run the last part of as a different user 🙂

Troubleshooting

If you run into any issues, check the following two log files:

• ZTIGroups.log. This file should show the user defined via the Administrators001 variable being added to the local administrators group.
• Configure-SetAutologonInDomain.log. This is the log file from the Configure-SetAutologonInDomain.wsf script.

Written by Johan Arwidmark