Microsoft 365 Apps and the Deathly Bits

Imagine the next scenario: You have a customer who needs Microsoft 365 Apps, but some of the employees need the 32-bit / x86 version instead of the 64-bit / x64 version. How are you going to make sure all new and existing devices get the version they need?

1. Introduction

I couldn’t find much information about deploying/migrating 64-bit and 32-bit versions of the built-in Microsoft 365 apps and how to ensure the proper device gets the right version.

Looking at the built-in option, you will notice that it is missing the “Requirements” tab.

Of course, we could switch to a Win32App that contains the ODT, as I explain in this the blog but that’s not what this blog is about!

How are we going to ensure that the proper device receives the proper Microsoft 365 apps version when we use the built-in option?

2. Configuring the required Groups

The first thing we need to do is to create a new group: Office365Apps_x86. Because like I told you earlier, we only want to deploy the Office X86 Apps to a subset of users.

After we create the group, we can create the Microsoft 365 Apps. One for the 64 bits version and one 32 bits version, and assign the proper groups

3. Configuring the 32 Bits Microsoft 365 apps

To ensure the Microsoft 365 32-bit apps would be installed without any issues, I manually configured the XML instead of choosing the GUI option.

(I tried the GUI version first, but it had no fixed outcome. On newly enrolled devices, the GUI option worked without any problems but sometimes on an existing device the 32 bits Office apps were installed without issues, other times the 32 bits version installed but after a while, the Office 365 apps reversed back to the 64 bits version because “something went wrong”.)

Microsoft tells you to include the MigrateArch to ensure that the Office 365 installation is changed to the architecture specified in the OfficeClientEdition.

Change a Microsoft 365 Apps installation from 32-bit to 64-bit – Deploy Office | Microsoft Docs

Also, there is an option to specify some other properties like “Forceappshutdown”, which I couldn’t find in the Office 365 apps GUI deployment.  The user-voice has not received that many votes yet…

Add MigrateArch option to the Office 365 Configuration Designer – Microsoft Intune Feedback (uservoice.com)

Please beware, on existing devices, you need to make sure the old 64 bits apps are closed before the new Office 365 32 bits version can be installed, otherwise, you would receive this error: “An update could not be installed because Office applications are open (0x426e)”

But beware configuring the “forceappshutdown” parameter will not guarantee success. My advice: patience… When migrating Office 365 to 32bits on an existing device, please advise to not open the Office 365 apps but open the Company Portal app instead to track its progress.

I also made sure this app is required for members of the office365_x86 group (we created earlier) and “available” for all users (I also made it available for all users so I could track the progress inside the Company Portal on existing devices)

4. Configuring the 64 bits Microsoft 365 apps

Let’s start taking a look at a nice screenshot to see what I configured.

I included: All users  and excluded the Office365app_x86 group as exclusion takes precedence over inclusion in the following same group type scenarios

*Including users groups and excluding user groups when assigning apps

*Including devices groups and excluding device groups when assigning apps

Intune doesn’t evaluate user-to-device group relationships. If you assign apps to mixed groups, the results could be different each time.

5. Configuring the ESP (Enrollment Status Page)

But we are not done yet. When using Autopilot, you will need to set up the Enrollment status page to ensure that some specific Apps are installed when the user logs in.

I selected the Office365 Apps x64 and the Office365 Apps x86 versions as required apps. The default ESP is by default assigned to all devices.

Now that we have configured all the necessary settings, I created a test user and added the test user to the Office365apps_x86 group.

6. Testing Both of the Office Deployments

Of course, now we have configured everything, we still need to test what happens when you have an existing device but also what happens when you deploy a new device. Let’s start with the new devices

New Devices:

To start testing, I enrolled a new device into autopilot and logged in with the test user, who is a member of the office365apps_x86 group.

After the ESP is completed, the device was ready for use with Office 32 Bits installed.

But what to do when you want to use Autopilot white glove?

As shown earlier, I assigned the Office 365 Apps x64 to all users instead of all devices. When you assign it to all devices, you can not exclude the Office365 x86 group. This will result in some weird behavior. Office 32 bits will be installed, but after some time, it will be removed, and the x64 version will be installed.

When you want to make sure the user-assigned apps are installed during white glove, you will need to assign a user to the autopilot device.

Existing devices:

How to check the progress when you have existing devices? Like I told you earlier I also made sure the Office 32 Bits apps were available for enrolled devices, so you could open the company portal to check its progress.

There are also some other methods to determine the installation progress and status.

The first one is to simply monitor the program files (x86)folder. You will notice the Office 32 bits files will be downloaded inside the c:\program files (x86)\microsoft office\packagefiles folder

Another option you have to monitor the status will be opening the register and looking for “FinalStatus“.

• 0:70 –> succeeded
• 0:60 –> failed

Also, take a look at the (standard) key, it contains the XML you configured.

Conclusion:

Microsoft recommends using the 64-bit Microsoft Apps, but sometimes, some people still need to use the 32-bit version. There could be many good reasons why some need to stick to the 32-bit version. It’s your job to make sure everything is being deployed as it should.

Beware: One setting that could easily be forgotten is the skipuserstatuspage. This setting should not be configured when you want to make sure the user-assigned apps are installed before the user logs in.

A way better option would be configuring the “only show page to devices provisioned by OOBE” inside the enrollment status page.