Blog: group policy

Quite frequently on information security audits we find machines where group policies have been applied incorrectly or not at all.  The IT administrator swears the policy is working, but the policies haven’t always taken on machines.  What we can do in that situation for Windows XP machines is use GPupdate.exe, Rsop.msc, and GPresult.exe to find out more information. [more]


After you make changes to group policies, you may want the changes to be applied immediately, without waiting for the default update interval (90 minutes on domain members and 5 minutes on domain controllers) or without restarting the computer. To make this update, at a command prompt, run the Gpupdate.exe utility.


The Resultant Set of Policy MMC snap-in has a nice interface and is easily used. Just go to Start, Run and enter rsop.msc. This will flash up a quick screen with a summary of the environment it’s processing.

When the progress reaches 100%, it will pull up a report for the policies upon which the computer and the user are having applied. You can browse the list, which mirrors the Group Policy Management Console, and see which policies the machine is seeing, which might not quite match what you’ve set in the Active Directory server.

You can also use this to diagnose any errors. For example, if a software deployment isn’t coming through for some reason, you can verify that it has access to the policy and has received the command. You can also see any related errors to help your troubleshooting.


Starting with Vista SP1, RSoP no longer shows all of the group policies that a computer might have being applied to it. Instead, Microsoft recommends that you use the command line tool GPResult. Just open the Command Prompt and type:  gpresult

Being a command line tool, it opens up the possibilities to include it in scripting. There are a large number of options you can use with GPResult to get exactly what you want. You can use it to create a nicely formatted HTML or XML report and you can also use it to run remotely on another system and as a different user (provided you know the password).


One of our IT consulting customers using a Windows 7 laptop was experiencing a problem with access mapped drives while connected to their company using VPN.

Doing some research I found that Windows 7 and Vista both have what's called "slow link mode".  The behavior is that if the latency of the network connection exceeds 80 milliseconds (ms), the system will transition the files to "offline mode".  The 80 ms value is configurable using a local group policy edit.

  1. Open Group policy (start -> run -> gpedit.msc)
  2. Expand "Computer Configuration"
  3. Expand "Administrative Templates"
  4. Expand "Network"
  5. Click on "Offline Files"
  6. Locate "Configure slow-link mode"
  7. This policy can either be disabled or set to a higher value for slower connections.

Note – The "Configure Slow link speed" value is for Windows XP Professional. [more]

Additionally, there is a registry value that can be added that can force auto reconnection...

When a server has been unavailable (offline mode) and then becomes available again for connection, Offline Files Client Side Caching tries to transition that server to online mode if all the following conditions are true:

  • There are no offline changes for that server on the local computer.
  • There are no open file handles for that server on the local computer.
  • The server is accessed over a "fast" link.

You can adjust the definition of "slow" and "fast" by using the SlowLinkSpeed Offline Files policy. With this, you can configure Offline Files Client Side Caching to ignore these conditions and transition the server to online mode regardless of whether these conditions exist. To do this, follow these steps:

  1. Click Start, click Run, type REGEDIT, and then click OK.
  2. Locate and click the following registry subkey:
    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Curr entVersion\NetCache
  3. Click Edit, point to New, and then click DWORD Value.
  4. Type SilentForcedAutoReconnect, and then press ENTER to name the value.
  5. Double-click SilentForcedAutoReconnect.
  6. In the Value data box, type 1, and then click OK.

Finally, here is a link to a Microsoft TechNet article explaining how Vista/7 handles offline files.  At the bottom of the article is a procedure for disabling offline files completely using a Group Policy Object.


I needed to turn on NTFS file system auditing for two specific application EXE files on 30+ servers.  I didn’t want to have to touch each server individually, so I decided to look into applying the audit settings centrally using group policy.  Using the Security Templates snap-in for MMC on one of the systems I wanted to set up auditing for, I was able to configure a custom file system security policy.

 Security Templates Snap-in:

Within the Security Templates MMC: [more]

  1. Define a new, empty security template
  2. Expand the new Template
  3. Right click on the File System section
  4. Select "Ad File..."
  5. Browse to the file you want to ad a group policy enforced ACL to
  6. Configure your desired access controls/audit settings
  7. Set appropriate inheritance options
  8. Once the policy settings you want are complete, right click the security template name
  9. Select "Save As..."
  10. Save the INF file somewhere
  11. Delete the security template

In my case, I only wanted to apply the audit policy portion of the ACL (not the file system permissions), so I opened the INF file and removed the permission settings that started with “D:PAR” and just left the “S:AR” settings.

Then, using the Group Policy Management console, I was able to create a new group policy object and import my file system auditing settings from the INF.  I then applied the group policy to the proper OUs and waited for the new settings to get applied.  Everything worked like a charm.  The completed policy looks like this (in the Group Policy Management HTM view):


