Although Group Policy is a large and complicated
service and technology, it also relies heavily on other complicated
services and technologies. You must understand these other services and
technologies to fully understand Group Policy, especially when you
encounter trouble. Understanding Group Policy’s dependencies will help
you pinpoint the source of the problem, whether it be Group Policy or
one of these services.
The services and technologies that Group Policy has direct dependencies on include the following:
Active Directory
Domain Name System (DNS)
Active Directory replication
Distributed File System Replication (DFSR)—formerly File Replication Service (FRS)
DFS publishing
Network Location Awareness (NLA)
As you can see from the
preceding list, the services and technologies that Group Policy depends
on are extremely important, not only to Group Policy, but to your
network as a whole. Without these services and technologies, you would
not have a fully functional enterprise.
Each of these
services and technologies is responsible for a specific aspect of Group
Policy. Understanding how each component fits into the bigger picture
will help you with design, implementation, management, and
troubleshooting of Group Policy.
Active Directory and Group Policy
Active
Directory has the biggest role as a dependent technology with Group
Policy. Most certainly, without Active Directory you would not have much
of a Group Policy infrastructure to work with. Active Directory
provides the foundation upon which Group Policy is embedded.
First, consider that Active
Directory houses all of the user and computer objects for the domain or
domains. It is these user and computer objects that Group Policy
controls. Next, Active Directory creates the structure that the objects
are placed within. The structure is made up of organizational units. The
design of the organizational units is essential in the deployment of
Group Policy—the user and computer objects located within the
organizational unit where
the GPO is linked, as well as those in child organizational units, are
affected by the settings in the linked GPO by default.
Important
A
poorly designed Active Directory structure can make it very difficult
to deploy Group Policy. It is always best to design Group Policy
deployment into the initial Active Directory design. If the Active
Directory design is too chaotic or disorganized, it might need to be
completely redesigned before Group Policy can be correctly deployed. A
well designed Active Directory structure considers the user and
computer object location within the organizational units. Because GPOs
are linked primarily to organizational units, ensuring that the links
are easy and efficient will help with the overall success and good
design of Active Directory. |
Note
Active
Directory should be designed to incorporate two important components:
Group Policy and delegation of administration should be the two driving
factors for your Active Directory design. As a best practice, delegation
of administration should have the highest priority, because Group
Policy can be filtered to apply to only certain objects in an
organization unit. |
GPOs can be linked to
three Active Directory components. These include the domain,
organization units, and sites. If Active Directory did not contain these
components, GPOs would not be able to link to them.
As a side
benefit, Active Directory allows for single sign-on for user accounts,
which Group Policy can leverage because each user is unique within the
Active Directory domain. Because each user is unique, administrators can
mold and deploy the precise security settings, desktop settings,
registry values, and profile environment for each user.
Note
Local
Group Policy objects can still be used without Active Directory, in a
small business or home office environment, for example. In such cases,
the Local Group Policy objects must be administered on each computer
separately. |
Domain Name System
You probably already
know what the Domain Name System (DNS) is, but as a reminder, DNS is a
distributed database that resolves DNS host names to Internet Protocol
(IP) addresses. In Active Directory, DNS is the locator service that
enables computers to find other computers, as well as important
networking services.
For Active Directory
networks, DNS has entries called Service Resource Records (SRVs) that
are associated with different networking services. These include entries
for Lightweight Directory Access Protocol (LDAP), Transmission Control
Protocol (TCP), and Kerberos. These SRVs help computers in the Active
Directory domain find the servers that are functioning as domain
controllers. At a domain controller, they might get a listing of Group
Policy Objects, update their Kerberos ticket, find a resource, and so
on. When DNS is not working properly or is misconfigured, computers will
not be able to use DNS to find this information. At this point, Group
Policy will fail to work properly; all updates and refreshes will cease
until DNS is functioning properly again.
DNS is also used
for Distributed File System (DFS). DFS can be used within Group Policy
to share applications or other resources. When a GPO is configured to
direct a desktop or user to a DFS distribution point for accessing
software, the computer must use DNS to find these installation points.
If DNS is not configured properly, the computer will never find the DFS
distribution point and the software will not be installed or updated.
Finally, DNS is
important for managing Group Policy. Domain controllers are the computers that store GPOs.
Therefore, when you are managing a GPO, a domain controller must be
contacted. If DNS is not functioning properly, a domain controller
cannot be found and an error will occur when trying to update or view a
GPO.
Replication
One of the more significant
tasks of Group Policy is to ensure that each GPO is synchronized with
each domain controller. Domain controllers are the command center of GPO
distribution. A GPO is
not just a single entity. It is really made up of two separate parts:
the Group Policy template (GPT), which is stored in the SYSVOL of each
domain controller, and the Group Policy container (GPC), which is stored
in Active Directory, again on each domain controller.
Both
portions of the GPO must be replicated to every domain controller
within the domain. If the GPOs do not synchronize to all domain
controllers after a change is made, strange behavior will occur. This
behavior might include differing settings on two desktops that should
have the same settings, errant settings on a server caused by a missing
GPO setting, failure to apply policy altogether, or a desktop that is
not secure because of a failure of the GPO to replicate.
As you can see,
replication is a significant factor for Group Policy. There is a small
concern with Group Policy replication, however. The GPO is made up of
two different parts, but the SYSVOL replication and the Active Directory
replication are not driven or supported by the same replication
technology.
SYSVOL replication is
controlled by either the Distributed File System Replication (DFSR) or
the File Replication Service (FRS), depending on the domain functional
level. Domain controllers running Windows 2000 or Microsoft Windows
Server 2003 cannot take advantage of DFSR for replication of the SYSVOL,
so they must still use FRS. Windows Server 2008 does support DFSR for
SYSVOL replication, but all domain controllers must be running Windows
Server 2008 to take advantage of this new technology. If any domain
controllers in the domain are running Windows 2000 or Windows Server
2003, the Windows Server 2008 domain controllers must also use FRS to
support the limitations of the older operating systems.
Active Directory
replication is not controlled by DFSR or FRS. Instead, Active Directory
replication is controlled by its own replication service. Active
Directory replication is responsible for replicating the entire Active
Directory database, not just the GPC. Because changes occur with the
other objects in the database more than the GPC, the technology and
details of replication were designed for those other objects more so
than for Group Policy. With this said, the replication of Active
Directory is quite complex, with many moving parts and considerations. An in-depth overview of Active Directory
replication will explain how it affects and controls the GPC.
DFS
Another service
that Group Policy depends on is DFS. You might miss this service unless
you consider how DFS assists Group Policy in many different areas. If
you think that DFS publishing can assist Group Policy when software is
delivered through a GPO, you are correct. However, Group Policy does not
depend on this service in this regard—DFS is simply an enabling service in this scenario.
So, how exactly does
DFS function with Group Policy as a dependant service? DFS is the
service that makes the SYSVOL on the domain controllers available. Every
domain controller has the SYSVOL shared. There are two folders named
SYSVOL, and only one of them is shared. The path to the shared SYSVOL is
C:\Windows\SYSVOL\Sysvol.
This
share is not a routine share. Rather, it is a domain-based DFS share.
This type of share is very useful in situations in which all computers
in the domain need to access the same resource. If you are not familiar
with domain-based DFS, it has some significant advantages.
With domain-based DFS
shares, all computers access the share by using the domain name, instead
of the domain controller’s NetBIOS computer name or DNS fully qualified
domain name (FQDN). Therefore, all computers that communicate with
SYSVOL on the domain controllers (every computer in the domain) do so by
using \\domainname\sysvol.
Although this might seem
simplistic and limited in rewards, the power is in the technology
behind the scenes. With this form of communication to the domain
controller and SYSVOL, the names of the domain controllers are
irrelevant. Domain controllers can be added, removed, changed, taken
offline, brought back online, and so on without the existing connections
and mapped drives. As long as there is at least one domain controller
online for the computers to access, the computers on the network will be
able to communicate with the domain-based DFS share.
This is possible
because domain-based DFS shares are accessed through DNS. SRV records
that help the computer find the nearest domain controller are
automatically registered in DNS. The nearest domain controller is
relative, because DNS uses Active Directory sites, which represent
physical networks. When a computer receives a list of domain controllers
from DNS, the domain controllers in the computers’ sites are listed
first, followed by the other domain controllers.
This process and
technology allows computers to receive the GPT information for the GPOs
from the domain controllers. The process is very efficient for both
keeping track of the domain controllers and allowing the computers on
the network to find the closest domain controller to retrieve the Group
Policy information from SYSVOL.
New Group Policy Service
One of the major changes
that came with Windows Vista and is now being leveraged in Windows
Server 2008 is a new Group Policy service. Earlier operating systems
used the WinLogon service to run Group Policy. There were no inherent
problems with using WinLogon, but there are significant benefits to
using a separate service to control Group Policy. Considering the
emphasis that Microsoft is putting into Group Policy, with advanced
technologies being included in Group Policy and new management tools,
the move to a separate service was not surprising.
The new Group Policy
service improves the overall stability of the Group Policy
infrastructure and computer by completely isolating it from WinLogon.
The Group Policy service uses a completely new architecture for
performing notifications and processing Group Policy. Not only does the
Group Policy service change the architecture, it also adds these
benefits:
New
Group Policy–related files can be delivered to computers administrating
GPOs and computers consuming GPO settings without requiring a restart
of the operating system.
Group Policy application is more efficient because fewer resources are required for background processing.
Less
memory is used for Group Policy on computers consuming GPO settings,
increasing performance and eliminating the need to load Group Policy in
multiple services.
The Group Policy service is started automatically and cannot be disabled, which creates a more stable environment.
To find the service in running services, look for gpsvc, as shown in Figure 1.
