Group Policy Management Improvements in Windows Server "8" Beta

Group Policy Management Improvements in Windows Server "8" Beta

  • Comments 11
  • Likes

Hi all, Ned here again. If you've been supporting group policy for years, you’ve grown used to its behaviors. For something designed to manage an enterprise, its initial implementation wasn’t easy to manage itself. The Group Policy Management Console improved this greatly after Windows Server 2003, but there was room for enhancement.

Windows Server "8" Beta introduces a number of interesting Group Policy management changes to advance things. These include detecting overall replication consistency as well as remote policy refresh and easier resultant set of policy troubleshooting. Windows 8 Consumer Preview benefits from some of these changes as well.

Let's dig in.

Infrastructure Status

Once upon a time, someone wrote a Windows 2000 resource kit utility called gpotool.exe (no longer supported). It was supposed to tell you if the SYSVOL and AD portions of a group policy were synchronized on a given domain controller and between DCs in a domain. If it returned message "Policies OK", you were supposed to be golden.

Unfortunately, gpotool is not very bright or honest, which is why we do not recommend customers use it. It only checks the gpt.ini files in SYSVOL. Anyone who manages group policy knows that each GP GUID folder in SYSVOL contains many files critical to applying group policy. The gpt.ini existing is immaterial if the registry.pol does not exist or is some heinous stale version. Furthermore, gpotool bases everything on the gpt.ini version matching between AD and SYSVOL and alerting you if they don't. Except that the version matching alone has not mattered since Windows 2000 and file consistency checking is super important.

Enter Windows Server "8" Beta. When you fire up GPMC from a server or RSAT, then navigate to a domain node, you now see a new Status tab (more properly called the Group Policy Infrastructure Status tool). GPMC sets the DC it connected to as a baseline source of comparison. By default, that would be the PDC emulator, which GPMC tries to connect to first.

image

If you click Detect Now, the computer running GPMC directly reaches out to all the domain controllers in that domain using the LDAP and SMB protocols. It compares all the SYSVOL group policy file hashes, file counts, ACLs, and GPT versions against the baseline server. It also checks each DC's AD group policy object count, versions, and ACLS against the baseline. If everything is copacetic, you get the good news right there in the UI.

image

If it's not, you don't:

image

Note how the report renders above. If the Active Directory and SYSVOL columns are blank, the versions match between gpt and AD, and this means that the file hashes or security are out of sync (an indication of latency at the least); otherwise you will see version messages. If the FRS or DFSR service isn't running on a DC other than the baseline or SYSVOL is not shared, the SysVol message changes to Inaccessible. If you turn off a DC or NTDS service, the Active Directory field changes to Inaccessible. If you just deleted or added a group policy, the Active Directory field changes to Number of GPOS for comparison. It's all straightforward.

This new tool doesn’t grant permission to turn off your brain, of course. It's perfectly normal for AD and SYSVOL to be latent and out of sync between DCs for periods of time. Don't assume that because you see servers showing replication in progress that it is an error - that's why it specifically doesn't say “error” in GPMC. Finally, keep in mind that this new functionality version in the public Beta is naturally a bit unstable; feel free to report issues the Windows Server 8 Beta Forums along with detailed repro steps, and we can chat about if your issue is unknown. For example, stopping the DFSR service on the PDCE and then then clicking Detect Now to use that DC as the baseline terminates the MMC. Don’t take it too hard - work in progress, right? We'd love your feedback.

Moving right along…

Remote Policy Refresh

You can now use GPMC to target an OU and force group policy refresh on all of its computers and their currently logged on users. Simply right click any organizational unit and click Group Policy Update. The update occurs within 10 minutes (randomized on each targeted computer) in order to prevent crushing some poor DC in a branch office.

image

image

image

Windows Server "8" Beta Group Policy also updates the GroupPolicy PowerShell module to include a new cmdlet named Invoke-GpUpdate. If you examine its help, you see that it is very much like the classic gpupdate.exe. If you -force using invoke-gpupdate, you do the same as /force in gpupdate.exe, for instance.

NAME

Invoke-GPUpdate

SYNTAX

Invoke-GPUpdate [[-Computer] <string>] [[-RandomDelayInMinutes] <int>] [-AsJob] [-Boot] [-Force] [-LogOff] [-Target <string>] [<CommonParameters>]

Obviously, this cmdlet gives you much more control over the remote policy refresh process than GPMC. For instance, you can target a particular computer:

Invoke-gpupdate -computer <some computer>

Moreover, unlike the "within 10 minutes" pseudo-random behavior of GPMC, you can make the policy refresh happen right now and forcing group policy to update regardless of version changes. I don't know about you, but if I am interactively invoking a policy update for a given computer, I am not interested in waiting!

image

Since this is PowerShell, you have a great deal of flexibility compared to a purpose-built graphical or command-line tool. For example, you can get a list of computers with an arbitrary description then invoke against each one using a pipeline to for-eachobject, regardless of OU:

image

