WIX MSI Upgrade fails on SECUREREPAIR on some domains - wix

I am having a MSI generated with WIX that either installs or upgrade a product.
It has normally worked fine but it is now failing in a set of computers of a domain.
The part of the log where the error is (note I have changed the paths...):
Action start 09:52:42: RegisterProduct.
RegisterProduct: Registering product
MSI (s) (20:28) [09:52:42:999]: Resolving source.
MSI (s) (20:28) [09:52:42:999]: Resolving source to launched-from source.
MSI (s) (20:28) [09:52:42:999]: Setting launched-from source as last-used.
MSI (s) (20:28) [09:52:42:999]: PROPERTY CHANGE: Adding SourceDir property. Its value is 'path to msi'.
MSI (s) (20:28) [09:52:42:999]: PROPERTY CHANGE: Adding SOURCEDIR property. Its value is 'path to msi'.
MSI (s) (20:28) [09:52:42:999]: PROPERTY CHANGE: Adding SourcedirProduct property. Its value is '{969A6191-5768-45DB-A282-337F711B06A3}'.
MSI (s) (20:28) [09:52:42:999]: SOURCEDIR ==> path to msi
MSI (s) (20:28) [09:52:42:999]: SOURCEDIR product ==> {969A6191-5768-45DB-A282-337F711B06A3}
MSI (s) (20:28) [09:52:42:999]: Determining source type
MSI (s) (20:28) [09:52:43:015]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (20:28) [09:52:43:015]: Source type from package 'software.msi': 6
MSI (s) (20:28) [09:52:43:015]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (s) (20:28) [09:52:43:015]: SECREPAIR: Hash Database: C:\Windows\Installer\SourceHash{969A6191-5768-45DB-A282-337F711B06A3}
MSI (s) (20:28) [09:52:43:015]: Machine policy value 'AlwaysInstallElevated' is 0
MSI (s) (20:28) [09:52:43:015]: User policy value 'AlwaysInstallElevated' is 0
MSI (s) (20:28) [09:52:43:015]: MSI_LUA: UAC support is not enabled; therefore no elevation thru prompting is possible
MSI (s) (20:28) [09:52:43:015]: Note: 1: 3
MSI (s) (20:28) [09:52:43:015]: SECUREREPAIR: SecureRepair Failed. Error code: 3F56634B8
Action ended 09:52:43: RegisterProduct. Return value 2.
Also, I am seeing several lines like:
MSI (s) (20:F0) [09:52:33:077]: MSI_LUA: Credential prompt disabled due to LUA policy settings
My first thought was that the MSI needs elevation but a GPO has disabled the prompt and the installation fails as seen in point 2 of:
Configure UAC settings via policy
But the Domain administrators swear by ... that there is not such policy in their GPOs and I cannot access it to check.
Then, my second thought takes me to:
Infamous KB2918614
But non of the described errors matches mine: SECUREREPAIR: SecureRepair Failed. Error code: 3F56634B8
All I have is the log to understand this problem and have no access to the machines.
The MSI runs well in other Domains and I have run out of ideas. Any lead is much appreciated as I have already been a couple of weeks reading things and can't find any. I am still suspicious of GPO but have to take the word...

Related

Display custom error instead of WiX default error for "MainEngineThread is returning 1624"

After silent installation of WiX MSI, it writes the default MSI error when the Instance or Transform is invalid. It's not even reaching to custom action method before that MSI fails.
MSI (s) (A0:D0) [00:48:39:793]: Machine policy value 'TransformsSecure' is 0 MSI (s) (A0:D0) [00:48:39:793]: User policy value 'TransformsAtSource' is 0 MSI (s) (A0:D0) [00:48:39:793]: Note: 1: 2203 2: Instance26 3: -2147287038 MSI (s) (A0:D0) [00:48:39:793]: **MainEngineThread is returning 1624**
How to throw a custom message instead of a default MSI error saying instance or transform is invalid?

Wix Error in action CommitIIS7ConfigTransaction

