none
Why some GPO has 'ADM' folder some has 'Group Policy' folder

    Question

  • Hi,

    Our GPO are created based on OU level (business unit), where each OU will have it own unique Group policy.

    There are x5 Business Units, thus there are x5 Office 2007 GPOs within the domain.T

    The mystery is when i navigate to the Central store in ....dfs\policies\... some of the GPO showing ADM folder and some showing Group Policy folder. They are both Office 2007 GPOs, but for different OU.

    What could be the reason why ADM folder does not exist in some of the GPO for Office 2007? -- hence unable to add/remove Template.

    How does the Group Policy folder got created in some of the Office 2007 GPO?

    note: We are operating in AGPM environment.

    please shed some lights on this.


    Best Regards,


    • Edited by BlueBerries Wednesday, August 10, 2016 12:44 AM
    Tuesday, August 02, 2016 8:28 AM

Answers

  • Hi,

    Thanks for your post.

    During the creation of the GPT main folder, additional folders and files are created under this root folder. These folders and files include: group policy folder, machine folder, user folder and Gpt.ini file.

    Group policy folder holds the GPE.ini file. The GPE.ini file tracks the GUIDs for the CSEs that are referenced in the GPO. As settings within the GPO are added or removed, the associated GUID for the CSE controlling the setting is added or removed from this file.

    For more information, you could refer to the article below.

    Architecture of Windows group policy

    https://www.microsoftpressstore.com/articles/article.aspx?p=2231763&seqNum=4

    Best Regards,

    Jay


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Marked as answer by BlueBerries Wednesday, August 10, 2016 12:43 AM
    Wednesday, August 03, 2016 5:15 AM
    Moderator
  • > Group policy folder holds the GPE.ini file. The GPE.ini file tracks the
    > GUIDs for the CSEs that are referenced in the GPO. As settings within
     
    Partially correct. I tried to verify - in my domain I have 233 GPOs and
    only 45 of them have a gpe.ini file associated...
     
    Even the MSFT GPO Core protocol specs does not mention this file:
    documentation anywhere with the exception of your book link has
    information about this file. The link you posted proves itself that it
    is partially wrong - see figure 4-6 :-), and it has some other mistakes,
    e.g. the ObjectGUID is _not_ the GUID of the GPO...)
     
    So I had a close look at my GPE.INI files and the GUIDS they contained.
    And it turned out: All CSE GUIDS I found in there are belonging to Group
    Policy Preferences, which were adopted from Desktop Standards back in
    2005/2006.
     
    My conclusion: GPE.INI is _not_ part of the native MSFT Group Policy
    infrastructure, but was added by Desktop Standards for whatever
    purposes. Native GP uses the AD attributes gPCUserExtensionNames and
    gPCMachineExtensionNames to store the referenced CSEs, and the GP Client
    evaluates these attributes. Only during editing a GPO and enabling any
    setting in Group Policy Preferences, a gpe.ini file will be created. An
    educated guess about this file might be "it not only tracks the used
    CSEs, but also individual version numbers for each CSE so each CSE can
    be skipped not only if the GPO overall is unchanged, but even if the
    individual CSE had no changes".
     
    I cannot track this down finally because deep technical docs about GPP
    are not publicly available... The GPPREF doc doesn't help -
     
    • Marked as answer by BlueBerries Wednesday, August 10, 2016 12:42 AM
    Wednesday, August 03, 2016 2:08 PM

