This post was written by Judith, a technical writer for Group Policy. This is the second post in a series on ways to use Powershell with Group Policy. See the first post on getting started with RSAT and Group Policy

Let’s say I have a forest and I’d like to document a listing of all the GPOs in that forest. And maybe be able to list the GPOs mapped to the domain the GPO is created in.

I can start with the Get-ADForest cmdlet which creates an object for the forest I’m logged into. This object has a Domains property. How do I know this? I can find this out by running:

Get-ADForest | Get-Member

Once I know that I can get a list of all the domains in the forest using the Domains property, I can pipe those domain names into the Get-GPO cmdlet to find the names of all GPOs for each domain in the forest.

Here’s how it works out in one long line:

(get-ADForest).domains |foreach { get-GPO -all -Domain $_| Select-Object @{n='Domain Name';e={$_.DomainName}}, @{n='GPO Name';e={$_.DisplayName}} }

The Select-Object cmdlet is used to create an associative array that maps the domain name with the GPO name.

For a sample domain called corp.Contoso.com, with a child domain of HQ.corp.Contoso.com, with one test GPO named testGPO, I would get a listing that looks like this:

Domain Name         GPO Name-------------------

corp.contoso.com     Default Domain Policy

corp.contoso.com     testGPO

corp.contoso.com     Default Domain Controllers Policy

HQ.corp.contoso.com Default Domain Policy

HQ.corp.contoso.com Default Domain Controllers Policy

Pipe the output of this command to the Out-Gridview cmdlet to get a spreadsheet style listing of GPOs for each domain in the forest.

(get-ADForest).domains |foreach { get-GPO -all -Domain $_| Select-Object @{n='Domain Name';e={$_.DomainName}}, @{n='GPO Name';e={$_.DisplayName}} } | Out-Gridview

You might have seen GP MVP Jeremy Moskowitz’s post on how to recycle GPO comments. While Jeremy points out you can do this without a script…. You can also do it with a script! Our tech writer, Judith, walks us through the process:

After I import the Group Policy module in PowerShell, I have access to the Get-GPO cmdlet. If I run that to create an object representing my test GPO:

PS C:\ >$testGPO= Get-GPO testGPO

PS C:\ >$testGPO

DisplayName : testGPO

DomainName : corp.contoso.com

Owner : CORP3\Domain Admins

Id : 4364e8c5-23a0-4020-9624-4dbcaac9c8c2

GpoStatus : AllSettingsEnabled

Description :

CreationTime : 5/9/201110:07:09 AM

ModificationTime : 6/27/20113:51:20 PM

UserVersion : AD Version: 1, SysVol Version: 1

ComputerVersion : AD Version: 1, SysVol Version: 1

WmiFilter :

I was pretty sure that Description would show the comment for the GPO. And I ran the Get-Member cmdlet against the $testGPO object just to verify that I can use the Description property to set the comment using PowerShell.

PS C:\ >$testGPO| gm -Membertype property

    TypeName: Microsoft.GroupPolicy.Gpo

    Name MemberType Definition

    ------------------------

    Computer Property Microsoft.GroupPolicy.ComputerConfiguration Computer {get;}

    CreationTime Property System.DateTime CreationTime {get;}

    Description Property System.String Description {get;set;}

    DisplayName Property System.String DisplayName {get;set;}

    DomainName Property System.String DomainName {get;}

    GpoStatus Property Microsoft.GroupPolicy.GpoStatus GpoStatus {get;set;}

    Id Property System.Guid Id {get;}

    ModificationTime Property System.DateTime ModificationTime {get;}

    Owner Property System.String Owner {get;}

    Path Property System.String Path {get;}

    User Property Microsoft.GroupPolicy.UserConfiguration User {get;}

    WmiFilter Property Microsoft.GroupPolicy.WmiFilter WmiFilter {get;set;}

Then I changed the comment by setting $testGPO.Description to a string value, which just looks like a simple assignment:

PS C:\ >$testGPO.description="This is my test GPO. I'm using this to try out GP and PowerShell."

