MCITP Exam Cram: Managing and Maintaining Systems That Run Windows Vista
Terms you'll need to understand:
- ✓ Active Directory (AD)
- ✓ Active Directory Users and Computers (ADUC)
- ✓ Local Computer Policy (LCP)
- ✓ Group Policy Object (GPO)
- ✓ AD Site
- ✓ AD Domain
- ✓ Organizational Unit (OU)
- ✓ L-S-D-OU-OU-OU
- ✓ Block Inheritance
- ✓ No Override/Enforced
- ✓ Group Policy Management Console (GPMC)
- ✓ Task Scheduler
- ✓ Event Viewer
- ✓ Event Subscriptions
- ✓ Windows Remote Management Service (WinRM)
- ✓ Windows Event Collector Utility (wecutil.exe)
- ✓ Reliability and Performance Monitor
- ✓ Data Collector Set
Techniques you'll need to master:
- ✓ Install and use the Group Policy Management Console
- ✓ Create, deploy, and troubleshoot Group Policy Objects (GPOs)
- ✓ Understand GPO processing
- ✓ Implement a Loopback GPO
- ✓ Implement an audit policy
- ✓ Implement a software deployment GPO
- ✓ Implement Device Restrictions by GPO
- ✓ Implement Software Restrictions by GPO
- ✓ Perform Resultant Set of Policies/Planning and Logging
- ✓ Schedule tasks with different triggers
- ✓ Understand Event Viewer
- ✓ Configure Event Forwarding from multiple Source computers to one Collector computer
- ✓ Configure Data Collector Sets in Performance Monitor
The tools that you must be familiar with and use in the management of Windows Vista computers in the enterprise are
- Active Directory Users and Computers (ADUC)
- Group Policy Management Console (GPMC)
- Group Policy Objects (GPO)
- Task Scheduler
- Event Viewer
- Reliability and Performance Monitor
As an enterprise support technician, you are responsible for management and maintenance of computers that run Windows Vista in the Enterprise. Your "heavy guns" in this administrative task are the Group Policy Objects (GPOs). You need to be fluent with their settings, the way they get processed, and the implementation and troubleshooting of GPOs in your enterprise environment.
The exam tests your knowledge of what settings are available, where to link the GPO, how to have the GPO apply to only selected computers or users, and how to troubleshoot them when you aren't getting what you expected from the GPOs.
Another tool that you use is the Task Scheduler. This tool launches tasks at a later and perhaps regularly scheduled time. This tool has changed significantly since the last versions of the Windows operating system.
There is impressive new capability in the Event Viewer. You probably won't even recognize it from earlier versions. It has a powerful, customizable filter that allows you to capture events of about any nature you can imagine. In addition to this capability, you can now aggregate events from remote computers onto a single monitoring system, through the use of Event Forwarding to an Event Collector and subscription services.
Finally, you look at the new and improved Reliability and Performance Monitor, where you configure counters to view and log performance parameters on the local and on remote computers. This new tool includes a collection of objects and counters to monitor a large number of system resources.
You can configure many of the configuration parameters in the Local Computer Policy (LCP) on each client computer that runs Windows Vista. In the corporate enterprise, remember that these numerous configuration settings can and typically should be centrally managed and deployed by GPOs within the Active Directory structure.
Some exam questions address a standalone Windows Vista computer, whereas others address the Windows Vista computer within an Active Directory environment. You need to know what security settings are available and how these controls affect the behavior of the Windows Vista computer in both cases. So put on your seatbelts and read on carefully.
Group Policy Object Overview
Policies are the way that computers are managed, either standalone computers or computers in the enterprise. Policies establish the vast majority of the configuration settings that control how the computer boots up and then how your desktop environment is constructed when you log on.
The Standalone Computer
Each computer has a Local Computer Policy, or LCP (also referred to as the Local GPO or LGPO), that is made up of many configuration settings on the various configuration dialog boxes throughout the user interface, as well as numerous settings that are configurable only in a Microsoft Management Console (MMC) called the Local Computer Policy. This policy is stored in the Registry on the computer's hard drive and is applied every time the computer is booted up. This computer configuration from the Local Computer Policy gets read into random access memory (RAM) on the computer. Think of this RAM copy of the Registry as the live, awake brain of the computer when it is booted up. This RAM copy of computer settings from the Registry is in place when you are presented with the Windows Graphical Identification aNd Authentication (GINA) dialog box.
Further configuration for the desktop environment is controlled by configuration parameters stored within your user profile in a file called NTUSER.DAT. NTUSER.DAT gets read into RAM from your profile folder when you successfully log on to the computer. As you make changes to your desktop environment, like the desktop wallpaper or items on the Start menu, these changes get recorded in the RAM copy of NTUSER.DAT. When you log off, by default, the operating system saves these changes into your profile. This file is the primary source of the configuration parameters that define your desktop environment.
The first time you log on to a computer, the operating system copies a read-only and hidden folder under C:\Users called \Default to a new folder under C:\Users and renames the new folder with your logon name. Within that folder is the file named NTUSER.DAT. This becomes your user profile on this specific computer. After that first logon on a given computer, now that you have an existing profile, this existing copy of NTUSER.DAT is the one that gets read into RAM for your user profile.
To summarize, two components define a desktop environment on a standalone computer (not participating within an Active Directory environment): the configuration parameters in the Local Computer Policy and the configuration parameters in your user profile. They get applied in that order.
The LCP can be accessed on a Windows Vista computer by building it into a new MMC.
Building a Local Computer Policy (LCP)
To build the Local Computer Policy (LCP) MMC, follow these steps:
- Click Start > Run, type MMC, and click OK. (You can also use Start > Start Search > MMC and then press Enter.)
- From the menu, select File > Add / Remove Snap-in.
- Select Group Policy Object snap-in and click Add.
- Accept the Group Policy Object for the Local Computer by clicking Finish.
- Click OK.
- From the menu, select File > Save As.
- Type LCP.msc and save the MMC either on the desktop or in Administrative Tools.
The Domain Member Computer
Back in the old days of the Windows NT domain and Windows 95 clients, Microsoft used something called System Policies, built using a tool called the System Policy Editor, to manage and configure these down-level computers. These System Policies would "tattoo" the Registry of the local box, actually writing settings to the Registry files on the local hard drive. If you wanted to remove policy settings from the computers, you had to write a new System Policy that would actually reverse the settings from the policy that was being removed.
When Windows 2000 was released, Microsoft implemented a whole new generation of policies and completely overhauled how they were applied on computers. These policies were improved yet again with the release of Windows XP, Windows Server 2003, and now again with Windows Vista. These new policies are called Group Policy Objects, or GPOs, and they exist in the Active Directory in an enterprise environment. These policies get applied to the computer over the top of the Local Computer Policy and your user profile settings to provide enterprise administrative dominance over the local configuration settings.
These new policies do not affect the configuration files on the hard drive (for the most part), so they do not "tattoo" the computer. Rather, as these new policies get applied, they modify the copy of the Registry (computer) and the profile (user) that has been read into RAM on the computer during the initial bootup and then the user logon for the current session. These modifications to settings do not get written back to the hard drive copies of the configuration files. Remember that this RAM copy is the actual functional copy that is being used to control and configure the user's current session.
Active Directory (AD) is a database and a collection of directory services that support the database and the network operating system. AD is created by configuring one or more domain controllers on a network. AD utilizes four types of containers to store and organize AD objects, like computers and users:
- Organizational Units
You can apply GPOs to sites, domains, and Organizational Units.
The AD forest is one or more AD domains that share a common schema. The schema is the structure of the AD database—not the data within the database, just the structure. The forest is created when you run DCPromo on a server to install your first domain controller in the first domain in the forest. This first domain is referred to as the forest root domain. The name of this forest root domain also is the name of the forest. All domains within the forest are trusted by and trusting of all other domains within the forest. Therefore, since members of your forest are, by default, all trusted and trusting, a lack of trust with some new domain indicates the need to generate a second forest, or create the new, untrusted domain in a different, existing forest. Forests are logical containers and have no real connection to any physical location, other than you must place your domain controllers somewhere. GPOs cannot be linked to the forest.
AD sites are created in AD once the forest is established and are defined as a collection of well-connected segments, where the bandwidth is at least local area network (LAN) speed. LAN speed is currently considered to be 10Mbps or greater. Any network link between segments that drops below LAN speed is defined as a boundary of the site and indicates the need for the creation of an additional site. Because sites are defined by physical connectivity, they are considered to be physical containers, with one site per location that is connected to AD by slower links. There are two major benefits to defining sites:
- Client computers within a site are preferentially directed to local (within the same site) resources.
- AD replication within the site happens without much regard for bandwidth consumption (because all segments are well connected at high bandwidth LAN speeds), but AD replication between sites, over slower wide area network (WAN) links, can be carefully controlled so as to avoid saturation of these lower bandwidth links. GPOs can be linked to sites.
AD domains are logical containers that are created within an AD forest. Domains (and AD) are created, and exist, on domain controllers. Domains in AD are security boundaries. In Windows Server 2003, they are defined by their unique namespace, like mobeer.com, buymeabeer.us, or boboville.com, as well as their single-password policy per domain. If you need a different namespace, you need another AD domain. If you need a different password policy for users, you need another AD domain. Domains are logical containers and can exist in multiple sites if placed in one or more domain controllers in more than one site. GPOs can be linked to the domain.
Organizational Units (OUs)
Organizational Units (OUs) are logical containers that are created within an AD domain. They are designed to be used to organize computers and users for two purposes: to delegate administrative authority of groups of computers and users to different administrators, and to provide grouping of computers and users for the assignment of different Group Policy Objects (GPOs). OUs can be nested within another parent OU, so they create a hierarchical structure, like the one shown in Figure 3.1. GPOs can be linked to Organizational Units.
Figure 3.1 The hierarchical structure of OUs in an Active Directory domain.
The OU is represented in AD Tools by a folder with a book icon on it. A folder without a book icon on it is not an OU but is an AD container that cannot have GPOs linked to it. By default, AD provides only one OU called the Domain Controllers OU so that security-related GPOs can be applied to this most sensitive class of servers. Administrators must create all other OUs.
Policies are applied in the order of L-S-D-OU-OU-OU. That is the Local policy, then site policies, then domain policies, and finally OU policies, starting with the top-level OU, and then followed by its child OU, and then its child OU, and so on.
Policies have two halves:
- A computer half, called the Computer Configuration
- A user half, called the User Configuration (see Figure 3.2)
Figure 3.2 Group Policy Objects can be applied to computers and users.
Applying GPOs to a Computer and User in an AD Environment
GPOs are applied to a computer and user in an AD environment as follows.
The computer is turned on. All the Local settings are read from the files on the local hard drive that make up the Registry and the Local Computer Policy (LCP) and are placed in RAM. Again, think of this RAM copy of the Registry as the live, awake brain for this session on the computer. This is the "L" part of the computer boot-up process.
Because the computer is a member of Active Directory, it contacts a domain controller for its domain and authenticates its computer account with AD. It then compares its IP address to IP subnets configured in AD sites to identify which site the computer is currently in. The computer then downloads and reads all GPOs for the site that it is currently in and applies only the computer half of those GPOs to the RAM copy of the Registry on the computer. (At this point in the bootup process, it cannot apply the user portion because there is no way to know what user will eventually be logging on.) If any Site level settings conflict with any Local settings, the Site level settings override the Local settings. This is the "S" part of the computer bootup process.
The computer then downloads and reads all GPOs for the domain that it is a member of and applies only the computer half of those GPOs to the RAM copy of the Registry on the computer. By default, if any Domain level settings conflict with any Local or Site level settings, the Domain level settings override the Local and Site level settings. This is the "D" part of the computer bootup process.
The computer then downloads and reads all GPOs for the top-level OU that its computer object resides in and applies only the computer half of those GPOs to the RAM copy of the Registry on the computer. By default, if any OU level settings conflict with any Local, Site, or Domain level settings, the OU level settings override the Local, Site, and Domain level settings. This is the "OU" part of the computer bootup process.
The computer repeats this process for each level OU that it may reside within. If the computer object for the computer resides in the top-level OU, these are the only OU GPOs to be processed. If the computer object for the computer resides in the third-level OU, the top-level OU GPOs are processed, then the second-level OU GPOs are processed, and finally the third-level OU GPOs are processed. By default, the last GPO that gets applied overrides all conflicts with previously applied GPOs.
Again, these GPO policies get applied to the computer over the top of the Local Computer Policy settings to provide enterprise (AD) administrative dominance over the local configuration settings.
When all appropriate OU GPOs are processed, the Windows GINA dialog box is presented, and finally you are allowed to attempt to log on.
You are prompted to press and hold the Ctrl+Alt keys and then press the Del key to initialize the logon process, as shown in Figure 3.3. You then provide your identity information, your username and password, and click Enter.
Figure 3.3 You provide your identity information, your username and password, and then click Enter.
When your identity information is accepted as valid by a domain controller, you are authenticated, and the L-S-D-OU-OU process begins all over again. Only this time it uses your user profile (L) and the user half of the S, D, and OU GPOs, as follows.
The user profile settings are read from the files on the local hard drive and are placed in RAM. This is the "L" part of the user logon process.
The computer again compares its IP address to IP subnets configured in AD sites to identify which site the computer is currently in. The computer then downloads and reads all GPOs for the site that it is currently in and applies only the user half of those GPOs to the RAM copy of the Registry on the computer. If any Site level settings conflict with any Local settings, the Site level settings override the Local settings. This is the "S" part of the user logon process.
The user object can be located in a different OU and even a different domain than the computer object, but because you are logging on to the computer, you must be in the same physical location as the computer and are subject to the computer's Site level GPOs.
The computer then contacts a domain controller for the domain that you are a member of and downloads and reads all GPOs for your domain. The computer applies only the user half of those GPOs to the RAM copy of the Registry on the computer. By default, if any Domain level settings conflict with any Local or Site level settings, the Domain level settings override the Local and Site level settings. This is the "D" part of the user logon process.
The computer then downloads and reads all GPOs for the top-level OU that the user account object resides in and applies only the user half of those GPOs to the RAM copy of the Registry on the computer. By default, if any OU level settings conflict with any Local, Site, or Domain level settings, the OU level settings override the Local, Site, and Domain level settings. This is the "OU" part of the user logon process.
The computer repeats this process for each level OU that the user account object may reside within. If the user account object resides in the top-level OU, these are the only OU GPOs to be processed. If the user account object for the computer resides in the third-level OU, then the top-level OU GPOs are processed, followed by the second-level OU GPOs, and finally the third-level OU GPOs are processed. By default, the last GPO that gets applied overrides all conflicts with previously applied GPOs.
Once again, these policies get applied to the RAM copy of the Registry on the computer over the top of the User Profile settings to provide enterprise (AD) administrative dominance over the local configuration settings.
Now you (finally) get your desktop and can begin working.
And If That Isn't Enough: Enforced, Block Inheritance, and Slow Link Detection
With all the different GPOs that can be applied to a computer and user, some settings in the different GPOs are bound to conflict. Suppose at the site level, a GPO sets the desktop wallpaper for all computers in the site to the company logo wallpaper. And then some domain administrator sets a GPO at the domain level so that the desktop wallpaper for all domain computers is a picture of the domain's softball team. By default, if any settings in the numerous GPOs conflict, the last GPO that gets applied wins the conflict.
This sounds like the lowliest administrator in charge of two or three computers and a few users in an OU can overrule the highest level enterprise administrator in charge of hundreds or thousands of computers and users. If left to the defaults, this is true. However, there is a setting called Enforced on each GPO. If this setting is enabled (it is not enabled by default), it locks every setting that is configured in the GPO, and no GPO that follows can override these locked settings. So with the Enforced setting enabled on GPOs, the first Enforced GPO that gets applied wins all conflicts. This is a top-down mechanism.
Another configurable setting regarding GPO processing is a bottom-up mechanism. If an administrator at a domain or some OU level does not want any previously applied, non-Enforced GPOs to affect his computers and users, he can enable a setting called Block Inheritance on the domain or the OU. This setting turns off processing of all GPOs from higher-level containers that are not Enforced. Remember, though, that a GPO with the Enforced setting enabled blows right past the Block Inheritance setting and is still processed by all computers and users in all child containers, even if the Block Inheritance setting is enabled.
One more parameter that changes the way GPOs are processed has to do with the bandwidth connecting the client computer to the domain controllers. Because some GPOs trigger a large amount of network traffic—a software deployment and folder redirection GPOs, for example—an evaluation of the bandwidth of the link to AD is performed before processing any GPOs. This is referred to as Slow Link Detection. If the link speed is below 500Kbps, the default data rate for a slow link, software GPOs do not deploy software, and folder redirection GPOs do not relocate folders. If a computer cannot identify the bandwidth of the link to AD, it assumes that it is using a slow link and may not process all appropriate GPOs, like the software deployment GPOs.
GPO Refresh, Loopback GPO Processing, and Turning Off the "L"
A few settings within the GPO also can affect the way this GPO processing happens. The first one is called the GPO Refresh. GPOs are applied to the computer during its bootup and then to the user during logon. They also get reapplied on a regular interval to ensure that new GPOs take effect quickly.
By default, GPOs refresh on member servers, member client computers, and domain users every 90 minutes, plus a random offset of 0 to 30 minutes (90 to 120 minutes). GPOs refresh on domain controllers every 5 minutes and have no random offset. These default refresh intervals can be adjusted within the GPO to affect all future refresh intervals. You can make this adjustment under User Configuration > Administrative Templates > System > Group Policy for the user refresh, and under Computer Configuration > Administrative Templates > System > Group Policy for domain member servers, domain member client computers, and domain controllers, as shown in Figure 3.4.
Figure 3.4 Determining the Group Policy refresh interval settings.
Another tool within a GPO that affects the way GPOs get processed is called Loopback, and it has two modes: Merge and Replace.
With Loopback Merge mode enabled, after the GPO processing described earlier (L-S-D-OU-OU-OU for the computer and then L-S-D-OU-OU-OU again for the user) completes, Loopback Merge mode kicks in and reapplies the computer settings, just in case any user settings conflict with any computer settings. Remember, the last GPO that applies wins conflicts, by default. User GPOs apply after computer GPOs by default. Loopback reapplies the computer settings to win any conflicts with user settings.
With Loopback Replace mode enabled, after the GPO processing described earlier completes, Loopback Replace mode kicks in and reapplies the computer settings, just in case any user settings conflict with any computer settings. Then Loopback Replace mode throws away every user GPO setting that has been applied, and it processes the user half of all GPOs (S-D-OU-OU-OU) that apply to the computer's position in AD, not the user's position in AD. The Loopback processing GPO is shown in Figure 3.5.
Figure 3.5 Using Loopback Merge mode or Loopback Replace mode to minimize or eliminate user GPO settings.
Another GPO setting that affects GPO processing is used to turn off Local Group Policy objects processing. You can access this setting under Computer Configuration\Administrative Templates\System\Group Policy in the Group Policy Management Console running on a Windows Vista computer, as shown in Figure 3.6.
Figure 3.6 Disabling the processing of the Local Computer Policy.
You can access the Group Policy Management Console (GPMC), as shown in Figure 3.7, on a Windows Vista computer by building a new MMC.
Figure 3.7 Accessing the Group Policy Management Console.
Building the Group Policy Management Console (GPMC) MMC
To build the Group Policy Management Console (GPMC) MMC, follow these steps:
- Click Start > Run, type MMC, and click OK. (You can use Start > Start Search > MMC > and click Enter.)
- From the menu, select File > Add / Remove Snap-in.
- Select Group Policy Management snap-in and click Add.
- Click OK.
- From the menu, select File > Save As.
- Type the name GPMC.msc and save the MMC either on the desktop or in Administrative Tools.
To create a new GPO in the GPMC tool, follow these steps:
- Expand Forest, Domains, and your domain name.
- Right-click the folder Group Policy Objects and select New.
- Give your new GPO a descriptive name so that you know what is configured in the GPO.
To edit the new GPO, right-click the new GPO in the Group Policy Objects folder and select Edit. This opens the GPO in the Group Policy Object Editor (GPOE).
To link a GPO to a site, domain, or OU in the GPMC tool, follow these steps:
- Expand the appropriate folder to be able to view the target container.
- Click the desired GPO and drag it to the target container and release. This creates a link between the GPO and the container.