Enable MSI verbose logging by default about choco

[ferventcoder]

I guess its good to have the issue logged. Take a look at
https://github.com/chocolatey/choco/blob/master/src/chocolatey/infrastructure.app/domain/MsiInstaller.cs#L75

We plan, once we get the remaining posh scripts into managed code, to move
fully over to installtype which already knows how to install and uninstall
things. So it becomes much smarter. Note that verbose logging is already
turned on by default in here and once we flip the switch, we'll be munging
silent args in the pkg with the ones listed here.

On Sunday, February 1, 2015, DarwinCSIWindowscom [email protected]
wrote:

Having MSI verbose logging can be very handy for packages. Many EXE based
package run one or more MSIs - so having the logging can help diagnose
challenging install problems.

The best approach is to backup the contents of the below registry key and
then put in the below and then set it back to the previous settings when
done.

The "DisableLoggingFromPackage" prevents a package's internal logging
settings from overriding and making the logging less than full verbose.

The "Debug" setting shows the exact command line the MSI was called with
(for example - from a setup.exe wrapper).

If no Installer policies are currently set, the entire "Installer" key
level will be absent.

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
"Debug"=dword:00000007
"Logging"="xvoicewarmup"
"DisableLoggingFromPackage"=dword:00000001

—
Reply to this email directly or view it on GitHub
#50.

Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[DarwinCSIWindowscom]

Sounds interesting!

MSI at the API level is dumb about minor upgrades. You must detect whether
the GUIDs are the same and then that the version numbers are only minor in
difference and then use the "reinstall" command line to do a minor
upgrade. If the packages don't match perfectly, it may not work.

With major upgrades (diff product codes) - you can just use /i - but then
the "upgrade" table needs to be properly populated.

Due to the above complexities of getting everything right, many companies
just require a deinstall of the previous version before installing - so the
lowest risk method is:

*) if GUIDS (Product Code) and versions match - just mark the package as
installed.
*) if GUIDS match and versions don't - uninstall the previous version
before installing.
*) if GUIDS don't match - you won't know via the API (a properly populated
Upgrade table is the only way MSI could make the correlation) - so you will
just try to install it. If the packages aren't written correctly you'll
end up with two product codes (and all associated MSI meta data) pointing
to one instances of the files and registry keys - but the MSI should
complete normally and the app should work properly. If the upgrade table
is populated - then in theory the software vendor did some testing between
the two releases and it should work.

D.

On Sun, Feb 1, 2015 at 10:13 PM, Rob Reynolds '[email protected]'
via 33Mail [email protected] wrote:

