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.

The new Windows Server 2003 R2 operating system upgrade is a bundle of several separate feature-packs with Windows Server 2003 SP1. This is supposed to mean that W2k3 R2 is compatible with everything that ran correctly on the SP1 version of the OS. However, a quick round of testing is in order for any operations that have had problems caused by any post-SP1 security updates. Many security updates released since SP1 was released are already bundled into R2.

As for real features added to R2: Microsoft’s hype-machine-generated list of features added to R2 highlights several technologies, including the .NET 2.0 libraries and upgraded identity managment (Active Directory Federation Services), as “new”. Nonetheless, it looks like R2 does have some hype-worthy features that should have been better marketed. These features include the new WAN communication algorithms, for better network synchronization with less bandwidth use, and more granular storage management & SAN configuration tools.

It is possible to create a situation where someone sending a meeting request will receive a “Message not delivered” response from a user who was not originally invited to the meeting. This is an uncommon message to receive because meeting requests and the use of delegates are relatively uncommon.

Specifically, this occurs when the user sending the meeting request receives a “5.1.1″ non-delivery report from the Exchange Server because a user was deleted from Active Directory and was an email delegate of an original meeting invitee. Exchange stores delegates in the message store instead of in Active Directory, so those references aren’t removed when the delegated user is deleted from Active Directory. Microsoft KB article #312433 describes how to remove an orphaned delegate directly from the Exchange information store - two resolutions are detailed, the second uses Microsoft’s MAPI message store viewer Mdbvu32.exe to edit the message store, Mdbvu32.exe can be downloaded here.

Windows DFS is supposed to do all sorts of useful things in a domain, like reducing mapped drives, acting as an online backup in the event of downed servers, and caching files locally so WAN usage doesn’t spike (see Microsoft’s DFS Infrastructure marketing info). for Windows DFS basics and setup information: WindowsNetworking.com has a good article explaining Microsoft’s DFS terminology and function, plus I don’t feel like explaining everything and creating the screenshots like they offer.

Like all “infrastructure” tools it adds complexity to the system and requires extra resources to function correctly. In particular, Windows DFS buffers all files that are changed locally before it copies them over the other replicas. Unfortunately, since DFS (as of Windows 2003 SP1) copies entire files and not just the changes it uses a lot of drive space as a buffer - and it can’t even replicate files that may exceed the buffer size. The default buffer size on windows 2000 and 2003 Server is 4GB, so consider not replicating the files causing this problem. After all, pushing 4GB+ files around the WAN isn’t exactly efficient for DFS or any system.

To bump up the DFS buffer size, first make sure you have enough disk space locally to allocate it to the buffer and enough disk space remotely to accommodate the multi-GB mile you’re about to send. Then open regedit and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\. Change the value of the DWORD “Staging Space Limit in KB” to accommodate your largest files (remember MS still uses binary KB and MB based on multiples of 1024, instead of digital 1000x units).

Who uses multiple, nested Org Units in Active Directory? Anyone using Group Policies beyond a bare minimum should be…

A very fast description of Microsoft’s Active Directory summarizes the reasons for various AD structures. The simplicity of the explanation and the recommendation to use Org Units to better delegate administration make it worth saving to your help desk’s knowledge base. Thanks to Alex Scoble for the original link.