Archive for November, 2013

Get AutoHotkey To Interact With Admin Windows Without Running AHK Script As Admin

November 21st, 2013 7 comments

A while back I posted about AutoHotkey not being able to interact with Windows 8 windows and other applications that were Ran As Admin.  My solution was to run your AutoHotkey (AHK) script as admin as well, and I also showed how to have your AHK script start automatically with Windows, but not as an admin.  Afterwards I followed that up with a post about how to get your AHK script to run as admin on startup, so life was much better, but still not perfect.UAC Never Notify


Problems with running your AHK script as admin

  1. You may have to deal with the annoying UAC prompt every time you launch your script.
  2. Any programs the script launches also receive administrative privileges.

#1 is only a problem if you haven’t set your AHK script to run as admin on startup as I showed in my other blog post (i.e. you are still manually launching your script) or you haven’t changed your UAC settings to never prompt you with notifications (which some companies restrict) (see screenshot to the right).

#2 was a problem for me. I use AHK Command Picker every day. A lot. I’m a developer and in order for Visual Studio to interact with IIS it requires admin privileges, which meant that if I wanted to be able to use AHK Command Picker in Visual Studio, I had to run it as admin as well.  The problem for me was that I use AHK Command Picker to launch almost all of my applications, which meant that most of my apps were now also running as an administrator.  For the most part this was fine, but there were a couple programs that gave me problems running as admin. E.g. With PowerShell ISE when I double clicked on a PowerShell file to edit it, instead of opening in the current (admin) ISE instance, it would open a new ISE instance.

    There is a solution

    Today I stumbled across this post on the AHK community forums.  Lexikos has provided an AHK script that will digitally sign the AutoHotkey executable, allowing it to interact with applications running as admin, even when your AHK script isn’t.

    Running his script is pretty straight forward:

    1. Download and unzip his file.
    2. Double-click the EnableUIAccess.ahk script to run it, and it will automatically prompt you.
    3. Read the disclaimer and click OK.
    4. On the Select Source File prompt choose the C:\Program Files\AutoHotkey\AutoHotkey.exe file.  This was already selected by default for me. (Might be Program Files (x86) if you have 32-bit AHK installed on 64-bit Windows)
    5. On the Select Destination File prompt choose the same C:\Program Files\AutoHotkey\AutoHotkey.exe file again.  Again, this was already selected by default for me.
    6. Click Yes to replace the existing file.
    7. Click Yes when prompted to Run With UI Access.

    That’s it.  (Re)Start your AHK scripts and they should now be able to interact with Windows 8 windows and applications running as admin 🙂

    This is a great solution if you want your AHK script to interact with admin windows, but don’t want to run your script as an admin.


    Did you know

    If you do want to launch an application as admin, but don’t want to run your AHK script as admin, you can use the RunAs command.


    I hope you found this article useful.  Feel free to leave a comment.

    Happy coding!

    Provide A Batch File To Run Your PowerShell Script From; Your Users Will Love You For It

    November 16th, 2013 115 comments

    Aside – This post has received many tangential questions in the comments. Your best bet at getting an answer to those questions is to check Stack Overflow and/or post your question there.

    A while ago in one of my older posts I included a little gem that I think deserves it’s own dedicated post; calling PowerShell scripts from a batch file.

    Why call my PowerShell script from a batch file?

    When I am writing a script for other people to use (in my organization, or for the general public) or even for myself sometimes, I will often include a simple batch file (i.e. *.bat or *.cmd file) that just simply calls my PowerShell script and then exits.  I do this because even though PowerShell is awesome, not everybody knows what it is or how to use it; non-technical folks obviously, but even many of the technical folks in our organization have never used PowerShell.

    Let’s list the problems with sending somebody the PowerShell script alone; The first two points below are hurdles that every user stumbles over the first time they encounter PowerShell (they are there for security purposes):

    1. When you double-click a PowerShell script (*.ps1 file) the default action is often to open it up in an editor, not to run it (you can change this for your PC).
    2. When you do figure out you need to right-click the .ps1 file and choose Open With –> Windows PowerShell to run the script, it will fail with a warning saying that the execution policy is currently configured to not allow scripts to be ran.
    3. My script may require admin privileges in order to run correctly, and it can be tricky to run a PowerShell script as admin without going into a PowerShell console and running the script from there, which a lot of people won’t know how to do.
    4. A potential problem that could affect PowerShell Pros is that it’s possible for them to have variables or other settings set in their PowerShell profile that could cause my script to not perform correctly; this is pretty unlikely, but still a possibility.
        So imagine you’ve written a PowerShell script that you want your grandma to run (or an HR employee, or an executive, or your teenage daughter, etc.). Do you think they’re going to be able to do it?  Maybe, maybe not.

    You should be kind to your users and provide a batch file to call your PowerShell script.

    The beauty of batch file scripts is that by default the script is ran when it is double-clicked (solves problem #1), and all of the other problems can be overcome by using a few arguments in our batch file.

    Ok, I see your point. So how do I call my PowerShell script from a batch file?

    First, the code I provide assumes that the batch file and PowerShell script are in the same directory.  So if you have a PowerShell script called “MyPowerShellScript.ps1” and a batch file called “RunMyPowerShellScript.cmd”, this is what the batch file would contain:

    SET ThisScriptsDirectory=%~dp0
    SET PowerShellScriptPath=%ThisScriptsDirectory%MyPowerShellScript.ps1
    PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& '%PowerShellScriptPath%'";

    Line 1 just prevents the contents of the batch file from being printed to the command prompt (so it’s optional).  Line 2 gets the directory that the batch file is in.  Line 3 just appends the PowerShell script filename to the script directory to get the full path to the PowerShell script file, so this is the only line you would need to modify; replace MyPowerShellScript.ps1 with your PowerShell script’s filename.  The 4th line is the one that actually calls the PowerShell script and contains the magic.

    The –NoProfile switch solves problem #4 above, and the –ExecutionPolicy Bypass argument solves problem #2.  But that still leaves problem #3 above, right?

    Call your PowerShell script from a batch file with Administrative permissions (i.e. Run As Admin)

    If your PowerShell script needs to be run as an admin for whatever reason, the 4th line of the batch file will need to change a bit:

    SET ThisScriptsDirectory=%~dp0
    SET PowerShellScriptPath=%ThisScriptsDirectory%MyPowerShellScript.ps1
    PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& {Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File ""%PowerShellScriptPath%""' -Verb RunAs}";

    We can’t call the PowerShell script as admin from the command prompt, but we can from PowerShell; so we essentially start a new PowerShell session, and then have that session call the PowerShell script using the –Verb RunAs argument to specify that the script should be run as an administrator.

    And voila, that’s it.  Now all anybody has to do to run your PowerShell script is double-click the batch file; something that even your grandma can do (well, hopefully).  So will your users really love you for this; well, no.  Instead they just won’t be cursing you for sending them a script that they can’t figure out how to run.  It’s one of those things that nobody notices until it doesn’t work.

    So take the extra 10 seconds to create a batch file and copy/paste the above text into it; it’ll save you time in the long run when you don’t have to repeat to all your users the specific instructions they need to follow to run your PowerShell script.

    I typically use this trick for myself too when my script requires admin rights, as it just makes running the script faster and easier.


    One more tidbit that I often include at the end of my PowerShell scripts is the following code:

    # If running in the console, wait for input before closing.
    if ($Host.Name -eq "ConsoleHost")
    	Write-Host "Press any key to continue..."
    	$Host.UI.RawUI.FlushInputBuffer()	# Make sure buffered input doesn't "press a key" and skip the ReadKey().
    	$Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyUp") > $null

    This will prompt the user for keyboard input before closing the PowerShell console window.  This is useful because it allows users to read any errors that your PowerShell script may have thrown before the window closes, or even just so they can see the “Everything completed successfully” message that your script spits out so they know that it ran correctly.  Related side note: you can change your PC to always leave the PowerShell console window open after running a script, if that is your preference.

    I hope you find this useful.  Feel free to leave comments.

    Happy coding!


    Several people have left comments asking how to pass parameters into the PowerShell script from the batch file.

    Here is how to pass in ordered parameters:

    PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& '%PowerShellScriptPath%' 'First Param Value' 'Second Param Value'";

    And here is how to pass in named parameters:

    PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& '%PowerShellScriptPath%' -Param1Name 'Param 1 Value' -Param2Name 'Param 2 Value'"

    And if you are running the admin version of the script, here is how to pass in ordered parameters:

    PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& {Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File """"%PowerShellScriptPath%"""" """"First Param Value"""" """"Second Param Value"""" ' -Verb RunAs}"
    And here is how to pass in named parameters:
    PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& {Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File """"%PowerShellScriptPath%"""" -Param1Name """"Param 1 Value"""" -Param2Name """"Param 2 value"""" ' -Verb RunAs}";
    And yes, the PowerShell script name and parameters need to be wrapped in 4 double quotes in order to properly handle paths/values with spaces.

    Problems Caused By Installing Windows 8.1 Update

    November 8th, 2013 No comments

    Myself and a few co-workers have updated from Windows 8 to Windows 8.1 and have run into some weird problems.  After a bit of Googling I have found that we are not alone.  This is just a quick list of some things the the Windows 8.1 Update seems to have broken.  I’ll update this post as I find more issues.


    IE 11 breaks some websites

    • I found that some of the links in the website our office uploads our Escrow deposits to no longer worked in IE 11 (which 8.1 installs).  Turning on the developer tools showed that it was throwing a Javascript error about an undefined function.  Everything works fine in IE 10 though and no undefined errors are thrown.
    • I have also noticed that after doing a search on Google and clicking one of the links, in order to get back to the Google results page you have to click the Back button twice; the first Back-click just takes you to a blank page (when you click the Google link it directs you to an empty page, which then forwards you to the correct page).
    • Others have complained that they are experiencing problems with GMail and Silverlight after the 8.1 update.
      So it may just be that IE 11 updated it’s standards to be more compliant and now many websites don’t meet the new requirements (I’m not sure); but either way, you may find that some of your favorite websites no longer work properly with IE 11, and you’ll have to wait for IE 11 or the website to make an update.


    VPN stopped working

    We use the SonicWall VPN client at my office, and I found that it no longer worked after updating to Windows 8.1.  The solution was a simple uninstall, reinstall, but still, it’s just one more issue to add to the list.



    Have you noticed other things broken after doing the Windows 8.1 update? Share them in the comments below!

    In my personal opinion, I would wait a while longer before updating to Windows 8.1; give Microsoft more time to fix some of these issues.  Many of the new features in Windows 8.1 aren’t even noticeable yet, as many apps don’t yet take advantage of them.  Also, while MS did put a Start button back in, it’s not nearly as powerful as the Windows 7 Start button, so if that’s your reason for upgrading to 8.1 just go get Classic Shell instead.

    Hopefully Microsoft will be releasing hotfixes to get these issues addressed sooner than later.