May, 2010

  • 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.