Import Administrative Templates (ADMX) into Intune

With Configuration profiles in Intune (or whatever Microsoft calls it these days), you can create an ‘Administrative Templates’ profile. Administrative Template profiles allows you to apply standard Windows and Microsoft Office group policy settings on Intune clients.

But what happens if you want to use ADMX that is provided for other companies? Unfortunately, at the time of writing, you cannot import 3rd party ADMX files into an Administrative Template profile.

However, hope is not lost! You can use the ‘Custom’ configuration profile in Intune to import (‘Ingest’) 3rd party ADMX files. Unfortunately, it’s not as easy as it could and should be. In this post I will explain how to use ‘Custom’ configuration profile in Intune to apply 3rd party group policy settings.

The example I use in this post is to import the Google Chrome settings. Google already has published steps on how to import their ADMX files into Intune using a ‘Custom’ configuration profile, however they are not as detailed as I think they should be.

You should be able to use the steps below for any 3rd party ADMX policy file.


Unfortunately, before I begin, I need to go over some things! You need to know the following:

  • When you set a Group Policy setting, Windows modifies registry keys
  • Group Policy registry keys are usually located/created in the following locations in either the HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE hives:
    • (hive)\Software\Policies
    • (hive)\Software\Microsoft\Windows\CurrentVersion\Policies
  • ADMX files are XML files specify what registry keys/values need to be created/modified to apply a setting.
  • When setting a Group Policy setting using a ‘Custom’ configuration profile, you have to use ‘OMA-URIs’. Unfortunately, these URIs do not map nicely to Group Policy settings in the ADMX file. This is explained under the Confirm ADMX Ingestion heading.

You should also have a nice text editor before you begin these steps as you will need to open the ADMX files in several steps.

Ingest the ADMX file

  1. Logon to Intune and navigate to Configuration profiles
  2. Click + Create Profile
  3. From the slide out Create a profile blade, select and create the following:
    1. Platform: Windows 10 and later
    2. Profile: Custom
  4. This should open the steps to create a Custom Profile
  5. In the Basics step, provide a name and a useful description, we tend to use a naming convention when we create Intune Configuration profiles. You should to!
  6. In the Configuration settings step, beside OMA-URI Settings, click Add. This is where you will configure this profile with the custom ADMX file.
  7. From the slide out Add Row blade that, configure the following settings:
    1. Name: <product> ADMX Ingestion (e.g. ‘Chome ADMX Ingestion’)
    2. OMA-URI:
      • This is a key setting, and MUST CONTAIN the following:
      • You can add whatever path you want after the above path, but try to make it sensible
      • I tend to follow how Google ingests their Chrome settings with a path similar to <product>/Policy/<product>Admx
      • Using Chome as the example, the full OMA-URI path would be:
      • The path that you choose here will determine how the ADMX file appears in the registry in later steps, and the OMA-URI paths
    3. Data type: String
    4. Value: Open the ADMX file and copy the contents of the file into this field.
    5. In the end, your add row should look similar to the following:
      Add Row
      Adding a custom OMA-URI row


  8. Once you have added the row, you can continue through the rest of the create profile steps. Setting the required scope and assignments. I would suggest that you apply the this profile to a select of test devices first.
  9. Now it’s time to see if the ingestion worked! Remember: Intune Clients can be a bit slow to apply new settings.

Confirm ADMX Ingestion

This step requires you to be on a Windows machine that has been targeted by the new ‘Custom’ configuration profile you created earlier.

  1. Within Intune, confirm that the Profile assignment status on the client machine you are about to use is marked as ‘Succeeded’
  2. On the Intune Client machine, open regedit, and navigate to this key
  3. If the client has ingested the ADMX settings, you should see the following registry paths:
    1. The entire ADMX file will be ingested and the XML structure will be turned into registry keys in the following location:

      Note: If you have ingested multiple ADMX files, settings for all files will appear here

    2. You will also see keys in the following location that relate to the ingestion of the ADMX file:

      Note: The path shown above should match the OMA-URI path you setup in the Ingest the ADMX file steps.

  4. In regedit, have a look through the sub-keys in the following location. The exact path of these subkeys are required when you want to manage the group policy settings contained in the ADMX file
    1. The policies should have subkeys that have names that match policies defined within the ADMX file
    2. In the example below, you can see what it looks like when the chrome.admx file is ingested into the registry:
    3. If I want to set the highlighted setting via OMA-URI path I will need to remember the following path:
    4. In the example above I have highlighted ‘PasswordManagerEnabled’, I can now open the chrome.admx file to find that policy definition:
    5. Note that, in the chrome.admx file it states that in order to configure the ‘PassowordManagerEnabled’ setting, it will:
      • Use the key:
      • Use the value:
    6. You will need to take note of these registry locations to confirm that the policy has applied in later steps.

