ADMX files, where to put them, and you – take 2

4 05 2012

A few years ago, I wrote a blog on the storage location of ADMX files. For Group Policy, these files are crucial, as they define the settings you see in the Group Policy Editor, and by extension, they describe the registry settings which need to be managed on each client workstation to which a policy is applied.

(Contrary to popular belief, the Group Policy Engine on a client does *not* need to refer to these files to actually apply Group Policy. The Group Policy Editor parses the file and stores the specific registry modifications in the appropriate location in the SYSVOL folder structure. The editor does, however, require access to all the proper ADMX files to allow an administrator to make policy changes)

The ADMX format was introduced in Windows Server 2008 and Windows Vista and is XML-based, unlike the previous ADM file syntax of Windows Server 2003, which was a custom syntax which proved challenging at times.

In my earlier post, I specified that the best location to store these files is %systemroot%\PolicyDefinitions on each of your DCs. This was in response to a specific problem I had at a customer with a new, single, standalone Domain Controller.

However, on much larger networks, this advice is not something I would endorse. By storing the policies in the PolicyDefinitions container on each DC, the ADMX files will only be available in the Group Policy Editor on that particular Domain Controller. If you want to use Group Policy Management Console from a workstation, another DC or a member server, then you are going to have many settings which have no policy definition, so you will be unable to manage them. With products like Server Core (a particular focus of Windows Server 8 Beta), managing Group Policy from the DC’s desktop is no longer a recommended or particular routine operation. Similarly, managing a DC directly from its desktop for such routine changes is not a best practice – delegating control over Group Policy and making the changes on a workstation would be a better choice. So, we need a better way of sharing the ADMX files across the entire LAN to ensure they roam to any machine where policy may be set.

Fortunately, Microsoft already have a solution. It’s known as the Central Store. Essentially, this is a PolicyDefinitions folder within the SYSVOL folder hierarchy which you already know about. By placing the ADMX files in this directory, they are replicated to every DC in the domain; by extension, the ADMX-aware Group Policy Management Console in Windows Vista, Windows 7, Windows Server 2008 and R2 can check this folder as an additional source of ADMX files, and will report them accordingly when setting your policies.

By default, the folder is not created. Whether you are a single DC or several thousand, I would strongly recommend you create a Central Store and start using it for all your ADMX file storage. It really does work well.

More information and detailed procedures are available from Microsoft Support.





Windows XP Favourites Redirection – ADMX files

3 08 2010

One of the major disadvantages of still running XP in production is its lack of Internet Explorer Favourites directory redirection. If your users frequently roam between computers, the usual workaround is to enable Roaming Profiles to have the favourites roam with them. This usually works, until Windows Vista or 7 is introduced into the environment.

The newer Microsoft operating systems from Vista onwards do not support the old, legacy format of the XP profile. Instead, users logging on to a modern OS for the first time will be given a new roaming profile with “.V2” appended to their username in the roaming profile share. This is the version 2 profile, used by Vista up and totally isolated from the XP profile, including total isolation of the data it contains. In a phased roll-out of the newer Microsoft operating systems, you must follow best practices by using folder redirection to redirect user data on all systems to a common network location. This removes the data from the profiles, maintains consistency and ensures the user experience is the same on all network stations, without concerns over which OS is installed and therefore which profile and data the user will have access to. Plus, roaming profiles are just too slow for storing lots of user data anyway.

Unfortunately, Windows XP does not support redirection of the Favourites directory; this support was added in Windows Vista. One workaround I have seen is the built-in Vista redirection configured to redirect user favourites folders on newer systems to the legacy XP roaming profile share. This works, but it’s not particularly clean; redirecting data to a profile share rather than a user (home folder) share just isn’t right. It also causes data loss issues if a user’s profile must be reset; I work by the principle that only disposable data – stuff the users could live without – should be put into a user’s profile for precisely this reason.

Implementing Favourites redirection in Windows XP is a logical alternative; it isn’t particularly difficult either. I developed the following ADMX files to supplement the older ADM solutions which are available through a search on a popular web search engine. With 2008 or 2008 R2 Domain Controllers, the ADMX format is available for your use and I would highly suggest you make use of it. ADMX is XML-based and much, much easier to use than the legacy ADM language.

XPFavouritesRedirect.admx

