Error 1605 occur when multiple-language MSI is deployed via GPO whereby its Product ID was set to asterisk (*) in Product.wxs

[ricardoleonhart]

Bugs

• Which version of WiX are you building with?

v3.11.2.4516

• Describe the problem and the steps to reproduce it.

I am testing deploying a multiple-language MSI via Group Policy Object (GPO). I noticed that when the Product ID in Product.wxs is set to asterisk (*), is built and deployed to the client machine via GPO, the installation will fail with error 1605. However, there is no issue if the Product ID is set to a static GUID before building. Manual installation is also working as per intended when Product ID is set to asterisk.

Note: You may view the failed and successful logs and MSIs in Annex II of this issue below.

Before starting, ensure that you have

1. Downloaded the source code from building multi-language msi tutorial or get it from Annex II below.
2. Setup a Windows Server and Windows client machine that can receive any GPO updates from the Windows Server machine. For reference, I used Windows Server 2012 R2 for server and Windows 10 Pro for client, all are VMs.
3. Setup a shared folder with read and execute permissions in Windows Server machine that will be used to store MSIs and is accessible by the Windows client machine.
4. tested that the GPO deployment is working.

Steps to reproduce:

1. In the source code folder of the multi-language msi, open Product.wxs and replace the GUID in line 4 with asterisk (*).
2. Run BuildMSI.bat to produce the MultiLanguage.MSI located in Output folder
3. In Windows Server, add MultiLanguage.MSI to the shared folder
4. Open Group Policy Management and create a GPO under Domain > Group Policy Objects.
5. Right-click the newly-created GPO and click Edit
6. Under User Configuration > Policies > Software Settings, right-click the right panel, select New > Package... and add MultiLanguage.MSI from the shared folder
7. Set Deployment Type to Assigned and click OK.
8. Right-click TestInstaller, select Properties and go to Deployment tab.
9. Set Deployment Options to Install this application at Logon, Installation user interface options to Basic, and go to Advance and set Ignore language when deploying the package. You may refer to picture in Annex 1 of this issue below.
10. In Windows 10 Pro client, open command prompt and run gpupdate /force /boot to trigger the GPO to update.
11. Re-login to Windows 10 Pro client and check Event Viewer and C:\Windows\Temp\MSI*.txt logs. You will see that there is an error 1605 and the installer failed to run.

• Describe the behavior you expected and how it differed from the actual behavior.

I expect the installer to successfully run and install the program without any errors.

You may view the failed and successful logs and MSIs in Annex II of this issue below.

Additionally, I noticed that if we set the Product ID to asterisk, it will produce localized MSIs with different Product IDs after building. Hence, I replaced the productCode of each localized MSIs with the productCode of the English MSI BEFORE the MST files are generated and combined into the English MSI, and found out that this resolved the issue.

So it seems that this issue only happens if we have combined localized MSTs (which were generated from each localized MSIs which have different Product IDs) into a single MSI.

Any help and insight on why this issue happens because of that will be much appreciated.

Annex 1

Annex II
Failed GPO deployment (where Product ID="*" in Product.wxs)
Logs:
failedLog.zip
MSI:
MultiLanguageFail.zip
Source Code:
failedCode.zip

Successful GPO deployment (where Product ID="4f87d4e4-d7ee-4f52-b4dd-3fe8109cef9f" in Product.wxs)
Logs:
SuccesfulLogs.zip
MSI:
MultiLanguagePass.zip
Source Code:
successfulCode.zip

[robmen]

Yeah, that makes sense. Your localized builds are getting unique ProductCodes with the * and the ProductCode is captured in your .MST.

From failed logs:

MSIe726b.LOG (publishing)

MSI (c) (58:B4) [23:17:05:513]: Executing op: ProductInfo(ProductKey={4AC8B148-A051-4CC4-86D4-8D2079A8CF54},ProductName=TestInstaller,PackageName=MultiLanguage.msi,Language=1031,Version=16777216,Assignment=0,ObsoleteArg=0,,,PackageCode={F1BE0379-D01B-47E6-BE33-361C9AF43E2C},,,InstanceType=0,LUASetting=0,RemoteURTInstalls=0,ProductDeploymentFlags=3)

MSIe726d.LOG (deploying)

MSI (c) (58:5C) [23:17:05:591]: ******* RunEngine:
           ******* Product: {e4bedd32-4df6-475e-aef5-b12a58497a1c}

In the success case, you have:
(publish)

MSI (c) (B8:20) [10:38:35:491]: Executing op: ProductInfo(ProductKey={4F87D4E4-D7EE-4F52-B4DD-3FE8109CEF9F},ProductName=TestInstaller,PackageName=MultiLanguage.msi,Language=1031,Version=16777216,Assignment=0,ObsoleteArg=0,,,PackageCode={9CFF6673-B58D-44D7-B15B-40CA5E3F9152},,,InstanceType=0,LUASetting=0,RemoteURTInstalls=0,ProductDeploymentFlags=3)

(deploy)

MSI (s) (38:78) [10:38:35:679]: ******* RunEngine:
           ******* Product: {4f87d4e4-d7ee-4f52-b4dd-3fe8109cef9f}

Notice the ProductKey and Product GUIDs matches/mismatches in the log files.

This is totally expected behavior given the way you've organized your product.

[ricardoleonhart]

Hi, thanks for the reply. Yes, it does seem that the Product GUID mismatch is the root cause but I still don't understand the relationship between them because AFAIK, error 1605 is related to the installer trying to change something on a product that has not yet been installed.

Do you mind elaborating on this? Thanks.

[BMurri]

You advertised the product {4AC8B148-A051-4CC4-86D4-8D2079A8CF54} and then tried to perform a transaction (I assume to transition it from advertised to installed) on the product {e4bedd32-4df6-475e-aef5-b12a58497a1c} (which doesn't exist on the system).

Basically, when advertising an MSI, any embedded transforms would appear to be ignored for purposes of the identification of the product(s) contained in the MSI file. Yet, when installing, embedded "language transforms" are automatically applied.

If you had installed the MSIs directly, without first advertising them, that may have worked.

Does that help with understanding the error code returned?

[ricardoleonhart]

Sorry for the late reply. Yes, I understand it now. Thanks!