Apply ADMX Settings

Now it is time to apply what has been learnt in the previous steps:

  1. Open Intune and on the Custom Profile you made earlier, edit the Configuration settings
  2. Beside OMA-URI Settings, click Add
  3. From the slide out Add Row blade that, configure the following settings:
    1. Name: <product> ADMX <setting> (e.g. ‘Chome ADMX PasswordManagerEnabled’)
    2. OMA-URI:
      • This is a key setting, and MUST CONTAIN the following:
      • The path after the above MUST MATCH the registry path you discovered earlier (e.g.)
      • Putting it altogether, the full OMA-URI path would be:
    3. Data type: String
    4. Value: This difficult to determine exactly what you need to put in here to configure the setting correctly. Some examples include:
      • If it’s a boolean that is either enabled or disabled the string can be:
      • If it’s a setting that you have to populate with a string, then you need to create a data id/value pair. The id needs to equal the name of the policy and the value needs to be the string you want to use. e.g.
        <enabled/><data id="ApplicationLocaleValue" value="en"/>
    5. In the end, your add row should look similar to the following:
  4. Save your configuration profile. Now it is time to check if your settings have applied!

Confirm ADMX Settings

Logon to the Windows machine that has been targeted by the ‘Custom’ configuration profile.

  1. Within Intune, confirm that the Profile assignment status on the client machine you are about to use is marked as ‘Succeeded’
  2. On the Intune Client machine, open regedit, and navigate to this key/value of the policy found in the admx file, in our example it should be:
    • Key:
    • Value:
  3. If you have been successful, the registry key should now be there!

Hopefully this has given an overview of how you can add any ADMX into Intune, and (by looking into the registry), discover the OMA-URI you need to use to configure whatever setting you want to set.

Using this method (say over using a script), is really powerful because Intune will report via Profile assignment status if the registry keys are being created or not.

It’s an annoying thing to setup though, and if you have any questions feel free to ask them in the comments!

Some Additional Notes

  1. If you are getting a -2016281112 (Remediation failed) / 0x87d1fde8 error, it could be either:
    • the OMA-URI is incorrect
    • you are trying to import Microsoft policies (it looks like Intune client blocks the ingestion of ADMX files that write keys into Software\Policies\Microsoft)


Microsoft ATA: Encryption downgrade activity

If you have Microsoft Advanced Threat Analytics (ATA) within your environment, you may have seen the following warning:

Encryption downgrade activity
The encryption method of the ETYPE_INFO field of KRB_ERR message from x computers has been downgraded based on previously learned behavior. This may be a result of a Skeleton Key on x domain controllers.

I work for quite a large firm, and we were getting these for a handful of computers and accounts.

Initially we looked through Microsoft’s somewhat useful Advanced Threat Analytics suspicious activity guide. However under the heading “Encryption downgrade activity” it somewhat puts the fear of God into you. Indeed, after we did our investigations with the tools provided in that article, we found nothing. So what was going on?

We raised an incident with Microsoft and eventually found that these accounts have passwords that had not been updated for a very long time (before 2010).


  1. When a client negotiates with the KDC (a Domain Controller), it will send the client principal name and realm (eg username/domain.local)
  2. The KDC will look up the client in Active Directory, specifically the supplementalCredentials field in AD.
  3. Should the user be missing the Primary:Kerberos-Newer-Keys property, then the KDC will negotiate a lower encryption with the client, and the warning will be raised in ATA.

If your domain functional level is Windows 2008 or higher (which quite frankly it should be by now!), reset the users password, as 2008 DFL introduces the Primary:Kerberos-Newer-Keys property. By resetting the users password, this *should* set the Primary:Kerberos-Newer-Keys property, and the error should go away in ATA.