PS C:\ >$testGPO

    DisplayName : testGPO

    DomainName : corp.contoso.com

    Owner : CORP3\Domain Admins

    Id : 4364e8c5-23a0-4020-9624-4dbcaac9c8c2

    GpoStatus : AllSettingsEnabled

    Description : This is my test GPO. I'm using this to try out GP and PowerShell.

    CreationTime : 5/9/201110:07:09 AM

    ModificationTime : 6/27/20113:51:20 PM

    UserVersion : AD Version: 1, SysVol Version: 1

    ComputerVersion : AD Version: 1, SysVol Version: 1

    WmiFilter :

Here’s the GPMC snapshot before changing the comment:

And here’s the GPMC snapshot after I changed the comment:

The latest Group Policy settings reference spreadsheet that covers the available administrative template settings and security settings for Windows Server “8” Beta, Windows 8 Consumer Preview and all earlier versions of Windows is now available in the download center here: http://download.microsoft.com/download/8/F/B/8FBD2E85-8852-45EC-8465-92756EBD9365/WindowsServer8BetaandWindows8ConsumerPreviewGroupPolicySettings.xlsx

To see the description of what is contained in this latest version before downloading, go here: http://www.microsoft.com/download/en/details.aspx?id=25250

The Group Policy settings reference spreadsheet that covers
the available administrative template settings and security settings for
Windows Server 2012, Windows 8, and all earlier versions of Windows is now
available in the download center here: http://go.microsoft.com/fwlink/?LinkId=261775.

New to This Spreadsheet

The Administrative Template spreadsheet contains a new column:

• Status: A “New” in this column means
  that the setting did not exist prior to Windows Server 2012 and Windows 8. It
  does not mean that the setting applies only to Windows Server 2012 and Windows
  8. Refer to the column entitled “supported on” to determine to which
  operating system the policy setting applies.

To see the full description of what is contained in this
latest version before downloading, go here: http://www.microsoft.com/download/en/details.aspx?id=25250

Now that Windows 8 and Windows Server 2012 have been released, we’d like to share with you some of the exciting enhancements that we’ve added for Group Policy.

While we hear plenty of great things from people who use Group Policy, we also hear complaints. By far the largest complaint we hear about Group Policy has to do with troubleshooting GP. Our main goal for Server 2012 was to improve the troubleshooting experience.

We added 3 new features to make your life as a GP admin easier. In the next week we’ll detail each of these improvements in their own blog post, but for now here’s a quick overview.

· Remote GP Update: Allow you to remotely update policy on one client computer or an entire OU, through the GPMC or through Powershell

· GP Results Report improvements: We’ve changed the layout and added a bunch of new information to the results report, including relevant events, specific callouts for disabled user/computer sections, extension processing time, and more!

· Infrastructure Status: We’ve made it easy to check in on replication status to make sure GPOs are propagating properly.

If you just can’t wait to learn more, there’s additional documentation of new features here: http://technet.microsoft.com/en-us/library/hh831791.aspx

Group Policy in Windows Server 2012: Using Remote GPUpdate

If someone calls to say their computer doesn’t work quite right, the first thing you might have them do is run gpupdate /force to ensure they have the latest policy applied to their system. Now, you have the power to reach out and force a gpupdate without needing to be at the computer, remote in, or ask the user do it themselves.

The way remote gpupdate works is this: It creates a task through task scheduler. The task will execute within the next 10 minutes, which runs the GPUpdate locally on the machine. This will work on Vista and beyond.

Because this feature uses a remote connection, in order to use it you will need the following firewall rules enabled on clients.

· Remote Scheduled Tasks Management (RPC)

· Remote Scheduled Tasks Management (RPC-EPMAP)

· Windows Management Instrumentation (WMI-In)

Once you have these firewall rules applied to your clients, there are two ways you can invoke a remote Group Policy update.

Remote GP Update Wizard

From the GPMC, right click on an OU that contains computer objects.

Click the “Group Policy Update” option.

This will run a gpupdate /force on all computers in the OU, and any subOUs. Computer policy will be refreshed for each computer, and user policy will be refreshed for any and all users currently logged into those computers.

The “success” and “failure” headers indicate how many computers were contacted and had the event planted on the computer. It does not indicate that those computers have already run gpupdate – just that they have successfully scheduled the update for some time in the next 10 minutes. In this case, I intentionally sabotaged one of my clients to demonstrate what failure looks like – you see an error code and a description, and you can “Save” your results to a .csv file to review what computers succeeded and did not succeed in receiving the task.

