Tải bản đầy đủ - 0 (trang)
Exploring ADM vs. ADMX and ADML Files

Exploring ADM vs. ADMX and ADML Files

Tải bản đầy đủ - 0trang

Exploring ADM vs. ADMX and ADML Files


There are now about 176 ADMX files, which roughly cover the same settings

found in Windows XP and all the new stuff in Windows Vista and later, including

Windows 10. They’re generally component specific. For instance, you’ll find things like

WindowsMediaPlayer.admx and EventLog.admx, among others.

Here’s something neat about ADMX files—they’re language neutral. That is, the definitions for the Registry values that are controlled live inside the ADMX file. However,

the text strings describing the policy and the Explain text are contained in a separate file

called an ADML file—each ADMX file has a corresponding ADML file. These ADML

files are located in specific subdirectories for each language within the C:\windows\

PolicyDefinitions folder. For instance, U.S. English is contained within the en-US directory, which can be seen in Figure 6.3.

F I G U R E   6 . 3     A quick list of some ADMX files. Note the language-specific directory here

for English (en-US).

The term en-US stands for U.S. English. For other locales, visit http://

tinyurl.com/223ebg. For instance, HE is for Hebrew, RU is for Russian,

DE is for German, and AR is for Arabic.


Chapter 6    Managing Applications and Settings Using Group Policy

So, let me spell it out a different way:



ADMX files store the same stuff as ADM files—except now (whoopee…) they’re

XML based.

ADML files are corresponding language files for ADMX files.

You may be wondering, “What special superpowers do I get now that we use ADMX

and ADML files?” Well, I dare say that you get “no new superpowers.” Just because you’re

using ADMX/ADML files, you don’t somehow magically get to “Group Policy enable”

applications and their settings or have more Registry control.

But there has to be some benefit, right? Or else Microsoft wouldn’t have done it, right?

Yep. They’re not superpowers, though. They’re fixes to some thorny problems.

Let’s compare ADM and ADMX files and then explore the four problems that the construct of ADM files caused and see how the newer construct of ADM and ADMX files fixes

each of those problems.

Comparing ADM vs. ADMX Files

Our goal for the rest of this chapter is to give you an in-depth look at both ADM and

ADMX files and for you to understand the differences between them. However, before we

get going, here’s a reference table so you can see where we’re going; you can also utilize this

table as an ongoing reference.

ADM Files

ADMX Files

Lots and lots of definitions are packed

Definitions are split logically into much

into several large-ish files. The biggest one smaller ADMX files, generally by Windows

is SYSTEM.adm.

feature area.

Each ADM file contains settings in one

specific language.

ADMX files are language neutral. Languagespecific information is contained within a

corresponding ADML file. Language-specific

files live in hard-coded directories. For example, U.S. English language files live in


Live on each Windows XP machine in

Live on each Windows Vista and later

machine (including Windows Server 2008

and later) in %systemroot%\



ADMX and ADML Files: What They Do and the Problems They Solve

ADM Files


ADMX Files

Every time a GPO is “born,” it costs about GPOs created from ADMX files never have

3MB on each Domain Controller because big space requirements. That’s because the

the ADM files are placed inside the GPO. ADMX files are never pushed into the GPO

themselves (whether or not the Central Store

is used). We’ll discuss the Central Store a bit


Use their own proprietary ADM syntax

for describing Registry policy.

Use standard XML as the syntax for describing Registry policy.

ADMX and ADML Files: What They Do

and the Problems They Solve

If ADM files were so wonderful, why did Microsoft have to (basically) dump this “tried

and true” way for a newer construct of ADMX and ADML?

At first glance, it seems that ADMX and ADML files are more complex than ADMs.

That’s true, at least because now inside each file is gobbledygook XML code, and arguably,

ADM files are easier to read (when being read by humans). Then, there’s the complexity of

having two (or more!) files, whereas before, one ADM file seemed to be perfectly sufficient.

Problem is—it just wasn’t. Let’s examine the four problems that ADMs had and how

ADMX and ADML files solve those problems.

Problem and Solution 1: Tackling SYSVOL Bloat

The older Group Policy editor pulls the ADM template files from the computer it is running

on. And it copies these ADM template files from %systemroot% \inf—usually C:\windows

\inf—directly into each GPO you edit. Each time you do this, you’re burning about 3MB

of disk space—on every Domain Controller. This is because all material inside the GPO is

replicated to every Domain Controller.

Imagine you’ve created 100 GPOs using the older GPMC. In that case, you’re using

about 300MB to 500MB of disk space on every Domain Controller to store these ADM

files! Ow! This problem is called SYSVOL bloat.

In Figure 6.4, you can see a sample SYSVOL with several GPOs. Recall that GPOs live

on every Domain Controller in the sysvol\corp.com\Policies directory underneath their