Environment Details: Installation package is created via a TFS continuous integration build process (using Wix 3.10.3) that has an agent on the deployment test server (A TFS user is running as a service on the release box) where I am having the issue below. Package is downloaded and installed via the release agent of TFS using the powershell function (NOT powershell on targeted machine) with this script, which runs the installation in admin mode if not already in admin mode.
If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{
Echo "This script needs to be run As Admin"
Start-Process powershell -ArgumentList '-noprofile -file [ps1file]' -verb RunAs
Break
}
else
{
Echo "Running as Admin"
MSIEXEC /i "[PathToMSI]" /qn /L*v "[PathToLog]" INSTALLDIR="[INSTALLPATH]" WEBAPPNAME="[Name]" AUTHMETHOD="[METHOD]" [SQLCONNECTIONPROPERTIES...]
Echo "Script complete"
}
First off I can install this product without issue the first time on the server in question, it is the updates that are producing strange behavior. The agent automated update produces this text with no discernible error code, minus the generic 1603.
Action start 11:20:45: CommitIIS7ConfigTransaction.
MSI (s) (74!18) [11:20:45:585]: PROPERTY CHANGE: Adding ConfigureIIs7Exec property. Its value is '**********'.
MSI (s) (74!18) [11:20:45:585]: Doing action: ConfigureIIs7Exec
MSI (s) (74:34) [11:20:45:632]: Note: 1: 2265 2: 3: -2147287035
MSI (s) (74:34) [11:20:45:632]: Machine policy value 'DisableRollback' is 0
MSI (s) (74:34) [11:20:45:632]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (74:34) [11:20:45:632]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (74:34) [11:20:45:632]: No System Restore sequence number for this installation.
MSI (s) (74:34) [11:20:45:632]: Unlocking Server
MSI (s) (74:34) [11:20:45:632]: Note: 1: 1708
MSI (s) (74:34) [11:20:45:632]: Product: MyProduct -- Installation failed.
MSI (s) (74:34) [11:20:45:632]: Windows Installer installed the product. Product Name: MyProduct . Product Version: 1.1.1.1. Product Language: 1033. Manufacturer: Me. Installation success or error status: 1603.
But when I run this update manually I get this error:
MSI (s) (34!1C) [16:27:41:979]: Doing action: StartIIS7ConfigTransaction
MSI (s) (34!1C) [16:27:41:979]: Product: MyProduct -- Error 26031. Failed to schedule transaction for changes to IIS. (-2147418113 )
MSI (s) (34:48) [16:27:41:994]: Note: 1: 2265 2: 3: -2147287035
MSI (s) (34:48) [16:27:41:994]: Machine policy value 'DisableRollback' is 0
MSI (s) (34:48) [16:27:41:994]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (34:48) [16:27:41:994]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (34:48) [16:27:41:994]: No System Restore sequence number for this installation.
MSI (s) (34:48) [16:27:41:994]: Unlocking Server
MSI (s) (34:48) [16:27:42:010]: Note: 1: 1708
MSI (s) (34:48) [16:27:42:010]: Product: MyProduct -- Installation failed.
MSI (s) (34:48) [16:27:42:010]: Windows Installer installed the product. Product Name: MyProduct. Product Version: 1.1.1.1. Product Language: 1033. Manufacturer: Me. Installation success or error status: 1603.
I have scoured this and other forums looking for any indication of how to fix it, but have yet to turn up anything related to this specific error code/text. I have exhausted all options I could think of over the last few days. Any help would be appreciated.

Wix checking netfreamwork 4 during installation of files

