Script Elevation PowerToys for Windows Vista

Script Elevation PowerToys for Windows Vista


Download the code for this article: Utility2007_06.exe (159KB)


Among the many features Windows Vista introduced to address security concerns, User Account Control (UAC) is one of the most significant. With User Account Control, even users who are administrators run most applications with standard privilege, but have "elevation potential" for specific administrative tasks and
application functions. After using Windows Vista™ for many months, elevating a task or application as necessary has become second nature. However, I also encountered a number of shortcomings when trying to elevate some types of tasks in Windows Vista, and that became frustrating.
So in the spirit of the old Windows® PowerToys, I’ve created a few Script Elevation PowerToys to overcome these limitations. You can find all of the PowerToys I’m about to discuss in the code download at technetmagazine .com/code07.aspx. And you can read about how UAC works in the November 2006 article "Achieve the Non-Admin Dream with User Account Control" by Alex Heaton (see the "Additional Resources" sidebar).

Elevate Command PowerToy

The first annoyance was that there was no method to elevate an application from the command line or from the Run dialog box. So after asking around within Microsoft, I came across a sample script from John Stephens (a Software Design Engineer at Microsoft) that provided the information I needed. It turns out that if you pass the verb "runas" to either the ShellExecute API or to its COM equivalent, the ShellExecute method of Shell.Application, the application launched will prompt for elevation (see the sidebar for details). This allowed me to create the first Elevation PowerToy—the Elevate Command PowerToy.
This tool (which consists of the files ElevateCommand.inf, elevate.cmd, and elevate.vbs) adds an elevate command to your system. This lets you launch applications that prompt for elevation from the command line, a script, or the Run dialog. For example, the following command opens Win.ini with Notepad (after prompting for elevation):

elevate notepad c:\Windows\Win.ini
When using the elevate command with Windows Script Host (WSH), Windows PowerShell™ or other scripts, you need to specify the script host executable (such as wscript, cscript, or powershell) as the application. To run a vbs, for example, you’d use this:

elevate wscript “C:\windows\system32\slmgr.vbs” –dli
The help text explains this. Use elevate with -? or with no parameters to see the help text.

Run as Administrator for Scripts

The next irritant was that there was no "Run as Administrator" context menu option (when you right-click on the file in Explorer) for most Windows script types. The one exception was for command-shell scripts (those with .bat and .cmd file extensions). So I set out to investigate this. Many of the context menu options for file types are controlled through command keys for the "object" type in the HKEY_CLASSES_ROOT section of the Registry (see Verbs and File Associations in the sidebar for details). It turns out that if that command key is named runas, the command invoked will prompt for elevation. This allowed me to create the following PowerToys:

• Elevate HTML Application PowerToy (ElevateHTA.inf)
• Elevate Windows PowerShell Script PowerToy (ElevatePowerShellScript.inf)
• Elevate WSH Script PowerToy (ElevateWSHScript.inf, elevate.cmd, elevate.vbs)

These PowerToys add a Run as Administrator Explorer context menu entry (as shown in Figure 1) for HTAs, Windows PowerShell, and Windows Script Host file types respectively. ElevateWSHScript.inf also adds a Run as Administrator with Command Prompt menu entry. (Please read the note in ElevatePowerShellScript.inf before installing it.)

Figure 1 Run as Administrator context menu options

Figure 1 Run as Administrator context menu options


Elevating Other Files Types

The runas command technique can be applied to just about any file type. For example, the Windows Installer in Windows Vista was designed to "do the right thing" when elevation was required for installing a package. However, some poorly authored packages (where, for example, custom actions are not marked appropriately) will not install correctly with UAC turned on unless they are installed using msiexec.exe from an elevated command prompt.
To allow this to be done directly from Explorer, I created ElevateMSI.inf. This tool clones the default actions for Windows Installer packages (.msi) and patches (.msp) to add an Install as Administrator context menu option for packages and Apply Patch as Administrator for patches.

CMD and PowerShell Prompt Here as Administrator

One of the most popular Windows PowerToys is the venerable Command (or CMD) Prompt Here. With this PowerToy installed, you can right-click on a folder or drive in Windows Explorer and select CMD Prompt Here from the context menu. This opens a command prompt with the selected folder as the current directory.
Because this is so handy, I use this PowerToy many times a day. As I was trying to learn and use Windows PowerShell, I found myself wishing for the same functionality. So I created the PowerShell Prompt Here PowerToy (see "An Old PowerToy Is New Again" in the sidebar).
But even that was not quite sufficient: many times I wanted that shell prompt to be open with elevated privileges. This led to the final two PowerToys: "CMD Prompt Here as Administrator" (CmdHereAsAdmin.inf) and "PowerShell Prompt Here as Administrator" (PowerShellHereAsAdmin.inf, elevate.cmd, elevate .vbs) as shown in Figure 2. Both PowerToys work the same way as their non-elevated counterparts (which are included in the code download for your convenience).

Figure 2 Prompts with elevated privilege (Click the image for a smaller view)

Figure 2 Prompts with elevated privilege (Click the image for a larger view)

Installation and Implementation

To install these PowerToys, right-click on an INF file, select Install, and approve the elevation. To uninstall, use the Programs and Features selection on the Control Panel.
In case you dig into the INF files and wonder why three PowerToys install elevate.cmd and elevate.vbs into different locations, I’ll explain. Most of the PowerToys are implemented by adding a runas subkey to HKEY_CLASSES_ROOT\objecttype\Shell key for the object type in the Registry.
However, for some PowerToys there were object types I wanted to have two context menu entries cause elevation ("CMD Prompt Here as Administrator" and "PowerShell Prompt Here as Administrator" for Drive and Directory object types; "Run as Administrator" and "Run as Administrator with Command Prompt" for all WSH object types.) Since there can only be one runas key for each object type, I had to implement the second action by calling the elevate command. But since I wanted each INF to be installable and uninstallable independently, I had to put the associated copies elevate.cmd and elevate.vbs in different places. (You can’t increment file usage counters from a raw INF file. Yes, MSI installers would be better, but I wanted installers that could be created and modified with a text editor.) One side effect of this is that only the context menu entries implemented using the runas key will display a shield in the menu.

Summary

I hope you find these tools useful and that they improve your experience with UAC. Perhaps they will inspire you to create PowerToys of your own. (For those who use other scripting languages like Perl or Python on Windows Vista, it should be easy to create an "Elevate Script" PowerToy for those languages as well.) As with all PowerToys, these are unsupported, "use at your own risk" tools. In any event, have fun elevating!

Click to expand...