If you’re interested, this tool works by creating remote scheduled tasks. That's how it works for logged on users and with randomized refresh times. Another good reason to ensure the Task Scheduler service is running.

image

New RSOP Logging Data

I saved the best for last. The group policy resultant set of planning logs include a number of changes designed make troubleshooting and policy analysis easier. Just like in the last few versions of Windows, you can still use GPMC Group Policy Results or GPRESULT /H to gather an html log file showing how and what policy applied to a user and computer.

When you open that resulting html file, you now see an updated Summary section that provides better "at a glance" information on policy working or not and the type of network speeds detected. Even better is the new Component Status area. This shows you the time taken for each element of group policy processing to complete processing.

image

It also stores the associated operational event log activity under View Log that used to require you running gplogview.exe. Rather than parsing the event log with an Activity ID for the computer and user portions of policy processing, you just click the link to see it all unfold before you.

image

Finally, there is a change to the HTML result file for the applied policies. After 12 years, we’ve reached a point where there are thousands of individual Administrative template entries; far more than anyone could possibly remember or reliably discern from their titles. To make this easier, the Windows 8 version of the report now includes explanatory hotlinks to each of those policy entries.

image

By clicking the links in the report, you get the full Explanation text included with that policy entry. Like in this case, the new Primary Computer policy for roaming profiles (which I’ll discuss in a future post).

image

Nifty.

Key Point

Remote RSOP logging and Group Policy refresh require that you open firewall ports on the targeted computers. This means allowing inbound communication for RPC, WMI/DCOM, event logs, and scheduled tasks. You can enable the built-in Windows Advanced Firewall inbound rules:

  • Remote Policy Update
    • Remote Scheduled Tasks Management (RPC)
    • Remote Scheduled Tasks Management (RPC-EPMAP)
    • Windows Management Instrumentation (WMI-in)
  • Remote Policy Logging
    • Remote Event Log Management (NP-in)
    • Remote Event Log Management (RPC)
    • Remote Event Log Management (RPC-EPMAP)
    • Windows Management Instrumentation (WMI-in)

These are part of the “Remote Scheduled Tasks Management”, “Remote Event Log Management”, and “Windows Management Instrumentation” groups. These are TCP RPC port 135, named pipe port 445, and the dynamic ports associated with the endpoint mapper, like always.

Feedback and Beta Reminder

The place to send issues is the IT Pro TechNet forums. That engages everyone from our side through our main conduits and makes your feedback noticeable. Not all developers are readers of this blog, naturally.

Furthermore, remember that this article references a pre-release product. Microsoft does not support Windows 8 Consumer Preview or Windows Server "8" Beta in production environments unless you have a special agreement with Microsoft. Read that EULA you accepted when installing!

Until next time,

Ned “I used a fancy arrow!” Pyle

  • That looks very slick.  I love the remote gpupdate push.

    I still have yet to play much with Win 8 at all... I would hate for my opinions to be biased by a beta... as so many others have already. It seems like other people are already going through the 8 stages of grief (denial, outrage, acceptance, etc.) with Win 8, and it hasn't even come out yet.

  • Just curious when NetBios will no longer be used for AD ?  We were just looking at Win08R2 and it still uses it ?

    Thanks

  • @Ryan

    Thanks. I look at it from the perspective of "if I hate something in Beta and it's way better in RC, I am cheered up."

    @mn8026

    NetBIOS in Windows will end shortly after the sun goes supernova. :) What specifically are you seeing in AD, that's a very big place.

  • Regarding the part about logging the time spent processing GP components:

    indiana.laxallstars.com/.../Picard_full_of_win.jpg

    :)

  • "NetBIOS in Windows will end shortly after the sun goes supernova."

    So, you mean a little later this year...(According to the ancient Mayans)  Sweet!

  • Sweet, good stuff!  Glad to see the Win8 posts have been let out of the gate.  One question on the Remote Policy Refresh stuff.  Does it work with any older OS's?  If so, which?

  • Excellent question Steve. The answer is: sometimes

    Windows 7 works as long as you have the firewall rules set correctly and task scheduler running, just like Windows 8. The eventual scheduled tasks are created with gpupdate.exe.

    There is some remote DCOM happening here too though, and when I try to remote refresh an XP machine, it always fails with access denied. I haven't spent any time figuring this out, but I am fairly sure we're not testing that scenario because XP is as dead as fried chicken. See previous post. :)

  • Speaking of XP, I had to get a loaner laptop today as my system needed some love and attention.  I've been using XP for the day today, and geez does this feel old and weird!!

  • Oh, and thanks for the feedback as always Ned!  I'm actually a bit surprised to hear the mention of scheduled tasks, but I guess it's a reliable way to fire off the command without needing other services being functional.

  • Wait until you are using Windows 2003, 2008 R2, and Win8 server all at once.

    And here's a new one to get used to: I keep mousing over the start button in Win2008 and then staring at it, waiting for something to happen, because I don't have to click in Win8... gah!