Office 365 Apps and the Deathly Bits

Office 365 Apps and the Deathly Bits

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

I couldn’t find much information about deploying 64 bits and 32 bits Office apps and how to make sure the proper device would get the right version, so I decided to create a blog about it.

The first thing to do is to create  a new group:Office365Apps_x86.

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

The 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 (

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.

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 apps but open the company portal instead to track its progress.

I made sure this app is required for members of the office365_x86 group 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)

The 64 bits version

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

*Including users groups and excluding user group when assinging apps

*Including devices groups and excluding device group 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.


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.

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 behaviour. 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 an 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 look for finalstatus.

0:70 –> succeeded

0:60 –> failed

Also take a look at the (standaard) key, it contains your xml you configured.


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 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.

Leave a Reply

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

64  +    =  66