How Can I Use the RunAs Command to Run a Script Under Alternate User Credentials?

How Can I Use the RunAs Command to Run a Script Under Alternate User Credentials?

  • Comments 10
  • Likes
Hey, Scripting Guy! Question

Hey, Scripting Guy! How can I use the RunAs command to run a script under alternate user credentials?

-- BE

SpacerHey, Scripting Guy! AnswerScript Center

Hey, BE. You know, in the business world one of the hot topics these days is synergy. For example, after The Mighty Ducks became a hit movie the Disney Company went out and bought themselves an NHL hockey team, renaming it the Anaheim Mighty Ducks. Coincidence? No, synergy, defined as “…the phenomenon in which two or more discrete influences or agents acting together create an effect greater than the sum of the effects each is able to create independently.” If there’s something more exciting than two or more discrete influences or agents acting together to create an effect greater than the sum of the effects each is able to create independently, well, we’d like to see it.

Synergy is important in the scripting world as well. For example, today we published the answer to a scripting puzzle that dealt with the issue of trying to run scripts under alternate credentials. In our answer we discussed the problems involved in getting WMI to run under alternate credentials when the script needs to run against the local computer. Our suggestion: read today’s Hey, Scripting Guy! column and learn how to run a script using the RunAs command.

Coincidence? No, laziness: we actually received this question several months ago, and we’re only just now getting around to answering it. But chalking this up to synergy sounded much better than chalking it up to lethargy!

As we noted in the weekly puzzle, you can use code similar to this snippet to run a script under alternate user credentials, provided that the script is running against a remote computer:

strComputer = "atl-fs-01"
strNamespace = "root\cimv2"
strUser = "kenmyer"
strPassword = "password"

Set objWbemLocator = CreateObject("WbemScripting.SWbemLocator")
Set objWMIService = objwbemLocator.ConnectServer _
    (strComputer, strNamespace, strUser, strPassword)

Unfortunately, though, this script will fail if you try to run it against the local computer. That’s because the ConnectServer method does not allow you to pass user credentials (like a user name and password) to the local machine. And, no, to be honest we’re not sure why it won’t let you pass user credentials to the local machine; it just won’t.

Note. Think of ConnectServer as being like a three-year-old child. Nobody knows why three-year-olds will eat only boxed macaroni-and-cheese; they just won’t eat anything else, period. And there’s not much you can do about that except try to live with the situation, whether that means making boxed macaroni-and-cheese for dinner every night, or not passing user credentials any time ConnectServer runs against the local computer.

So is this really a problem? Well, it can be. After all, Microsoft recommends that - for security reasons - you never log on to a computer using an Administrator account. Instead, we suggest that you log on using a regular old user account, then use a utility such as RunAs any time you need to run a program as an Administrator. And so, seeing as how everyone always does whatever Microsoft tells you to do, you type the following command at the command prompt and try using the RunAs utility to run the script C:\Scripts\Test.vbs:

runas /profile /user:fabrikam\kenmyer "C:\Scripts\Test.vbs"

And here’s what happens when you press ENTER:

Attempting to start C:\Scripts\Test.vbs as user "fabrikam\kenmyer" ...
RUNAS ERROR: Unable to run - C:\Scripts\Test.vbs
193: C:\Scripts\Test.vbs is not a valid Win32 application.

It’s at this point that people typically do one of two things: either they give up, or they start debugging the script, trying to figure out why their code isn’t valid. But here’s the deal: the error message says nothing about the script or the script code being invalid, it simply states that Test.vbs is not a valid Win32 application. That’s because RunAs is expecting to run an executable file. Test.vbs is obviously not an executable file, so the command fails. Most likely your code is just fine; the problem is that you’re trying to run a script rather than a .exe file.

So if RunAs accepts only executable files then obviously we can’t run a script using RunAs, right? Well, not necessarily. Although Test.vbs might not be an executable file, the two Windows script hosts - Cscript.exe and Wscript.exe - are executable files. The secret to running a script under RunAs is to call one of the two script hosts, passing along the name of the script as a command-line argument. For example, this RunAs command will fire up Cscript.exe and then run the script C:\Scripts\Test.vbs:

runas /profile /user:fabrikam\kenmyer "cscript.exe C:\Scripts\Test.vbs"