All replies

  • The ADM files in your picture (abcxyx14.adm) are all for Office2010 (office v14 is Office2010).
    My guess is that at some time, some admin in your organisation has used the GPMC "add/remove template" function to load the OFF2010 templates and this has caused those template files to load into that particular GPfolder on SYSVOL.

    This is exactly why the Central Store was designed/created (to avoid this type of SYSVOL bloat).

    You can delete these ADM files from the relevant GPfolder. If you *do* use OFF2010 in your organisation, you should consider adding the OFF2010 ADMX/ADML files into your Central Store.

    The "Group Policy" subfolder is normal and expected, depending upon the nature of your GP scenarios in your AD (e.g. we have it in ours)


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Tuesday, August 02, 2016 8:47 AM
  • Hi Don,

    Thanks. yes, I was referring to Outlook 2010 (v14.), sry abt the confusion.

    We want to utilize the Central Store concept, thus I am trying to figure out how all these GPOs have been set up.

    1. For the individual Office 2010 GP that has the Group Policy folder, there is no ADM files, there is one GPE.ini file.

    and I have noticed that the Group Policy folder only exist in the Office 2010 USER GPO and not the in the Computer GPO. There are only the "Machine" and "User" folders in Computer GPO:

     Is this by design?

    Moving forward, since we want to utilize the Central Store concept, any new GPO created should not have ADM folder (with ADM files) in the individual GPO - am I understanding this correctly? 

    All DC servers are running Windows Server 2012 R2, with Windows 7 desktops.


    Best Regards,





    • Edited by BlueBerries Wednesday, August 03, 2016 3:09 AM
    Wednesday, August 03, 2016 2:33 AM
  • Hi,

    Thanks for your post.

    During the creation of the GPT main folder, additional folders and files are created under this root folder. These folders and files include: group policy folder, machine folder, user folder and Gpt.ini file.

    Group policy folder holds the GPE.ini file. The GPE.ini file tracks the GUIDs for the CSEs that are referenced in the GPO. As settings within the GPO are added or removed, the associated GUID for the CSE controlling the setting is added or removed from this file.

    For more information, you could refer to the article below.

    Architecture of Windows group policy

    https://www.microsoftpressstore.com/articles/article.aspx?p=2231763&seqNum=4

    Best Regards,

    Jay


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Marked as answer by BlueBerries Wednesday, August 10, 2016 12:43 AM
    Wednesday, August 03, 2016 5:15 AM
    Moderator
  • Moving forward, since we want to utilize the Central Store concept, any new GPO created should not have ADM folder (with ADM files) in the individual GPO - am I understanding this correctly? 

    All DC servers are running Windows Server 2012 R2, with Windows 7 desktops.

    the ADM subfolder will only be (re)created if you have GPadmin staff using old machine for GPediting or if the GPadmin staff are doing the wrong thing.

    e.g. if you were to action some of the advice from the linked blog articles and deleted all the ADM files from your SYSVOL, it would only take one GPadmin person to 'do the wrong thing' and those ADM files will all come back into SYSVOL again..

    if your GPadmin staff all use modern platforms to manage GP and if they don't use the 'Add/Remove Templates' feature in GPMC/GPME, you will have the best chance to eliminate ADM files from SYSVOL ;)


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Wednesday, August 03, 2016 8:40 AM
  • > Group policy folder holds the GPE.ini file. The GPE.ini file tracks the
    > GUIDs for the CSEs that are referenced in the GPO. As settings within
     
    Partially correct. I tried to verify - in my domain I have 233 GPOs and
    only 45 of them have a gpe.ini file associated...
     
    Even the MSFT GPO Core protocol specs does not mention this file:
    documentation anywhere with the exception of your book link has
    information about this file. The link you posted proves itself that it
    is partially wrong - see figure 4-6 :-), and it has some other mistakes,
    e.g. the ObjectGUID is _not_ the GUID of the GPO...)
     
    So I had a close look at my GPE.INI files and the GUIDS they contained.
    And it turned out: All CSE GUIDS I found in there are belonging to Group
    Policy Preferences, which were adopted from Desktop Standards back in
    2005/2006.
     
    My conclusion: GPE.INI is _not_ part of the native MSFT Group Policy
    infrastructure, but was added by Desktop Standards for whatever
    purposes. Native GP uses the AD attributes gPCUserExtensionNames and
    gPCMachineExtensionNames to store the referenced CSEs, and the GP Client
    evaluates these attributes. Only during editing a GPO and enabling any
    setting in Group Policy Preferences, a gpe.ini file will be created. An
    educated guess about this file might be "it not only tracks the used
    CSEs, but also individual version numbers for each CSE so each CSE can
    be skipped not only if the GPO overall is unchanged, but even if the
    individual CSE had no changes".
     
    I cannot track this down finally because deep technical docs about GPP
    are not publicly available... The GPPREF doc doesn't help -
     
    • Marked as answer by BlueBerries Wednesday, August 10, 2016 12:42 AM
    Wednesday, August 03, 2016 2:08 PM