I experienced strange behavior from wix. I created installation and when I wanted to test it, everything works fine, my dialog shows... But when I clicked on install, it looks like it is installing but in one third of installation files message box pop up saying: Installation of MYPRODUCT requires .NET Framework 4!
My first idea was that I have bad launch condition... but still it is launch condition and not install or what... so I deleted it a problem still is there...
Then I thought that it is maybe because of my custom action in C#, so I deleted it also, but problem is still there. Any idea?
Thanks
and btw. that launch conditions (netframework) are working fine...
EDIT: if I set InstallScope="perUser" it works...
Log:
Action start 12:54:33: INSTALL.
MSI (s) (A0:F4) [12:54:33:505]: Running ExecuteSequence
MSI (s) (A0:F4) [12:54:33:505]: Doing action: FindRelatedProducts
Action 12:54:33: FindRelatedProducts. Searching for related applications
Action start 12:54:33: FindRelatedProducts.
MSI (s) (A0:F4) [12:54:33:507]: Skipping FindRelatedProducts action: not run in maintenance mode
Action ended 12:54:33: FindRelatedProducts. Return value 0.
MSI (s) (A0:F4) [12:54:33:507]: Doing action: AppSearch
Action 12:54:33: AppSearch. Searching for installed applications
Action start 12:54:33: AppSearch.
AppSearch: Property: FM70HOME, Signature: FM70_HOME_PathRegistry
MSI (s) (A0:F4) [12:54:33:508]: Note: 1: 2262 2: Signature 3: -2147287038
MSI (s) (A0:F4) [12:54:33:508]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE32\SOFTWARE\Adobe\FrameMaker\7.0 3: 2
AppSearch: Property: FM71HOME, Signature: FM71_HOME_PathRegistry
MSI (s) (A0:F4) [12:54:33:509]: Note: 1: 2262 2: Signature 3: -2147287038
MSI (s) (A0:F4) [12:54:33:509]: PROPERTY CHANGE: Adding FM71HOME property. Its value is 'C:\Program Files (x86)\Adobe\FrameMaker7.1'.
AppSearch: Property: FM72HOME, Signature: FM72_HOME_PathRegistry
MSI (s) (A0:F4) [12:54:33:509]: Note: 1: 2262 2: Signature 3: -2147287038
MSI (s) (A0:F4) [12:54:33:509]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE32\SOFTWARE\Adobe\FrameMaker\7.2 3: 2
AppSearch: Property: FM80HOME, Signature: FM80_HOME_PathRegistry
MSI (s) (A0:F4) [12:54:33:510]: Note: 1: 2262 2: Signature 3: -2147287038
MSI (s) (A0:F4) [12:54:33:510]: PROPERTY CHANGE: Adding FM80HOME property. Its value is 'C:\Program Files (x86)\Adobe\FrameMaker8\'.
AppSearch: Property: FM10HOME, Signature: FM10_HOME_PathRegistry
MSI (s) (A0:F4) [12:54:33:510]: Note: 1: 2262 2: Signature 3: -2147287038
MSI (s) (A0:F4) [12:54:33:510]: PROPERTY CHANGE: Adding FM10HOME property. Its value is 'C:\Program Files (x86)\Adobe\AdobeFrameMaker10\'.
AppSearch: Property: NETFRAMEWORK45, Signature: NetFramework45
MSI (s) (A0:F4) [12:54:33:510]: Note: 1: 2262 2: Signature 3: -2147287038
Action ended 12:54:33: AppSearch. Return value 1.
MSI (s) (A0:F4) [12:54:33:511]: Doing action: LaunchConditions
Action 12:54:33: LaunchConditions. Evaluating launch conditions
Action start 12:54:33: LaunchConditions.
Installation of eAIP.wiz#rd requires .NET Framework 4!
MSI (s) (A0:F4) [12:54:40:586]: Product: Product -- Installation of Product requires .NET Framework 4!
Action ended 12:54:40: LaunchConditions. Return value 3.
Action ended 12:54:40: INSTALL. Return value 3.
also I have no idea why it check for NetFramework45...
My launch conditions are:
<Condition Message="Installation of Product requires .NET Framework 40 full!">NETFRAMEWORK40FULL OR REMOVE ~= "ALL"</Condition>
<Condition Message="Installation of Product requires Framework!">NOT WF_INSTALLED = "NOT INSTALLED" OR REMOVE ~= "ALL"</Condition>
<Condition Message="Can't find any of Adobe Framemaker 10.0, 8.0, 7.2, 7.1, 7.0 installation.! Product would not be working.">FM10HOME OR FM80HOME OR FM72HOME OR FM71HOME OR REMOVE ~= "ALL"</Condition>
And why it writes message that requries .Net Framework 4, when firt time launch condition passed... and when I have net framework 4 full installed?
Full log: http://pastebin.com/eEGCnQXu
Ok probably I found a solution.
The whole problem is logged in my log:
MSI (c) (B8:58) [12:54:23:788]: Doing action: FindRelatedProducts
Action 12:54:23: FindRelatedProducts. Searching for related applications
Action start 12:54:23: FindRelatedProducts.
FindRelatedProducts: Found application: xxx
MSI (c) (B8:58) [12:54:23:788]: PROPERTY CHANGE: Adding WIX_UPGRADE_DETECTED property. Its value is 'xxx'.
MSI (c) (B8:58) [12:54:23:788]: PROPERTY CHANGE: Adding MIGRATE property. Its value is 'xxx'.
FindRelatedProducts: Found application: xxx
which telling that I have already installed that product... at least some registry must be there... so I changed product guid and upgrade.. and it works... but it is still strange to me, why it tells that net framework 4 is missing when it passed at launch condition at beginning.

