Performing RSoP Calculations with the GPMC

In Chapter 1, we charted out a fictitious organization's GPO structure on paper. We looked and saw when various GPOs were going to apply to various user and computers. Charting out the RSoP (Resultant Set of Policies) for users and computers on paper is a handy skill for basic understanding of GPO organization and flow; but in the real world, you'll need a tool that can help you actually figure out what's going on at your client desktops.

The GPMC has a handy feature to show us all the GPOs that are going to apply for the users and computers at a specific level in Active Directory. In Figure 2.21, when you click the Human Resources Users OU and then click the " Group Policy Inheritance" tab, you can see a list of all the GPOs that should apply to the Human Resources Users OU.

Figure 2.21: The Group Policy Inheritance tab shows you which GPOs should apply.

The site level is not shown in this Group Policy Inheritance tab. Because computers, particularly laptops, can travel from site to site, it is impossible to know for sure what site to represent here.

As I said, this tab in Figure 2.21 should really tell you what's going to happen. The operative word here is should . That's because a lot can go wrong between your wishes and what actually happens on the client systems. For instance, you already saw how to filter GPOs using Security groups, which would certainly change the experience of one user versus another on the very same machine. And in Chapter 10, you'll learn about WMI filters, which limit when GPOs are applied even more.

The point of all this RSoP stuff is help us know the score about what's going on at machines that could be many hundreds of millimeters, meters , or kilometers away. When users freak out about getting settings they don't expect or when they freak out about lacking settings they expect, the point is to know which setting is causing the stir and which GPO is to blame for the errant setting.

We know one thing's for sure: users do freak out a lot if anything changes; and it's our job to douse water on the problem (but not the user or computer). So the point of performing an RSoP calculation is to help you know what is going on and why it's going on that way. The GPMC can help with that.

What's-Going-On Calculations with Group Policy Results

If someone calls you to report that an unexpected GPO is applying, you can find out what's going on via the GPMC. You can find out what's going on if the machine in question is a Windows XP, Windows 2003, and presumably later clients . Sorry, Windows 2000 computers are left in the dust.

Note 

Windows 2000 computers are not left in the dust for the what-if calculations with Group Policy Modeling in the next section.