GUID. If you’re using the older GPMC, each GPO will have an ADM directory containing

the same ADM templates, at about 3MB for each directory.


Chapter 6    Managing Applications and Settings Using Group Policy

F I G U R E   6 . 4     Every GPO created with an XP management station pushes about 3MB

into SYSVOL.

So, what does the updated GPMC do differently? Well, instead of copying stuff up from

the local machine into the GPO, it just does “nothing.” That’s right—nothing. Figure 6.5

shows the difference between the older GPMC and the newer GPMC.

Don’t believe it? Let’s look at what’s generated inside SYSVOL. In Figure 6.6, you can

see that the top window was created using a modern GPMC, like what’s available for

Windows 10 (or really Windows Vista and later). You know this because there’s no ADM


So, did we solve problem 1, SYSVOL bloat? You bet. Because there’s no ADM directory

(and no ADM files inside it) there’s no wasted space (SYSVOL bloat) from ADM files.

Problem 2: How Do We Deal with Multiple Languages?

Let’s imagine that you’re a part of a big company (heck, maybe you are). And in this company you have multiple administrators speaking multiple languages. And these administrators need to modify GPOs. Worse, they sometimes have to modify each other’s GPOs.

If you’re using the older GPMC (which uses ADM files), this is a real problem. When

Vlad in the Russian corporate office edits the GPOs, he wants to see those policy settings

and help texts in Russian. When Björn in the Sweden corporate office edits GPOs, he wants

to see those policy settings and help texts in Swedish.

ADMX and ADML Files: What They Do and the Problems They Solve


F I G U R E   6 . 5     What’s copied into the GPO when using the older and the newer GPMC

Your machines—the

Administrators who

control Group Policy



(ADM files)


Updated GPMC

(ADMX files)

ADM files from the \windows\inf

directory copied into the GPO

Active Directory Domain

Controllers of any kind

Nothing copied into the GPO

GPO: “Sales

desktop settings”


GPO: “Nurse

desktop settings”

The problem is, if Vlad creates and edits the GPO first using the older GPMC, Vlad’s

Russian ADM templates (which start out on Vlad’s XP machine) go into the GPO. This is no

big deal, until Björn wants to edit that same GPO. If Björn’s ADM templates on his machine

are older or have the same release date, then when Björn goes to edit the GPO that Vlad created, Björn will see the GPO’s policy settings and help text in Russian, not Swedish.

So is problem 2, multiple languages solved? Yes, because when admins use the updated

GPMC, each admin simply uses his own machine to grab the definitions and it uses his own


But, let’s read on to problem 3, which is interrelated.

Problem 3: How Do We Deal with “Write Overlaps”?

Let’s extend problem 2 a little bit. Let’s assume that in the previous example, Vlad’s machine

was an XP/SP2 machine. Let’s also assume that in the previous example, Björn’s machine was

also an XP/SP2 machine.


Chapter 6    Managing Applications and Settings Using Group Policy

F I G U R E   6 . 6     The top window shows a GPO’s contents when it’s created using an

updated GPMC management station. The middle window shows a GPO’s contents when it’s

created using an older GPMC management station. The bottom window shows the contents

of the ADM directory for the GPO created using the older GPMC management station.

Now, Björn is able to update his machine to XP/SP3, while Vlad still uses XP/SP2

(which is unsupported, I might add). Now when Björn goes to edit the GPO, Björn’s

ADM templates are newer. And because they’re newer, they overwrite the ADM files

already inside the GPO.

This is great news for Björn. Now when he edits the GPO, everything inside is Swedish!

But this is bad news for Vlad, because now the GPOs he originally created, which had

Russian policy settings and help text, will display in Swedish if Björn ever edits them.

Turns out the solution to solving problems 2 and 3 is exactly the same as solving problem 1.

To solve the multiple languages problem (that’s problem 2) and the “write overlaps” problem

(problem 3), the updated GPMC once again simply “does nothing.”

Since the modern GPMC doesn’t use ADM files, it won’t copy any definitions into the

GPO at all. Not ADM, not ADMX/ADML. Nothing.

So why does this “do nothing” approach solve the problem? Because now when Vlad

edits the GPO, Vlad uses his own local machine (say, a Windows 10 machine) for the

Russian definitions. When Björn edits the same GPO, Björn uses his own local Windows 7

Swedish definitions. (Yep, Björn has maintained using his Windows 7 machine, but Vlad

has moved on to Windows 10 to get the latest, greatest features.)

The Central Store


Since both Björn and Vlad are using modern GPMCs, magic just happens automatically,

and they don’t have to do anything special.

This “do-nothing” approach works, because there’s never anything written into the

GPO regarding definitions. Only the data, the “directives,” are inside the GPO. And therefore each administrator simply uses his local %systemroot%\PolicyDefinitions folder to