You can see how easy that is. You simply call the RunAs command along with the following parameters:

/profile, which causes the appropriate user profile to be loaded. This is optional, but makes it more likely RunAs will be able to do what it needs to do.

/user:fabrikam\kenmyer, which is the user account (in the form domain\user_name) under which the process is to run.

“cscript.exe C:\Scripts\Test\.vbs”, which is the process you want RunAs to execute. Note that the entire command must be enclosed in double quote marks, and should be typed the same way you would type the command from the command prompt.

That, by the way, is the second problem people encounter when trying to run a script under RunAs. As long as your scripts are in the folder C:\Scripts you won’t have any problems; that’s because C:\Scripts has no spaces in the path name. But suppose your scripts are in C:\Documents and Settings\kenmyer\Scripts. If you were at the command prompt and you wanted to run a script in this folder you would need to surround the path in double quotes; that’s because the path includes blank spaces. In other words:

cscript.exe "C:\Documents and Settings\kenmyer\Scripts\Test.vbs"

Logically enough, then, you might then expect the RunAs equivalent to look something like this:

runas /profile /user:fabrikam\kenmyer "cscript.exe "C:\Documents and Settings\kenmyer\Scripts\Test.vbs""

Unfortunately, that’s not the case: the double quotes nested inside double quotes simply causes RunAs to give up and display the usage screen. Tossing double quotes inside double quotes won’t work. Nor will it work to try double double quotes or triple double quotes or any other variation of quotes inside of quotes. Like a three-year-old child (or many thirty-three-year-old adults) RunAs wants things to be exactly right or it won’t even try to help you.

Fortunately, it’s fairly easy to make RunAs happy. All you need to do is use the \ character to “escape” any double quote marks that must to be embedded within the process path. This command will work:

runas /profile /user:fabrikam\kenmyer "cscript.exe \"C:\Documents and Settings\kenmyer\Scripts\test.vbs"\"

Notice how we put our path together. We start out with a double quote mark and then the name of the script host:

"cscript.exe

At this point we need to insert the path, which includes blank spaces (and thus needs to be surrounded by double quotes). To do that we simply put a \ immediately before the first double quote and another \ immediately after the second double quote:

"cscript.exe \"C:\Documents and Settings\kenmyer\Scripts\test.vbs"\

All we have to do then is tack on the ending double quote and we’re done:

"cscript.exe \"C:\Documents and Settings\kenmyer\Scripts\test.vbs"\"

It’s simple, but it works. Just remember to bracket long file paths and any other item requiring double quotes and you’ll be home free.

So there you have it, BE: you can now use the RunAs command to run a script. As we noted earlier, you might want to check out the weekly puzzle for more information on running scripts under alternate credentials. And, in the spirit of synergy, stay tuned: it’s just a matter of time before the Anaheim Mighty Scripters come to a hockey rink near you. (And, yes, this would be the time when the Scripting Guy who writes this column would usually note that hockey isn’t even a real sport. But he’s decided not to say anything controversial ever again, so you won’t hear a word from him about that.)


Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • I think the description you gave was for a 'synergism', rather than a 'synergy'. :)

  • Thanks a lot!!!!!

  • nice post, I'm facing the same problem but just a bit more evolved ^^

    what happen if i want to pass named arguments to the script like

    cscript.exe "C:\Documents and Settings\kenmyer\Scripts\test.vbs" /a:Charly /b:10.0.0.1

    I'm struggling with it for a while now

  • You Rocks!

  • How to solve cscript.exe is not a valid win32 application ?

  • If a script is being run with RunAs, is there anyway to find the userid that executed the runas?

  • does not work for me, getting no output from local or remote machines on an input list that bombs once it goes to remote machines when done without this BS.

  • You should note that this will not work as a unattended script for 99% of all cases as the runas command does not support passwords - so you either must use an account that has no password or let it prompt you, which means it cannot be part of any automation.

  • Mark, excellent point. I was disappointed not to see this fact mentioned, until I read your comment. What a horrible oversight to be (inadvertently) omitted.

    QUOTE:

    "You should note that this will not work as a unattended script ... as the runas command does not support passwords - so you either must use an account that has no password or let it prompt you, which means it cannot be part of any automation."

  • Thanks Scripting Guy!