Once the user with the problem has logged on to the machine in question, you can tap into the WMI provider built in to both Windows XP and Windows 2003. Without going too propeller-head here, the upshot of this magic is that the GPMC (and the GPRESULT command as you'll see in Chapter 4) can " pretend " to be any particular user that has ever logged on locally. It's then a simple matter to display the sexy results within the GPMC.

Tip 

Once the results are displayed, you can right-click over them and save then as an HTML report.

The magic happens when the computer asking "What's going on?" (in this case, the computer running the GPMC) asks the target client computer. The target client computer responds with a result of what has happened which GPOs were applied to the computer side and to the user side (provided the user has ever, at least once, logged on).

Let me expand on this important point: this Group Policy Results magic only works if the target user has ever logged on to the target machine. They only need to have ever logged on once, and here's the amazing part: They don't even need to be logged on while you run the test. But if the target user has never logged on to the target machine, the Group Policy Results will not allow you to select that user.

You can run your what's-going-on calculations inside the GPMC by right-clicking the Group Policy Results node at the bottom of the GPMC's hierarchy as shown in Figure 2.22. When you do, you can select the user and the computer and see their interaction.

Figure 2.22: The Group Policy Results Wizard performs What's-going-on calculations.

You need to remember the following before trying to run the Group Policy Results Wizard to figure out what's going on:

• The target computer must be Windows XP, Windows 2003, or later. Again, Windows 2000 machines are left out of the fun here.

• The target computer must be actually turned on and on the network. If this is not the case, you'll get an error regarding this fact. It will state that it cannot contact the WMI service via RPC.

• If the target machine is Windows XP / Service Pack 2 or Windows 2003 / Service Pack 1, the Windows Firewall must be disabled. Alternatively (in advance), you can open up port 135 on the target machine. See the sidebar entitled "Understanding Windows XP / SP2's Firewall Settings (and Dealing with Group Policy Results)" for some ideas on how to mitigate this. If the machine is unreachable because the firewall is blocking access to port 135, you'll get the same "RPC Error" as if the computer was off.

  Understanding Windows XP / SP2's Firewall Settings (and Dealing with Group Policy Results)

  Once SP2 is loaded upon Windows XP, the Windows Firewall is automatically engaged. As we just learned, getting Group Policy Results is effectively disabled when the Windows Firewall is engaged. It's like the target computer is turned off.

  There was always a firewall built in to Windows XP, but with Windows XP / Service Pack 2, the firewall is turned on by default. To boot, it's now much more controllable via Group Policy. The policy settings used to control the Windows Firewall can be found in two locations: Administrative Tem plates ˜ Network ˜ Network Connections ˜ Windows Firewall ˜ Domain Profile and Administrative Templates ˜ Network ˜ Network Connections ˜ Windows Firewall ˜ Standard Profile.

  You can see that the exact same policy settings are listed for both the Standard Profile and Domain Profile nodes. The Domain Profile settings are what will take effect when users are inside your corporate network; that is, when they're actively logged in by a Domain Controller. The Standard Profile, on the other hand, is used for when users are out of the office (perhaps in a hotel or other public network where they cannot reach your company's Domain Controllers for authentication.)

  Once a Windows XP / Service Pack 2 computer receives the policy settings for both the Domain Profile and Standard Profile, that computer is ready to travel both in and out of the office. You can be sure that machine is embracing your company's firewall security policy both in the office and on the road.

  If you're interested in learning more about how a computer makes a determination if it is supposed to use "Domain Profile" or "Standard Profile" policy settings, be sure to read Microsoft's document entitled Determination Behavior for Network- Related Group Policy Settings at www.microsoft.com/technet/community/ columns /cableguy/cg0504.mspx ( shortened to http://tinyurl.com/cao73) .

  You have three options if you want to restore the Group Policy Results functionality when you have Windows XP / SP2 clients. Note that if you cannot locate the following policy settings to control the Windows XP / SP2 firewall, be sure to read Chapter 5, which explains ADM Template management.

  Approach #1: Kill the Windows XP / SP2 firewall Now that you understand how to control Windows XP's Firewall Settings, one approach is to kill the firewall completely. If you do this, you understand that you're giving up any of the protection that Windows XP / SP2's firewall affords. However, by doing so, you will restore communication to the target Windows XP/SP2 computer. To kill the XP / SP2 firewall, drill down to Administrative Templates ˜ Network ˜ Network Connections ˜ Windows Firewall ˜ Domain Profile and select Windows Firewall: Protect all network Connections. But here's the thing. You don't Enable this policy to kill the firewall. You Disable it. Yes, you read that right, you Disable it. Read the Explaintext help inside the policy for more information on specific usage examples.

  Approach #2: Poke just the required holes in the Windows XP / SP2 firewall Instead of killing the firewall dead, you can simply open up the one port you need. Again, the idea is that if the target computer responds on port 135, you're golden. Windows XP/ Service Pack 2 has a new policy setting you can enable named Windows Firewall: Allow Remote Administration Exception , which is located in Computer Configuration ˜ Administrative Templates ˜ Network ˜ Net work Connections ˜ Windows Firewall ˜ Domain Profile. Again, when you do this, you're opening up the necessary port 135 (RPC). Note, however, that enabling this policy setting also opens up port 445 (SMB), which might be more than you need.

  Approach #3: Keep the firewall engaged, and don't use Group Policy Results You might opt for this third approach. That is, you really, really want to keep the firewall enabled and all ports closed on that target Windows XP machine. If so, how will you find out "what's going on" on a target machine? There are two ways, both explored a bit later. One way is to trot out to the machine (or take remote control of it somehow) and run the GPRESULT command, which will tell you what's going on. Or, you can use a tool called GPMonitor (which we explore in the Appendix.) The idea is to have the target machines periodically push their Group Policy Results data to a location of your choosing. So, even if they're behind a firewall, you're still periodically able to see what's going on.

   

• The Windows Management Instrumentation service must be started.

The user you want to find out about must have logged on to the target computer at least once to be eligible to perform a Group Policy Results calculation.

The output generated from the GPMC version when performing Group Policy Results RSoP calculations is quite powerful, as shown in Figure 2.23.

Figure 2.23: The Group Policy Results report shows lots of useful information.

Similar to the Settings tab, you can expand and contract the report by clicking Show and Side. Inside, you can clearly see which GPOs have been applied and any major errors along the way. At a glance, you can see which GPOs have Applied and which were Denied (passed over) for whatever reason, such as filtering or that one-half of the GPO was empty.

Tip 

The WMI filters category (shown in Figure 2.23) will not display data unless the target machine is running Windows 2003 or Windows XP with SP2.

If you click the Settings tab here, you get an extra bonus. That is, if there are conflicts along the scope of the GPO, you can see which other GPOs "won" in the contest for the ultimate Group Policy smackdown! Indeed, you can see this in Figure 2.24. Note, however, that the GPMC doesn't show you which GPOs "lost" when there is a conflict. This can sometimes mean more troubleshooting to determine other GPOs with conflicting settings. In Chapter 4, you'll learn how to locate "losing" GPOs.

Figure 2.24: If specific settings conflict, you can quickly determine which GPO "wins."

There are one or two caveats about Group Policy Results data. Specifically, when you produce a Group Policy Results report, some data simply isn't reported ! Specifically, here's what you won't see in a report:

• IPSec

• Wireless

• Disk Quotas

• Third-party add-ins

Note, however, that after the report runs, you can right-click on the entry for the report (located right under the Group Policy Results node, as seen in Figure 2.25) and select "Advanced View." When you do this, you'll see an alternate view of the report, which isn't HTML, but does show all the attributes -- even the stuff listed above which isn't normally reported. Since the report isn't HTML however, it's not really "portable" and you can't print it or send it in an email.

Figure 2.25: The Policy Events tab shows you events specific to this target computer.

Additionally useful here is the Policy Events tab, which will dive into the target machine's Event Viewer and pull out the events related to GPOs, as shown in Figure 2.25. Just double-click the event to open it. Talk about handy!

Tip 

In the actual description of the specific event code shown in figure 2.25, the text states that "an administrator has enabled logon optimization." This is really talking about Windows XP's "fast boot" and is enabled by default, You'll learn more about Windows XP and fast boot in Chapter 3.

The GPMC will also save the query so you can reuse it later if you want to retest your assumptions. For example, you might want to retry this after you've corrected your Software Installation failure, added a new GPO to the mix, or moved a machine from one OU to another.

Warning 

If you move a computer from one OU to another, you might not get the correct results right away, because the computer may not immediately recognize that it has been moved. If you move a computer from one OU to another, you might want to synchronize your Domain Controllers and then reboot the target machine to get accurate results right away. This is discussed in more detail in Chapter 3.

What-If Calculations with Group Policy Modeling

Finding out what's going on is useful if someone calls you in a panic. However, you might also want to plan for the future. For instance, would you be able to easily determine what would happen to the users inside the Human Resources Users OU if a somewhat indiscriminately named GPO called "Desktop Settings" was linked to it? Maybe or maybe not. (With a horribly named GPO like that, likely not.)

Or, what might happen if Frank Rizzo took a trip to another site? Which GPOs would apply to him then? Or which GPOs would apply if the HR-OU-Admins were granted (or revoked ) different security rights? The Oracle, er, the Group Policy Modeling Wizard found in the GPMC can answer a million of these questions. Its job is to answer "What happens if?"

This function is available only if the domain schema has been updated for Windows 2003 and you have at least one Windows 2003 Domain Controller available. This is because a Windows 2003 Domain Controller runs a service that must be running for the calculation to occur.

The best news about What-If calculations is that Windows 2000 computers aren't left out of the picture. The most accurate answers are achieved with Windows XP and Windows 2003 machines as clients because, again, they tap directly into the computer's soul with the WMI providers for GPOs. Windows 2000 doesn't have this provider, so a "best guess" is used in calculation.

Tip 

Windows XP-specific features and WMI filters are ignored when Windows 2000 clients are used with modeling calculations.

The only catch to this magic is that when you want to run What-If modeling calculations, the processing of the calculations must actually occur on a Windows 2003 Domain Controller. Even if you have the GPMC loaded on a Windows XP client, you'll still have to make contact with a Windows 2003 Domain Controller to assist in the calculations.

Warning 

This is the biggest warning icon the publisher gives me, but it isn't big enough for this message. If your Windows 2003 domain has been upgraded from Windows 2000, and you want to perform Group Policy Modeling between domains, it is likely it will not work without some manual attention. There are ACL permission problems on GPOs upon performing a domain upgrade. To fix the problem in a flash you run the GrantPermissionOnAl1GPOs .wsf script that is included with the GPMC. Specifically, you run cscript GrantPermissionOnAlIGPOs.wsf /FulIEdit "Enterprise Domain Controllers" This will "touch" all GPOs in SYSVOL, which will force replication to all Domain Controllers and, hence, may cause a lot of network traffic. This could be an issue with environments with many GPOs.

You can kick off a modeling session by right-clicking the domain or any OU (as well as the "Group Policy Modeling" node and selecting "Group Policy Modeling Wizard" When you do, you'll be presented with the Group Policy Modeling Wizard Welcome screen.

You then choose which Windows 2003 Domain Controller will have the honor of performing the calculation for you. It doesn't matter which Windows 2003 Domain Controller you chooseeven those in other domains. Just pick one. Just note that it does need to be a Windows 2003 Domain Controller and not anything less.

You'll then get to play Zeus and determine what would happen if you plucked a user and/ or computer out of a current situation and modified the circumstances. In the wizard screens, you get to choose the following:

• Which user and/or computer you want to start to play with

• Whether to pretend to apply slow-link processing (if not already present on the target)

• Whether to pretend to apply loopback processing (if not already present on the target)

• The site in which you want to pretend the object is starting

• Where to move the user (if the user account moves at all)

• Where to move the computer (if it moves at all)

• Whether to pretend to change the user's Security group membership

• Whether to pretend to change the computer's Security group membership

• Whether to pretend to apply WMI filters for users or computers (if not already present on the target)

Warning 

You will likely get inaccurate results if you try to do something that isn't really possible. For instance, you can force the wizard into seeing what happens if Frank Rizzo's account is moved to another domain. But, since there isn't a way to actually move Frank's account, the displayed results will be cockeyed. You'll learn more about some of the new concepts, such as slow-link processing and loopback processing in Chapter 3. You'll learn more about WMI filters in Chapter 10.

The output in Figure 2.26 shows what would happen if Frank Rizzo were removed from the Human Resources Users OU (and plopped into the root of the domain).

Figure 2.26: Here, the Group Policy Modeling summary screen shows you what you're about to simulate. For instance, you can simulate moving a computer and/or a user to other locations, among other scenarios.

What to Expect from the Group Policy Modeling Wizard

When you first use the Group Policy Modeling Wizard, you may be surprised to see that it has "Loopback," "WMI Filters," and "Slow Links" options. At first, I was curious about why these were options in the wizardif the wizard's whole job is to figure out what will be at the end of the simulation.

In a nutshell , the Group Policy Modeling Wizard allows you to simulate these additional items as if they all were actually going to be true. This way, you wouldn't have to create an OU and/or a GPO with the specific policy settings (Loopback, and so on) just to turn it on. This makes sense: if you enable these options on the real OU, you change the live environment.

The point of the Group Policy Modeling Wizard is to let you just simulate what if you did this on the target. When using the wizard and selecting Loopback, Slow Links, or WMI Filters, don't expect it to tell you that any of these things are true in the target. The simulation demonstrates what would happen if these properties came into the mix.

Note that the Group Policy Modeling Wizard is unable to take into account any Local Group Policy Object settings on the potential target workstation. That's because this wizard never actually queries a target computer. The calculations all happen on a Windows 2003 Domain Controller and are then outputted in the GPMC.

 

When the calculations are complete, you'll get a results dialog that looks quite similar to Figures 2.23 and 2.24. There, you can see how results will be displayed in both a Summary and Settings tabs. As a reminder, the Summary tab shows you which GPOs applied; the Settings tab shows you which policies inside the GPOs will "win" if there's a conflict. Present only in Group Policy Modeling output (not shown) is another item, called the Query tab, which can remind you of the choices you made when generating the query.