We help IT Professionals succeed at work.

How to run VBScript as an administrator?

I'm a VBScript noob and could really use the collective's help.  I have a VBScript that I downloaded from this website that runs at user logon through Windows group policy.  Basically the script forces the user's computer to reregister itself with my Windows Software Update Server (WSUS).  Users do not have administrator rights on the local workstation.  What do I need to add to the script in order to have it run without admin rights?  Or is there something that can be added that will run the script as an administrator?  Here is the code:

Set oShell = CreateObject("WScript.Shell")

sRegKey = "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate"

' suppress error in case values does not exist
On Error Resume Next

' check for marker
sIDDeleted = oShell.RegRead( sRegKey & "\IDDeleted")

' to be sure values is only deleted once, test on marker
If sIDDeleted <> "yes" Then
' delete values
oShell.RegDelete sRegKey & "\AccountDomainSid"
oShell.RegDelete sRegKey & "\PingID"
oShell.RegDelete sRegKey & "\SusClientId"

' Stop and start the Automatic updates service
oShell.Run "%SystemRoot%\system32\net.exe stop wuauserv", 0, True
oShell.Run "%SystemRoot%\system32\net.exe start wuauserv", 0, True

' Run wuauclt.exe with resetauthorization
sCmd = "%SystemRoot%\system32\wuauclt.exe /resetauthorization /detectnow"
oShell.Run sCmd, 0, True

' create marker
oShell.RegWrite sRegKey & "\IDDeleted", "yes"
End If

Thanks for any and all help.  It is greatly appreciated!
Watch Question

Top Expert 2006

Run it from command prompt using RunAs

RunAs /user:YourDomain\Administrator CScript YourVbsFiel.vbs

It would ask for password and then execute the vbs as Administrator.
Most Valuable Expert 2012
Top Expert 2014

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.



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.
Most Valuable Expert 2012
Top Expert 2014

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.


Most Valuable Expert 2012
Top Expert 2014
With the help of another post, I have developed a self-calling VBS file, accepting a parameter that tells it if it is has been called using administrator credentials.
I have also figured out that by using PSExec to run either wscript.exe or cmd /c BEFORE the path to a script file, you can pass them both a UNC path, meaining you don't have to copy any files to the local PC.

My script uses this UNC approach to get the target PC to use wscript.exe and call the VBS file on a network share (the same that you run), but pass it a parameter.

So when you first run it, it has no arguments passed to it, so it asks you enter the name of a remote PC to run commands on.
Then the script runs PSExec against that computer, supplying Admin credentials.  The command that PSExec then runs (with Admin rights) is wscript to call the script again, this time passing an argument (parameter) of "AsAdmin" so the script knows it has admin rights.
Now the vbs script is running as Admin from the target pc, therefore, you can issue commands as if you were at the target pc.
Option Explicit

Dim strArgs, strAdminUser, strAdminPass
Dim objFSO, wshNetwork, strComputer, objShell, strCommand

Set objFSO = WScript.CreateObject("Scripting.FileSystemObject")
Set wshNetwork = WScript.CreateObject("WScript.Network")
Set objShell = WScript.CreateObject("WScript.Shell")

strAdminUser = "YourDomainAdminAccount"
strAdminPass = "YourDomainPassword"

If WScript.Arguments.Count < 1 Then
      Call Normal_User_Commands
ElseIf WScript.Arguments(0) = "AsAdmin" Then
      Call Admin_User_Commands
      MsgBox "Unknown Argument received"
End If

Sub Normal_User_Commands
      'MsgBox "Running as initiating user"
      strComputer = InputBox("Enter computer name to map a printer to:", "Enter Computer", "")
      strCommand = "cmd /c \\server\share\temp\test\psexec.exe \\" & strComputer & " -i -u " & strAdminUser & " -p " & strAdminPass & " wscript.exe \\server\share\temp\test\My_Self_Calling_VBS.vbs ""AsAdmin"""
      objShell.Run strCommand, 0, True
End Sub

Sub Admin_User_Commands
      'Now running as Administrator on the target macchine
      'MsgBox "Running as Admin"
      strCommand = "notepad.exe"
      objShell.Run strCommand, 0, True
End Sub


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!
Most Valuable Expert 2012
Top Expert 2014

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!

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.

I just realized how I can do this.

Create a script, and assign it to a GPO in their OU (I have each site have their own OU).  Then I can run it upon bootup.