If you want to test if you have this issue, just try logging on with one of these impacted user accounts to a domain joined PC, or any other system that authenticates via Kerberos.  Just use a bogus password for the account, don’t worry about it if you don’t know the accounts password because the Kerberos negotiation happens before authentication. If your failed logon raises an alert in ATA, then that account needs to change it’s password.

TL;DR: Just reset the password of the impacted users.


Filtering the Windows Security Log

Filtering the Windows Security Log can be a pain in the arse if you don’t know how to use the XML filtering.

Here are two filtering options I use a lot in order to glean some information…

Filter Security Log by username:

Find all successful and unsuccessful logons from a particular user…

<Query Id="0" Path="Security">
<Select Path="Security">* [EventData[Data[@Name='TargetUserName']='USERNAME']]</Select>

Get NTLM Logons

Find all logons that were done with NTLM (good for finding the old crap on your network)

<Query Id="0" Path="Security">
<Select Path="Security">* [EventData[Data[@Name='AuthenticationPackageName']='NTLM']]</Select>

Visio org chart: entries not in the organization

If you are trying to create an organisation chart in Visio using Exchange, and getting the error:



Your organization data contains 1 entries that are not in the organization. Do you want to include them in your drawing?

To fix this, turn off caching in Outlook.

No idea why this works, haven’t looked much into it. If you do know of a more elegant way to solve this issue, leave a comment!

2012R2 Core and Hyper-V on Intel Nuc

As I am currently between jobs (read: Unemployed), I thought I would build my own mini lab to help practice the timeless art of being a Windows System Administrator.  To that end I have purchased a Intel i5 NUC (D54250WYKH). I chose this as a lab computer because my current place doesn’t have much space, and while it may not have incredible performance, it’s reasonably powerful enough to run a number of virtualised servers, provided you have enough ram and an SSD.

This post will cover installing Windows Server 2012 R2 Core with Hyper-V on an Intel NUC in a workgroup environment (non domain joined).

Initial Notes

  1. According to Intel the D54250WYKH does not come with AMT, so unfortunately you’ll have to connect a keyboard and monitor at least initially as Windows Server 2012 R2 does not come with the nic drivers ootb.
  2. The steps below rely on using both the command prompt and PowerShell. To enter PowerShell from the command prompt in Windows Server Core, just type: powershell. To exit PowerShell back to the command prompt, just type: exit.
  3. The client I am using is a Windows 8.1 Pro computer


You’ll need the following:

  1. An Intel NUC (D54250WYKH), and the following drivers:
    1. Ethernet Adapter (you will need to modify the driver to allow installation on Windows Server 2012 R2, follow these steps)
    2. Chipset Device Software (you will need to extract the driver from the installer, you can do that by running SetupChipset.exe with the -extract argument)
    3. Management Engine Driver
  2. Windows 2012 R2 on a bootable USB
  3. Hyper-V Remote Management Configuration Utility (HVRemote)


  1. Install Windows Server 2012 R2 Core.
  2. Give the server a name, in PowerShell run:
    Rename-Computer -NewName server-name -Restart

  3. Because we are installing modified drivers, we need to disable Windows restrictions around unsigned drivers, run the following commands in command prompt:
    bcdedit /set TESTSIGNING ON
    bcdedit /set nointegritychecks ON
    You will now need to reboot the server

  4. Install the drivers using pnputil in command prompt:
    pnputil.exe -i -a D:intel-driversnicRarSFX0PRO1000Winx64NDIS64e1d64x64.inf
    You will be prompted with Windows can’t verify the publisher of this driver software, just Install this driver software anyway
    pnputil.exe -i -a D:intel-driverssmbusChipset_SMBus.inf
    pnputil.exe -i -a D:intel-driversintelMEDriversMEIheci.inf

  5. Now you should have network connectivity, lets enable remote desktop connections, file sharing and ping with powershell:
    Set-ItemProperty -Path ‘HKLM:SystemCurrentControlSetControlTerminal Server’ -Name “fDenyTSConnections” -Value 0
    Enable-NetFirewallRule -DisplayGroup “Remote Desktop”
    Enable-NetFirewallRule –DisplayGroup “File and Printer Sharing”

  6. Install Hyper-V and allow remote management (this is where you will need the hvremote script):
    Install HyperV: Install-WindowsFeature –Name Hyper-V -IncludeManagementTools –Restart
    cscript hvremote.wsf /mode:server /add:administrator
    cscript hvremote.wsf /mode:server /firewallhypervmgmt:enable
    cscript hvremote.wsf /mode:client /anondcom:grant

  7. If you are remoting to this server you will need to whitelist clients using the following command:
    winrm set winrm/config/client @{TrustedHosts=”client-name”}

  8. On your Hyper-V client
    1. Make sure you have PowerShell and the HyperV Management Tools installed
    2. Open Component Services
    3. Expand Component Services, then Computers
    4. Right click on My Computer and click on Properties.
    5. In the COM Security tab, click Edit Limits under Access Permissions.
    6. Enable Remote Access for Anonymous Logon
    7. In PowerShell run:
      Set-Item WSMAN:LocalhostClientTrustedHosts -Value * -Force # *
    8. In command prompt (replace the server-name and password):
      cmdkey /add:server-name /user:ADMINISTRATOR /pass:password

