Central Store and ADM Removal Q&A (with an updated script!)



AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!

We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!

Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.

If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.

NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!

As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!


We’ve recently received some great feedback from several customers and other PFEs on the ADM template post that Mark and I wrote a month or two back. I thought I’d take some time to respond to some of those questions and to post an updated version of the script. Going forward, we plan to spend some time responding to questions, either on previous posts or new topics, so keep them coming!


The dates in the script for the out-of-box ADM templates are different than what I have on SYSVOL. Why is that?


We tried to track down all of the possible dates for out-of-box ADM templates and missed a few. I’ve added those to the list, as well as added a new switch to the script –NoDateCheck. Using this switch will cause the script to remove all ADMs where a matching ADMX template is found, regardless of time stamp.


What’s with all of the dates for the ADMs in the script, anyway?


When Mark and I were originally discussing this post and the script, we decided to err on the side of caution. We wanted to be 100% certain that nobody had modified the original ADMs and that there wouldn’t be unexpected behavior, or anything missing, when the migration to ADMX was complete. Checking for the time stamps ensured that things were good. The original plan was to have script users add their own “known good” ADM dates to the script, then run it to verify ADM consistency. For example, if I created a custom ADM and added it to GPO A, then modified that custom ADM again and deployed with GPO B, I’d have two different versions of the ADM template. After, I convert the ADM from GPO A to ADMX and place it in the store. I delete all of my ADMs then I attempt to edit GPO B. Since it’s using an ADMX template that differs from the ADM it was using originally, you may be missing settings or options. We wanted to prevent that.

If you’re 100% certain you won’t see this issue, feel free to use the –NoDateCheck switch I mentioned above to remove all ADMs where a matching ADMX name is found.


Can I use the script if my organization hasn’t implemented the GP central store? (See: An Alternative to the Central Store in this AskDS post).


With the old script, no. With the new one, it’ll check for the central store, first. If it doesn’t exist, it will check the default policy definitions folder (C:\windows\policydefinitions) and use that as the ADMX source. If you’ve got any non-standard ADMX templates, and you aren’t using the central store, you’ll need to ensure those ADMX/ADML files are in c:\windows\policydefinitions.


There’s a switch in the script, –ADMCSVPath, and I’m not sure why it’s there. So why is it there?


Good question. I forgot to remove it. Thanks for reminding me.


Is it possible to add my own ADMs to the script so that I can check for and remove Office ADMs, custom ADMs, and more?


You sure can. If you go to line 130 in the script where all of the out-of-box ADMs are listed you can add each of your own ADMs, as well as the date stamp you’re expecting to find on that ADM. This is only necessary if you want to check specific dates on the ADMs. If you’re comfortable running the script with –NoDateCheck, it’ll remove any ADMs it finds with a matching ADMX regardless of the date stamp.


I’ve run the script and cleaned up all of the ADMs on sysvol. How can I keep ADMs from re-appearing?


First, make sure that all GPO admins are on Vista SP1/Server 2008, or later (read this if you have Vista/7 mixed). If you’re worried about a rogue GPO admin showing up and using an older OS, enable the group policy setting, Always use local ADM files for Group Policy Editor. This setting, outlined here, will force GPMC to use ADMs from %systemroot%\inf instead of storing and reading the ADMs from sysvol.


What happens if I don’t have ADMX templates in my central store or local policy definitions and I remove the ADMs? Is that a resume generating event?


In short, you’ll probably irritate your Group Policy administrators. Removing the ADM template, and not having the ADMX present, means that when attempting to manage a GPO the administrator will not be able to modify, or view, any of the GPO settings specific to that ADM.

Here’s a quick illustration. Assume that you’ve created a GPO which uses an Office12 ADM template (office12.adm). If you view the details on that GPO in GPMC, you’ll see a “Unique ID” or GUID. When you navigate out to SYSVOL on one of your DCs, and go to the Policies folder, you should see a whole bunch of GUIDs. Find the one that matches your GPO GUID and navigate to it. Then open the ADM folder. In the case of my GPO, I see this:


I delete it and let the change replicate around, then edit the policy in GPMC.

When I open the GPO to view the Office 2007 settings, I can’t find them.


What I would have seen before I deleted the template is this:


Fixing it is easy. Find the missing template (because of course you made a backup), right click on Administrative Templates in the GPO and click Add/Remove Templates. In the Add/Remove Templates dialog, click Add… and navigate to the missing ADM. Click Close. If you go back out to SYSVOL and take a look at that Adm folder on the PDCe, you’ll see the template is there and all of the group policy admins have stopped yelling at you.

So don’t worry about that resume, unless you’re looking for a job.


Now you can get out there, convert your ADMs to ADMX, clean up sysvol, and save yourself a ton of disk space.

Also, here’s a link list to the Office ADMX templates because Mark insisted I include it.


Update 1/24/2013: We’ve removed the script from the blog and uploaded it at the script center. It can be found here

– Tom Moser