Task Sequence – Run As

This page is to provide more information about the Run As feature that is available on several steps. Instead of adding this info to each step that has this ability, I’ve pulled it out.

The Run As feature gives you the ability to run the step as a specific user account. Since the task sequence is running as the local system account, it will not have permissions on any domain devices. If you’re planning to save logs, pull files from a share, or connect with most any network resource, you’d need credentials.

Potential Use Cases

• Connecting to network folders
  • Transferring Files or connecting to file like a database to read information.
• Making Active Directory Changes
  • Moving the machine to a differnet OU
  • Looking up Group Information
• Running ConfigMgr PowerShell Commands
  • Example Script on GitHub where I used a Task Sequence to update Packages. Full Blog Post

Common Issues

• Bad Username / Password
  • Error Codes: 2147943726 / 0x8007052e / -2147023570
    
• Not able to transfer files to network resource: I’ve run into issues when using RunAs on a PowerShell Script Step which was set to copy files to a network location. I added a “Connect to Network Folder” Step before the PowerShell Script Step, using the account information, which did successfully map a drive, then the PowerShell Step worked fine to transfer files using UNC Paths without using the Run As option.

Using Local Account

If you want to use a local account to run the step, you can do that. In the user name field use either of these options:

• %ComputerName%UserName
• .UserName
• Variable

Using Local Account – Demo

In this demo I create a local administrator, then use that account to run the actions. I then run 3 steps that create a registry key using a different method of calling the local account.

• Test 1: %ComputerName%UserName
• Test 2: .UserName
• Test 3: %Variable%
  • This is a variable that is created that shoves the domain and user into a single variable.

Test 1 Step

Test 1 Log

Note, this section above is the same for all 3 steps

Test 2
Test 2 Log

Test 3
Test 3 Log

Results

All successfully wrote their keys and values to the registry.

You can see from the logs how it captures the username used, but not the password. It will not let you hide the username, so take that into account if you’re ever worried about the SMSTS Log falling into the wrong hands.
Sometimes if you have a sensitive command line, you might want to hide the information from being shown, in which case you can have it hide the output from the command line itself by using the Task Sequence Variable OSDDoNotLogCommand

In this demo, I’m going to run the same thing, but set the OSDDoNotLogCommand variable.


There, you can see it completed the step successfully, but unlike the logs above, it did not show the command line that was running.

---

About Recast Software

1 in 3 organizations using Microsoft Configuration Manager rely on Right Click Tools to surface vulnerabilities and remediate quicker than ever before.

• Download Free Tools
• Request Pricing