Last Updated on April 13, 2022 by rudyooms

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

I will divide this blog into multiple parts

1. Introduction
2. Configuring the required groups
3. Configuring the 32 bits version
4. Configuring the 64 bits version
5. Configuring the ESP
6. Testing the Office 365 deployments

1. Introduction

I couldn’t find much information about deploying/migrating 64 bits and 32 bits of the built-in Microsoft 365 Office apps and how to make sure the proper device would get the right version.

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

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

How are we going to make sure, when we are using the built-in option to make sure the proper device will receive the proper Microsoft 365 apps version.

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 created 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 Office 365 apps (32 Bits Version)

To be sure the Office 365 32 bits apps will be installed without any issues, I manually configured the XML instead of choosing the GUI option.

(I tried the GUI version first, but it resulted in 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, you will need to include the MigrateArch to be sure the Office 365 installation is changed to the architecture that is 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 Office 365 apps (64 bits version)

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, because when using Autopilot you will need to set up the Enrollment status page to be sure some specific Apps are installed when the user logs in.

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

Now we have configured all the settings necessary, 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. Because when you have assigned 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 bits Office Apps, but sometimes some people still need to use the 32 bits version. There could be a lot of good reasons why some need to stick to the 32 bits version. It’s your job to make sure everything is being deployed as it should.

Beware, one of the settings which could easily be forgotten would be 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.