Powershell

The other option is to use Group Policy’s new PowerShell cmdlets. The Invoke-gpupdate cmdlet is part of the Group Policy Powershell Module that is installed when you install the Group Policy Management Feature on a machine.

This cmdlet gives you more flexibility with how Group Policy is updated. You can use all of the gpupdate parameters you may be familiar with, plus you can use the new remote GP update functionality to target one computer – or write a script that targets many computers.

An example of the most basic use of invoke-gpupdate:

Import-module groupPolicy

Invoke-gpupdate computername

The completion of this cmdlet will put a task on the computer that will execute a gpupdate /force

Another change we made in Windows Server 2012 is in the Resultant Set of Policy reports. In previous versions of Server, you had to look at the results report, and the event log, and the tracing logs to find all the information you needed about why policy did or did not apply. Now, we’ve consolidated most of that information right into the results report to make troubleshooting Group Policy easier.

The biggest change we made is to the Summary section.

Here’s what the summary section used to look like:

And here’s what it looks like now:

As you can see, we summarized important information that was previously difficult to find, like loopback mode, slow link detection, and GPOs with enforce (or have block inheritance enabled)

We also added information to the computer/user details. Now we show how long client side extensions take to process, the last time an extension processed and detailed event log information from the latest pass of policy.

We also added more detail to the report, including sorting information by GPO, showing where the GPOs were linked, and reporting on modifiers like “enforced” or “disabled”.

How you run the GP results report hasn’t changed. If you choose to run it from the GPMC against a remote client, the client needs the following firewall ports opened:

· Remote Event Log Management (NP-In)

· Remote Event Log Management (RPC)

· Remote Event Log Management (RPC_EPMAP)

· Windows Management Instrumentation (WMI-In)

Running it this way against a downlevel client still gets you the new format and most of the new information.

The command line GP results functionality still works. You can run gpresult.exe /h out.html on a client machine to have the report created as out.html. However, this will only get you the new format and information when it’s run on a Windows “8” machine.

You may be asking yourself, “What does infrastructure status have to do with Group Policy”. Well, group policy depends on other technologies to ensure that policy settings are replicated throughout your environment so that end users / computers will get the settings that you configure.

And when you’ve run into problems you start wondering: did replication finish? Are there errors? And if there are, how am I supposed to see what errors have happened?

Since you are a GP admin and not necessarily an AD/DFSR admin, you only want to know that all of the replication that is supposed to be happening for Group Policy Objects is happening. In Windows Server 2012 we have added a feature that will tell you just this.

The feature is called Infrastructure Status and you can find it in the GPMC results pane for each domain object. Simply click the domain that you are interested in and in the result pane you will see a new tab labeled “Status”. This “status” tab will show the status of GPO replication (for both SYSVOL and AD) of all GPOs across your entire domain.

If you suspect you have a replication problem with a single GPO, to speed up your troubleshooting, you can check the infrastructure health status for that GPO. To see the status, open the Group Policy Objects node and select the GPO listed under that node.

Note: The infrastructure health status is not available when you click on GPO links displayed under the domain and OU nodes.

Initially, the Status tab will not have any information about replication status. Once you hit “detect now”, the GPMC contacts all domain controllers in your domain and collects information about Group Policy Object(s) from AD and SYSVOL. It uses a “baseline” domain controller to compare GPO information against GPO information from all other domain controllers. The baseline domain controller defaults to the DC that the GPMC is connected to but can be changed by clicking Change.

The first level of information will show the number of domain controllers that have GPO information “In Synch” with the baseline domain controller and the number of domain controllers that have GPO information that is “In Progress”. Domain controllers that are “In Synch” have all of the same GPO information as the baseline DC. Domain controllers that are “In Progress” do not have all of the same GPO information as the baseline DC. This may mean that there is a problem with GPO replication but it also may mean that replication just has not converged yet. For those DCs that are “In Progress” additional details are provided which explain exactly what is not in sync. The following is the list of reasons a DC can be “In Progress”:

Within the details of each of the errors a link is provided to help you further investigate why the DC is not In Sync.

Group Policy can be very difficult to troubleshoot and we hope that this feature allows you to find and resolve GP related replication issues more quickly.