utilize his own ADMX and ADML definitions.

This “do nothing” approach with the updated GPMC seems like a great solution. It’s

now officially solved three of our four problems. Can we go four for four?

Problem 4: How Do We Distribute Updated Definitions

to All Our Administrators?

Let’s assume we have some software and the manufacturer created, and then occasionally

updates, some policy definition files.

That’s great. We get updates from the vendor; now assume we have 20 administrators at

our company. Or even two—just Vlad and Björn.

How are we going to get those updated ADM files delivered to those administrators and

make sure they’re installed correctly? Are we going to e‑mail these updates to each of them?

Are we going to script these updates and hope the script correctly identifies our administrators and the machines they work upon?

In short, how the heck are we going to get our updated definitions to every administrator

in a hurry?

Well, turns out that the updated GPMC has a trick up its sleeve, and it’s called the

“Central Store.” We’ll explore the Central Store in an upcoming section, but the idea is

simple: rather than trying to get every administrator’s machine up to date with ADMs,

we’ll use ADMX and ADML files, and just plunk them in a centralized place—a “Central

Store” if you will.

Stay tuned—I’ll show you exactly how that works in the next section.

The Central Store

As we discussed, in the ideal world you’d use only the updated GPMC for your management stations. Sure, that means you’d have to spin up one Windows 10 machine (and download and install the updated GPMC within RSAT or use a Windows Server 2016 machine).

That’s easily done in the real world, so we’ll assume from here on that you’ll be using

only updated GPMC as your management station, eschewing older XP/2003 GPMC management stations.

As you’re reading this right now, Microsoft has just shipped Windows 10 “out of the

box” (also known as RTM, or Released to Manufacturing). But let’s fast-forward a bit and

assume, oh, that we’re up to Windows 10/SP3. Yep, Windows 10 Service Pack 3 has just

been released (in my fantasy land) and you need to control the new whiz-bang features that


Chapter 6    Managing Applications and Settings Using Group Policy

only come with Windows 10/SP3 client computers. (Again, I’m dreaming a little into the

future here; new whiz-bang features might or might not come in service packs, but stay

with me through this example anyway.)

“No problem!” you say, “I’ll just create a Windows 10/SP3 machine and put on the

updated GPMC as my management station. That will always have the latest, greatest definitions in the local PolicyDefinitions folder.” And you’d be right! Except that you already

have an updated GPMC machine as your management station. So, you wouldn’t want to

spin up a whole new machine just for this. You’d want to leverage the updated GPMC management station you already have, right?


This is easy! You’re a diligent administrator (you bought this book, subscribe to the

www.GPanswers.com mailing list, and practice good Group Policy hygiene, after all),

and you know you have three ways to update your current updated GPMC management





If your updated GPMC management station is Windows 10, you would just apply

Windows 10’s SP3. That would update the ADMX files that live in C:\windows\


Or, you could forgo applying SP3 to your Windows 10 management station and simply copy the ADMX (and associated ADML) files from another Windows 10/SP3

machine to your management station. Again, you’ll plunk them in the C:\windows\

PolicyDefinitions directory.

Or, if your updated GPMC management station is Windows Server 2016, you could

also just simply copy the ADMX (and associated ADML) files from another Windows 10 / SP3 machine to your Windows Server 2016’s management station. Again,

you’ll plunk them in the C:\windows\PolicyDefinitions directory.

So, the message again sounds simple: whenever Microsoft has new ADMX/ADML files,

get them into your updated GPMC management station.

Simple, yes—until you remember that you have 20 administrators in your company, each

with their own Windows 10 management station. Or you remember those administrators

who love to bounce from machine to machine because they have three sites to manage.

Yikes! How are you going to guarantee that all of these administrators will use the updated

ADMX files?

Let’s assume you’ve successfully upgraded your Windows 10 management station to

