Method One: The Old Fashion BAT file. You probably noticed that all the executables listed within the App Paths registry section reside outside of the Windows folder. In fact, all the entries reside outside of folders that Windows typically looks in first for self-launching files when you fail to specify a path to the file. What are these default paths? It can vary from computer to computer, but opening a DOS prompt and typing "ECHO %PATH%" will show you what those paths are. Regardless of any additions made by users or applications, you will always see a reference to your Windows path, as well as the System or System32 folder therein. If you open notepad, you can type in a command such as this: "START RunDll32.exe shell32.dll,Control_RunDLL hotplug.dll". Save it to your Windows folder, named (for this example) HOTPLUG.BAT. You can now go to your Run dialog, type in "hotplug" (or "hotplug.bat") and the command will run, similar to registered applications. For this option, I suggest keeping all your BAT files in one location to ease maintenance. If you don't like the idea of putting them all in the Windows folder, you can create a folder somewhere and amend the environmental PATH statement to include that folder (will require a reboot).

Method Two: Create Your Own Executables. This is a little more complicated than the first method, but some people like it. Many scripting platforms, such as Visual Basic Script, JavaScript and AutoIt, can be "compiled". The scripts aren't really compiled like a normal application, but rather they are wrapped around a helper program which launches them, allowing you to create "stand-alone" scripts that can be launched like applications without the need to write out a command line to the script engine and then the script file. This feature is not always free, and typically comes as a feature of either a scripting development studio (such as Admin Script Editor or PrimalScript), or as a bonus from the script's developer. AutoIt gives one away for free, so I'll use that as my example platform. Using notepad again, creating a one line AutoIt 3 script "Run("RunDll32.exe shell32.dll,Control_RunDLL hotplug.dll")", saving the file as HOTPLUG.AUT, then using the compiler to change it into HOTPLUG.EXE will then put you into the position you are in now, where you can save your executable somewhere and register it within the App Paths registry key.

Method Three: Freeware / Shareware. Lots of these types of programs are out there. The software provides you with either a command prompt-like box on your desktop or on your Start Bar, and allows you to create "macros"; keyword initiated commands. Because I'm personally familiar with this software, I'll use TrueLaunchBar as my example. With this, you can use the Command Line plug-in to create keyword-launched macros you can type in and run just like your normal application.

Intranet Page. This is a very common, albeit a little more intensive, solution to providing elevated rights to specific tasks. Using simple ASP, you can create a user form with a server side process that asks the support person for the name or account of the locked out user and upon submission, unlocks the account. Using IIS, you can either have the intranet site accessed using the requesting user's network credentials, or you can allow anonymous access and use an administrative account with AD manipulation permissions. Because you are 100% in control of what the end user can do via the pages, and as the support person is at no time given the user name or password of the administrative account, you can effectively provide users with elevated rights on specific tasks.

Compiled Script. Using a similar but different approach, you can utilize VBScript to create a script that asks for the end user's account ID, and then unlocks the account. When using this approach, you need to use a development studio such as PrimalScript or Admin Script Editor that allows you to package the script and then execute the script using alternative credentials. In this manner, the support person can run the utility from any networked computer which belongs to the same domain as the account specified for your alternate credentials, and perform the action against the AD without ever knowing the administrative user name or password used.