This blog post is written by Judith, our technical writer, and based on an old blog post by Jeffrey Snover. (http://blogs.msdn.com/b/powershell/archive/2007/01/11/sorting-out-groupby.aspx) Jeffrey wrote a piece that showed how to sort system services with the Format-Table (ft) cmdlet and the –GroupBy parameter.

This is one of those tidbits that when I come across them I wonder how I can use this for making it easier to create Group Policy reports. So, here’s what I’m thinking:

If you administer Group Policy in a somewhat large enterprise then you’ve probably got hundreds, if not thousands, of GPOs to deal with.

If you’re like me, I used to grab a listing of GPOs, throw the listing into Excel and start playing games with the data. Well, what if you could pretty quickly grab GPO data on the fly and play some games with it?

More importantly, what if you could grab GPO data on the fly, not just for a single domain, but for your whole forest? But wait, you say. We already did that. Actually, I already wrote a blog post on how to list all the GPOs for a forest. And if you haven’t read that, you can find it here: http://blogs.technet.com/b/grouppolicy/archive/2011/06/10/listing-all-gpos-in-the-current-forest.aspx.

But what if you could look for all the GPOs in your entire forest and list them based on the GPO status? In other words, list all GPOs in a forest with the disabled or partially disabled GPOs grouped separately. And you can do this in a single line of Windows PowerShell. Would you find that interesting? If you agree that this would be helpful then read on.

Jeffrey in his blog post explained that the Format-Table cmdlet has a parameter –GroupBy that tells Format-Table to generate a series of tables instead of one big table. These tables will be based on the –GroupBy parameter.

Big note here. Before we get into the guts of the blog post, you need to remember to import both the Group Policy and Active Directory modules before running these cmdlets. In other words, GPMC is installed on server or client and Active Directory role is installed on server or AD tools are installed on client. Then from the Windows PowerShell command prompt, I need to run these two commands at the start of my session:

Import-Module ActiveDirectory

Import-Module GroupPolicy

I still have my little test domain called, corp.Contoso.com, with a child domain of HQ.corp.Contoso.com. And I can very easily use the Get-GPO cmdlet with the –all parameter to see all the GPOs in the entire forest with the following command:

(get-ADForest).domains | foreach { get-GPO -all -Domain $_ }

This will display all the GPO information, but it will come as the GPOs are read from each domain.

Now, it becomes clear why I started this blog mentioning Jeffrey Snover’s blog post about sorting a table using the –GroupBy parameter. I want to see all the GPO information grouped by the status of each GPO. What happens if I add Format-Table (with alias of ft) using the –GroupBy parameter to the end of my previous command line?

(get-ADForest).domains | foreach { get-GPO -all -Domain $_ } | Format-Table -GroupBy GpoStatus

This will group the GPOs, but not quite as I expected. Instead of one table for AllSettingsEnabled, another for AllSettingsDisabled, etc., I seem to be getting clumps of GPOs based on status. You can see that in this partial display.

There’s a technical reason that Jeffrey goes into in his blog post. But the short answer is that the Format-Table cmdlet processes the input as it comes to the cmdlet. There’s no place to hold the input in order to group all of the results together at once. Presorting the information in this case will get us what we really want.

I want to make sure the GPO status is sorted first. Then it’s a toss-up of whether I want to see GPOs in alphabetical order based on the display name or an alphabetized list of GPOs first grouped by domain. For this example, I’m going to list the GPOs in alphabetical order within the GPO status groups. I’ll leave it up to you to play with changing the order of the sort to see what happens.

(get-ADForest).domains | foreach { get-GPO -all -Domain $_ } | sort GpoStatus, DisplayName | Format-Table -GroupBy GpoStatus

Now, we get what we wanted a series of tables that show GPOS based on status: AllSettingsDisabled, UserSettingsDisabled, ComputerSettingsDisabled, and AllSettingsEnabled. Much better.

My only problem with this is I can’t see all the data because my screen isn’t wide enough. The other way of displaying all the data for GPOs worked better in this case. So, how can I group by GpoStatus, and get all my data?

The answer is once again pretty simple. The –GroupBy parameter also works for Format-List.

Running the following command gives me the results I want:

(get-ADForest).domains | foreach { get-GPO -all -Domain $_ } | sort GpoStatus, DisplayName | Format-List -GroupBy GpoStatus

You can try grouping by other things than GpoStatus. For example, you can DomainName, Owner, or WmiFilter. Or try sorting by CreationTime or ModificationTime.

We have a new document in our technet library. The Core Network Companion Guide has a section specifically about Group Policy Deployment. Check it out! Or just take a look at James McIllece’s blog post summarizing the deployment guide companion.

You can make decisions as you design and deploy your Group Policy Objects (GPOs) that will have an impact on how quickly your Windows desktops start and become usable to your users. Some of these decisions are obvious, while many are not. This post will guide you through some of the ways Group Policy can impact performance as well as some of the improvements we made for Windows 8.

This post (including the introduction) is a partial reproduction of a white paper written by one of our Group Policy MVPs, Darren Mar-Elia, with some additional comments and information. Darren has also written a free tool to help identity if your configuration might be susceptible to long logons.

This post covers:

•          Foreground vs. background processing.
•          Synchronous vs. asynchronous processing.
•          GPOs with WMI filters.
•          GPOs with scripts.
•          Group Policy Preferences.
•          Actions you can take in Windows 8.

Foreground vs. background processing

Foreground and background processing are key concepts in Group Policy. Foreground processing only occurs when the machine starts up or when the user logs on. Some policy areas (also called Client Side Extensions (CSEs)) can only run during foreground processing. Examples of these include Folder Redirection, Software Installation and Group Policy Preferences Drive Mapping. In contrast, background processing is that thing that occurs every 90 or so minutes on Windows workstations, where GP refreshes itself periodically. Background processing happens, well, in the background, while the user is working and they generally never notice it. While background processing doesn’t impact performance, foreground processing can extend start and login times. This post will be focusing on foreground processing.

Synchronous vs. asynchronous processing

Foreground processing can operate under two different modes—synchronously or asynchronously. The default foreground processing mode for Windows clients since Windows XP has been asynchronous. Asynchronous GP processing does not prevent the user from using their desktop while GP processing completes. For example, when the computer is starting up, GP asynchronous processing starts to occur for the computer, and in the meantime, the user is presented the Windows logon prompt. Likewise, for asynchronous user processing, the user logs on and is presented with their desktop while GP finishes processing. The user is not delayed getting either their logon prompt or their desktop during asynchronous GP processing. When foreground processing is synchronous, the user is not presented with the logon prompt until computer GP processing has completed after a system boot. Likewise the user will not see their desktop at logon until user GP processing completes. This can have the effect of making the user feel like the system is running slow. In short, synchronous processing can impact startup time, where asynchronous does not.

Foreground processing will run synchronously for two reasons:

1)      The administrator forces synchronous processing through a policy setting. This can be done by enabling the Computer ConfigurationPoliciesAdministrative TemplatesSystemLogonAlways wait for the network at computer startup and logon policy setting. Enabling this setting will make all foreground processing synchronous. This is commonly used for troubleshooting problems with Group Policy processing, but doesn’t always get turned back off again.

