Elevation PowerToys for Windows

  • PowerShell Script to Create a Sysinternals Suite INF File Installer

    In my February 26, 2010 post I provided an updated INF file to install the Sysinternals Suite.  I also mentioned that I would try to update this more frequently in the future as the content of the Sysinternals Suite changes.  Well my free time being what it is, I have not had a chance to do that yet.  So instead I took to heart a comment left by Chris Sagovac that I make a script to create the INF file.

    The PowerShell script (New-SysinternalsSuiteInstaller.ps1) attached below does the following:

    • Downloads the Sysinternals Suite web page and parses out the Updated date.
    • Creates a subfolder below the script folder named with the Updated date.
    • Creates an Extracted folder under the date folder.
    • Downloads the Sysinternals Suite Zip file in the date folder.
    • Extracts the contents of the Zip file to the Extracted folder.
    • Generates Install_SysinternalsSuite.inf in the Extracted folder.

    The INF file has entries to create Start Menu shortcuts for the graphical programs and help files.  You can change the list of programs and help files that will have shortcuts by changing the entries in the $hashStartMenuPrograms and $hashStartMenuHelp hashtable variables in New-SysinternalsSuiteInstaller.ps1.

     

    - Michael Murgolo, Senior Consultant, Microsoft Services, U.S. East Region.

    Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

  • Creating a Self-Elevating Script

    The question recently came up on during an internal discussion about how to quickly (“one double-click”) elevate a script on a machine with UAC enabled without installing anything or manually configuring a shortcut to “Run as administrator”.  So to answer this question I decided to share my “self-elevating” CMD script.  This script relies on the same technique as my previous post on my updated version of Launchapp.wsf.  It uses the method of detecting whether the script is running elevated from John Howard’s blog (http://blogs.technet.com/jhoward/archive/2008/11/19/how-to-detect-uac-elevation-from-vbscript.aspx), translated to CMD script.  The following script will “re-launch itself” elevated if it is not already running elevated.  This version (RelaunchElevated.cmd in the download below) requires that either that the Elevate Command PowerToy from here is installed or that elevate.cmd and elevate.vbs from the same download are in the same folder with the script or in the Windows search path.

    @echo off
    setlocal enabledelayedexpansion

    set CmdDir=%~dp0
    set CmdDir=%CmdDir:~0,-1%

    :: Check for Mandatory Label\High Mandatory Level
    whoami /groups | find "S-1-16-12288" > nul
    if "%errorlevel%"=="0" (
        echo Running as elevated user.  Continuing script.
    ) else (
        echo Not running as elevated user.
        echo Relaunching Elevated: "%~dpnx0" %*

        if exist "%CmdDir%\elevate.cmd" (
            set ELEVATE_COMMAND="%CmdDir%\elevate.cmd"
        ) else (
            set ELEVATE_COMMAND=elevate.cmd
        )

        set CARET=^^
        !ELEVATE_COMMAND! cmd /k cd /d "%~dp0" !CARET!^& call "%~dpnx0" %*
        goto :EOF
    )

    :: Continue script here

    echo Arguments passed: %*

    This script looks for the System Manadatory Label in the output of whoami /groups.  If it is not found, the script uses the elevate command to launch a new instance of cmd.exe, changes the directory to the script directory, and re-launches itself with the same arguments.

    In order the make the script even more self contained (i.e. requiring no additional files) I created another version of this script (RelaunchElevated_EmbeddedScripts.cmd in the download below) that creates elevate.cmd and elevate.vbs in %Temp% on the fly when it is run, uses them from there, and then deletes them after they are used.

     

    - Michael Murgolo, Senior Consultant, Microsoft Services, U.S. East Region.

    Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

  • UAC, Logon Scripts, and the Launchapp.wsf workaround

    When UAC is enabled on Windows Vista and higher, logon scripts that map network drives do not appear to work for users who are administrators on their computer.  This is described in the Group Policy Scripts can fail due to User Account Control section of this TechNet article:

    Deploying Group Policy Using Windows Vista
    http://technet.microsoft.com/en-us/library/cc766208(WS.10).aspx

    This happens because logon scripts run with an administrative user’s full token.  The desktop then loads with the user’s limited token.  The split token sessions do not share the view of network resources, so the mapped drives are not visible when the desktop loads.  The workaround in the article above involves using a wrapper script, Launchapp.wsf, as the logon script.  This deletes and recreates a scheduled task to launch the real logon script when the scheduled task is created.  (The schedule trigger is whenever the scheduled task is created or changed.)  This scheduled task is set to run as the logged on user and will launch in the limited token session.  This will allow the drives to be visible to the user in the limited token session.

    Unfortunately, an recent customer case pointed out an issue with using Launchapp.wsf.  Launching a logon script in this way can cause the logon script to fail on shared computers, especially on machines where users who are administrators share the machine with users who are standard users.  After an administrative user logs on and off, standard users will not have the permissions necessary to delete the schedule task and the script will fail.

    To work around this issue, I have created a new version of Launchapp.wsf (attached below).  I took the existing version of Launchapp.wsf and combined it with code from John Howard’s blog (http://blogs.technet.com/jhoward/archive/2008/11/19/how-to-detect-uac-elevation-from-vbscript.aspx).  If this version of Launchapp.wsf detects it is running elevated, it deletes/creates the scheduled task as the original did.  If it is not running elevated, it simply launches the app or script passed on the command line directly.

    - Michael Murgolo, Senior Consultant, Microsoft Services, U.S. East Region.

    Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

  • Scripting PowerToys for Windows 64-bit

    Moving to a 64-bit version of Windows allows Windows and 64-bit applications to take advantage of greater than 4 gigabytes of physical memory.  64-bit Windows also includes an x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows.

    However, running 64-bit Windows has implications when running some scripts.  Because the default scripting environments on 64-bit Windows (CMD shell, Windows Script Host, and Windows PowerShell) are themselves 64-bit, scripts that need to interact with 32-bit software or COM components can experience issues when run with the default scripting environments.

    For example, the sample VBScript below lists all the actions that can be executed with the System Center Configuration Manager 2007 Client software.

    Set oCPAppletMgr = CreateObject("CPApplet.CPAppletMgr")
    Set oClientActions = oCPAppletMgr.GetClientActions()

    For Each oClientAction In oClientActions
        WScript.Echo oClientAction.Name
    Next

    However, because the ConfigMgr 2007 client software is still only 32-bit even when installed on 64-bit Windows, running the script above fails.  This happens because the 64-bit Windows Script Host (cscript.exe/wscript.exe) cannot load the 32-bit CPApplet.CPAppletMgr COM object.

    image

    To run this successfully requires using the 32-bit Windows Script Host.  One way to do this is to start a 32-bit CMD shell (C:\Windows\SysWOW64\cmd.exe) and then run the script using cscript.exe.  This will run the 32-bit version of cscript.exe and the script will run successfully.

    image

    So in order to make is simpler to create and run scripts using the 32-bit scripting environments on 64-bit Windows, I’ve developed a few PowerToys.  CMD Prompt Here 32-bit and PowerShell Prompt Here 32-bit (and their “as Administrator” counterparts) can be used to right click on a drive or folder in Explorer and start the 32-bit version at that location.  These are installed using the INF files CmdHere32bit.inf, CmdHereAsAdmin32bit, PowerShellHere32bit.inf, and PowerShellHereAsAdmin32bit.inf.

    Explore as 32-bit and Explore as Administrator 32-bit work similarly to the Explore as Administrator PowerToy from my 20-Nov-2009 post.  It requires installing a third party 32-bit file manager program.  For this example I again use Explorer++ (http://explorerplusplus.com/).  I have provided in the attachment an INF file, Explorer++_WOW64.inf, that will install the 32-bit version of Explorer++ into \Program Files (x86)\Explorer++.  If you would like to try these PowerToys with Explorer++, place Explorer++_WOW64.inf into the folder with the 32-bit Explorer++ extracted files.  Then right click on Explorer++_WOW64.inf and select Install.  This will install Explorer++ into a \Program Files (x86)\Explorer++ folder and add an Explorer++ 32-bit program group to the Start Menu.

    If you would like to use this PowerToy with another 32-bit file management program, simply install that program and find the full path to the executable file. Then edit ExploreAs32bit.inf and ExploreAsAdmin32bit.inf and replace both instances of the following path with the path to the desired executable:

    %ProgramFiles(x86)%\Explorer++\Explorer++.exe

    Then install the modifed INF Files.

    For more information on running 32-bit applications and scripts on 64-bit Windows, read the following MSDN articles.

    Running 32-bit Applications
    http://msdn.microsoft.com/en-us/library/aa384249(v=VS.85).aspx

    Requesting WMI Data on a 64-bit Platform
    http://msdn.microsoft.com/en-us/library/aa393067(VS.85).aspx

    Important Note: For these PowerToys to work, the Elevate Command PowerToy from here must also be installed.

    - Michael Murgolo, Senior Consultant, Microsoft Services, U.S. East Region.

    Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

  • Updated Sysinternals Suite Installer

    In my June 2008 TechNet Magazine article I provided an INF file for installing the Sysinternals Suite, which is used by the CMD and PowerShell Prompt Here as System PowerToys.  It installs the Suite into the Program Files\Sysinternals Suite folder, creates Start Menu shortcuts for the Suite's graphical tools/help files and registers the ShellRunas tool.  It also adds an entry into Add/Remove Programs so that the Suite can be uninstalled.

    image

    I recently had the need to reinstall the Sysinternals Suite on my computer.  However, I realized that I needed to update the installer due to changes in the mix of tools included in the Suite.  I’ve posted the updated Install_SysinternalsSuite.inf file in the attached Zip file.  Follow the instructions in the June 2008 TechNet Magazine article for using it.

    I will try to update this more frequently in the future as the content of the Sysinternals Suite changes.

     

    - Michael Murgolo, Senior Consultant, Microsoft Services, U.S. East Region.

    Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

  • Elevation PowerToys for the Windows PowerShell Integrated Scripting Environment (ISE)

    Windows PowerShell 2.0 includes an Integrated Scripting Environment (ISE).  This application enables you to write, run, and test scripts and modules in a graphical environment.  It has features such as syntax-coloring, tab completion, visual debugging, Unicode-compliance, context-sensitive Help, and a tabbed/multi-pane user interface.

    Windows PowerShell 2.0 adds an Edit command to the context menu options for Powershell script, module, and data file types (.ps1, .psm1, and .psd1 extensions).  However, if you need to edit/test a script as an Administrator you would need to right click on the start menu icon for the ISE, run it as administrator, open the script in the editor, and navigate the Command Pane to the script’s folder to run it.  So I created an Edit as Administrator PowerToy for these file types to shortcut this process.  Install PowerShellEditAsAdmin.inf to use it.

    The other two PowerToys add context menu options (PowerShell ISE Here and PowerShell ISE Here as Administrator) to folders and drives to open the PowerShell ISE with the selected folder or drive as the ISE current directory.  Install PowerShellISEHere.inf and PowerShellISEHereAsAdmin.inf to use these.

    When you use the “as Administrator” versions of these PowerToys, you will see the elevation prompt will be for Windows Command Processor (cmd.exe).  This happens because I am using the Start command that is built into cmd.exe to launch the ISE and set the working directory.  I initially attempted to do this with the new Start-Process PowerShell cmdlet.  However, I hit two issues that prevented me from using it.  Start-Process allows you to use the “runas” verb with the –Verb switch to start a process elevated.  Unfortunately, if you use the “runas” verb then the –WorkingDirectory switch does not work.  So then I tried elevating powershell.exe first and then using Start-Process.  Unfortunately, passing in the Start-Process cmdlet with the –Command switch kept stripping out the double quotes causing the –WorkingDirectory path to error when it contained a space in the path.  If anyone out there can figure this out, please post the solution back as a comment.

     

    Important Note: For these PowerToys to work, the Elevate Command PowerToy from here must also be installed.

     

    - Michael Murgolo, Senior Consultant, Microsoft Services, U.S. East Region.

    Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

  • Elevation Gadget 2.0

    In my June 2008 TechNet Magazine article I introduced the Elevation Gadget.  This Windows Sidebar Gadget functioned as drag and drop target to elevate programs, scripts, etc.  Version 2 sports an updated look and can now be enlarged (enlarges when undocked on Windows Vista, enlarges via the Size control on Windows 7). However, the biggest change is the addition of a command box.  Below are a few screen shots.

    GadgetSmall      GadgetLargeCmd

     

    You can type directly into the command box.  You can also drag a file to the command box and the path to the file will appear there.  To execute the command, press Enter or click on the Elevation Arrow graphic.  The command box has a 100 line history buffer.  You can cycle through the items in the history using the Up and Down Arrow keys.  To clear the command box, hit the Escape key.

    Finally, if you have the Explore as Administrator PowerToy installed you can type:

    explore "<drive or folder path>"

    to launch the file manager application configured for the Explore as Administrator PowerToy focused on the drive or folder path specified on the command line.

    To install the Elevation Gadget 2.0, download Elevate.zip below and rename the file Elevate.gadget.  After renaming, double click on the file to install it.  (If you have the older version installed.  You should uninstall it before installing the new version.)

     

    - Michael Murgolo, Senior Consultant, Microsoft Services, U.S. East Region.

    Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

  • Explore as Administrator PowerToy

    Have you ever tried to use Windows Explorer to create a folder within or copy a file into a protected folder such a Program Files or Windows and had to deal with the confusing “File Operation” dialog box before you could complete your task.  This is one of the most confusing and poorly understood features of User Account Control.

    When running as a administrator with UAC enabled, your standard user token does not have write permissions to these protected folders.  Unfortunately, because Windows Explorer was not designed to run in multiple security contexts in the same desktop session, Windows cannot simply throw up a UAC prompt and then launch an elevated instance of Explorer.  Instead, you get one or more elevation prompts (if full-prompting is enabled) and Windows completes the operations using the full administrator token.  This can be annoying if you have to make repeated operations in these folders.

    So to work around this annoyance, I’ve created a new Explore as Administrator PowerToy.  Since this PowerToy cannot simply elevate Explorer, it requires that you install a third-party graphical file management program.  You can use almost any file management program you like as long as it will accept a folder path as a command line argument.  Let me illustrate what I mean by this with the program I like to use with the Explore as Administrator PowerToy, which is called Explorer++ (http://explorerplusplus.com/).  Download the Zip file for Explorer++.  (Grab the 32-bit or 64-bit version that matches the version of Windows that you are running.)  Extract the files, you’ll see that Explorer++ is a single executable file.  Open a command prompt in the folder where you extracted the files and run the following command:

    Explorer++.exe C:\Windows

    You will see that Explorer++.exe opened with the C:\Windows folder already selected.

    If you would like to try this PowerToy with Explorer++, place Explorer++.inf included in the attachment for this post into the folder with the Explorer++ extracted files.  The right click on Explorer++.inf and select Install.  This will install Explorer++ into a \Program Files\Explorer++ folder and add an Explorer++ program group to the Start Menu.

    You can then right click on the ExploreAsAdmin.inf also included in the attachment for this post and select Install.  Once the PowerToy is installed, you will see an Explore as Administrator option when right clicking on drives and folders in Windows Explorer.  When you select this option it will start Explorer++ elevated focused on the selected drive or folder.

    If you would like to use this PowerToy with another file management program, simply install that program and find the full path to the executable file. Then edit ExploreAsAdmin.inf and replace both instances of the following path with the path to the desired executable:

    %ProgramFiles%\Explorer++\Explorer++.exe

    Then install the modifed ExploreAsAdmin.inf.

    Important Note: For this PowerToy to work, the Elevate Command PowerToy from here must also be installed.

     

    - Michael Murgolo, Senior Consultant, Microsoft Services, U.S. East Region.

    Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

  • Welcome to the Elevation PowerToys Blog

    A while back I wrote two articles for TechNet Magazine describing a set of tools to work around a number of shortcomings when trying to elevate some types of tasks in Windows Vista and higher with User Account Control enabled.  You can find these articles here:

    Utility Spotlight: Script Elevation PowerToys for Windows Vista
    http://technet.microsoft.com/en-us/magazine/2007.06.utilityspotlight.aspx

    New Elevation PowerToys for Windows Vista
    http://technet.microsoft.com/en-us/magazine/2008.06.elevation.aspx

    Since then I have been working on several Elevation PowerToys but have not had the time to sit down and create another large article and tools download.  My experience with blogging on the Deployment Guys blog made me realize that the best way to get these new tools to you would be to create a new blog where I could write about and host the new Elevation PowerToys.  It would allow me break up the work by posting about one tool at a time and take feedback on them as well.

    So welcome to the blog and I hope you find the content to come useful and enlightening.

    - Michael Murgolo, Senior Consultant, Microsoft Services, U.S. East Region.

    Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.