One way to exclude directories (thus not single files or filettypes) of roaming profiles to be placed on the servers is by using the Group Policy Object:

  • User Configuration
  • Administrative Templates
  • System
  • User Profiles
  • "Exclude directories in roaming profile" [more]

You can enable this and type in the folders you want to exclude.  You only type the name of the folder from the root directory of the profile.  So if you want to exclude "D:\Documents and Settings\tuser\Application Data\Microsoft\Internet Explorer\UserData" then you type in “Application Data\Microsoft\Internet Explorer\UserData”.  For extended folder entries you separate each by a semi-colon:  "UserData;Cookies;My Documents;Temp;Start Menu;Application Data\Microsoft\Internet Explorer\UserData;"

Be sure to include a semicolon at the end.

To verify delivery to the targeted user accounts, go to a device where a targeted user account has logged on and check the following registry key manually: HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System


With Windows Server 2008, Windows Vista, and Windows 7 Microsoft changed the group policy template files to an XML format (.ADMX file extension).  These files are stored in the PolicyDefinitions folder under %systemroot%.   If you open the Group Policy Editor from a 2008 or higher system, it will automatically access these files on the local system.  However if you want to automatically have access to the templates across the network you can create a central store on a domain controller and they will be automatically replicated with other domain controllers in the domain.  Using this method I was able to make the newer Windows 7 ADMX files available on our 2008 domain controllers. [more]


A client of ours uses the Cybernet iONE all in one PCs for customer internet stations at several of their locations. One oddity of these machines is that they ship with dual Gigabit onboard NICs. On these internet stations we typically use just one and disable the other NIC. While building out a particular machine, I needed to install several pieces of software that we deploy via Group Policy Software Installation. The problem is that any time I would attempt to deploy the software via Group Policy, it would fail and I would see event ID 1054 in the event logs… “Windows cannot obtain the domain controller name for the computer network. (The specified domain either does not exist or exist or could not be contacted). Group Policy processing aborted. Data: (unavailable)”.  Everything else was working fine. The machine was a member of the domain, I could ping the domain controller that DHCP had assigned to the machine, I could resolve internal and external addresses, gpresult showed that the PC was successfully linked to the software installation OU, etc. [more]

After conducting some research on this error and on these machines, it turns out the problem was that the onboard Broadcom gigabit NIC was taking too long to auto-negotiate its link speed, creating a “race condition” between the TCP/IP protocol and the NIC driver when they try and register with the MS Nework Driver Interface Specification. The local Userenv process (what actually performs GP’s instructions) would attempt to install the software before the NIC was fully available, thereby causing it to fail when it would attempt to run the assigned MSI over the network. Here’s how to rig the race so that the NIS driver always wins the “race”. There is a MS hotfix available for this along with a more detailed problem description at After installing this hotfix you must add the DWORD registry entry GpNetworkStartTimeoutPolicyValue in  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon and set the value of that DWORD entry to the number of seconds you would like the OS to delay processing Group Policy Startup scripts.


I was assisting a vendor with a software update at a client site that required .NET 3.5 SP1. An error keep popping up (“remote user install not available”) when I attempted to install .NET 3.5 SP1.  RGBRast was listed as the problem child. I looked at group policy as many web post suggested.

(Computer Configuration: Administrative Templates: Windows Components:Windows Installer) (Disable Windows Installer) Set to "Disable"

The group policy was not set so I went ahead and disabled the setting to see if it would help, but it did not.

After researching more I found that with .NET 3.0 and up, the RGB Rast msi appears to be configured to do a per-user install, rather than per-machine. The server had the "Prevent per-user installs" Group Policy enabled which would cause the install to fail, preventing .Net 3.5  from installing. [more]

I modified the registry value

Key: HKLM\Software\Policies\Microsoft\Windows\Installer
Value: DisableUserInstalls
Data: 1

And was then able to complete the .NET 3.5 SP1 installation as well as the database / program upgrade.


When you setup a group policy that assigns internet settings located in User Configuration\Windows Settings\Internet Explorer Maintenance\Security\Security Zones and Content Ratings you have to copy your current internet settings to the GPO. These settings are useful if you wish to use the “preference mode” option so that the setting is set once and then the user has the ability to modify it from there. This all works fine when importing from IE6 but if you try to import settings from IE7 it will not work properly and you will get an error when trying to view the settings of that GPO:

“An error occurred while generating report:
An unknown error occurred while the HTML report was being created.”

There is rumor that this problem has been fixed in the Vista version of GPMC and I am assuming that this would include the server 2008 version but I have not tested this yet. A workaround as mentioned in the article linked below is to set the internet settings from here: User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page\Site to Zone Assignment List. This works great accept that you do not have the option to use the “preference mode”. [more]


When creating or using a custom ADM file in group policies, some options may not be visible.  This is because the setting is considered a "preference" and the settings will not revert if the group policy is removed.  You must uncheck "Only show policy settings that can be fully managed" under the group policy editor's context menu.  (View->Filters).