2)      A particular CSE requires synchronous foreground processing. There are four CSEs provided by Microsoft that currently require synchronous foreground processing: Software Installation, Folder Redirection, Microsoft Disk Quota and GP Preferences Drive Mapping. If any of these are enabled within one or more GPOs, they will trigger the next foreground processing cycle to run synchronously when they are changed.

Action: Avoid synchronous CSEs and don’t force synchronous policy. If usage of synchronous CSEs is necessary, minimize changes to these policy settings.

GPOs with WMI filters

If you must use a policy setting that triggers synchronous processing, another area to take note of is the use of WMI filters. A WMI filter does not automatically slow down GP processing appreciably, but if a WQL query implemented in that filter is time consuming, it could slow down the startup or logon  process, This is true especially if that workstation is running Group Policy processing synchronously. A few long-running queries can extend the amount of time it takes to finish processing Group Policy. Costly WMI filters include those that rely heavily on network traffic, such as LDAP queries.

Action: Avoid costly WMI filters such as LDAP queries

GPOs with scripts

As with WMI filters, long-running scripts might impact performance during synchronous processing. Startup or logon scripts are not by themselves always a problem. But too many scripts running for a given user or computer, or scripts that hang or are no longer really in use, can add to startup and logon times. Frequently, people don’t recognize the number of scripts that are present. Try looking through your environment for startup or logon script policies and reviewing them to ensure they are responding (scripts that aren’t responding will not timeout for 10 minutes, by default) or otherwise taking a long time to execute.

