Office CSP vs Win32App: Dawn of Justice

Last Updated on November 1, 2023 by rudyooms

This blog will show you how to make sure the Microsoft 365 apps are installed during Autopilot by converting the Microsoft 365 Apps setup to a Win32App instead of using the built-in Office 365 CSP option.

I will divide this blog into multiple parts, describing all the options you have!

  1. Introduction
  2. The “Built-in/CSP” option
  3. Important knowledge about the CSP Option
  4. What could go wrong with the CSP option
  5. The “Win32App” option
  6. The “PowerShell Script” option
  7. What the Win32app of the Office 365 apps setup doesn’t fix!

1. Introduction

When you start using Intune and start deploying the Microsoft 365 apps to your devices you will probably be using the built-in option in Intune. With this built-in option, you could easily make sure the Microsoft 365 Apps are deployed to your devices.

Some time ago I wrote a blog about how you could make sure you can make sure each group who needs the x64 version will get it and who needs the x86 would also get it installed.

In the blog I mentioned above, I showed you which options you have to deploy the Microsoft 365 apps. One of these options was using the built-in Microsoft 365 Apps in Intune. It looks great because you only need to configure some basic stuff as shown below and you are good to go

Graphical user interface

Description automatically generated

Let’s take a closer look at this built-in option!

2. The “Built-in/CSP Option”

Before I am going to show you the “New way” let’s take a look at how the Microsoft 365 Apps are deployed when using the built-in option in Intune.

This Built-in Microsoft 365 application is using the Office *CSP. “The Office configuration service provider (CSP) enables a Microsoft Office client to be installed on a device via the Office Deployment Tool (ODT)”

*A configuration service provider (CSP) is an interface to read, set, modify, or delete configuration settings on the device

A picture containing table

Description automatically generated

The CSP (POLICY) will download the Office 365 Click2Run setup.exe, the configure.xml. With these 2 files, it will start downloading the necessary Microsoft Installations files from the Office CDN (Content Delivery Network) with the Office CDNBaseUrl :officecdn.microsoft.com

When using Firewall rules, please make sure you are allowing traffic to this OfficeCDN Microsoft endpoint!

Of course, everyone is using delivery optimization so these files will first be downloaded in the C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\cache folder

After Delivery optimization did its perfect job these files will be moved to the C:\Program Files\Microsoft Office\Updates\Download\PackageFiles folder.

After it finished downloading all the required installations files, it will start installing the Microsoft 365 apps on the device by triggering the OfficeClickToRun.exe

After a while, if the installation is finished successfully with the status code (70) you will end up with the Microsoft 365 Apps installed! Isn’t that nice?

3. Important knowledge about the Office CSP Option

I will try to point out some “fun” facts about the CSP option in this section

  • Normally a CSP is used to deploy an Intune configuration policy to your device but when deploying Microsoft 365 apps, a CSP is used to deploy the Microsoft 365 apps to your device. I guess that’s the main difference between a normal Win32app and the built-in/CSP option in Intune to deploy Microsoft 365 apps.
  • The built-in CSP option in Intune to deploy Microsoft 365 apps is just a POLICY, not an Application!
Break Policy GIFs - Get the best GIF on GIPHY
  • Looking at this picture below (added some stuff 🙂 ) because this option IS NOT AN Win32App some important configuration items are missing. Comparing the built-in option with a Win32 app, you will notice the CSP option is missing the possibility to configure some, Requirements, Dependencies, Detection rules, and supersedence. These wonderful options could really come in handy but unfortunately, they aren’t available when using the CSP option.

4. What could go wrong with the CSP option

Wondering what could go wrong when choosing the Office365 CSP option? Let me show some examples:

Example 1: FinalStatus

The Office CSP XML and the FinalStatus code are stored in this registry key: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OfficeCSP\a7226049-b2b4-4a1b-9b3d-50dc78f2e816

FinalStatus:

When the Microsoft 365 Apps are being installed with the CSP option, it will first check if the FinalStatus key exists. If it does it will make sure the FinalStatus key will be deleted first. When the installation exits with a specific status, this FinalStatus key will be created with the corresponding status code.

  • Status = 0: 70 (succeeded)
  • Status = 0: 60 (failed)
  • Status = 0: 997 (Installation in Progress)

Please Note: This exit code/status could give you some weird issues during Autopilot because sometimes it will give you a nice random status code or the status code 997. I guess we all know what happens when “the installer gets tired & then takes a nap” during Autopilot?

I Love Sleep GIFs | Tenor

If you somehow stumble upon a device that has the 0:60(failed) status event when Office is installed successfully and you want your device to continue, you could just change that 0:60 to 0:70 (Succeeded)

When the installer is taking a nap when deploying the Microsoft 365 apps you could stumble upon some weird behavior during Autopilot and weird behavior during Autopilot is something we don’t want! I guess we don’t want to end up with the installation exceeding the time limit message!

If you are interested in all of the status codes, please visit this MS Doc: Office CSP – Windows Client Management | Microsoft Docs

Example 2: Mixing LOB Apps

Because this option uses a CSP, the Enrollment Status Page (ESP) could have a hard time tracking this! I am also describing it in this blog below!

When deploying the Office365 apps with the CSP option and mixing it up with some other LOB apps, there is a slight chance that you will end up with Office365 installed but without Teams. Let me explain why. The Office 365 apps are including the Teams Machine-Wide installer. This installer is an MSI-based installer as shown below

When your device is enrolling with Autopilot, the Office365 apps are already being installed at the “preparing your device for mobile management” ESP . At that moment other required LOB apps are also being installed. Guess what could happen? Yep! you could end up with the famous error code 1618 (another installation is already in progress)

“{\”message\”:\”InstallTeams: MsiInstallProduct failed due to install already in progress.\”,\”Status\”:\”1618\”}”}

4. The Win32App Option

As told in the first part, the built-in option is using a CSP to deploy the Microsoft 365 apps. Let’s create our own Win32App with the ODT instead!

To do so we also need the Office Deployment Tool. This tool is nothing more than a command-like tool you could use to download and deploy Click-to-Run versions of the Microsoft 365 apps.

Please download it below

https://www.microsoft.com/en-us/download/details.aspx?id=49117

Text

Description automatically generated

When looking at the official Microsoft documentation about the Office Deployment Tool, you could be tempted to use the “sourcepath” to download the files first with the /download parameter.

After you have downloaded you could wrap the whole folder with the office files in it.

Graphical user interface, application

Description automatically generated with medium confidence

But when converting it to a Win32App you will stumble upon some red flags! So don’t use the SourcePath!.

Text

Description automatically generated

Even when this “stupid” idea would succeed, you will end up with a Win32App you need to update regularly to make sure a new device isn’t going to receive a very old Office build. Also, the ESP issue we could encounter is not as much about the download itself but as we read earlier, it’s more about “something” else triggering the installation instead of the Intune Management Extension (IME)

Let’s move on shall we? The only things we need to make sure we don’t run into issues during Autopilot are the Office Deployment tool itself and 2 XML Files as shown below.

INSTALL.XML

In this example below, I am of course using the

*The Current 64 bits Channel version of the Microsoft Apps

*AllowCdnFallback=”True”

“When installing languages, the ODT looks first for source files in the location specified in the SourcePath attribute. If the language pack isn’t available at that location and the AllowCdnFallback setting is set to True, then the ODT will use source files from the Office CDN.”

*MigrateArch=”TRUE”

Migrate Office 365 Apps from 64 to 32 Bits with MigrateArch (call4cloud.nl)