This email was sent to the alias '[email protected]' by '
[email protected]
',
and 33Mail forwarded it to you. To block all further emails to this alias
click here
http://www.33mail.com/alias/unsub/b702cb770029578500909d19da31c0bc
http://www.launchbit.com/az/17278-10977/
(Prefer no ads? Upgrade to Premium.
http://www.33mail.com/dashboard/choose_account)

I guess its good to have the issue logged. Take a look at

https://github.com/chocolatey/choco/blob/master/src/chocolatey/infrastructure.app/domain/MsiInstaller.cs#L75

We plan, once we get the remaining posh scripts into managed code, to move
fully over to installtype which already knows how to install and uninstall
things. So it becomes much smarter. Note that verbose logging is already
turned on by default in here and once we flip the switch, we'll be munging
silent args in the pkg with the ones listed here.

On Sunday, February 1, 2015, DarwinCSIWindowscom [email protected]

wrote:

Having MSI verbose logging can be very handy for packages. Many EXE
based
package run one or more MSIs - so having the logging can help diagnose
challenging install problems.

The best approach is to backup the contents of the below registry key
and
then put in the below and then set it back to the previous settings when
done.

The "DisableLoggingFromPackage" prevents a package's internal logging
settings from overriding and making the logging less than full verbose.

The "Debug" setting shows the exact command line the MSI was called with
(for example - from a setup.exe wrapper).

If no Installer policies are currently set, the entire "Installer" key
level will be absent.

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
"Debug"=dword:00000007
"Logging"="xvoicewarmup"
"DisableLoggingFromPackage"=dword:00000001

—
Reply to this email directly or view it on GitHub
#50.

Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

—
Reply to this email directly or view it on GitHub
#50 (comment).

[ferventcoder]

Wow, it really seems like some packages are really doing MSIs incorrectly.
Where I work we say you NEVER change the upgrade code -https://github.com/puppetlabs/puppet_for_the_win/blob/master/wix/include/puppet.wxi#L24-L31

[DarwinCSIWindowscom]

Rob - I feel that is Microsoft's fault - not the devs trying to use MSI.

Should an installation framework really require as much study to get right as the coding language of the software it is meant to deliver?

I think MSI got too big while in development. And then it wasn't backed by a program that made it workwhile for ISVs to invest in knowing MSI well enough.

Consequently most software vendors and the vast majority of Administrators punt to "detect and uninstall the previous version before even trying to install the new MSI"

Because it works every time (or rather "has the best chance of success in the most circumstances") no matter where you got the package and how badly it is coded.

My two cents.

[ferventcoder]

I think we always do major upgrades so we sidestep the issue of minor upgrades. But the major upgrades are a full uninstall / reinstall by the MSI when it runs the install/upgrade anyway.

[DarwinCSIWindowscom]

It's not actually possible to side step a properly configured minor upgrade because the currently installed package and the new one have the same GUID. The interactive error is "this package is already on the system", when run silent it does not do an upgrade - but might not be a hard error either.

Also, although a major upgrade is internally an install and uninstall operation - the MSI "upgrade" table must be configured to support it or you end up munging two GUIDS into one file set. MSI does not even recognize that the apps are the same ones. You'll have two GUIDs - one file set.

Even if the upgrades table is configured, by default the RemoveExistingProducts standard action runs AFTER the installs occur. (https://msdn.microsoft.com/en-us/library/aa371197%28v=vs.85%29.aspx) This is the most efficient bit wise (you don't want to remove 1 GB of Microsoft Office just to lay down 50 MB of changes). However, component codes must be PERFECT or you'll get self-heals afterward because RemoveExistingProducts removed stuff that was put down by non-unique component codes of the new version. Component codes for the exact same DLL that is at the exact same version as a prior package are supposed to match exactly to prevent this problem. I have a classroom lab that sets up this exact scenario and the results is immediately after you complete the major upgrade there is only one file on the system - one that was only in the new package. Start the software and the entire package is needlessly self-healed into place.

So the only truly clean way to do this blindly without having to understand the underlying compliance of the MSI package is to externally deinstalls the old version in one transaction and install the new version in a seperate transaction.

The exception to this rule would be some (few) microsoft packages that follow the rules correctly and some big companies like Adobe. But even adobe follows the rules on reader and breaks them on Flash by changing product codes on minor updates.

So there is [a] a very distinct and [b] rather large advantage to externally uninstalling the old version before installing the new - two seperate MSI transactions in script code - because all these issues go away for every package transaction type.

[ferventcoder]

Except in the case of MSIs that would delete user data on uninstall, whether from the file system or the registry.

[DarwinCSIWindowscom]

In chocolatey you should never be doing a MSI per-user install - which means no MSI data in user profiles.

In regard to deleting application artifacts from users that is ONLY done if the uninstall runs in the context of that SPECIFIC user and only for that user.

Do an MSI Per-Machine install on a shared desktop machine used by 5 users in a call center. Wait 6 months and uninstall via an administrator profile and you have HKCU and %USERPROFILE% leftovers of the application in all the profiles.

MSI does not clean up application bits - even the ones it knows about - and especially not the ones created by the application itself that are not defined in the MSI database.

It does not triage profiles and clean them up.

[ferventcoder]

Sorry by user data I didn't mean actually the user profile. I meant any
customizations including custom install directory. My bad on terminology.

It does sound like you answered that though. I'm still concerned that some
folks would write their MSIs in a way that it would be an issue of getting
app data cleaned up on uninstall. You already mentioned that Windows
Installer takes forever to learn, and that most folks don't invest enough
time into doing it right, which means that there is more potential for harm
in uninstall/install scenarios.

On Monday, February 2, 2015, DarwinCSIWindowscom [email protected]
wrote:

In chocolatey you should never be doing a MSI per-user install - which
means no MSI data in user profiles.

In regard to deleting application artifacts from users that is ONLY
done if the uninstall runs in the context of that SPECIFIC user and
only for that user.

Do an MSI Per-Machine install on a shared desktop machine used by 5 users
in a call center. Wait 6 months and uninstall via an administrator profile
and you have HKCU and %USERPROFILE% leftovers of the application in all the
profiles.

MSI does not clean up application bits - even the ones it knows about -
and especially not the ones created by the application itself that are not
defined in the MSI database.

It does not triage profiles and clean them up.

—
Reply to this email directly or view it on GitHub
#50 (comment).

[DarwinCSIWindowscom]

I am trying to express that by doing anything other than a full de-install of a known previous version (in your code - not relying on MSI) you are taking a much bigger dependency on the quality of the MSI (and knowledge of those who coded it) than when you attempt to install over a known previous version using MSI (by which I mean running "msiexec.exe" against a package when you know there is already a previous version of that software on the system).

So the lowest risk, least hassle, leave MSI's bar of impossible GUID perfection behind, approach - you deinstall the previous package via msiexec /x and then install via msiexec /i.

To handle the much fewer times that this creates an actually problem - make sure you always run with full on MSI verbose logging.

Also - in a powershell template I manage, I have a log collection routine that grabs all those logs and dumps them in the folder with the log my framework generates. It is jaw dropping amazing: [a] how many MSI logs some EXEs generate and [b] incredibly helpful to finding hard problems when you scan them and [c] incredibly helpful to move them out of their original folder because technicians who are non-familiar with generating and identifying these logs are many times capable of analyzing them. So in my case Level 1, 2 or 3 support can solve the problem and it never hits my desk.

These verbose logs would be even more helpful for those generating packages - especially new package authors who might get discouraged by weird issues.

But, not to lose the point that deinstall before installing a package that contains the same software is going to buy your framework the most upgrade compatibility possible.

You could provide an override switch to install over in case the chocolatey package author knows the package is capable of upgrading over ALL - ALL previous versions that might be on the system. However, if you do - you should engineer logic to detect if a minor upgrade command line (/rvomus) or major upgrade (/i) command line needs to be used. Remember that in real environments any previous version of either a chocolatey installed or independently installed package could be either a "minor upgrade" or a "major upgrade" when compared to the package chocolatey is currently evaluating for for install.

I guess that's an additional advantage of uninstall first - if a previous version was not chocolatey installed - you would still be very likely to have a successful install.