Action: Look for costly scripts by running them in isolation and work to improve the scripts’ performance or avoid these scripts

Group Policy Preferences

GP Preferences settings that use Item- Level Targeting (ILT) are not inherently harmful. However, certain kinds of Item Level Targeting queries can take more time to run. You can find these targets in any Group Policy Preferences setting under the Common tab. Costly ILT evaluations include all of the ILT types that must work over the network against AD to be evaluated: OU, LDAP Query, Domain, Site and Computer Security Group filters.

Actions:

•          Don’t run ILT evaluations such as OU, LDAP Query, Domain, Site, or Computer Security Groups.
•          If you need to use security group filters, consider this KB article.

Similarly, Group Policy Preferences Printers can take some time to install a printer driver. If a printer item is set to “replace,” it will re-install the printer driver every time it runs. If you are deploying several printers at once, this can add up quickly. Instead of “replace,” consider using “create” or “update.”

Action: Don’t use “Replace” with Group Policy Preferences Printers.                 

Actions You Can Take in Windows 8

We made changes in Windows 8 to give greater control over synchronous processing. Synchronous processing takes longer over slow networks, because Group Policy makes many requests to domain controllers when applying Group Policy. To mitigate this effect, we added an option to allow computers or users on a slow network connection to avoid processing any CSEs that require synchronous processing. All other policy settings will apply as normal. Those synchronous policies that were skipped while on a slow network will take effect the next time a user or computer is on a fast network (as usual).

You can find this policy setting in Computer and User configurations under Policies -> Administrative Templates -> System -> Group Policy -> Change Group Policy Processing to run asynchronously when a slow link is detected

The Configure slow link detection policy setting in the same path allows you to configure the threshold at which Group Policy determines a link is slow. Slow link detection raises event 5314 in the Group Policy Operational Log (Located in the Event Log Viewer under Applications and Services Logs -> Microsoft -> Windows -> Group Policy) . Checking this event will show if Group Policy has detected a fast or slow link, as well as the detected bandwidth, and the threshold that has been set. 

Action: Disable synchronous logins when on a slow link

Summary

Windows 8 provides new mechanisms to help reduce the impact of synchronous processing. By utilizing available tools and being aware of the necessary difference in the design and deployment of GPOs you can substantially improve your user’s desktop startup experience.

Actions you can take to improve Group Policy performance:

•          Avoid synchronous CSEs and don’t force synchronous policy, or if CSE usage is necessary, minimize changes to these policies.
•          Avoid costly WMI filters such as LDAP queries.
•          Look for costly scripts by running them in isolation, and work to improve the scripts’ performance or avoid these scripts.
•          Don’t run ITL evaluations such as OU, LDAP Query, Domain, Site, or Computer Security Groups.
  •    If you need to use security group filters, consider this KB article.
•          Don’t use “Replace” with Group Policy Preferences Printers.
•          Disable synchronous logins when on a slow link.

We already talked about Darren’s tool to investigate Group Policy performance, so here’s what some other GP MVPs are up to:

Jeremy Moskowitz blogs about how to use his product, PolicyPak, to disable various 3rd party software through Group Policy.

Derek Melber has launched a new site, http://auditingwindowsexpert.com/.

Alan Burchill has written best practice guides for Active Directory and Group Policy design .

The Intune blog has a new post, “The Path to Modernizing Windows Management“. It discusses the various options available to administrators when it comes to managing Windows 10 devices. Although there are many new options, technologies like Group Policy continue to be relevant:

Many organizations still need to manage domain joined computers at a granular level such as Internet Explorer’s 1,500 configurable GP settings or very specific Windows Firewall rules. In these cases, Group Policy and System Center Configuration Manager continue to be excellent management choices. Group Policy is the best way to granularly configure domain joined Windows PCs and tablets connected to the corporate network using Windows-based tools. Microsoft continues to add Group Policy settings with each new version of Windows.

To see the latest Group Policy settings in Windows,  Check out the Group Policy Settings Spreadsheet for TP4 to see the latest policies, and get those policies with the Windows 10 ADMX 1511 package.