<Configuration>
<Add OfficeClientEdition="64" Channel="Current" AllowCdnFallback="True" MigrateArch="TRUE">
    <Product ID="O365ProPlusRetail">
      <Language ID="en-us" />
      <ExcludeApp ID="Groove" />
      <ExcludeApp ID="Lync" />
    </Product>
    <Product ID="ProjectProRetail">
      <Language ID="en-us" />
      <ExcludeApp ID="Groove" />
      <ExcludeApp ID="Lync" />
    </Product>
    <Product ID="VisioProRetail">
      <Language ID="en-us" />
      <ExcludeApp ID="Groove" />
      <ExcludeApp ID="Lync" />
    </Product>
  </Add>
  <Updates Enabled="TRUE" />
  <Property Name="FORCEAPPSHUTDOWN" Value="TRUE" />
  <RemoveMSI />
  <AppSettings>
    <User Key="software\microsoft\office\16.0\excel\options" Name="defaultformat" Value="51" Type="REG_DWORD" App="excel16" Id="L_SaveExcelfilesas" />
    <User Key="software\microsoft\office\16.0\powerpoint\options" Name="defaultformat" Value="27" Type="REG_DWORD" App="ppt16" Id="L_SavePowerPointfilesas" />
    <User Key="software\microsoft\office\16.0\word\options" Name="defaultformat" Value="" Type="REG_SZ" App="word16" Id="L_SaveWordfilesas" />
  </AppSettings>
   <Display Level="None" AcceptEULA="TRUE" />
</Configuration>

UNINSTALL.XML

Of course, we also need an uninstall XML to make sure there is a possibility to remove the Microsoft 365 Apps

<Configuration>
<Display Level="None" AcceptEULA="True" />
<Property Name="FORCEAPPSHUTDOWN" Value="True" />
<Remove>
<Product ID="O365ProPlusRetail">
</Product>
</Remove>
</Configuration>

In the XML I used, I also added Visio and Project. When you don’t want those to be installed you can remove them from the XML or create the XML on your own. You could do so by specifying everything you want on this website https://config.office.com/ and exporting the XML.

When you don’t want to create the XML files yourself, here is the download link

https://call4cloud.nl/wp-content/uploads/2022/04/office.zip

Packaging the Files

After we have created the install and uninstall XML files, let’s proceed with packaging the app by running the IntuneWinApputil.exe

Text

Description automatically generated

When we have our own Intunewin file, let’s create a new Win32App in Intune and select this file. After choosing the IntuneWin file you just created, you will need to configure some additional parameters:

Install Parameters

Setup.exe /configure install.xml

Setup.exe /configure uninstall.xml

Graphical user interface, text, application, chat or text message

Description automatically generated

Detection Rules

Detection Rules are always important, to make sure you have the right registry path, open the register and choose your option!

Option 1:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\O365ProPlusRetail – en-us

Graphical user interface, application

Description automatically generated

When you have selected this option you need to configure some detection rules. please make sure you configure the detection rule as shown below.

Graphical user interface, text, application

Description automatically generated

Option 2:

Another possibility would be to use the ClickToRun registry key itself instead of the uninstall key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration

Please Note: When you have messed up the detection rule, you will be prompted with the 0x81036502 error during the ESP Device Phase

Graphical user interface, text, application

Description automatically generated

When you need to troubleshoot this 0x81036502 error, as always the IME will show you the stuff you need. As shown below: Exitcode is defined as success but it actually failed according to detection result

Graphical user interface

Description automatically generated with medium confidence

If you want to make sure this nice new Win32App will be installed during Autopilot, please don’t forget to add it to the required apps during ESP. When adding the custom-made Win32App or the built-in Microsoft 365 apps as required apps during ESP, you can be certain the device is ready to go when the user logs in!

Changing the ESP

Please! Make sure you assign the Microsoft 365 Apps as required in the Enrollment Status Page configuration.

Graphical user interface, application

Description automatically generated

Of course, you want the Microsoft 365 Apps deployed to your device before the user logs in but did you ever thought about the Windows 10 (NOT 11!!) start menu layout? (thanx Bruce for bringing it up!)

As shown above, when you are requiring the Microsoft 365 apps to be installed during the ESP, you will end up with a very nice Start Menu layout when using Windows 10!

Customize the Start layout | Microsoft Docs

5. The PowerShell Script Option

Besides using a Win32App with the ClicktoRun in it to download and configure the Microsoft 365 apps on the device, you could also choose the PowerShell option!

https://github.com/mallockey/Install-Office365Suite

On this GitHub page above, you will find all the information required to start using this option

