Now that Windows 8 is out (or almost out), the inevitable questions will arise about introducing it into your Group Policy Management world. As with previous versions of Windows, the approach with Windows 8 (and Server 2012) will be similar. Since Windows 8 and Server 2012 will be introducing more new settings into Group Policy, you’ll need to use the GPMC and GP Editor versions that come with those new OS versions to be able to see those new settings. There’s two main approaches that I typically recommend when introducing a new OS into your Group Policy management practice:
- The first approach is to introduce a Windows 8 or Server 2012 “management station” as your new, sole GP management platform, managing both new GPOs that you create specifically for Windows 8/Server 2012 machines, as well as existing GPOs that apply to downlevel OS. The advantage to this is that all of your GP management will now happen from this new version of the OS. This means that all of the new settings in Windows 8 will be available to you, and, you will still have *most* of the settings that you managed in downlevel versions available as well. I say “most” because, for the first time in a while, Microsoft has actually removed a policy area in the Windows 8 GP editor. Specifically, as I blogged about recently, Microsoft has removed Internet Explorer Maintenance Policy from the Win8/2012 GP Editor. So, if you have IE Maintenance settings in your existing GPOs, you won’t be able to see them from your Windows 8 GP editor (though those settings will still appear in GPMC settings reports on Windows 8). This means that you’ll need to keep around at least one downlevel management station for managing these settings. In addition to Windows 8, Microsoft will from time-to-time rename settings between OS releases, as they appear in GP editor. The underlying setting itself will not have changed but the name of the setting may. So, if you’re managing existing GPOs that implement renamed settings, and you view those settings in Windows 8, for example, they may appear different than they would in the GP Editor for Windows 7. It’s not a bad thing. It is just something to be aware of. The final thing to be aware of in this approach is that the ADMX files for Windows 8 and Server 2012 have been updated. As a result, if you are using the SYSVOL-based Central Store to keep your ADMX files in a central location, you would need to update those files with the new ones found under C:\windows\policydefinitions on your Windows 8 management station. Keep in mind that once you upgrade your Central Store, you should plan on using Windows 8 or Server 2012 for your management station for all GP tasks. Your Windows 7 GP tools will *probably* work reading those Windows 8/2012 ADMX/L files, but there have been episodes in the past where Microsoft made changes to the schema of these files and it required using the latest version of the OS to properly read them.
- The second approach is the more conservative one , but also potentially more complex. It calls for having both Windows 7/2008-R2 and Windows 8/2012 GP management stations on your network. You’ll use the Windows 7 tools to manage your existing GPOs targeted at downlevel machines and users, and use the Windows 8 tools to manage new GPOs that you create specifically to apply to Windows 8 clients and servers (and their users). Obviously, this approach has challenges. As you introduce more and more Windows 8/2012 systems, you may find users that cross between downlevel OS’ and Windows 8. So the distinction between what are Windows 8 GPOs and downlevel GPOs becomes less clear. But, in the beginning, it does provide a clear delineation between the various platforms and their Group Policy support.
So, which approach do I recommend? In general, approach #1 is best if you can make it work. The key to making it work is to test the different scenarios you’ll need to support. Obviously, if you have IE Maintenance settings in your environment, you’ll need to still keep around a downlevel GPMC install to support editing those settings. But beyond that, it should be fairly straightforward to shift from managing your new and existing GPOs using earlier OS versions to Windows 8/2012 GPMC and GP Editor.
Let me know if you have questions on this, since it always brings up lots of discussion when this topic comes up. Feel free to comment on this blog posting or join the GPTalk Mailing list at GPOGUY.COM to discuss.
Thanks,
Darren
I’m leaning towards option #1, but there’s no mention if we need a Server 2012 domain controller. What if I don’t have any 2012 servers, just 2008 R2, but want to manage Windows 8 clients, is it enough to just copy the ADMX files to the Central Store? Will all settings (which ones not) apply?
I actually just did this the other day. You need to run forestprep and adprep which on the Windows Server 2012 ISO. After that your AD infrastructure is now Windows 8 and Windows 2012 ready. You can then use the remote administration tools from a Windows 8 machine to mange group policy on your Windows 2008 R2 domain. To update group policy copy both the ADMX files and the ADML files to your central store. Your old setting will remain in tack and you will the new ones as well.
I tested some group policy changes and they stick when using them against a Windows 8 machine.
Thanks Anthony. I actually didn’t think a schema upgrade was needed to use the Windows 8/2012 tools. I will have to check into that.
Hi there, just wondering was this confirmed that you need to execute forestprep & adprep in order to utilize the current set of admx files?
No AD schema changes are required for any of the new policies in Win8/Server 2012. In any case, ADMX will never require AD schema changes because they don’t store their settings in AD. Hope that helps!
Darren
Great, thank you very much for this. So no Server 2012 domain controller is needed in the environment.
I downloaded 8 Pro through my Tech Net account and installed the 32 bit version on a Dell 330 Optiplex. I added the computer account to the 2008R2 domain controller before joining it to the domain. It joined just fine. It’s time source is the domain controller according to the event logs. It did not pick up on the Administrator accounts set by group policy. Guess I’ll start looking at the ADMX files. Currently there is no Server 2012 DC in our environment as I can’t afford the CAL’s right now.
Well, I was wrong about trying to pre-poulate the pc name in an OU I created. The pc showed up in the Default Computers container, so I guess you can’t pre-populate Windows 8 into an OU in 2008R2 AD. From the DC, I could not manage the one I created in the OU, however, I could manage the one in the default computers container. Plus the properties for the pc in the default Computers contaier showed the OS as Windows 8 Pro, version 6.2 (9200), while the one in the OU did not. I deleted the one in the OU and replicated dc’s. I then moved the Windows 8 from the Default Computers container to the OU and forced replicatipon again. This time it picked up the settings for admin accounts I had set in group policy related to the OU. Long story short, when adding the Windows 8 client to your 2008R2 AD, don’t pre-populate. Find it in the Default Computers container and move it to where you want it. Ther’s a lot to study with this rascal.
So to sum this up: If you have a Windows 2008 R2 domain and want to start joing Windows 8 computers and apply Windows 8 GPOs all you have to do is add the admx and adml-files from a Windows 8 machine to the central store?
This won´t break any of the existing Win XP/Win 7 policy settings? It will only add more options to the existting policys?
In general, that is true. However, copying the ADMX/ADMLs to the Central Store is only a requirement if you have multiple people who plan to edit GPO and you want them all to see the new ADMX/L files. If not, then I think it’s sufficient to just use a Win8 management station to make your Win8 GPO changes. The reason I say that is that in past upgrades, MS made syntax changes to the ADMX format that threw errors in downlevel GP Editors. Not saying that they’ve done that here, but I haven’t tested it yet to know for sure. So, the “management station” approach is a conservative one until all people editing GP are using Win 8.
Darren
Sorry Im abit confused by this statement. If you had a windows 8 Management machine, wouldn’t the GPMC snapin retrieve the policy definitions from the central store, therefore hiding the local policy definitions?
GFX–you’re absolutely right. That is why I mentioned that *if* you didn’t have a Central Store, then using a Windows 8 management station with local ADMXs is fine. Frankly, I’m not a big fan of the Central Store. It means that you can never *experiment* with new ADMXs locally, like you could do with XP. If I’m authoring an ADMX and then testing it, I don’t want to have to expose it to all other GP management editors until I’m ready. But if I have the Central Store, then either I need a different domain to test that in or I need to copy that ADMX to the Central Store. No middle ground. As an aside, I just discovered that a Win 8 machine, trying to read settings defined on an Office 2010 set of ADMXs that were used to define the setting in Windows 7, was unable to parse that setting and basically threw up all over Admin Templates in GPMC reporting–unable to report on any of them. Yet another argument for not having a Central Store :).
Darren
Darren, I totally do agree that the Central Store lacks of a feature enabling administrators to develop and test ADMX templates without exposing the “beta version” files to all GPMC users .
On the other hand I’d declare the Central Store as a useful (and the only) approach to force a certain set of templates for a whole organization, e,g, if you want to prevent using un-approved ADMX files being used by GPO admins. Probably this is not a matter in a small or medium environment, but rather in big enterprise domains. Moreover, take into account that the “gpresult” tool also makes use of the Central Store. So if you use custom templates and run gpresult on a client machine, the Central Store is the only way to get appropriate reports via gpresult (copying custom templates to all clients is not a real alternative).
So my preferred solution would be:
use the Central Store and a have a method to force GPMC to use a specific ADMX path on the developer machines. See also the blog discussion here: http://blogs.technet.com/b/askds/archive/2009/12/09/windows-7-windows-server-2008-r2-and-the-group-policy-central-store.aspx?CommentPosted=true
Patrick-
Agreed — for shops that want total control over ADMXs, the Central Store is helpful. Of course, a user could still add an ADM file locally if they really wanted to have access to additional settings, but from an ADMX perspective, the Central Store provides some manner of control.
I will mention that one of the “side effects” of our Group Policy Automation Engine is that it allows you to specify a particular path to a set of ADMXs that could be pretty much anywhere. So it does allow you to test a new ADMX even in the presence of the Central Store. But of course, only from PowerShell.
Darren
I discovered something disturbing the other day. I had to edit a wireless profile in a GPO that was created in Windows 7 using my Windows 8 GPMC. After doing the edit, another admin went into the same GPO to review the wireless profile settings and received the following error: “Windows has detected that this policy was created by a more recent version of Windows.”
As the majority of our machines are still on Windows 7, I was able to restore the policy from backup and can now edit it via Windows 7. Has anyone else run across similar issues?
Ryan-
I just confirmed this behavior here. Neat!—NOT. That’s good to know.
Hi – Am I missing something. I have a 2008 R2 domain. I built a W8 Pro pc to manage the new policies. However, after copying the templates to the central store, when I try and add a Template to the Group Policy Management console on the W8 pc, it can’t see any of the templates via the browse option. I can confirm they are there though by using Windows Explorer. This is the same if I navigate to the central store or the local W8 policy files. ???
Not sure I follow what you’re trying to do. When you right-click the Admin Templates node in GP Editor to add a template, its only going to show you ADM files. ADMX files do not need to be, nor can they be, explicitly added to a GPO. They are all there automatically, either locally based on what is in c:\windows\policydefinitions, or from the Central Store.
Darren
I have windows2003 domain in enviroment. want to put admx policy on windows 7/8 . let me know the feasiblity for the same
Your DC level doesn’t matter all that much. Domain Controllers are just file servers at that point. As long as you manage GPOs from your Win7/Win8 management station, you are fine.
Darren
So, wait a second. If loading group policy objects in the GPMC via RSAT on Windows 8 pointing at Server2008R2 still only allows you to add ADM templates, then what tool do I need to run to edit Windows 8 Group policy objects company wide? …and why did I go through the trouble of installing RSAT? I’ve only ever used GPMC so If there’s something I’m missing, please let me know.
Eddie-
Not sure I understand the question. When you manage GP from a version of Windows that understands ADMX files (e.g. Windows 7 or 8), then you can use both ADM and ADMX files to manage Administrative Templates policy. Let me know what I’m missing in your question.
Darren