Office 365 ProPlus - How To: Add previously excluded components
If you have installed a Office 365 ProPlus with a custom XML file with excluded components and then struggled to add components that users needed, this post should help you with the process of pushing additional components to managed devices.
Hello, Nandan here again. When I last wrote a blog post I was based in Reading, UK and have since relocated to Dublin. It’s been a busy but interesting last few months with the transition.
Back working with customers, helping them with their move to a modern desktop, I ran into an interesting query last week. One of my customers is in the process of deploying Windows 10 with Office 365 ProPlus. As part of the operating system deployment, they are deploying a generalized Office configuration. The XML file that is being used to configure the Office client excludes a specific set of components and the setup process works exactly as it is expected to. The components that are excluded are not available on the system. Here is a snippet of the XML file to show the components that are not being deployed. 
As you can see, we are excluding Access, Skype for Business and both OneDrive components - OneDrive Desktop and OneDrive Groove.
Now, certain users within the organization need to work with Access databases. So obviously, they will need Access on their systems. The business wants to make Access available to users on demand when they need it and not have it installed as a standard component of Office. This is understandable and a common practice. To perform this installation, we have created a second XML file which does not have the exclusion for Access.
In the first instance, Office is installed successfully without Access. In the second instance, with the modified XML file, setup runs and when the over-the-top install completes Access is still missing.
So, how do we resolve this problem to ensure Access is deployed for users that have a need for this component?
As it turns out, there are two ways to do this.
Simple and Dirty: Install Access as an Independent Application
Create a new XML: 
We use AccessRetail as the Product ID. 16.0.9126.2295 - the Version element - is an Office 365 ProPlus Semi Annual Channel build from the 1803 release of Office 365 ProPlus and when Access is installed, it is the right branch and version as needed.
This is the dirty approach because now, Office 365 ProPlus and Access 2016 show up as two separate applications in the Add Remove Programs dialog box. Access might need separate patch management and also, I am not 100% sure if Access will update in line with how other O365 ProPlus components would. I haven't used the Office 365 ProPlus components with this configuration and this will need a considerable amount of testing to ensure things work as expected. Finally, if you are using multiple language packs, there will be one entry for each language pack. In our case, we had 18 entries in Add Remove Programs because we were using 9 language packs (this will be cleaned up in a separate exercise). Cosmetically, this is a nightmare. 
The Cleaner Way
To begin with, I modified my second XML file to add logging for the Office 365 ProPlus installation. 
I also used SysInternal’s Process Monitor to track any file and registry activity that was happening on the system while an over-the-top-install was running to install the missing Access components.
The logs revealed some interesting information. About three seconds in after calling setup.exe, we see the following information in the log file:
01/21/2019 11:46:06.522 SETUP (0x28ec) 0x1b0c Click-To-Run General Telemetry aoh9t Medium TryLaunchClient::HandleStateAction {"MachineId": "71f7769c1fca0c488833235052d1f416", "SessionID": "1eb0e35a-e57c-4051-b6a2-497355a89d17", "GeoID": 242, "Ver": "16.0.9126.2295", "C2RClientVer": "16.0.9126.2295", "ContextData": "{\"message\":\"Launching executable\",\"ClientExeName\":\"OfficeClickToRun.exe\",\"Parameters\":\"culture=en-us defaultplatform=False allowcdnfallback=False deliverymechanism=7ffbc6bf-bc32-4f92-8982-f9dd17fd3114 platform=x86 productreleaseid=none forcecentcheck= lcid=1033 b= storeid= piniconstotaskbar=FALSE autoactivate=1 productstoadd=O365ProPlusRetail.16_en-us_zh-cn_cs-cz_hu-hu_ms-my_pl-pl_ko-kr_sk-sk_th-th_x-none scenario=CLIENTUPDATE updatesenabled=True acceptalleulas=True cdnbaseurl=https://officecdn.microsoft.com/pr/7ffbc6bf-bc32-4f92-8982-f9dd17fd3114 version=16.0.9126.2295 sclcacheoverride=0 mediatype=Local baseurl=\\\"C:\\\\Users\\\\username\\\\file_location\\\\OfficeC2R\\\" o365proplusretail.excludedapps=groove,lync,onedrive sharedcomputerlicensing=0 flt.useexptransportinplacepl=unknown flt.useoutlookshareaddon=unknown flt.useofficehelperaddon=unknown\"}"}
We can see that setup is correctly identifying that Access should be installed. However, the end result is not aligned with our requirements or expectations.
A process monitor trace gives us some more information.
11:46:06.7572701 OfficeClickToRun.exe 684 10964 RegSetValue HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Scenario\CLIENTUPDATE\ExcludedApps SUCCESS Type: REG_SZ, Length: 78, Data: o365proplusretail_groove,lync,onedrive 11:46:12.0268475 OfficeClickToRun.exe 10468 1264 RegSetValue HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Scenario\INSTALL\ExcludedApps SUCCESS Type: REG_SZ, Length: 78, Data: o365proplusretail_groove,lync,onedrive 11:46:12.1683621 OfficeClickToRun.exe 10388 10132 RegQueryValue HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Scenario\INSTALL\ExcludedApps SUCCESS Type: REG_SZ, Length: 78, Data: o365proplusretail_groove,lync,onedrive 11:46:12.1683934 OfficeClickToRun.exe 10388 10132 RegQueryValue HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Scenario\INSTALL\ExcludedApps SUCCESS Type: REG_SZ, Length: 78, Data: o365proplusretail_groove,lync,onedrive 11:46:12.1685581 OfficeClickToRun.exe 10388 10132 RegQueryValue HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\O365ProPlusRetail.ExcludedApps SUCCESS Type: REG_SZ, Length: 56, Data: access,groove,lync,onedrive 11:46:12.1686073 OfficeClickToRun.exe 10388 10132 RegQueryValue HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\O365ProPlusRetail.ExcludedApps SUCCESS Type: REG_SZ, Length: 56, Data: access,groove,lync,onedrive 11:46:12.1688617 OfficeClickToRun.exe 10388 10132 RegSetValue HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Scenario\INSTALL\ExcludedApps SUCCESS Type: REG_SZ, Length: 92, Data: O365ProPlusRetail_access,groove,lync,onedrive 11:46:12.1902420 OfficeClickToRun.exe 10388 10132 RegQueryValue HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Scenario\INSTALL\ExcludedApps SUCCESS Type: REG_SZ, Length: 92, Data: O365ProPlusRetail_access,groove,lync,onedrive 11:46:12.1902609 OfficeClickToRun.exe 10388 10132 RegQueryValue HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Scenario\INSTALL\ExcludedApps SUCCESS Type: REG_SZ, Length: 92, Data: O365ProPlusRetail_access,groove,lync,onedrive 11:46:12.1903673 OfficeClickToRun.exe 10388 10132 RegSetValue HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\O365ProPlusRetail.ExcludedApps SUCCESS Type: REG_SZ, Length: 56, Data: access,groove,lync,onedrive 11:46:12.1913449 OfficeClickToRun.exe 10388 10132 RegQueryValue HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\O365ProPlusRetail.ExcludedApps SUCCESS Type: REG_SZ, Length: 56, Data: access,groove,lync,onedrive
Setup.exe calls into OfficeClickToRun.exe which is querying the ExcludedApps value from the initial install. It sees that Access was excluded in the initial deployment, and then reconfigures the Configuration\O365ProPlusRetail.ExcludedApps to reflect the original configuration that excluded Access. The setup process then completes without enabling the components for Access and it does not show up as installed.
To resolve the issue, we ended up using a simple batch file that first modified the registry before invoking setup.exe. As you can see below, this really as simple as simple can get.
===== START BATCH FILE ===== reg.exe add HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration /v O365ProPlusRetail.ExcludedApps /d REG_SZ /v groove,lync,onedrive /f setup.exe /configure .\OfficeC2R_1803_Access_Config.xml ===== END BATCH FILE =====
This works great and when setup.exe completes an over-the-top install, Access is included on the Office deployment and works just as expected.
On my side, I am trying to see if I can reproduce this problem on a test environment and then flag this with the product group for some more investigation as I have seen threads on various forums where people have experienced similar problems. Once I have an update, I will refresh the content of this post with relevant information.
In the meantime…
- If you experience any inconsistencies with Office 365 ProPlus installations, irrespective of which build you are installing, see if you are using the latest version of the Office Deployment Tools. The tooling is update frequently, and can be downloaded from HERE. The latest version is 16.0.11306.33602, dated 14th January 2019 (at the time this post was written) and which is what we used while trying to crack this problem.
- If you need to deploy Office 365 ProPlus and need to author your configuration.xml files, try using https://config.office.com. This is a great online tool that lets you create your configuration files without having to remember the tags and structure of the XML file.
- For more details on Office Customization, refer to THIS.
- And finally, refer to this link for the configuration options for the office deployment tool.