by Marcin Policht
You probably are familiar with “system” and “boot”
partition naming confusion in Windows NT – “system” is the one you
boot from, “boot” is the one containing system files. Windows
2000 made some contribution in this linguistic chaos as well. Group Policies,
for example, can not be directly applied to groups. But first things
Are you implementing group policies under Windows 2000? If you are, you don’t want to miss these tips from columnist Marcin Policht!
Unlike System Policies in previous versions of Windows, Win2000 Group
Policies are not limited to registry settings (stored under SoftwarePolicies
and SoftwareMicrosoftWindowsCurrentVersionPolicies for both HKLM and HKCU)
which in Win2000 are handled by Administrative Templates node of Group Policy
snap-in, but can also be used to control:
– security settings (for both computers and users)
– user data and settings management (via folder redirection and software
– software installation (via publishing and assigning) and maintenance (with
a separate section dedicated to Internet Explorer)
– scripts (logon and logoff, startup and shutdown)
– remote operating system installations via RIS
This makes Group Policies an invaluable administrative tool, which has to be
well understood in order to efficiently manage Win2000/AD environment.
Group Policies depend on existence of Active Directory, since they link Group
Policy Objects to specific Active Directory containers, described by Microsoft
using the term SDOUs – which stands for Sites, Domains, and Organizational Units (with the highest priority assigned
to OUs unless “No override” settings are used on a higher level). Any
number of group policy objects can be linked to any number of containers (providing permissions are properly granted), however
each additional group policy increases overhead associated with processing it,
so try to keep the number of policies processed by any specific user or computer down to minimum.
Strangely enough, you can not link Group Policies to Win2000 groups (a bit of
misnomer). You might think of trying placing groups into OUs in order to bypass
this limitation, but unfortunately this will not help either. Groups placed in OU are not affected by processing of group
policies (only users and computers). However, you can apply GPOs to groups based
on the DACLs (Discretionary Access Control List entries) assigned to groups (or other Win2000 security
principals, such as computers or users) using Security tab of GPO’s properties.
This is done by checking Allow column for Read and Apply Group Policy permissions for groups you want to have GPO applied to.
Tips and Pointers
– certain settings (such as password restrictions, account lockout, and
Kerberos settings) can be applied only at the domain level. Windows 2000 will
not process any changes that you make to these settings in a GPO linked to a site or an OU.
– try to limit number of group policies used in your environment. If you do
not use computer or user part of a particular group policy, disable it using
Disable computer configuration settings or Disable user configuration settings under Properties of particular GPO on the General
– if you want to exclude your account or administrative group from processing
a specific group policy object, simply check Deny column for Apply Group Policy
permissions for your account or group under Security tab of this group policy object properties.
– avoid using Block inheritance and No override settings, in larger
environments they might make troubleshooting very time consuming.
– remember (important) that the system policies can be applied not only at
the boot (computer) and logon (user), but also afterwards (by default, for
client computers, every 90 minutes with 30 minute random offset, and for domain controllers every 5 minutes) – so be careful
when making changes. The actual frequency is specified (where else) under
SystemGroup Policy under Administrative Templates of user and computer sections of a GPO. You can also refresh
policies manually on a client by using the SECEDIT.EXE tool with the /refreshpolicy
– remember that the policies are “non-sticking” (unlike in Windows
NT), which means that any settings affected by policies are automatically
changed back to the original ones as soon as the policy is removed.
– to troubleshoot group policies, use Gpresult.exe command line utility from
Win2000 Resource Kit.
– in a mixed environment, a combination of System Policies and Group Policies
will be applied to users and computers, depending on the OS installed on the
client computers and whether user and computer accounts reside in an Active Directory or a NT4.0 SAM (check http://support.microsoft.com/support/kb/articles/Q253/6/72.ASP).
However, downlevel computers (NT and Win9x) do NOT process GPOs (just as Win2000 computers are not affected by any of the *.POL
– another concern in a mixed environment is keeping your NETLOGON shares
consistent. You have to remember to place a copy of Config.POL (for Win9x
clients) and NTConfig.POL (for NT clients) in SYSVOLSYSVOLDomainNameScripts folder which is shared as NETLOGON on
Win2000 domain controllers (Windows NT LanMan Directory Replication can not be
configured to replicate with Win2000 File Replication Service, so until you migrate completely to Win2000
with AD, you’ll have to remember to keep *.POL files in both environments
synchronized. You can use Microsoft provided LBridge.cmd script to copy the data from Win2000 Based DC to NT4.0 BDC
configured as an export server)
– distribution groups can not be used for group policy filtering (only
– on stand-alone computers, you can use Local Group Policy Object
– on computers which are members of Active Directory, Local GPO is applied
first (with the lowest priority), Active Directory-based policies are processed
afterwards (overwriting any settings conflicting with the Local GPO). However, if user’s and computer’s accounts exist in NT
4.0 domain, Local GPO will not be applied.