Introduction
When installing Office 365 ProPlus today, the recommended and default architecture is 64-bit. It has been so for some time, but it’s not until lately (at time of writing) that the Office Deployment Tool (in short ODT), is able to migrate from 32-bit to 64-bit in a single operation.
I have tested the migration, both using Microsoft Intune and System Center Configuration Manager and the outcome is what made this blog post.
Note: Migrating Office 365 ProPlus like this, from 32-bit to 64-bit in production, probably has more to it in terms of considering third party add-ins. You will have to test and make sure those add-ins are compatible with the relevant 64-bit Office application. I expect there will be some migration paths for those as well, where you will need to remove the 32-bit add-in prior to migrating Office 365 ProPlus to 64-bit.
Microsoft Intune
Doing the migrating using Microsoft Intune begins in the Microsoft 365 Device Management portal: https://devicemanagement.microsoft.com
- Navigate your way into Client apps -> Apps and create a new app: Office 365 Suite Windows 10
- Select the Settings format to be: Enter XML data
- Fill in App Suite Information, paste in the Configuration File and create the app. The important part here is obviously the MigrateArch attribute, which is set to TRUE.
Note: This requires a minimum of Office 365 ProPlus Version 1902.
Also, you have the option to modify the entire installation of Office 365 ProPlus in this process. The changes done here, are not limited to the architecture.
<Configuration>
<Add OfficeClientEdition="64" MigrateArch="TRUE" Channel="Monthly" ForceUpgrade="TRUE">
<Product ID="O365ProPlusRetail">
<Language ID="en-us" />
<ExcludeApp ID="Groove" />
<ExcludeApp ID="OneDrive" />
</Product>
</Add>
<Property Name="SharedComputerLicensing" Value="0" />
<Property Name="PinIconsToTaskbar" Value="FALSE" />
<Property Name="SCLCacheOverride" Value="0" />
<AppSettings>
<Setup Name="Company" Value="www.imab.dk" />
</AppSettings>
<Display Level="None" AcceptEULA="TRUE" />
<Logging Level="Off" />
</Configuration>
- Assign the app to a group consisting of users or devices. In my scenario, I assigned this as available to a group consisting of my user, making it display in the company portal.
Excuse the danish language – company portal insist on being in my native language due to tenant settings.
And post installation, I can verify that my Office 365 ProPlus indeed now is running 64-bit:
Configuration Manager
Note: The built in Office 365 ProPlus installation wizard in SCCM, which launches the Office Customization Tool does not currently and at time of writing have an option to select the MigrateArch attribute.
- Using ConfigMgr will be a tad different. For starters, you will need the latest and greatest Office Deployment Tool found here: https://www.microsoft.com/en-us/download/details.aspx?id=49117
- Extract the content and find setup.exe.
- Use this in combination with the following 64bit.xml file to download the 64-bit binaries. You download the binaries by running: setup.exe /download 64bit.xml having setup.exe and the .xml in the same folder.
<Configuration>
<Add OfficeClientEdition="64" MigrateArch="TRUE" Channel="Monthly" OfficeMgmtCOM="TRUE" ForceUpgrade="TRUE">
<Product ID="O365ProPlusRetail">
<Language ID="en-us" />
<ExcludeApp ID="Groove" />
<ExcludeApp ID="OneDrive" />
</Product>
</Add>
<Property Name="SharedComputerLicensing" Value="0" />
<Property Name="PinIconsToTaskbar" Value="FALSE" />
<Property Name="SCLCacheOverride" Value="0" />
<AppSettings>
<Setup Name="Company" Value="www.imab.dk" />
</AppSettings>
<Display Level="None" AcceptEULA="TRUE" />
<Logging Level="Off" />
</Configuration>
- The result is similar to below. Copy all of that into your source files library.
Package or Application
Whether you want use an application or regular package is up to you. I’m going to go with a package for the simplicity. See below snippets for the creation of the package and program.
Deployment
Now, deploy the package to the relevant devices and you will have your Office 365 ProPlus installation migrated to 64-bit in a jiffy.
More info
- https://docs.microsoft.com/en-us/deployoffice/change-bitness
- https://support.office.com/en-us/article/choose-between-the-64-bit-or-32-bit-version-of-office-2dee7807-8f95-4d0c-b5fe-6c6f49b8d261?ui=en-US&rs=en-US&ad=US
Hi, is there an easy way to tackle the opposite. Say all client builds get office 64 bit as default and then we can revert to 32 bit via collections or something in SCCM. I am guessing the steps would be 64 bit will need uninstalling, reboot and install 32 bit – do it as task sequence perhaps? Or is there an alternate?
I haven’t tested it, but I would assume the MigrateArch attribute works the opposite way as well. What the setup essentially does is to uninstall and install fresh. You can script that as well, but of course having the setup doing it for you is easier 🙂
Thanks, will give it a go and let you know.
I notice that you have the “” in your XML and from what I know that property is not working with Windows 10. Have you manage to figure out a solution to it?
Sorry, what property? 🙂
The conversion from x64 to x86 does work.
🙂 PinIconsToTaskbar
If the previous 32-bit App Package was deployed via Intune as “Required” for devices in an SG, would we simply change it to “Available,” remove the Security Group containing ‘required’ installs, or simply delete the 32-bit App Package? We’re concerned that MigrateArch reverts to 64 bits, but Intune forces device back to 32bit after some time unless we change the old package.
I wouldnøt have 2 separate assignments with separate architecture deployed to the same group of device, though in order for the setup to move from 32 o 64 or vice verca, you would need the MigrateArch attribute set in the config. If you’re migrating to 74 bit, you’re essentially reinstalling office, and I assume you are going to use 64 moving forward. Do you still have a need having the 32 bit package deployed then?
No need to keep 32bit, but we fear that deploying a new x64 package as “required” (and removing the 32 bit package) would result in a period of time where Ofice is removed (and thus unavailable) on a given device based on when it’s scheduled to checkin/sync next.
Are you suggesting that we can using this XML in place of the 32bit package and make it required to o the same Device Group used previously, will result in both:
1. Existing installations while be converted to x64?
2. New devices (autpoilot) will simply perform a fresh install of only the x64 bit?
Simply removing an assignment of office will not automatically uninstall it from the devices where it was assigned.
You can keep the MigrateArch attribute in the same xml you use for both fresh installs and new installations. It will only have effect if office is already installed, and on fresh installations it will have no effect. Does that answer your question? 🙂
Yes, thank you!
Last piece is that we’re not seeing a Teams installation despite does this article implying that it is now included in all distros since 2020: https://docs.microsoft.com/en-us/deployoffice/teams-install (we use Monthly Channel).
We’ll exclude Lync/Skype and keep testing.
What about the need of the office to be closed before the upgrade works , is there a way to have this prompted so user will be asked to close office to get the upgrade to 64bit from 32bit ?
Hi there –
Do you need to deploy the Office Deployment Tool to devices before deploying the XML ?
Thanks