In Part 1 of this series of posts, I discussed the number of app types supported by Intune for you deployments and discussed how the current gold medal winner – at least in my opinion – as of now is the Windows app (Win32) type. In Part 2, I went further into the explanation of how to get and use the Microsoft Win32 Content Prep Tool to create intunewin packages needed for the Win32 app type. And in this post, I’ll talk about why I suggest using the Win32 app type for everything, including any Line of Business (LOB) applications or Microsoft 365 Apps deployments you wish to assign.
Consider NOT using the “Microsoft 365 Apps” App type
In short, for those that need the TL/DR version: Mixing Windows app (Win32), Microsoft 365 Apps, and Line of Business apps in the same Autopilot deployment can cause some unusual delays/timeouts and even deployment failures, so it’s better to stick with the one deployment type that works for all of these. But don’t just take my word for it, here’s what Microsoft says on the matter:
“When you’re deploying Win32 apps, consider using the Intune Management Extension approach exclusively, particularly when you have a multiple-file Win32 app installer. If you mix the installation of Win32 apps and line-of-business apps during Autopilot enrollment, the app installation might fail as they both use the Trusted Installer service at the same time.”
Source: https://learn.microsoft.com/en-us/mem/intune/apps/apps-win32-app-management#app-dependencies
Okay, so that probably wasn’t the clearest of statements to prove my point, so let me try to explain further. I don’t want to get too “in the weeds” with this, but the short answer is that the solution used by Intune doesn’t allow you to set application installation order, or that you need to wait for a previous application to finish before starting a new install process, and this gets particularly problematic if more than one Microsoft Instaler (MSI) is opened by the TrustedInstaller process. This can happen if the Open Mobile Alliance (OMA) Device Management (DM) side of Intune kicks off an install for a LOB, while the Intune Management Extension plugin tries to install a Win32 app that is also an MSI. The resulting deadlock tends to cause app installation failures, and these can abruptly end the entire provision process in errors. So, unpacking Microsoft’s comment above is hopefully a bit easier: If you decide to use Win32 apps, don’t use any other type that may cause it issues, especially if that app type relies on MSIs, and consider repackaging everything as a Win32 app.
So now you might be thinking, “Okay, we won’t mix LOB and Win32 packages, but what about this Microsoft 365 Apps thing you also mentioned?”. This is a little less defined in the “known issue” camp, but admins all around the world have certainly run face-first into this, which is why I’m writing about it. Autopilot frequently has issues with when installing Microsoft 365 (Office) apps using the built-in app type. Sometimes, admins are seeing this app type get skipped during the Autopilot ESP phase and installed later (unless they add the app in the ESP blocker list). Sometimes, admins report that the install just… hangs, and often until the timeout of the Autopilot process which then causes a failure. Sometimes it just works, and people have no idea what we’re all complaining about. But as an admin that also uses Configuration Manager and faces regular Content Distribution network (CDN) failures obtaining apps during our regular, monthly patch cycle… I can’t imagine that the Intune way is any more reliable.
Now, you could just make the Microsoft 365 apps available for users to get after the Autopilot process has completed; You could just ask your OEM/vendor to pre-load the Office applications onto the device image you use for Autopilot; Or… you can just use the Win32 app type to deploy Office apps.
Okay, so how do I use the Win32 App Type for Office?
If you’d like to know more about the modern versions of Office, and how they made a change from the legacy MSI installer type to the Click-to-Run (C2R) type, I’ve written a previous post all about this:
Long story short, deployment of Office requires the use of three things:
- The Office Deployment Tool (ODT)
This is a command-line executable that you can use to download, deploy, and reconfigure Microsoft 365 Apps to your client computers. You can download the latest ODT setup from the Microsoft Downloads site. Once downloaded, run the self-extracting setup to find a copy of the ODT executable (the setup.exe file, version 16.0.15601.20148 as of writing) as well as a few sample XML files. Find out more here. - A configuration XML file that contains the instructions for the ODT
You can either edit the included XMLs from the ODT folder to your liking, or you can use the Office Customization Tool (OCT) to help you generate your XML using a helpful online wizard. In my previous blog post, I linked to the old “Office Click-To-Run Configuration XML Editor”, however this has now been replaced with the much-improved ODT, which you can now access here: https://config.office.com/deploymentsettings. I will also provide a sample XML below if you’d like to use that as the basis of your instal as well. Find out more here. - And internet connection
Pretty self-explanatory, but at some point – now or later – you’ll need to download Office setup files beyond the ODT, especially if you want to include Office in you Win32 app package.
Okay, that last part of (3) might need some explaining, so let’s get to the next part.
Do You want Files with That?
The ODT is only an 8MB setup file, and there are no other Office installation files included by default… but that doesn’t have to be the case. The magic of ODT is that, when you run the configure command, ODT will access the Microsoft CDN to download the required Office installation files and then use those to install Office on the client device. Furthermore, if you don’t specify a particular version number in the configuration XML files, ODT will always install the latest version of Office for your desired Channel. But ODT also has the download command available, and this changes everything.
- If you know that the client device will have a suitable Internet connection and access to reliably download around 3.5GB from Microsoft’s CDN at the time the install is triggered, then you can create a very small, and always-up-to-date Office installer by only including the ODT setup file and the needed configuration XML(s).
- If you are less sure about the client connection or CDN access, or if you want to standardise on a specific version (at least initially), then you want to run the download command before creating your Win32 package. This will contact the CDN immediately and download the current (or specified) build to an “Office” sub-folder at the same level as the ODT setup file. This will download the full 3.5GB immediately, which you can then capture in the Win32 package, avoiding the need for Microsoft’s CDN to install. Though you’ll still need Intune to be working, and a connection to download the 3.5GB Win32 app package now.
In our case, it’s a case of doing both. For our general Autopilot devices, it makes a lot of sense to just include the ODT and XML package so that we can be sure Office is installed and up to date. But for specific deployments, where we want to validate a deployment and be sure we are consistent and working, we perform a download and re-package the apps.
The Office Configuration XML
This doesn’t need to be complicated. Often, you’ll create a working XML once and then re-use that over, and over again. So, while the Office Customisation Tool might be good if you want a user interface to choose options and see what happens in the XML when you change things… awesome. But for most people, the setup/install configuration will look a little something like this:
<Configuration ID="3be197f7-fa04-4e2f-9d2f-76c5cd669929">
<Add OfficeClientEdition="64" Channel="Current" MigrateArch="TRUE">
<Product ID="O365ProPlusRetail">
<Language ID="en-us" />
<ExcludeApp ID="Groove" />
<ExcludeApp ID="Lync" />
</Product>
</Add>
<Property Name="SharedComputerLicensing" Value="0" />
<Property Name="FORCEAPPSHUTDOWN" Value="TRUE" />
<Property Name="DeviceBasedLicensing" Value="0" />
<Property Name="SCLCacheOverride" Value="0" />
<Property Name="TenantId" Value="12345678-9012-3456-7890-123456789012" />
<Updates Enabled="TRUE" />
<RemoveMSI />
<AppSettings>
<Setup Name="Company" Value="Company Name Here" />
<User Key="software\microsoft\office\16.0\common\general" Name="shownfirstrunoptin" Value="1" Type="REG_DWORD" App="office16" Id="L_DisableOptinWizard" />
<User Key="software\microsoft\office\16.0\common" Name="qmenable" Value="1" Type="REG_DWORD" App="office16" Id="L_EnableCustomerExperienceImprovementProgram" />
</AppSettings>
<Display Level="None" AcceptEULA="TRUE" />
</Configuration>
And I’d recommend an uninstall XML to be included for your package, and this will be even easier:
<Configuration ID="3be197f7-fa04-4e2f-9d2f-76c5cd669929"> <Remove All="TRUE" /> <Property Name="FORCEAPPSHUTDOWN" Value="TRUE" /> <Display Level="None" AcceptEULA="TRUE" /> </Configuration>
In the setup XML above, you really don’t need the TenantID, or any of the AppSettings, but setting these can help avoid a few issues I’ve seen in the past and make your deployment a little nicer. You can also use the AppSettings area to include any specific Office changes needed, such as showing certain tabs in apps. That being said, these are things that can be managed via other configuration profiles in Intune, and I’d recommend going that way instead of baking them into your Office setup unless you need to.
At this point, decide if you’d like to package the ODT and XMLs, or use the installer to download the current build for your selected channel. If the latter, simply run:
setup.exe /Download <name_of_install_xml>
Wait until the command-line finishes and shows a new console line, at which point you should see an Office folder containing around 3GB of files… and you’d be ready to package.
Packaging office is just a matter of running the Win32 Content Prep Tool like last time, specifying the source folder (the folder where you have ODT, your XMLs, and any included Office download files), the name of the setup (just setup.exe for now), the output folder (i.e. “C:\Packages\Out”), and either Y or N for the catalog option. Once the Content Prep Tool has finished, you upload the intunewin file to a new Win32 app type, just like normal.
The setup command will be:
setup.exe /configure <name_of_install_xml>
The uninstall command will be:
setup.exe /configure <name_of_uninstall_xml>
And the rest of the App information is up to you.
Webber Zone 
You must be logged in to post a comment.