Windows Installer reconfigured the product.

[bat2001]

Hello,

We are using TFS 2017 build/release to wrap around Deployment Framework for BizTalk 5.7. For the release, we deploy a couple PowerShell scripts to each BizTalk server and then use PSRemoting (PowerShell on Target Machines task in TFS) to make the calls to install. We pass some arguments that are set in the task to help with the deployment.

We have the following steps: 1) Uninstall on first server (firstserver 1) 2) Uninstall on rest of servers (firstserver 0) 3) Install MSI on rest of servers (lastserver 0) 4) Install MSI and Import on last servers (lastserver 1)

This works super slick. However, we've noticed a lot of the following event log entries (these are at the Information Level, so they aren't warnings or errors) when triggering the release:

Windows Installer reconfigured the product. Product Name: {xxxxxxx} Product Version: xxxx. Product Language: 1033. Manufacturer: Microsoft Corporation. Reconfiguration success or error status: 0.

and other like this (similar): Windows Installer reconfigured the product. Product Name: {yyyyy} Product Version: yyyy. Product Language: 1033. Manufacturer: Generated by BizTalk. Reconfiguration success or error status: 0.

We came across this from Microsoft which seems to match the verbage: https://support.microsoft.com/en-us/help/974524/event-log-message-indicates-that-the-windows-installer-reconfigured-al

It doesn't appear that the environment is compromised, but it's a bit of a concern that there may be some kind of reconfiguration with other applications.

Any insights? Bruce

[tfabraham]

Hi Bruce, You found the right article -- it matches my past experiences using WMI to manipulate Windows Installer packages. Are you certain it only occurs when deploying to BizTalk? No possibility it could be caused by system/operation management agents, etc.? If it's limited to the BizTalk app deployments, then I'd suspect the PowerShell code or an underlying module is using WMI, since you describe using PowerShell to install/uninstall the MSI's. You may need to try a different method or PS module for the MSI query/install/uninstall portion of the script.

The reconfiguration is harmless as far as I've observed, but it does cause some extra processing load and the event log noise.

Thanks, Tom

[bat2001]

Hi Tom,

We are using the PowerShell command Start-Process "msiexec.exe" $Arguments -Wait -Passthru to kick this off

I'll need to verify that this command is the perpetrator...

Bruce

[tfabraham]

Seems unlikely that msiexec would cause the reconfiguration of multiple products. You're certain that it isn't arising from system management agents of some sort?

[bat2001]

Hi Tom,

After a bit of digging, I've come across the real issue. The process first looks to see if the msi is already installed and then uninstalls it. The script uses the following to do the uninstall of a BTDF msi: $app = Get-WmiObject -Class Win32_Product -Filter "PackageName = '$msi'"

So it is indeed NOT the BTDF that causes this, but rather the Get-WmiObject call when trying to uninstall an older version of the solution.

Currently reviewing how to determine the next best approach to manage this.

[tfabraham]

Glad you found it -- so it was WMI after all. That's consistent with my past experience and the article. I'd recommend giving this PowerShell module a shot -- Heath Stewart is a Windows Installer expert.

[paulfijma]

way late to the party (but still) if someone reads it: its not WMI, but the call to Win32_Product class. https://docs.microsoft.com/en-us/troubleshoot/windows-server/admin-development/windows-installer-reconfigured-all-applications use Win32reg_AddRemovePrograms where possible instead of Win32_Product

[tfabraham]

Thanks for the update. Now that you point it out, I recall running into that many years ago on a long-lost project.