How to run VBScript as an administrator?

Using the RunAs command will prompt for a password.  I have implemented this by using PSExec from Microsoft, and passing the Administrator password to PSExec.  The major problem with this is I have had to use two script files. The first one that is run by the login script copies a second script file to the local PC (usually C:\Temp) and then the first script file invokes PSExec to run the second script file using wshShell.Run "\\server\share\psexec -u:" & strUser & " -p:"  & strPassword & " wscript.exe C:\Temp\2ndFile.vbs"

Now, the major problem with doing this, is you could have someone edit your script file and get your admin password.  That would be bad.  You should use the Microsoft Script Encoder to at least scramble the visible code in your script files.

Hope this helps.

Rob.

I appreciate the input, and I may be forced to use 2 script files as you mentioned Rob.  I guess there's no way to include in the original script code a way to run the rest of the script as the admin?

In a perfect world, I would like to run this completely as VBscript as my users do not use a traditional login script batch file.  Running it from a command prompt, while do-able is not good for practicality purposes as i have over 300 workstations in house.

You can still use VB script to initiate the process, and use a File System Object to copy the second script file without a command prompt
objFSO.CopyFile "\\server\share\2ndFile.vbs" "C:\Temp"
Then by using wshShell.Run as above, you can hide any user dialog by having a zero in the command.
wshShell.Run strCommand, 0, True
The zero means the command runs hidden, and the True waits for the Run command to finish before executing the next command.
This approach would hide any visible command prompt, which would be initiated by VBScript anyway.

Regards,

Rob.

Rob, I believe you created the miracle I have been looking for.  I was thrown this problem without any regard for the fact that I know next to nothing about VBScript.  But I believe this will do the trick.  Kudos to you and thank you for sticking with this problem!  Your help is greatly appreciated.  Bravo!

Thanks Mike, I was pretty happy with it when I got it working.  I'm a bit annoyed that I didn't think of it before, but a couple of heads are better than one!  You made me re-think it to better suit requirements, and I am now going to use it in all of my future scripts!

Rob.

Easier option:

You only need to run the vbscript as a Startup script in a group policy
Startup scripts get executed under the LocalSystem account which has admin rights by default.

I agree with SchalkVermeulen, but sometimes you need to run commands that are unique to that user (printer installation only for that user/group) that need to be elevated.

Yes, for user scripts (when user do not have admin rights) you need to do a few fancy things. The above scripting will work.

To do printer installations you might be looking into using "rundll32 printui.dll,PrintUIEntry"  This allows you to install printers via a startup script, as mentioned earlier, and making them visible/usable by any user using that a workstation. The user does not need to be an admin.

Perhaps off topic but related... Another tool is "Encrypted Runas"  Nice tool to run apps with alevated privilages and encrypt/hide password

I will look into that tool, that sounds awesome, because I was not a big fan of putting any passwords in a plain text file.

I do get the idea of running it at startup, but I would like printers to only map if the user needs them.  I have 20 sites that I manage, each with 3 printers, so that would be a HUGE amount of printers if all of them were installed!

Agree, If you have all the printers on a LAN it will not be a huge prob but as soon as they are placed accross WAN links you will experience a LOT of chatter relatting to printer polling,discoveries,etc. This is especially true if the printers get published in Active Directory.
We have bout 350 sites with at least 3 printers in each site. No DC at any site thus all chatter accross WAN links :-(

An idea: install all the printers of a site on all the machines BUT disable printer publishing to AD. Also remember to set printer prunning in AD. There is a tool in the Windows Resource Kit that the user can then use to set his default printer.

It wasn't so much chatter, as the user being overwhelmed by having 60+ printers to choose from when they log in.
All of the printers are local so they wouldn't be going across our MPLS for printing (now THAT would be painful!).

Fortunately all our sites look exactly the same so we could add all the printers as a once off and did not need to run a script at every logon.
If you have something like SMS/SCCM you can attempt the same.