Closing Notes

You should now be able to:

  1. Connect your client HyperV manager to the server you created
  2. Enter remote PowerShell sessions via Enter-PSSession -ComputerName
  3. Ping and File Share with your server

There will be some devices that aren’t installed, these are 2 Audio Devices and the Infrared sensor on the front of the Nuc, I have not bothered to install those drivers.

If you have any comments, please leave them! I would appreciate the feedback, and I would also love to know if I have missed anything or whether I should have done something differently.

LibreOffice group policy

LibreOffice 4.2 introduced the ability to control LibreOffice settings via registry keys. In so doing, it allows Group Policy to set LibreOffice settings.

Unfortunately, LibreOffice have not provided much documentation on their main.xcd file, so it’s hard to know exactly what registry key you need to create in order to set a particular setting.

I have created a stub Group Policy admx / adml file for LibreOffice. Check it out on github.

With this admx file, hopefully it will be easy for you to set LibreOffice settings, without trying to figure out where the particular setting is stored in main.xcd.

user profile not loading

Have you got a windows user profile that isn’t loading correctly?

Have you checked:

  1. Is the profile loaded into the registry already? (check regedit under HKEY_USERS)
  2. Has the user got write access to the registry hive? (can be an issue in default profile / roaming profile scenarios)

Well if it’s not those things! Open regedit and head to:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList

Find the folder that contains your user profile information (it’ll be in the key ProfileImagePath) and then delete this folder.

libreoffice spellcheck fails with roaming profiles

Occasionally I receive helpdesk calls from staff reporting that their LibreOffice spell check has failed, as this issue is not reported often, my initial response is just to clear the users LibreOffice appdata folder and have them launch LibreOffice again.

This would fix the spell check issue and I considered it something the user must have done, as I did not receive that many calls.

However the calls picked up, so I decided to investigate the issue. This is what I have found.

LibreOffice will not load Language modules if the user is not using the RDS server that they originally launched LibreOffice on.

So consider the following scenario:

  1. You open LibreOffice for the first time and you get RDS Server 1
  2. The next time you open LibreOffice, you get RDS Server 2. You will notice that your Language modules are not loaded, so spell check fails to work.
  3. The next time you open LibreOffice you get RDS Server 1 again. Language modules will load now and spell check will work!

As you can see this could be very annoying if you have a lot of servers. So what’s going on?

It seems to relate to the users libreoffice folder. In particular the LibreOffice3userextensions folder (you will find this in the users %appdata% folder). I am not quite sure of what is happening, but if you remove this folder LibreOffice will re-create it the next time you open LibreOffice.

I created a logoff script to delete the %appdata%LibreOffice3userextensionssharedlastsynchronized file when the user logs off an RDS server. The next time they open LibreOffice it will re-create whatever it needs to re-create in order for the Language modules to be imported correctly.

I believe that LibreOffice could fix this issue, so I have opened a bug here:

Though LibreOffice have not been very helpful in fixing it!