Open iakroohs opened 2 years ago
@denelon what happened to more Office XML's? To answer this issue, this https://aka.ms/fhlwingetconfig is the only Office config we have, the --architecture switch does nothing because its the same installer with the same config
I'll have to ping the Office team. My understanding was that the download would take care of locale and architecture when it was being installed.
I appreciate the updates. I am playing with scripting Powershell for consistent setups within the MSP that I work for and I have a non-insignificant number of clients that have no reason to stick with the x86 Office installs and I would rather distribute the x64 install when possible.
I'll have to ping the Office team. My understanding was that the download would take care of locale and architecture when it was being installed.
Sadly, it only depends on the input XML configure file. So we need to create multiple config files.
Sadly, it only depends on the input XML configure file. So we need to create multiple config files.
Adding on to this, the reason it's in the XML file is because there are reasons for installing 32-bit Office on 64-bit systems, like older addons that don't support 64-bit Office. (Or if you want to make sure that your office staff doesn't make too large of a spreadsheet ;D)
Adding on to this, the reason it's in the XML file is because there are reasons for installing 32-bit Office on 64-bit systems, like older addons that don't support 64-bit Office. (Or if you want to make sure that your office staff doesn't make too large of a spreadsheet ;D)
IMO this is something the company needs to enforce and could do with --architecture if they use winget for installation, for normal users i believe x64 should be default on a 64-bit machine, the addon issue could be a issue tho, but hopefully the one who uses it knows about it
Also IIRC i've used winget to update Office and it stayed 64-bit
From the Office team:
The Office installer is 32-bit only. Office itself will install according to the config XML. If unspecified in config.xml, as is the case for the config that Windows Package Manager uses, the behavior is: 1, If OS is 32-bit then install 32-bit
- Else, If any Office is detected on the machine, then match existing Office architecture (32 or 64)
- Else install Office 64-bit Office installer is not hooked up with “--architecture x64” flag, so it is expected to not have any effect. My guess is an isolated single-device repro, caused by some existing (or remnants of) 32-bit Office already installed, and Office installer tries to match that.
I have been running these commands on a clean, though virtualized, install of Windows 64-bit though I will admit that there had been several attempts at the command, with and without the architecture flag, before submitting the issue here. However, I did reinstall Windows on the virtual machine, updated App Installer, and ran the basic install command with no other changes and still ran across the 32-bit install.
I did create a config file through config.office.com, and it does what I need it to, but it would be nice to have a cleaner option for scripting.
Please confirm these before moving forward
Category of the issue
Installation issue.
Brief description of your issue
When installing the Microsoft Office package via Winget, the installation ignores the --architecture flag and installs the 32-bit version of Office. The 32-bit version of Office also gets installed if the --architecture flag is not included in the command.
Steps to reproduce
Actual behavior
The Office install is installing the 32-bit version of the software regardless of the --architecture flag or the architecture of the machine that it is running on.
Expected behavior
I am expecting Office to install to correct architecture version of Office as passed by the command.
Environment
Screenshots and Logs
WinGet-2022-04-26-14-23-30.229.log![Winget Microsoft-Office](https://user-images.githubusercontent.com/104458035/165368673-c070decd-ee10-40e8-b278-818598f03fe2.png)