SP3, but only some of your 20 administrators successfully upgrade to Windows 10/SP3 (or

have created custom ADMX files, or jam the ADMX files into their own local C:\windows\


This becomes a big problem—fast. Here’s why: if you create a new GPO, that GPO will

have the definitions for all the whiz-bang stuff Windows 10/SP3 has to offer. However,

when another administrator (who doesn’t have the latest ADMX files) tries to edit or report

on that GPO, they simply won’t see the policy settings for Windows 10/SP3 available.

The Central Store


GPMC reports about this newly created GPO would show the new whizbang features as “Extra Registry Settings,” but actually trying to edit the

GPO itself will not show them.

What you need is a way to ensure that all administrators who are using updated GPMC

management stations have a one-stop-shop way to ensure that they’re getting the latest

ADMX files. That way, everyone will be on the same page, and there will be no challenges

when one administrator creates a GPO and another tries to edit it.

The Windows ADMX/ADML Central Store

As described earlier, the updated GPMC has a trick up its sleeve.

That is, administrators using the updated GPMC can use a Central Store for ADMX

and ADML files. Recall that the ADMX files are the definitions themselves and the

ADML files are the language-specific files for each ADMX file.

The idea is that the Central Store lives on every Domain Controller. So, after the Central

Store is created, your updated GPMC management station simply looks for it—every time it

tries to create or edit a GPO—and it will automatically use the definitions contained within

the ADMX files inside the Central Store.

This means you don’t have to worry about running around to each of your 20 management stations to update them whenever new ADMX files come out. You simply plop them in

the Central Store and you’re done. You don’t even have to tell the updated GPMC management stations you did anything; they’ll just automatically look and use the latest definitions!

Here’s the best part: It doesn’t matter what kind of Domain Controllers you have.

Doesn’t matter if you have Windows Server 2008, 2012, 2016, or a mix of all of them. It’s

the updated GPMC that is doing the work to look for the Central Store in the prescribed

location (which lives on Domain Controllers).

Wait, I’m going to stop here and take a big deep breath and say it one more time.

Because I know you’re reading fast and want to get to the good stuff. So, say it out loud

if you have to.

It doesn’t matter what kind of Domain Controllers you have. You can still make and

use the Central Store.

It doesn’t matter what domain mode you’re in. It’s the updated GPMC that is doing the

work to look for the Central Store in the prescribed place on the Domain Controller.

Got it? You don’t have to “sell” your boss on upgrading the whole Domain Controller

back end just to get this cool Central Store stuff. With one updated GPMC management

station, you’ve basically got the magic you need.

So, let’s read on and make it happen.

Creating the Central Store

A Domain Administrator must create the Central Store because only a Domain Administrator

has the ability to write to the location we need in SYSVOL. You can do this operation on any


Chapter 6    Managing Applications and Settings Using Group Policy

Domain Controller, because all Domain Controllers will automatically replicate the changes

we do here to all other Domain Controllers via normal Active Directory/SYSVOL replication.

However, it’s likely best to perform this on the PDC emulator because that’s the location the

GPMC and Group Policy Object Editor use by default.

To create the Central Store:

1. On the PDC emulator, use Explorer or the command line to create a directory in:


(That’s the usual location; yours could be different.) You want to create a directory

called PolicyDefinitions, as seen in Figure 6.7.

F I G U R E   6 . 7     Create a new directory called PolicyDefinitions in the Policies folder


2. We need a location to store our language-specific ADML files. Within

PolicyDefinitions you’ll create a directory for each locale. Again, U.S. English is

en-US. For other locales, visit:


Note that the directory name must be the same as specified in the locale

reference page. If it’s not, the ADMX file will not find its corresponding

ADML file for that language.

The Central Store


Populating the Central Store

Now, you simply have to get the latest, greatest ADMX and ADML files from your updated

GPMC machine into the Central Store.

There are a zillion possible ways to copy the files there. But the steps are most easily

done with two xcopy commands. This will work if your Windows 10 management station

has access to the Domain Controller and if you have write rights.

To copy the ADMX files into the Central Store from your Windows 10 management


xcopy %systemroot%\PolicyDefinitions\*



To copy in the ADML files into, say, the U.S. English directory we created earlier:

xcopy %systemroot%\PolicyDefinitions\EN-US\*



You can also use good ol’ drag and drop. Here’s a YouTube video I created to help you

out: http://youtu.be/Q4DBdQo4XZs. I also have another video showing how to upgrade

your central store after you download the latest files: http://youtu.be/acYb2wQeL94.

Verifying That You’re Using the Central Store

Once you’ve created the Central Store directories in SYSVOL and copied the ADMX and

ADML files to their proper location, you’re ready to try it out. Start by closing the updated

GPMC if it’s already open, then reopen it. You can fire up the GPMC by clicking Start and

in the Run box typing gpmc.msc.

And then just create and edit a GPO.

However, can you be sure you’re really using the Central Store?

The updated GPMC’s Group Policy Management Editor will tell you if you’re using

local policy definitions or using the Central Store. In Figure 6.8, you can see a GPO where

the Administrative Templates are retrieved from the local machine. However, as soon as the

Central Store is available, that same notice changes to what’s seen in Figure 6.9.

There is a secondary test as well to help you verify that you’re using the Central Store.

That is, when you create and edit a GPO, then click the Settings tab in the GPMC, you’ll

see a line under either Computer Configuration or User Configuration that says “Policy

definitions (ADMX files) retrieved from the central store.” You can see this in Figure 6.10.

Updating the Central Store

ADMX and ADML files will be updated at some point.

Likewise, when Windows 10’s SP2, SP3, and so on come out, those will be newer still,

and so on.

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Exploring ADM vs. ADMX and ADML Files

Tải bản đầy đủ ngay(0 tr)