<policyDefinitions revision="1.0" schemaVersion="1.0">
  <policyNamespaces>
    <target prefix="customFavorites" namespace="Microsoft.Policies.Favorites" />
    <using prefix="inetres" namespace="Microsoft.Policies.InternetExplorer" />
  </policyNamespaces>
  <resources minRequiredRevision="1.0" />
  <supportedOn>
    <definitions>
      <definition name="SUPPORTED_IE5" displayName="$(string.SUPPORTED_IE5)" />
    </definitions>
  </supportedOn>
  <policies>
    <policy name="IE_Favorites" class="User" displayName="$(string.IE_Favorites)" explainText="$(string.IE_Favorites_Location_Explain)" presentation="$(presentation.IE_Favorites)" key="Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders">
      <parentCategory ref="inetres:InternetExplorer" />
      <supportedOn ref="SUPPORTED_IE5" />
      <elements>
        <text id="IE_Favorites_Location" key="Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" valueName="Favorites" required="true" expandable="true" />
      </elements>
    </policy>
  </policies>
</policyDefinitions>

XPFavouritesRedirect.adml (name this the same as the ADMX file and dump it in the language folder in your PolicyDefinitions directory)

<policyDefinitionResources revision="1.0" schemaVersion="1.0">
  <displayName>
  </displayName>
  <description>
  </description>
  <resources>
    <stringTable>
      <string id="IE_Favorites">Location of Internet Explorer Favorites</string>
      <string id="IE_Favorites_Location">The path to the favorites folder</string>
      <string id="IE_Favorites_Location_Explain">Specify the path to the location of your Favorites folder. This is stored in an expandable registry string value, so you can use environment variables, such as %HomeDrive%%HomePath%.</string>
      <string id="IE_Favorites_Location_Tip1">Specify the UNC path to the favorites location</string>
      <string id="InternetExplorer">Internet Explorer</string>
      <string id="SUPPORTED_IE5">at least Internet Explorer v5.01</string>
    </stringTable>
    <presentationTable>
      <presentation id="IE_Favorites">
        <textBox refId="IE_Favorites_Location">
          <label>Path:</label>
          <defaultValue>
          </defaultValue>
        </textBox>
      </presentation>
    </presentationTable>
  </resources>
</policyDefinitionResources>

The above is standard ADMX/ADML format which can be dumped in the correct locations of your Central Store (if you don’t have one, why not? Set one up, otherwise you will need to store them in the local store on each DC). In the GP Editor, it will appear as a policy in the standard Internet Explorer area under the User Configuration / Windows Components node.

The Favourites registry value in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders is of type REG_EXPAND_SZ. The ADMX implements this with the expandable=”true” syntax, meaning from your perspective, you can specify environment variables in the GPO and these will be properly expanded by the system to their full paths. I personally use %HomeDrive%%HomePath%\Favourites to direct them to a subfolder of the user’s defined home folder location in their Active Directory user account properties.

This does not move any existing Favourites out of the profile and into the redirected location. However; this is fairly easy to script in a logon script or one-time operation. For new users, the Favourites directory will be created automatically, assuming the home drive exists, the user has permissions, quota is not fully used and so on.

It is a good idea to set the XP Favourites redirection policy in its own GPO object, then apply a WMI condition to filter the policy to XP/2003 and older systems only. Windows Vista and above support native redirection of Favourites, so you should use a separate, WMI filtered policy for Vista+ computers to redirect their Favourites to the same location as defined for XP clients.





Where do I put my ADMX files?

6 06 2009

Note (4th May 2012): As this post proves to be ever popular, I have updated it to account for new developments and to provide a more general method of storing your ADMX files, especially on large networks. Please check out the new post: ADMX files, where to put them, and you – take 2.

ADMX files are the new form of ADM files, the format which defines what Group Policy settings set what registry changes when they are applied. With Microsoft’s move to XML-based file formats and alongside their release of the new Office 2007 file extensions (DOCX, XLSX, PPTX etc.) the ADM format was also upgraded to ADMX.

People familiar with ADM files would remember that in order to have Group Policy Editor read the ADM file and add the settings to the policy, they would need to Add the template. However, for ADMX files, you cannot add them via the Add/Remove Template wizard in Group Policy Editor, because they do not appear as an option to add.

Windows reads the ADMX files on the system from a pre-defined location, and that location is the only location on the system where you should place the ADMX files. It is %systemroot%\PolicyDefinitions, where %systemroot% is normally C:\WINDOWS.

Any ADML files you receive with the ADMX files should be placed into a subfolder within PolicyDefinitions, named after their MUI ID. For example, a en-US ADML file would be placed into the directory %systemroot%\PolicyDefinitions\en-US.

Once you have stored your ADMX files in their respective locations, it is simply a matter of restarting Group Policy Management Console for the files to appear in the Group Policy Editor.

It should be noted that any form of ADM/ADMX file only needs to be present on the machine where the policies are edited from. It does not need to be present on every machine on the network. The ADMX files simply link the GUI of the GPO Editor with the appropriate registry settings to make; the registry settings are simply stored and processed at each client where the GPO applies.