New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 658728 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug

Blocked on:
issue 664255



Sign in to add a comment

Published Enterprise x64 MSI, is recognized as x86 MSI within the Software deployment via Group Policies

Reported by wiechm...@itebo-hcs.de, Oct 24 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36

Steps to reproduce the problem:
1. Open the Group Policy Management Console
2. Create or open an existing Group Policy Object
3. Go to "Computer Configuration\Policies\Software Settings\Software Installation"
4. Right click on the list and Select "New\Package"
5. Select a x64 Package of the Chrome Browser
6. In the Software Deployment dialogue, click "Advanced"
7. In the new dialogue, you see that the MSI is treated as a x86 Package (Platform).

What is the expected behavior?
The MSI package should be treated as an x64 installer.

What went wrong?
The Software deployment solution from Microsoft via Group Policies, detect the x64 MSI file as a x86 Installer. This is problematic as the system is now trying to install the package on x86 systems. The only workaround would be, to create an WMI filter for the group policy object. But with this, you have to create three GPOs where one is for the x86 Package, one for x64 Package and the other one for the settings.

But normally one GPO is enough. You can add the x86 Package and remove the checkbox, that this software package should be installed on a x64 machine. The x64 Package will innately only be installed on x64 machines.

Did this work before? N/A 

Chrome version: 54.0.2840.71  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0
 
Small annotation: The problem is caused by the MSI file and not by the management console. So it seems that some informations are missing to treat the MSI as a x64 package.

Comment 2 by grt@chromium.org, Oct 24 2016

Cc: georgesak@chromium.org
Components: Enterprise
My guess: we should be adding "-arch x64" to the candle.exe command line when building the .msi.
Cc: pbomm...@chromium.org ananthak@chromium.org ligim...@chromium.org bustamante@chromium.org
Labels: -Pri-2 ReleaseBlock-Stable M-54 Pri-1
Cc: mmoss@chromium.org
Based on comment#2 from Greg adding Michael.

Comment 5 by mmoss@google.com, Oct 24 2016

Just curious, is this a recent problem, or were we never using that flag?

Comment 6 by grt@chromium.org, Oct 24 2016

I suspect we didn't add it when we added support for x64 Chrome. I found documentation for the Platform attribute on the WiX Package element here: http://wixtoolset.org/documentation/manual/v3/xsd/wix/package.html, which says that "-arch x64" for candle.exe is the right thing. I can't say for certain that this is all that is needed, but it sounds right.
If you could provided an updated MSI file, I'm gladly willing to test it for you.

Comment 8 by grt@chromium.org, Oct 25 2016

If you have Microsoft's Orca tool (it's a part of the Windows SDK), you can flip the "Platform" property in the summary information stream's "Template Summary". To do so:
- Open the .msi in Orca
- Select "Summary Information..." from the "View" menu
- Change the "Platform" property to "x64"

I was able to install Chrome from the .msi after making this change. There may be side effects to flipping this in the production installers, so we need to understand what changes (e.g., various properties may become the 64-bit counterpart) and be sure that we handle them properly.
I can confirm that with this change, the Group Policy Management Console treats the MSI file as an X64 Package. Also a deployment via GPO was possible on an Windows 10 LTSB 2016 x64 System.

The digital signatur of the package got lost, but that's normal.

Comment 10 by mmoss@chromium.org, Oct 26 2016

Status: Fixed (was: Unconfirmed)
Added "-arch" flag in internal cl/137323845, so should be in the next releases.

Comment 11 by mmoss@chromium.org, Nov 11 2016

Blockedon: 664255
Status: Available (was: Fixed)
Apparently this change has made the 64-bit MSIs uninstallable. See also  Issue 664255 .

Comment 12 by mmoss@chromium.org, Nov 11 2016

That should say, un-uninstallable.

Comment 13 by mmoss@chromium.org, Nov 11 2016

Owner: grt@chromium.org
Status: Assigned (was: Available)
Just as a note: The simply change of the "Platform", like mentioned in comment #8, didn't broke the uninstall function. I was always able to remove the MSI after this. So it should be something within building process

Comment 15 by grt@chromium.org, Nov 11 2016

It turns out that changing the Platform via Orca doesn't truly make it a 64-bit installer in the same way that candle.exe -arch x64 does. We need to revert that change for now until we can resolve the problems it caused.
Labels: TE-NeedsTriageHelp
Adding TE-NeedsTriageHelp as its out of scope from TE end.

Comment 17 by grt@chromium.org, Dec 2 2016

Status: Fixed (was: Assigned)
This should be fixed in 55.0.2883.75. Please take a look at the current MSI and let us know how it goes. Thanks.
Labels: Merge-TBD
[Auto-generated comment by a script] We noticed that this issue is targeted for M-54; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-54 label, otherwise remove Merge-TBD label. Thanks.
Hey,

the installer is now recognized as x64 installer. So the problem is fixed.
Or should I also check the uninstall function because of the previous bug?


Comment 20 by grt@chromium.org, Dec 9 2016

We have tested uninstall and found that it works without issue. Please let us know if you find otherwise. Thanks.

Comment 21 by grt@chromium.org, Dec 20 2016

Labels: -Merge-TBD
-Merge-TBD, as no merge is needed.

Sign in to add a comment