Installer Transaction with ExternalUI destroys my log files

Strange behavior with Installer Transaction and ExternalUI that destroys my log files.
I'm chaining three MSIs in this Transaction.
I make a verbose log file for each Setup.
In the end my "last" verbose Log will be deleted.
It is always the "last" one that.
What I'm doing wrong?
How to avoid this behavior?
This happens after i commit the Transaction
transaction.Commit();
Exactly here:
private void End(bool commit)
{
uint ret = NativeMethods.MsiEndTransaction(commit ? 1 : 0);
}
My last Logfile will be deleted and replaced with this shot one:
=== Verbose logging started: 15.02.2011 10:58:16 Build type: SHIP UNICODE 5.00.7600.00 Calling process: \\olli\Public\Hin und her\Kai-Uwe\InstallWizard.exe ===
MSI (s) (08:30) [10:58:16:631]: User policy value 'DisableRollback' is 0
MSI (s) (08:30) [10:58:16:631]: Machine policy value 'DisableRollback' is 0
MSI (s) (08:30) [10:58:16:631]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (08:30) [10:58:16:631]: MSCOREE not loaded loading copy from system32
MSI (s) (08:30) [10:58:16:959]: Note: 1: 2318 2:
MSI (s) (08:30) [10:58:16:975]: Note: 1: 2318 2:
MSI (s) (08:30) [10:58:16:975]: Note: 1: 2318 2:
MSI (s) (08:30) [10:58:16:975]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (s) (08:30) [10:58:16:990]: Restoring environment variables
MSI (s) (08:30) [10:58:16:990]: Calling SRSetRestorePoint API. dwRestorePtType: 0, dwEventType: 103, llSequenceNumber: 12, szDescription: "".
MSI (c) (E0:0C) [10:58:16:990]: Cloaking enabled.
MSI (s) (08:30) [10:58:16:990]: The call to SRSetRestorePoint API succeeded. Returned status: 0.
MSI (c) (E0:0C) [10:58:16:990]: Attempting to enable all disabled privileges before calling Install on Server
From my Class:
using (Transaction transaction = new Transaction("Install", TransactionAttributes.None))
foreach (MsiPackage package in _availableMsiPackages.Values){
Installer.EnableLog(InstallLogModes.Verbose, LogPath);
Installer.SetInternalUI(InstallUIOptions.Silent);
ExternalUIRecordHandler _processMessageHandler = new ExternalUIRecordHandler ProcessMessage);
ExternalUIRecordHandler result = Installer.SetExternalUI(_processMessageHandler, InstallLogModes.Verbose);
Installer.InstallProduct(fi.FullName, _commandLine);
}
transaction.Commit();
Have you tried calling the four-parameter version of EnableLog()? In that version, the third parameter allows you to put it in append mode, and the fourth turns on flushing. I'm guessing the don't append mode is applying to a reopening of the log file during Commit(). If you still want to truncate at the beginning, you could delete any existing file before starting the installation.
Installer.EnableLog(InstallLogModes.Verbose, LogPath, true, true);

