Have you implemented software restriction policies in Active Directory only to find that they stop working a few months later? Initial investigation may show the executable to still be blocked in the Group Policy - while the same executable now runs just fine on user desktops. This is because Microsoft’s software restriction policies are usually specific to the version of the .EXE file. I’ve heard all sorts of explanations for this, usually related to not wanting to block the function of service packs and other vital updates due to “overly restrictive software policies”… The truth is that Microsoft was smart enough to block program .EXE’s based on a hash value generated when the program was compiled from the prgrammers’ code - which means that changing the filename will not circumvent a software restriction policy.

This article is based on a recent, real-life scenario using the Internet Explorer executable, “iexplore.exe”, as the blocked program. The recent release of the IE 7.0 beta software and some freetime playing around by one of my client’s employees provided a chance for plenty of hours watching ESPN and YouTube videos on a warehouse floor and even slowdowns in getting and filling order downloads because of the use of all WAN bandwidth.

To troubleshoot failed software restriction policies I prefer to start on the client machine. To determine both whether a policy is applied correctly and the version of an executable blocked by software restriction:

• Open regedit
• Open the following key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\
• Inside that key will be one or more numbered branches related to the software restriction policies applied to that machine. To see what program each policy covers, open the numbered branch, then open the Hashes branch and click on each GUID.
• Inside each GUID key will be a string value with the data “program.exe (#.#.####.#) … and so on”. The numeric value #.#.####.# describes the program version. In my case the policy applied to “iexplore.exe (6.0.2900.2180)”
• Then, go check the version of the same executable that’s now installed on the system. In this case, I right-clicked on the iexplore.exe file and selected “Properties” and then the “Version” tab. Right at the top was the file version: 7.0.5335.5.

In this case, that was the answer - the IE 7.0, iexplore.exe was blocked with a new policy and everything was back to normal. In case the solution isn’t that simple, the best thing to do is to gether more data. Enable software restriction policies advanced logging by reopening the registry and:

• Navigate to the following key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\
• Create a new string value named LogFileName
• Enter the full path and filename of a text file that can be used for logging, ie: C:\sres_log.txt

Now, every executable run on the system will be logged to the file with a reason for wy it was or wasn’t allowed to run. Details include the executable name, PID number, GUID, path name, and an allowed/disallowed/unrestricted comment with a short reason why. Since EVERY program is logged each time it is run, the log can get quite long. To keep it from getting out of control, either disable advanced logging by deleting the key or add a batch script that will truncate the log file periodically.

Comment on this post below

You can leave a response, or trackback from your own site.