A small sample of some of the new Group Policy settings added in TP4

These settings are designed to give granular control over individual aspects of Windows, so you can configure domain-joined computers in the way that works best for you. While Intune is a great choice for mobile phones or users on the go using non domain joined or Azure AD joined laptops, Group Policy is great at managing domain-joined machines.

Nano Server is a remotely administered headless server operating system optimized for private clouds and datacenters. Nano Server is significantly physically smaller than Server Core, has no local logon capability and only supports 64-bit applications, tools and agents. As we prepare to release Windows Server 2016 Technical Preview 5, I wanted to provide more information on how to properly configure Nano Server at scale – without Group Policy.

One of the things that makes Nano Server so interesting is that it takes up far less disk space, installs significantly faster, and requires far fewer updates and restarts than Windows Server. When it does require a restart, it restarts much faster. To achieve this speed and small physical footprint, Nano Server has the absolute minimum amount of inbox components. As a result, Group Policy and the associated Group Policy Management Console (GPMC), editor (GPMC), Group Policy client and local policy editor (GPEdit) tools are not present on Nano Server. This is expected as they are graphical components and Nano Server is headless and remotely managed. Even when domain joined, Nano Server will not consume and enact Group Policy settings.

So, without Group Policy, how do you apply security policies to Nano Server? We have a series of documents coming out to answer this question. The first one can be found here: https://blogs.msdn.microsoft.com/powershell/2016/05/09/new-security-cmdlets-in-nano-server.

Windows Server 2016 Technical Preview 5 still has complete Group Policy controls, of course. In fact, it has its fair share of new Group Policy Settings, even over Technical Preview 4. You can find the updated Windows 10 / Windows Server 2016 TP5 group policy settings here. Client SKUs also have Group Policy in full.

To sum up:

• Nano Server has different capabilities than Windows Server 2016
• Nano Server does not have the Group Policy editing, management, or client service.
• To manage Nano Server security policy, refer to this post: https://blogs.msdn.microsoft.com/powershell/2016/05/09/new-security-cmdlets-in-nano-server
• Windows Server 2016 and Windows 10 clients continue to have full support for Group Policy.

Hi Everyone,

My name is Kai Ohnesorge and I am working with Microsoft in a position as Premier Field Engineer (PFE) based in Germany. In my job I am confronted with a large amount of GPO topics, one being changes in ADMX templates over the various versions of Windows. From time to time, we as PFEs are asked for changes in ADMX templates between different versions of Windows operating systems, but so far the only sources of information were the “Group Policy Settings Reference for Windows and Windows Server” spreadsheets. These contain all Group Policy settings available in the corresponding version of the Windows operating systems, but unfortunately there has never been a comprehensive documentation of all changes. A spreadsheet containing all changes in ADMX files shipped with Windows Vista up to Windows 10 Anniversary update (not containing Windows Server 2016 yet) can now be downloaded here. Later on in this article you will find a description of the spreadsheet, but first let me explain why this information might be of importance to you.

Originally, my answer regarding changes to ADMX files always was “ADMX files shipped with newer versions of Windows contain additional settings, but no settings are removed or basic changes are made”. Today, I know this is not the entire truth. In 2012 my good friend Mark Empson, PFE based in the UK, discovered that ADMX files are not always growing between OS versions, but many stay the same size – some of them are actually shrinking! During further investigation he identified settings that were indeed removed from newer versions of ADMX files, which means if a Central Store has been configured for the ADMX and ADML files in a domain, affected settings might not be manageable after updating the files in the central store to the newest version. So if a domain is configured with a Central Store, containing the ADMX templates delivered with Windows Server 2008 R2, a Group Policy might contain the following settings:

After updating the ADMX files to the versions delivered with Windows Server 2012 R2, the same GPO might be displayed as:

As a result, all of these settings are not manageable anymore and cannot be changed or removed within the Group Policy Management Console (GPMC). The same situation will occure when a GPO, that was originally created with Windows Server 2008 R2, is edited with a GPMC installed on Windows Server 2012 R2 while using the local ADMX files.

