ADMX Backed – The Office Case

2019-02-28

This case come from one of my customer, they followed the Chrome example available at code.vmware.com, but didn’t seems to work correctly for the Office ADMX available from Microsoft, as the profile said “Install Failed”.

Step 1 – Reproduce

Created a custom XML in the console in this format :

<Add>
 <CmdID>2</CmdID>
 <Item>
  <Target>
   <LocURI>./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Office16/Policy/Version1</LocURI>
  </Target>
  <Data>{AMDX DATA HERE converted from <value> to <value> }</Data>
 </Item>
</Add>

Deploying the profile gives the following SyncML response from the device :

<Status>
 <CmdID>3</CmdID>
 <MsgRef>3</MsgRef>
 <CmdRef>2</CmdRef>
 <Cmd>Add</Cmd>
 <Data>425</Data>
</Status>

According to the SyncML Protocol, 425 mean ‘access denied‘.

Discovered that later but you have also an Windows Event ID 850 in Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin which gives the information required…

ADMX-Backed-OfficeADX-Windows-Event-Error

Step 2 – Back to basics

I decided to try another ADMX but as I wanted to rule out any issue with 3rd party ADMX, I’ve used my own.

Deployed using the same profile as Office, worked as the SyncML response is 200, checked the registry at HKLM\SOFTWARE\MICROSOFT\PolicyManager\AdmxInstalled

ADMX-Backed-ADMXTesting-Registry

We can see the ADMX install with the right settings.

Step 3 – RTFM

I started to read docs.microsoft.com, I come across this documentation, Win32 and Desktop Bridge app policy configuration.

In the overview, it describe how the ADMX are imported and what are the check against it, and at one point, it says the following :

the ingested policies are not allowed to write to locations within the System, Software\Microsoft, and Software\Policies\Microsoft keys, except for the following locations:

  • Software\Policies\Microsoft\Office\
  • Software\Microsoft\Office\
  • Software\Microsoft\Windows\CurrentVersion\Explorer\
  • Software\Microsoft\Internet Explorer\
  • software\policies\microsoft\shared tools\proofing tools\
  • software\policies\microsoft\imejp\
  • software\policies\microsoft\ime\shared\
  • software\policies\microsoft\shared tools\graphics filters\
  • software\policies\microsoft\windows\currentversion\explorer\
  • software\policies\microsoft\softwareprotectionplatform\
  • software\policies\microsoft\officesoftwareprotectionplatform\
  • software\policies\microsoft\windows\windows search\preferences\
  • software\policies\microsoft\exchange\
  • software\microsoft\shared tools\proofing tools\
  • software\microsoft\shared tools\graphics filters\
  • software\microsoft\windows\windows search\preferences\
  • software\microsoft\exchange\
  • software\policies\microsoft\vba\security\
  • software\microsoft\onedrive
  • software\Microsoft\Edge
  • Software\Microsoft\EdgeUpdate\

We know that the Office ADMX is using Software\Microsoft\Office\ but is it possible that it may have something not in the white list?

Step 4 – Wrapping Up and Scripting

I started checking manually as no script available and coding one would take longer, also Notepad++ is very efficient if you know how to use it.

Bingo! One of the policy within office16.admx goes to software\policies\microsoft\vsto which is not in the white list.

<policy name="L_DisableVSTOLegacy1Or2" class="User" displayName="$(string.L_VSTOLegacy1Or2)" explainText="$(string.L_VSTOLegacy1Or2Explain)" key="software\policies\microsoft\vsto" valueName="vstolegacy1or2disable">
  <parentCategory ref="L_SecuritySettings" />
  <supportedOn ref="windows:SUPPORTED_Windows7" />
</policy>

Deleted this policy from the ADMX, added the new ADMX in the profile and no issue, registry keys created correctly

Registry

If you need to deploy the policy, you will require to deploy it with other means like powershell script or else.

As Office use multiple ADMX, we need to check every ADMX file, in order to make sure that there is no issue with the other ones. As there is 11 ADMX just for Office 2016, and other version will have other ADMX, I created a PowerShell script which check the ADMX file and give the name of the problematic policy. You can also specifiy a folder with ADMX files in it and it will analyze everyone of them.

PowerShell script : https://github.com/CamilleDebay/Scripts/blob/master/ADMX/ADMXValidation.ps1


Usage:

.\ADMXValidation.ps1 -Path "C:\Temp\Admx\" [-DisplayCorrectPolicy]

-Path : Path to folder or admx file - Mandatory
-DisplayCorrectPolicy : Display name of correct policies - Optional