Why choose this option? Because this PowerShell script will first download the latest ODT before installing the Microsoft 365 Apps.

This nice PowerShell script could also be converted to a Win32App and just like with the Win32App option, you could assign it as required during the ESP.

6. What the Win32app version of the Office 365 setup doesn’t fix!

Of course, there are days when just everything breaks, even the Office 365 Apps Win32app version is going to give you errors. As shown below, when requiring the Office 365 apps during ESP (Intune built-in Option or the Office 365 apps) you could end up with the error: 0x81036502 Installation Timed Out

What could be causing this? We switched to a Win32App so we are all good right? I guess not because as mentioned earlier when running setup.exe /configure configuration.xml it will download the required files from the Office CDN. (officecdn.microsoft.com)

Determining on your Office 365 Click to Run configuration.xml it will fetch the right build

Normally this shouldn’t be an issue BUT sometimes there are issues with a specific Office 365 build. When there are issues with an Office 365 build, you need to switch to another channel/version(or wait until Microsoft fixed the issue with the Office 365 build) otherwise your Autopilot deployments will keep timing out!

When using the built-in option to deploy the Office 365 apps with Intune, you will also need to change some settings. As shown below, I switched from the latest version to be installed to a specific version. A version that is not giving you headaches!

Conclusion

If you ever run into weird app installation issues during ESP out of the blue, please have a reminder of this blog. Because maybe the Microsoft 365 apps CSP option or the Office CDN is giving you some headaches!

Tate finding dory mine 2 GIF on GIFER - by Karan

7 thoughts on “Office CSP vs Win32App: Dawn of Justice

  1. Loved the Article, and it is good to see a ‘formal’ write up of the approach we have been using for a while. We started using Win32 for the office deployment when we found that the ‘native’ Office install in Intune wasn’t updating the Office that shipped on the OEM preload for Dell and Microsoft devices.
    I just wanted to ask about the detection side of things. We have found that when using the registry keys to check the uninstall values as ‘evidence’ we get a very hit and miss experience. It’s almost like the IME is checking too soon. Using a PowerShell script to check for these values (and doing a greater than or equal to check on the version number) is returning a much more consistent experience.

    1. Hi .thanx!… I indeed noticed the same thing… and indeed not every time but after testing it multiple times it didn’t detect the installation at that time. A powershell script would be indeed a better option

  2. Thank you for the great article! I used the GitHub script, together with a custom .xml in a script. Works like a charm, except one thing; the script gives after installation a timeout. Can’t pinpoint what is causing the timeout. Installation succeeds.. Can you pinpoint me in the right direction?

  3. Have you seen any issues with using the built in M365 App deployment method where upon M365 Apps installation a PC loses it’s Windows Activation? I was having all sorts of activation issues, so I scaled back my Intune deployment to just configuration profiles and a handful of PowerShell scripts. I also ensured the Universal Store Service APIs and Web Application was excluded from my MFA Conditional Access policy. After doing this, everything worked like it should including activation. After this, I decided to reassign M365 Apps via the built in method and immediately upon installing the M365 Apps my dev machine lost activation status.

  4. Hi, this has been an extremely helpful article, thank you. One quick thing I’d like to point out is that when you typed “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\O365ProPlusRetail – en-us”, the character right before “en-us” is a different sort of dash than what I have in my registry. My registry reads “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\O365ProPlusRetail – en-us”

    I do not know if this is a locale difference or an automatic formatting effect (I know Outlook and Word will both automatically convert these). As a result of this character difference, my detection rule for Office was failing and I was getting an 0x81036502 error during setup. It was easy enough to correct, but it did cause me to scratch my head for a little bit this morning.

    Anyway, I want to thank you again for your blog. It’s been invaluable in my Intune deployment.

  5. Re: Dash types:

    I see the character changed in my previous comment after it appears on the site, so it must be related to how text is formatted here. That said, I promise the character is different! The correct character appears to be a hyphen but the character that is rendering is a unicode en dash.

Leave a Reply

Your email address will not be published. Required fields are marked *

5  +  3  =