I have an HTA file with a VBScript embedded in it. From the VBScript, I need to call a command prompt command (powercfg /energy) that requires elevated permissions. The command will be called more than once a minute, so I can't have the user dealing with UAC prompts every time I need to run the command.
When I use the line Shell.Run "cmd /k powercfg /energy", 1 in the script, the command fails because elevated permissions are not given. When I try doing ShellApp.ShellExecute "cmd", "/k powercfg /energy", "", "runas", 1, which runs the command with elevated permissions, it opens up a UAC prompt with "yes" and "no" buttons. (This is running on Windows 10 Education Edition).
Obviously I can't have UAC prompts bothering the user multiple times a minute, so I tried implementing the following subroutine in the VBScript to re-run the HTA file in elevated mode from the beginning (it was running with basic permissions before) if it is not already elevated:
Sub ensureAdmin()
is_admin = isAdmin() ' function that checks for admin permissions in current window
If is_admin = False Then
ShellApp.ShellExecute "mshta", "C:\%userprofile%\desktop\gPowerMeter.hta", "", "runas", 1
Window.Close
End If
End Sub
I know that this code successfully relaunches the HTA file with elevated permissions because it pops a UAC prompt with "yes" and "no" buttons.
The problem is, adding this subroutine doesn't seem to affect the ability of the script to run elevated console commands. I get the same results with the two lines that I tried earlier when the HTA was running with basic permissions.
Does anyone have any suggestions on how to run the HTA and all scripts coming from it in elevated mode? I could implement a workaround, but it would be less elegant. Thank you.
NOTE: I'm not having problems getting the HTA to run elevated. I just want all commands executed from that HTA file through the VBScript ".Run('')" command to be elevated.
Unfortunately, what you are trying to do just isn't possible within the constraints of the technologies you are using.
Elevating the MSHTA process does not affect the elevation of the executed shell process you wish to run from it. The best you can hope for is elevating the individual shell process via the runas command. However, as you have already pointed out, this will trigger a UAC (User Account Control) prompt.
The best advice would be to build the processes using a fully-fledged programming language that allows you more control over the elevation of processes via UAC programmatically over using an HTA.
Useful Links
MSDN - Create and Embed an Application Manifest (UAC)
Related
So here's the case.
I'm in an a domain environment (Windows 7) where users are stripped from local administrator group. I created a batch file to install a program and it requires administrator privilege. After installation I want the program to be pinned to the current user start menu. The way I pinned it is by calling a powershell script from inside the batch file to do that.
So I can elevate the batch file to have admin privilege, but the problem is the program will not be pinned to the current user, and instead it is pinned for the admin user that I'm using to elevate the batch file. I'm guessing that this is because the powershell script was called from inside an elevated batch file, so it is also elevated.
Is there any way for me to achieve what I want without splitting the script?
I think that your problem is not about privileges or user.
You are probably editing the wrong environement to pin your program.
You should copy (or create) your shortcut in :
C:\Users\%USER%\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar
I am trying to automate a VBScript by using Windows Task Scheduler. However, I tried to use cscript.exe + "C:\...\script.vbs" but it didn't run. I also tried to directly run the same command in CMD (cscript.exe "C:\...\script.vbs") and it worked.
What might be the problem?
EDIT :
I just tried to switch the setting to "Run only when user is logged on" from "Run whether user is logged on or not" and it worked. I am wondering if there is a way to make my task scheduled run even when the user is logged off.
After hours of research, one of Blake Morrison (from Microsoft)'s blogs came up; it mentioned that
If running a .vbs / .ps1 script, try launching it from a .cmd / .bat script
see Help! My Scheduled Task does not run…
That blog also explains a lot of rules/tips when using Task Scheduler.
So please create a .cmd/.bat file that calls for your VBScript. For example: cscript.exe YourScript.vbs would be in your .cmd/.bat script.
Write a batch file like this:
echo "Started!" > c:\foldergoeshere\log.txt
cscript.exe "C:\...\script.vbs" > c:\foldergoeshere\log.txt
echo "Stopped!" > c:\foldergoeshere\log.txt
Then schedule the batch file instead of the vbs. That will allow you to see what is happening that is preventing it from running. Any error that you would have seen executing in the console (CMD), will be instead output to that log file between "Started!" and "Stopped!"
What's the hassle all about? I don't use .cmd/.bat and script works! (Windows7 here)
My VBS script (as a scheduled task) runs well on any scenario of these 4:
cscript and option "Run only when user is logged on"
cscript and option "Run whether user is logged on or not"
wscript and option "Run only when user is logged on"
wscript and option "Run whether user is logged on or not"
It's only that on the 1st scenario I encounter the black command window flashing on my screen.
Action settings:
or
My script, which simply creates a file:
Set objFSO = CreateObject("Scripting.FileSystemObject")
filename = "C:\Temp\" & Hour(Time) & Minute(Time) & Second(Time)
Set objFile = objFSO.CreateTextFile(filename)
Greg answered this https://superuser.com/a/816073
Basically you need to create 2 folders:
You have to create a folder (or two on a 64bit-windows):
(32Bit, always) C:\Windows\System32\config\systemprofile\Desktop
(64Bit) C:\Windows\SysWOW64\config\systemprofile\Desktop
Fixed the issue for me (and I could point to the .vbs file, not bat needed).
The .vbs file is running invisibly, which is a consequence of running it with the 'logged on or not' option.
You will not be allowed to interfere with a user using the computer, which means you will be able to help yourself, but not others.
Please read the following text from the Task Scheduler Help menu:
Task Security Context
You can specify that a task should run even if the account under which the task is scheduled to run is not logged on when the task is triggered.
To do this, select the radio button labeled Run whether user is logged on or not.
If this radio button is selected, tasks will not run interactively.
To make a task run interactively, select the Run only when user is logged on radio button.
You can do this.
cmd as the Program.
/c start cscript //nologo "W:\Pathto with spaces\VBScript.vbs"
/c send the following to the cmd
start starts the next parameter
cscript //nologo "W:\Path with spaces\VBScript.vbs" self explanatory. Path wrapped in quotes to allow spaces in the filename.
Screenshot
Have experienced more than once that a VBScript running as planned task worked fine for months and years but suddenly would not work any more despite nothing was changed. Have tried to reactive the task using all the recipes given here and elsewhere, but no success. My workaround was to create a new planned task with all settings copied from the original one.
I tried this on Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
AKA Window 7, But in my case i first cd to the dir and then ran the .bat file to execute the .vbs file
Go to start menu
Search for run
Once it opens, Type "shell:startup" and press Enter
You'll be directed to the Start Up folder. In this folder you can put create a .bat file which you want to execute the .vbs file (You'll do this in a special way)
cd C:\the\path\were.vbs\file\located && wscript.exe start_app.vbs
What your doing is cd to the directory cd C:\the\path\were.vbs\file\located
And then run the .vbs file wscript.exe start_app.vbs
How do I start/call a batch file from another, but with administrative privileges, so that it doesn't give me errors like the following?
Access is denied error code 5
Here is something like what I would like it to be.
echo PLEASE TYPE YOUR USERNAME AND PASSWORD IN THE FIELDS BELOW.
echo.
echo.
echo.
echo.
set /p u=Username:
echo.
set /p p=Password:
start next.bat %u% %p%
No matter which way you chose, You must accept run it with admin privilege, so the point is which way is shorter? You could Right Click > Run as administrator as jean-Michael said although I prefer james approach (using vbScript) but if you don't want to use another vbScript file and just want benefit of just click on batch file and accept run with admin privilege (Note you have one right click and left click less) I suggest you this:
create a shortcut from your batch file and right click on shortcut > Properties > Shortcut Tab > Advanced now check the Run as administrator check-box. every time you execute it from the shortcut you just have one click to accept run it with admin privilege.
Hope this help.
Sometimes third party utilities like AutoIt (see runas function) are not an option - but if you do have that option, check it out as that will let you do exactly what you're aiming to. You can then call the AutoIt script from your script and use its runas function.
Windows runas doesn't support providing a password unless you're happy with the /savecred option - which is fine if you're only running the task from a single computer. The first time it will ask you for a password, but after that it won't (though you still have to use /savecred option each time you use it). I've got a feeling using this could be a huge security hole. But since it seems this is for your own machine, in your batch use this:
runas /user:computername\username /savecred yourcommand.exe
Another way is to make a scheduled task that can be called by your script. You can make it using the GUI or from an elevated command line as described here.
You can then call it from your script like this:
SCHTASKS /Run /TN yourtaskname
Simply put the bat file into the Windows directory, and it will run as administrator. I tried this myself, and it worked:
C:\Windows\batch_file.bat
It should work like that.
Within the batch file itself there is no way to run as an administrator, however if you launch the batch file from within a .VBS file, you are able to specify a 'runas' parameter.
set shell=CreateObject("Shell.Application")
shell.ShellExecute "your_batch_file.bat",,"C:\path\to\thedirectory", "runas", 0
set shell=nothing
This will launch your batch file as an administrator, and you can enable or disable the shell display (this example hides it as i wanted my program to run in the background without being seen).
Right click -> Run as administrator.
I think microsoft made as much as they could to prevent batch script to get administrative privileges on their own.
#cmd, I posted an example (How can I test effective permissions of a user from a batch script?) to run another bat file with ShellExecute and elevated rights (only when it's needed).
Take a look if it's what you looking for and what you need. If not, let me know and we could adapt your script to make it work.
good luck
I actually joined just to answer this, the simplest way by far is to create a shortcut to the program you want to run, then set the shortcut to run as administrator and just call the shortcut from the batch file. This will run with the settings specified in the shortcut and you could place this shortcut in the same folder as your batch file or just call it from the start menu.
Example:
"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Folder\Shortcut Name.lnk"
I have written a batch file which will call another batch file and delete some files. For this I need to have admin rights. I tried following command...
runas /user:bala#nsc cmd
Enter the password for bala#nsc: xxxxxxx
Even though bala#nsc has admin rights command prompt is getting opened as a simple user rather than administrator.
I guess, I am missing something. Please help me.
Your results aren't what I expected, either. But I've got a few workarounds to suggest.
You could turn off User Account Control.
You could go to Start --> All Programs --> Accessories, then right-click on "Command Prompt" and choose "Run as Administrator."
You could right-click on your batch script and do the same.
You could create a shortcut to either cmd or your batch script on your Desktop, then modify the properties of that shortcut to run as Administrator.
You could add some code to your batch script to check for admin privileges and prompt for escalation if needed.
Turning off UAC would be my choice.
I've created a simple batch file that kicks off my *.msi installer within our company, creating a log file of the process, then displays the log file after the installer has completed.
installAndLog.bat:
msiexec.exe /i "\\FileServer2\setup.msi" /l*v "C:\setupLog.txt"
"C:\setupLog.txt"
It works, but there are two (2) glitches that annoy me:
The black console box shows in the background the whole time the installer is running and the log file is being displayed. Q1: How do I hide that?
and
The console box will not close until the log file is no longer being viewed (i.e. notepad.exe is closed). Q2: Can I call the text file in a new process and simply exit?
I was a DOS lover back in the day, but that was too many years ago.
I don't think you can hide the console window when running a batch file. However you can use vbscript instead which will by default not create a console window.
Take the below and put it in a file with a .vbs extension:
Dim wshShell
Set wshShell = CreateObject("WScript.Shell")
wshShell.Run "msiexec.exe /i ""\\FileServer2\setup.msi"" /l*v ""C:\setupLog.txt""", 1, true
wshShell.Run "C:\setupLog.txt"
All the double double quotes are there because the entire command must be surrounded by "'s and doubling them escapes them. The the documentation for WshShell.Run for more info.
Q1 - AFAIK you can't really hide the console window.
Q2 - Use the start command. This will launch the specified program (notepad) outside of the shell. It will also prevent the shell from waiting until the application closes to continue processing the batch script.
You might be better off changing the batch script to launch the MSI installer using the start command and having the installer launch notepad to view the log file once installation is complete.
If you really want to get these batch windows away, you'll have to switch over to something else. One simple alternative could be one of the scripting languages supported by the windows scripting host.
Or you try HTA (HTML applications) see here and here.
Run the dos script as a different user by scheduled task or as a service.