Windows 7 / Getting Started

---

Group Policy Before Windows Vista

In earlier versions of Windows such as Microsoft Windows 2000 Server, Windows XP, and Windows Server 2003, Group Policy had a number of limitations due to how it was implemented on these platforms. These limitations included the following:

• Administrative Template (ADM) files used a proprietary syntax that made it complicated for administrators to create their own custom ADM template files to extend Group Policy management functionality by extending or introducing new registry-based policy settings for Windows, other Microsoft software products, third-party applications from Independent Software Vendors (ISVs), and custom internal applications. In addition, the syntax for ADM template files made it difficult for administrators to develop localized versions that they could use to view registry-based ADM policy settings in their own languages. (Using multiple languages with ADM files resulted in a mixture of languages in the user interface-the ADM file with the latest date/timestamp overwrote the other ADM files.) All of these limitations made it difficult for administrators to create their own custom Group Policy solutions for managing registry-based settings, especially in global enterprises with multilingual environments.
• Whenever you used the Group Policy Management Editor on an administrative workstation to create a new domain-based Group Policy object (GPO), the entire set of default ADM template files was automatically copied from the %SystemRoot%\inf folder on the computer where the GPO was being edited to the Group Policy Template (GPT), which is the physical portion of the GPO stored on the domain controllers for your domain. For each GPO that you create, the GPT is created at %SystemRoot% \SYSVOL\domain\Policies\GPO_GUID and also appears in the SYSVOL share at \\domain_controller_name\SYSVOL\domain_name\Policies\GPO_GUID, where GPO_GUID is a folder named after the globally unique identifier (GUID) of the GPO. (The other logical portion of each GPO is stored in the Group Policy Container [GPC], found in the CN=Policies,CN=System container in AD DS.) The File Replication Service (FRS) replicates the contents of each GPT folder within the SYSVOL share to all domain controllers in the domain, and the storage cost of having copies of all of the default ADM template files stored in each GPT is at least 4 megabytes (MB) per GPO. The result of these conditions in large enterprise environments-where dozens or even hundreds of GPOs are deployed-was SYSVOL bloat, a condition that caused excessive replication traffic and consumption of hard drive space whenever a change was made to the settings in a GPO. For domain controllers at different sites linked by slow wide area network (WAN) links, such excessive replication traffic could at times affect the availability and performance of network applications relying on other forms of traffic. This issue was exacerbated when events occurred that caused all GPOs to change simultaneously, such as when permissions on GPOs were modified when upgrading a domain from Windows 2000 to Windows Server 2003.
• To help reduce Group Policy traffic over slow WAN links, a feature called slow-link detection was used on earlier versions of Windows. Slow-link detection used exchanges of Internet Control Message Protocol (ICMP) packets to detect increased network latency and reduced responsiveness. When a slow link was detected, which by default corresponded to a latency of more than 10 milliseconds, the client pinged the domain controller three times using 2-kilobyte (KB) Echo Request packets and then used the returned Echo Reply packets to determine the effective bandwidth for the network link to the domain controller. If the effective bandwidth was determined to be fewer than 400 kilobits per second (Kbps), the client identified the network link as a slow link and informed the domain controller. If the link was identified as a slow link, Group Policy processed only security and ADM settings during background policy refresh. Because slow-link detection used ICMP for determining effective network bandwidth, problems arose if host or perimeter firewalls blocked ICMP traffic. In addition, being unable to block ICMP traffic increased the attack surface of computers.
• Group Policy processing took place only during startup (processing of machine settings), logon (processing of user settings), and at scheduled background policy refresh intervals, which by default for client computers and member servers was every 90 minutes plus a random offset of up to 30 minutes. For domain controllers, the interval was every 5 minutes. However, Group Policy was implemented on earlier versions of Windows in such a way that Group Policy processing would not take place during the following types of events: when a client computer recovered from hibernation or standby, when a mobile computer was docked with its docking station, when a computer established a virtual private network (VPN) connection with a remote computer or network, and when a client computer successfully exited network quarantine. As a result of these limitations and circumstances, earlier versions of Windows might not have the latest Group Policy settings for the domain applied to them. If updates to the Group Policy settings mitigated security vulnerabilities, this could result in temporary security vulnerabilities until the next round of background policy refresh occurred. In addition, if a domain controller temporarily became unavailable when scheduled background policy refresh was to occur, no mechanism was available to alert the client computer that the policy should be refreshed when the domain controller became available again. Instead, the client computer would log an error event in the event log and attempt policy refresh at the next scheduled refresh time.
• Configuring the Local Computer Policy (also called the local Group Policy object [LGPO]) on stand-alone computers resulted in settings that applied to all users (including administrators) on the computer. This limitation made it difficult to lock down and administer shared computers for kiosk use in environments such as libraries and other public places, as well as for Windows computers used in other non-AD DS environments, because all configured settings applied not just to ordinary users but also to local administrators on the computer.
• Troubleshooting Group Policy currently requires being enabled to log on to the core Group Policy engine Userenv.dll. Log files generated by Userenv.dll are stored in the %WinDir%\Debug\Usermode folder and contain Group Policy function trace statements conflated with roaming profile load and unload function statements, making these log files hard to interpret when trying to diagnose Group Policy failure.
• Although Windows XP Service Pack 2 (SP2) and Windows Server 2003 SP1 and later versions support more than 1,800 different policy settings covering a wide variety of areas, you can't use Group Policy to manage many of these features on earlier versions of Windows. For example, there is no native way to use Group Policy to control power management; to block the installation and use of removable drives, such as universal serial bus (USB) key drives; or to deploy printers to users based on the location of their computers. (Third-party solutions do exist, however, for adding some of these functionalities to Group Policy on these platforms.)