WIX: How not to call ActionStart(Name=StartMetabaseTransaction) during installation

My installer would fail when installed on a machine that has no IIS installed. The features that are going to be installed doesnt need IIS. The error says "Cannot connect to Internet Information Server".
In addition to that. The installer file has also a feature that requires IIS. But when I unselect that feature, the installer still looks for IIS. Below is the log it generated.
MSI (s) (D0:F8) [11:39:12:437]: Note: 1: 2318 2: C:\Program Files\Cormant Technologies\DCE\WindowsService\UninflectedWords.txt
MSI (s) (D0:F8) [11:39:12:437]: Executing op: CacheSizeFlush(,)
MSI (s) (D0:F8) [11:39:12:437]: Executing op: InstallProtectedFiles(AllowUI=1)
MSI (s) (D0:F8) [11:39:12:437]: Executing op: ActionStart(Name=StartMetabaseTransaction,Description=Starting IIS Metabase Transaction,)
Action 11:39:12: StartMetabaseTransaction. Starting IIS Metabase Transaction
MSI (s) (D0:F8) [11:39:12:453]: Executing op: CustomActionSchedule(Action=StartMetabaseTransaction,ActionType=11265,Source=BinaryData,Target=***,CustomActionData=***)
MSI (s) (D0:D4) [11:39:12:453]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI1D.tmp, Entrypoint: StartMetabaseTransaction
StartMetabaseTransaction: Error 0x80040154: failed to get IID_IIMSAdminBase object
Error 26001. Cannot connect to Internet Information Server. (-2147221164 )
MSI (s) (D0!78) [11:39:13:812]: Product: DCE -- Error 26001. Cannot connect to Internet Information Server. (-2147221164 )
Action ended 11:39:13: InstallFinalize. Return value 3.
MSI (s) (D0:F8) [11:39:13:828]: User policy value 'DisableRollback' is 0
MSI (s) (D0:F8) [11:39:13:828]: Machine policy value 'DisableRollback' is 0
MSI (s) (D0:F8) [11:39:13:828]: Executing op: Header(Signature=1397708873,Version=301,Timestamp=1029397732,LangId=1033,Platform=0,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=0)
MSI (s) (D0:F8) [11:39:13:828]: Executing op: DialogInfo(Type=0,Argument=1033)
MSI (s) (D0:F8) [11:39:13:828]: Executing op: DialogInfo(Type=1,Argument=DCE)
MSI (s) (D0:F8) [11:39:13:828]: Executing op: RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Rolling back action:,RollbackTemplate=[1],CleanupAction=RollbackCleanup,CleanupDescription=Removing backup files,CleanupTemplate=File: [1])
Action 11:39:13: Rollback. Rolling back action:
Rollback: Starting IIS Metabase Transaction
MSI (s) (D0:F8) [11:39:13:828]: Executing op: ActionStart(Name=StartMetabaseTransaction,Description=Starting IIS Metabase Transaction,)
MSI (s) (D0:F8) [11:39:13:828]: Executing op: ProductInfo(ProductKey={FC6DA479-9C97-4941-8AAE-3E0C9D6DAA56},ProductName=DCE,PackageName=DCEWebInstaller.msi,Language=1033,Version=50462720,Assignment=0,ObsoleteArg=0,,,PackageCode={FBFBCC4D-BE93-4AEA-8B05-922409001DE5},,,InstanceType=0,LUASetting=0,RemoteURTInstalls=0)
MSI (s) (D0:F8) [11:39:13:828]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\Administrator\Application Data
Rollback: Copying new files
If you take a closer look at the ConfigureIIs custom action in the InstallExecuteSequence using Orca, you'll see its execution depends on the property called SKIPCONFIGUREIIS. It is "all-or-nothing" switch, and if you set this property for those cases when your IIS-related feature is off, the installation won't try to address IIS services.
Hope this helps.