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
Hi Johan,
thanks for this post. I'm trying to get the task sequence to run as a local administrator named admin, which I create in the unattended.xml. I already figured out that that's not working, it brings up the BDD.something error. So far, it only works when using the built-in admin account. However, we'd like to use a local account. Any idea on how to achieve that?
No easy workaround since it would involve making lots of changes to the MDT scripts. Better to rename the admin account after deployment is completed.
Hi I have implemeted this just successfully on a Win11 21H2 task sequence, yet when doing the same on a Win10 Task sequence I get the below error when adding the account to local admins: <![LOG[Group or user 'xxx\yyy' could not be added because it does not exist (possibly an obsolete local account).]LOG]!>
I have double checked and the account does still exist, I've also checked for blank space in the account and domain name but none, any ideas?
Steve, no idea I'm afraid. I have only tested on Windows 10 and Windows Server 2016/2019/2022. but its great to know it seem to work ok on Windows 11.
I am trying to make this work, but hitting an odd issue. I have everything in place but when it goes to run the Configure-SetAutologonInDomain.wsf I get an error code "1" I have recreated everything and re-downloaded the script (overkill i know). the machine reboots fine etc but does not login as the user specified in the customsettings.ini
I am not sure how to diagnose as the logfiles are just showing that its attempting to run, and the erroring. no reasons for the error.
Any help gratefully received
Typically, error code 1 means MDT couldn't find something, so double-check that the script is directly in the application folder you created and that the command line is correct for the application. Since the script is referencing the ZTItility.vbs script, it would fail if it's placed in a subfolder within the application. Below is an example of what my folder looks like for the app. The script also creates a log file that may give some clues as well. The log file is Configure-SetAutologonInDomain.log. I updated the post with some troubleshooting tips at the end.
I am on LTSC 21H2 and trying to implement this. It is currently failing at the 'Instruction name: Add Administrator001 user to local admin group' step with the following error:
<![LOG[Failed to run the action: Add Administrator001 user to local admin group.
Incorrect function. (Error: 00000001; Source: Windows)]LOG]!>
Is there a different way to do this now? My security team wants the OS to use a Domain account and not the local Administrator.
The account running MDT has to be a local admin, but can be a domain user that has been added to the local administrators group.
/ Johan
Hello Johan,
Thanks for the post
In the command line \ missing before ZTIGroup.wsf
Run Command Line
Name: Add Administrator001 user to local admin group
Command line: cscript.exe "%SCRIPTROOT%ZTIGroups.wsf" /restore
Hi Payam,
Thank you for letting me know, the post has been udpated.
How do I run MDT Task Sequence under different local admin account already apart of my image?
I haven't tried, but I would guess using the computer name as domain name would work.
What would be the best way to swap back to the default built-in Administrator account when all done using the domain account? My main purpose for this is to have one last reboot and clean-up of the alternate profile (remove from local admins / delete locally cached profile) before wrapping up.
Should be to modify the same script to restore control to the original administrator account.
Never mind 🙂 the issue was with the USB label…
Hi Johan, I tried to add this to our MDT/WDS environment and followed the same exact setup but I am running into an issue. After finishing the "Prepare for running TS as different user" steps, the domain account I setup won't auto-login after the restart. I will get the prompt "We can't sign you in with this credential because your domain isnt available." When I login manually, the task sequence will continue. I noticed the network connection icon in the login screen is showing not connected even though the computer is already joined to the domain and ethernet connection is… Read more »
These types are often DNS or network related. If it's a workgroup machine, use the computername as the domain.
is there also a variable for the pcname?
Well, the OSDComputerName variable has the PC name, but MDT requires a user to drive the process.
/ Johan
Hello, Somewhat related to this post – what would be the best way to start the deployment from a MDT server with and admin account, other than "Administrator" ? So far the task sequence is deployed under "Administrator" account and I have a script that contains WMIC command (wmic useraccount where "name='Administrator'" rename SysAdmin – for example). The issue with this is that the user profile folder remains "Administrator", it's not renamed to Sysadmin. I would like to avoid some extra steps (like logging in with another admin account, deleting the Administrator user profile and logging back with the Sysadmin… Read more »
Not that I know of, well, unless you completely change how MDT does it (not recommended).
Hey Johan, where is the script? I see it is greyed out on your website.
Sorry about that, post has been fixed now. / Johan