By Bryan Keadle

Having restrictive group policies applied for a user/workstation is nice in order to keep users from doing what they shouldn't or tweaking their way to a Help Desk call. However, it also becomes a hassle when you do need to provide support for the end user. Often, logging out and logging in as an Administrator to remove the restrictions isn't only slow and cumbersome, it also isn't helpful if the issue you may be trying to resolve is specific to the user's profile.

In my environment, I use my own custom utility, Policies.exe, which allows me to temporarily remove policy restrictions, do what needs to be done, then put the policy restrictions back...all without a reboot!

Here's how it works:

With policies accessible on a network drive (or delivered as a NAL object), as the user I run POLICIES.EXE. I'm prompted to enter the administrative password:

Password is: Authorized (case sensitive)

Click to view.

Because the password dialog only shows * entries, an observing user wouldn't know what to type. After entering the correct password, it exports the registry keys to some temporary files, then deletes the registry keys, thereby removing all restrictions. Now you can do whatever you want to the machine, *before* pressing OK on the message box.

Click to view.

Once you press OK on the message box, the exported registry keys are re-imported and the temporary files deleted, restoring the workstation to it's "locked down" state. Quick and easy.

This works as long as the user has the necessary rights to these registry keys to be able to modify and delete them.


This version of POLICIES.EXE is also INI-configurable. An INI of the same name in the same directory (IE: policies.ini) provides these options:

PSWD=Hex Password (set with PSWD command line)
LOG=Log File
LogEntry=%UserName% on %ComputerName% incorrect password for POLICIES.EXE
LogUse=Y ;to log use of policies

PSWD= alternate, encrypted password

LOG= Log filename (and path) for logging usage of Policies

LOGEntry= text of log entry

LogUse= Enable/disable use of policies.exe logging

To set your own password for Policies.exe, run:


Click to view.

Enter existing password (default=Authorized)

Click to view.

Enter your new password. This will then be stored in the .INI in an encrypted format.

To address the concerns that your end-users could find this tool, download it, and run it from anywhere to circumvent your group policies, POLICIES.EXE will also check the search path AND Z:\PUBLIC for any other POLICIES.INI file and if found, *AND* the user is unable to change it's file attributes (hence, placed there on a restricted network drive by a NetAdmin), IT'S INI settings will be used instead, thereby overriding any default settings or settings that may be defined by an .INI located with the .EXE.


Note: Alert reader Vicki W. noted that having this tool freely available for download by her students was a significant security concern for allowing them to also circumvent their policy security measures.

To address this legitimate concern, POLICIES.EXE will also check the search path and Z:\PUBLIC for any other POLICIES.INI file and if found, *AND* the user is unable to change the attributes of the file (hence, placed there in a restricted directory by a NetAdmin), it's INI settings will be used instead, thereby overriding any default settings or settings that may be defined an .INI located with the .EXE.

Note for v42

By popular demand...or should I say...UNpopular demand (!)... this tool *requires* the NetAdmin conditions to be in place for it to work. If attempted to run this program without the read-only conditions in place, the user will simply get this "You are not authorized to use this program without the Network Administrator's approval!" message:

Click to view.

This addresses the concerns from people that the availability of this tool to run without NetAdmin approval and conditions set makes your job harder...not easier...which certainly isn't my intent! Thanks for participating in this community....this is how it's supposed to work!

(Works for Win2K and WinXP)


How To-Best Practice
Comment List