Skip to content

May 24, 2011


OSD: “Run As” Caveats

When trying to run some customization scripts during an OSD Task Sequence, I found some issues when trying to use the Run As feature during a Run Command Line step.  In my case, I wanted to add the computer object that was being built in the Task Sequence to a custom group in Active Directory.

I found that my script (PowerShell based) ran perfectly when executed in a windows environment, but during the task sequence it would fail.  The root of the problem was that the Run As functionality affects the ability to access COM objects.  When using the Run As feature, I was unable to connect to and manipulate Active Directory.  I found that I had to run the script without the Run As option and embed the credentials in the script itself.  (I used some methods to encrypt the password, but that is really outside the scope of this blog post).  In my case, when using PowerShell, I used the Invoke-Command with the -Credential cmdlet.  The reason I used that cmdlet is because Start-Process and Start-Job can’t use the -Credential parameter when running as Local System (which is what the task sequence uses).

One thing to keep in mind when writing scripts to be used in OSD, if you need to elevate permissions, you may not be able to use the Run As option and may need to find an alternate way of elevating permissions.

7 Comments Post a comment
  1. BarryB
    May 31 2011

    Nice post, I been trying to figure this out for a couple of days! Think I chose the worst time ever to start using powershell for my OSD scripts 🙁

  2. Brent
    May 31 2011

    Yeah, it took me a while to figure out why it wasn’t working. I didn’t test it very extensively, but it appeared that vbs scripts experienced the same issue that my PowerShell scripts did when using the Run As; so I ended up sticking with Powershell. Hope you can get yours working! OSD is definitely not the easiest place to start messing with scripts, sometimes things just don’t work…

  3. BarryB
    Jun 1 2011

    I think I’m close, using Invoke-Command though it is not querying AD :/ and I know for sure the script is good! I used -ScriptBlock paramameter and hosting my code in there for now tried both [ADSI] and New-Object to connect to the object and they both work, just not in the script lol.

    Also do your workstations have WinRM enabled on them? Mine don’t just now but the script isn’t running on a machine with it enabled.


  4. Brent
    Jun 1 2011


    Yes, we have WimRM enabled, but it doesn’t run during OSD. Invoke-Command does require WimRM on the target machine.

    What I did was to actually use the command like this: Invoke-Command -FilePath “myscript.ps1” -ArgumentList MyParameter -ComputerName adserver -Credential $Credentials

    myscript.ps1 is the script that actually does all the work (except in my case populating $Credentials, that way all my objects get created on the remote machine. You should be able to use the -ScriptBlock parameter if you prefer and embed all your code there, if you wanted to keep it all in one file; I just haven’t tested it that way. I got my script working first on its own, this I worked on wrapping it in the Invoke-Command.

    Do you have PS Remoting setup and working on your target machine? Have you tested invoke-command with a simple command like ipconfig? Does it work if you run script manually without Invoke-Command on a regular machine?

  5. BarryB
    Jun 2 2011

    Thanks Brent,

    I did try the file method as well, I really need this to run within OSD phase however rather than outwith, it is to do AD related work as part of the OSD process, I have opened a case with MS as well as not being able to manipulate AD objects is really going to hinder the rebuild process.


  6. Travis
    Jul 24 2012

    I just spent days trying to figure this out and finally stumbled on your post. I’m surprised this isn’t well documented with a Microsoft KB or something. I’m using AutoIT scripts but ran into the same issues with COM objects. Most were giving me access denied.

    I’m wondering if this is related to DCOM/COM security in Win7? I noticed the other day that there are some permissions out there based on interactive login. Is the RunAs always non-interactive? Haven’t tested but perhaps tweaking permissions a little in dcomcnfg.exe may do the trick. Has anyone played around with it from that angle yet?

  7. Hermes
    Jul 26 2012

    For anyone that have still this problem:

    For the execution of task with alternate credential out of a process running in local system context is there no way out.
    But, if you need to do some Active Directory (ad) related tasks you can connect to ad with the alternate credential:

    $d = New-Object System.DirectoryServices.DirectoryEntry(“LDAP://$DomainName”, $User, $Password)

    After this you can do anything the user can do in ad.

    I hope this help.


Share your thoughts, post a comment.


Note: HTML is allowed. Your email address will never be published.

Subscribe to comments