To bypass this situation, several workarounds are available after identifying if your environment is affected at all. The amount of Policy settings that have been removed is curently around 40 over all versions of Windows, including settings added to Operating systems via patches, but not available in the RTM version of the next release. For example the setting “Do not reinitialize a pre-existing roamed user profile when it is loaded on a machine for the first time” has been added to Windows Server 2012 and Windows Server 2012 R2 via an update (yes, updates do change ADMX files!), so it has been available in the latest version of Windows Server 2012 ADMX files, but not in the RTM version of Windows Server 2012 R2.

So if your environment is affected, here are two possible workarounds  (not in a particular order):

1. Identify all related settings and remove them from the Group Policy before updating the Central Store, if currently configured
2. Create a management system (server or client) per version of the Windows Operating system present in your environment and configure the Group Policy objects for a specific version of Windows from the corresponding management system. If a Central Store is configured in the environment, configure the GPMC on these management systems to bypass the central store as described in this article:

An update is available to enable the use of Local ADMX files for Group Policy Editor

https://support.microsoft.com/en-us/kb/2917033

Furthermore, for a few Policy settings essential information in the ADMX files, such as the key value or the enabled / disabled values have changed. One example is the Group Policy setting “Turn off Fair Share CPU Scheduling “. Prior to Windows 8 / Windows Server 2012, the key values were:

<enabledValue>

<decimal value=”1″ />

</enabledValue>

<disabledValue>

<decimal value=”0″ />

</disabledValue>

Starting with the ADMX files shipped with Windows 8 / Windows Server 2012, the key values are:

<enabledValue>

<decimal value=”0″ />

</enabledValue>

<disabledValue>

<decimal value=”1″ />

</disabledValue>

It is important to mention that this does not affect GPOs present in your environment before updating the ADMX files, but it might affect your clients when editing the GPOs after the update. If any affected Policy settings are configured in your environment, additional testing should be planned before changing the GPOs or applying them to newer versions of Windows.

The comparison file contains a number of spreadsheets:

• Annotations: General comments about the document
• ADMXOSAvailability This spreadsheet displays all ADMX files and their availability in different versions of Windows
• ADMXChangesFull All changes in ADMX files, starting Windows Vista up to Windows 10 Build 1607 Patch state August 2016
• admx_IE11 All changes that occurred in the Internet Explorer 11 ADMX file
• Removed_Items A list of all ADMX files and Policy settings removed between Windows Vista up to Windows 10 Build 1607 Patch state August 2016
• New_Items A list of all ADMX files and Policy settings added between Windows Vista up to Windows 10 Build 1607 Patch state August 2016
• Changed_Items Changes made to Policy settings between Windows Vista up to Windows 10 Build 1607 Patch state August 2016. Important changes, as Registry Key value changes, are marked red.

The file can be downloaded directly from the following location:

https://go.microsoft.com/fwlink/?linkid=829685

Kai Ohnesorge, Microsoft Identity PFE

This blog post was written by Mark Empson, who is a Premier Field Engineer based in the UK.

Back in 2013, I started to uncover some challenges around upgrading ADMX/L files in the policy definitions folder (be it Local or in the central store) and the ramifications of some of the changes that can occur, with later revisions of the files.  I initially put together a spreadsheet at the time, that looked at how the physical files changed between builds by using MD5 hashes of each released file and a direct comparison between only two builds of ADMX releases, to visualize the differences.  This work was built upon by Kai Ohnesorge, as he took that work to the next stage, by documented all aspects of the content changes between all versions of the files (as can been seen on this blog site, via this link https://blogs.technet.microsoft.com/grouppolicy/2016/10/12/admx-version-history/ ).

Today, marks the release of a new knowledge base article that explains the known issues that could be experienced, while upgrading the PolicyDefinitions folder from a Windows Server 2012R2 build, with later version of ADMX files and it also explains how to mitigate those known issues.  This document is also important while using the Advanced Group Policy Management (AGPM) server, as the same issues will also be visible.

This KB article 4015786 can be found on any of the links below:

Direct Link:   https://support.microsoft.com/en-us/help/4015786/known-issues-managing-a-windows-10-group-policy-client-from-a-windows-

FWLINK: https://go.microsoft.com/fwlink/?linkid=845418

AKA :  https://aka.ms/admxupgrade

Special thanks to Ajay Sarkaria, who is the Supportability PM for Group Policy and Kai Ohnesorge, who is also a PFE.