So now let's look how the resultant set of policy or are soapy tools within Windows can help with troubleshooting
challenges that we have?
So resultant set of policy comes in two flavors, if you will.
The first is called RCP modeling, and this is a feature that tells you what should happen from a group
policy processing perspective on a given system.
And it's basically kind of an analysis tool that lets you before you've deployed a policy or before
you've made a change, lets you essentially do some analysis of group policy and see what's going to
happen.
It actually runs against a DC in your environment.
So any DC that it can find will run against it.
Does the modeling at the DC and it lets you place sort of a what if scenario with some group policy
processing conditions like slow link and loopback.
And you can also sort of do it against the whole or you rather than picking a specific machine or user.
Now.
The other flavor of our soap is our soap logging.
Our soapy logging is also called group policy results, and this is the feature that tells you what
has happened on a given target system.
So you run it against an actual system and it gathers up all the ah soapy data that the clients or extensions
have logged for the last GP processing cycle.
And it shows what worked and what didn't from my group policy processing perspective.
One thing to note about it, and this is also true with our soapy modeling, is that our soap in general
only shows you the winning settings or the setting that were actually delivered to the system or will
be delivered.
It doesn't show you, for example, settings that are in conflict with the winning settings from other
GPOs.
Now the requirements to run are soapy.
For our soapy modelling you need at least one 2003 R to DC in the domain.
This shouldn't be a problem for most folks, given where a two hour or 2003 is these days.
You need those delegated rights that I talked about in the previous module on delegation to be able
to do group policy modeling, and that those rights have to be at the container where you're modeling,
whether it's an O.U.
Or a particular machine or user.
It does not require GP processing to have happened for either the user or the computer.
So this is going to be different from what you need for group policy results or ah, soapie logging,
which I'll talk about in a second.
So with our soapy logging, what you need is you need to be able to connect to that target system over
WMI using the decon protocol.
So what this means is if you have a firewall on your client systems, it needs to be able to allow either
what's called the remote administration exception or the WMI com exception in the firewall so that you
can get access to via WMI the ah soapy data on that system.
So without this access, RSVP will simply fail, usually with a message that says our PC server unavailable.
It needs those delegated rights, just like our soapy modeling does.
So you just need to have rights over the container for that you're modelling against and for a given
user, if you're trying to find out if Joe Sales got a specific set up policy on the win client, that
user has to have at least logged into the system once and processed policy in order to get our soapie
data from them.
So that's pretty self-evident.
But it is something to keep in mind.
If you're looking for data from a particular user, that user has to have logged into the machine that
you're reporting against.
So when to use our soap?
So RCP modeling is it's kind of a good tool for analyzing the effect of future changes.
Now, what it doesn't do is, is it doesn't let you modify the settings in the GPO to say, what if
I added the setting to this GPO?
It doesn't do that.
It only takes the current sets of GPOs that are available and it lets you make changes, theoretical
changes to, for example, security groups where WMR filters that are linked to the GPOs or whether
a slow link was detected or a loopback was detected.
And so it's of limited value for doing settings.
What if analysis?
But it lets you do some of that and at least lets you see what settings will be on a system.
I find that I use it much less than I use RCP logging or GP results, but it is something out there
as a tool for you to use when you're making changes to your environment.
Now RCP logging.
On the other hand, I consider this the first line of defense for group policy troubleshooting.
So this is the go to tool that I use.
Whenever I'm trying to figure out where there are problems in group policy, this is the very first
thing I will run.
And what it does is it tells you what's actually happened on the system during the last group policy
processing cycle.
So it's only telling you what happened during the last cycle, but it's giving you that kind of at on
the ground information about what's going on, on the system and there's ways to run that group policy
results or RSP login.
The first is through the group policy results node, and this is in M.S. and then the second is in a
command line tool called Pre-salt Dot XY.
And I'll show you both of these methods in a second.
The command line version.
Some people really like it because it's command line.
I find it to be hard to read and hard to get information out of.
I much prefer the version in group policy management console, but the command line version is available
for getting some basic information.
So let's go ahead and dive in and actually play around with these tools and see how they work in practice.