WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

plus
plus
plus
plus
plus

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

Making Your WinBatch Script Run on Windows Vista and Newer

Keywords: UAC Manifest requestedExecutionLevel UiAccess Windows Vista Win7 Win8

These are a few things to keep in mind while developing and testing .WBT scripts and distributing your compiled WinBatch script on Systems with UAC enabled. This includes: Windows Vista, Windows 7 and Windows 8 ( and newer ).

We recommend getting up to speed on UAC and Manifests if you plan on doing scripting on UAC enabled (Vista and newer) systems. This article is intended as only a starting place. However this topic is much discussed in the Tech Database (UAC and manifest search terms) and on MSFT's web site.

For more about UAC: http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/UAC+UAC~Help.txt


Use of Application Manifests


An application manifest enables Windows to provide the behavior that the application (exe) expects based on the version of Windows that is targeted. This is especially important in regard to systems that have UAC enabled (which is enabled by default on most systems ).

In Windows Vista or newer, the Windows application manifest has been enhanced with attributes that allow developers to manifest their applications with a requested execution level. The available options are:

As Invoker The application runs with the same access token as the parent process. (Recommended for standard user applications)
Highest Available The application runs with the highest privileges the current user can obtain. (Recommended for mixed-mode applications)
Require Administrator The application runs only for administrators and requires that the application be launched with the full access token of an administrator. (Recommended for administrator only applications)
No Execution Level Information No requested execution level information in Windows application manifest.

WinBatch and WinBatch Studio

WinBatch needed some way for script developers to test and debug their interpreted .WBT scripts using different manifest settings. So since version 2007B, WinBatch includes many differently manifested versions of its WinBatch.exe and WinBatchStudio.exe. Specifically, WinBatch is shipped with 8 versions of WinBatch and WinBatch Studio with 7 different manifest combinations.

WinBatch Special Manifest versions

Tool Requested Execution Level uiAccess
WinBatch.exe highestAvailable true
WinBatch_AF.EXE requireAdministrator false
WinBatch_AT.EXE requireAdministrator true
WinBatch_HF.EXE highestAvailable false
WinBatch_HT.EXE highestAvailable true
WinBatch_IF.EXE asInvoker false
WinBatch_IT.EXE asInvoker true
WinBatch_NN.EXE Un-manifested Un-manifested
You can also give your WinBatch script a special file extension, and WinBatch will run the appropriately manifested version of WinBatch.

32-bit

File Extension Tool Requested Execution Level uiAccess
.WBT WinBatch.exe highestAvailable true
.WBT_AF WinBatch_AF.EXE requireAdministrator false
.WBT_AT WinBatch_AT.EXE requireAdministrator true
.WBT_HF WinBatch_HF.EXE highestAvailable false
.WBT_HT WinBatch_HT.EXE highestAvailable true
.WBT_IF WinBatch_IF.EXE asInvoker false
.WBT_IT WinBatch_IT.EXE asInvoker true
.WBT_NN WinBatch_NN.EXE Un-manifested Un-manifested

64-bit

File Extension Tool Requested Execution Level uiAccess
.WBT64 WinBatch.exe highestAvailable true
.WBT64_AF WinBatch_AF.EXE requireAdministrator false
.WBT64_AT WinBatch_AT.EXE requireAdministrator true
.WBT64_HF WinBatch_HF.EXE highestAvailable false
.WBT64_HT WinBatch_HT.EXE highestAvailable true
.WBT64_IF WinBatch_IF.EXE asInvoker false
.WBT64_IT WinBatch_IT.EXE asInvoker true
.WBT64_NN WinBatch_NN.EXE Un-manifested Un-manifested

WinBatch Studio Special Manifest versions

By default the WinBatch Studio.exe file provided with WinBatch has a manifest with the settings: 'Requested Execution Level: highestAvailable' and 'uiAccess Flag: True'. However, if you are trying to develop and debug scripts with UAC on you might be prompted each time your script attempts an operation that requires a higher execution level. Therefore, we have made available various WinBatch Studio EXEs with all the possible manifest setting combinations.
Tool Requested Execution Level uiAccess
WinBatch Studio.exe highestAvailable true
WBStudio_AF.EXE requireAdministrator false
WBStudio_AT.EXE requireAdministrator true
WBStudio_HF.EXE highestAvailable false
WBStudio_HT.EXE highestAvailable true
WBStudio_IF.EXE asInvoker false
WBStudio_IT.EXE asInvoker true
WBStudio_NN.EXE NA NA
By default the WinBatch.exe and WinBatchStudio.exe are manifested using requestedExecutionLevel=Highest Available and UIAccess=TRUE. Most scripts will never need UI Access set to TRUE, however some of the functions in WinBatch do require UIAccess=TRUE ( specifically the Control Manager extender Functions ). So the default tools, are manifested to give WinBatch script developers the highest privileges the current user can obtain, so that they have access to all of WinBatches functionality.

For example, if you happen to be logged in as an administrator, by default you only have standard user access. That is until you attempt to do an administrative operation. At which time Windows will prompt for consent to elevate to full administrative privileges. However if your script is manifested using Highest Available, the script will run with the full administraive privileges. However there is a catch when it comes to mapped drives. if the user ( in this case an administrator ) maps a drive under the standard users token then a script running with highest available will not see those mapped drives. For more info on this subject please see: http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/UAC+Mapped~Drives~Issue~with~UAC.txt

Even though WinBatch is manifested to give the highest privileges it is important to know that when developing your script, you should keep in mind that unless an application is designed to be run exclusively by system administrators, it should be run with the least privileges. For most scripts this means using the manifest settings: requestedExecutionLevel=As Invoker and UIAccess=FALSE.

Compiler

Once you have run and debugged your script and you decide it is time to compile, the WinBatch Compiler offers the ability to define which manifest settings you would like your EXE to use. Keep in mind that all EXE should be run with the least privileges necessary. The SETTINGS button in the WinBatch+Compiler can be used to specify the appropriate options.

Digitally Signing Your Compiled Exes


Digitally signing an executable requires a digital certificate from a trusted certificate authority, such as VeriSign or Thawte. The code signing certificates from these authorities allow you to sign your executable files to guarantee to your end users that the files have not changed since the time you compiled them. Windows also displays the publisher name on the UAC elevation dialogs, so it reassures your end users that the program they're about to run really did come from you.

By Default all tools distributed with WinBatch are code signed. However if you plan on creating your own compiled EXE using the WinBatch+Compiler then you need to consider digitally code signing your compiled EXEs.

For example, if you try to run an unsigned application (in Vista or newer) that requires elevation, but you have the "User Account Control: Only elevate executables that are signed and validated" policy enabled you will get the error 'A Referral was Returned From the Server'. Administrators will enable this policy in domain environments if they really want to control which applications users run with administrative privileges. If the application is a compiled WinBatch script, then you will need to contact your IT department/developer to get it signed. If you've been tweaking the Group Policy settings in your domain, go ahead and disable this policy if you want to run the tool.

For more on this subject please see: http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/64-bit+Code~Signing~an~EXE.txt


Modify Where Scripts Store User Data


Old Windows programs wrote configuration data into files in the application's installation directory, usually under the Program Files folder. Beginning with Windows Vista, most users should be running with "standard user" privileges, and these privileges don't allow them to write to the Program Files folder. That means that any programs they run should be writing configuration data and other settings to an appropriate application data directory. The table below shows some of the common data locations.

Common Data Locations on Windows

This directory paths can be obtainsed using the ShortCutDir function in WinBatch.
Directory Property Type of Data and Example
AppDataFolder Per-user, roaming application data C:\Users\username\AppData\Roaming\
CommonAppDataFolder Per-machine application data C:\ProgramData\
LocalAppDataFolder Per-user, non-roaming application data C:\Users\username\AppData\Local
PersonalFolder User-specific documents C:\Users\username\Documents\

You will need to change your script to use these directories to store any application data. If you use the registry, make sure that the script treats HKEY_LOCAL_MACHINE and HKEY_CLASSES_ROOT as read-only registry hives. All user-specific registry data should be stored in HKEY_CURRENT_USER.

In our expereience most users run in a locked-down desktop environment, which means that most users will not be able to run applications with administrator privileges. This means you should design your script to run using standard user privileges. This can be accomplished using proper coding or by repackaging the script with a setup that grants permissions to the appropriate files, folders and registry keys. Is is important that you make your script work well in Windows (Vista and newer) right from the start.


Article ID:   W17507
Filename:   Making Your WinBatch Script Run on Windows Vista and Newer.txt
File Created: 2013:07:26:11:41:19
Last Updated: 2014:08:13:06:28:57