Different minds, different worlds. A case study.

The giants in the new world are called Google, Apple or Microsoft. In the old ages, they were called Siemens or Asea Brown Boveri.

Lets compare their philosophy when it comes to deliver software products. I've made an easy to understand table comparing a typical Google program, such as Google Earth, with software from ABB or Siemens, such as ABB Automation Builder or Siemens Totally Integrated Automation Portal (say it quickly five times).

Google	ABB and Siemens
Small msi or single file setup.	Ginormous installer, dozens or even hundreds of smaller setups, wrapped in a launcher, difficult or impossible to install without the wrapper.
Installs in under 1 minute.	Takes hours. Often takes a different amount of time to install each time, even on the same clean computer. Fails unpredictably.
Silent install with simple parameters.	Nope, never in a million years. Even autoclicking through the install is difficult, because the control IDs change or buttons are not real buttons.
Just works.	Doesn't work. Drivers bluescreen! Actually crashes regsvr32! Has issues with UAC and Credential Guard, can't install in Console 0, and even has problems with long filenames. I mean, long filenames, seriously?
Seamless automatic updates.	Requires elevation for updates nobody is asking for, and also for add on modules you are asking for but are not included in the offline install.
Secure.	Requires full permission in its many many Program Files folders and can't be installed elsewhere, breaking AppLocker security. Confusing number of processes requiring firewall exceptions.
Distinctly different programs each with a clear purpose.	Several identical looking programs with no description of what they are for or what the differences are.
Just download.	After registering an account and finally finding the correct program using a horrible search engine, you are told you don't qualify to download their precious software.
Just install and run.	After finally installing you are told you need to apply for a license or to put a hardware dongle into the USB. Who pirates engineering software?
Usually a free version, the paid version costs a few dollars.	Costs a fortune.
Program is contained in one folder.	Installs everywhere, including the root of the drive. Computer is never the same again.
Modern look and feel.	GUI like it's 1999.
Explore the entire world.	Automates something something, except itself.
Steals your soul.	Forces you to slowly descend into madness.

Prepare deployment by reading these two thousand pages

Some companies think their product is the best. It's da bomb as they might say, if bombing was a positive thing for software to do.

They think their product is such a gift to humanity they expect you to read through dozens or hundreds of pages even to just get past the EULA.

This might be fine for the user who purchased the application who then spend days excitingly exploring this new wonderous program.

It is not fine at all for the application deployer who has 550 other applications to manage and can't spend his full time job just on your special snowflake and don't give a shit about how great it is, or even what it does or why. Yes, 550 is the actual number of applications that I manage.

This is the Oracle Database Client Installation Guide. Also available as PDF it is 84 painfully boring pages, and yet when it comes to the most critical part of the installation, what components to include or not include, all it says is;

If you selected Custom as the type of installation in step 4, then the Available

Product Components screen is displayed. Select the products that you want to

install and click Next. 

What? How the fuck am I supposed to know what "Product Components" that "I want"? I don't want to install anything, I have to. What I want is to know what the fuck I have to install and why. Do my clients need "Oracle SQLJ"? How am I supposed to know that?

What I want. Apparently.

This is the Deployment guide for Office 365 ProPlus. Who on Earth has the time to read that through? Does it say anything about how licensing works on shared computers? I don't know because there is too much text.

The Overview: Deploying Creative Cloud for enterprise starts with a seven and a half minute long video. That is the overview. The full guide is found here with more pages than I care to count.

A deployment guide should consist of a single page. This is what I need to know:

• Prerequirements. Do your program require some other program?
• What the components are for and which are required.
• How to configure the install. If it's an MSI, use properties.
• What the error codes mean. ALL of them.

That is it. Most companies fail on all but the first bullet point and many even fail on that one.

What do these companies think I do at work all day long?

Not working, that's what.

Self Repair

There are things that probably had good intentions early in its developement but eventually didn't turn out as great as one had hoped. Communism. The DeLorean DMC-12. MSI Self Repair.

An msi normaly register itself into the system during the end of the installation, running actions such as "PublishFeatures". With an msi you don't actually have to install the program, you only need to "publish" it. Some files and registry entries in the msi is set as keys, and if one of those is missing when the program needs it, Windows Installer will perform a Self Repair.

I don't know anyone who has ever published a program instead of installing it. But then again, I don't know that many people.

However, Self Repair has effect even when a program is fully installed, because the keys always have to be present. An msi usually applies source resiliency. In the rare case of an install that becomes corrupt it will try to reinstall the broken feature, but the more common scenario is that a user is launching the program for the first time and files and registry keys that are supposed to be in the user space are missing. When this works, it is ok. Not great, but ok.

This brings us to when it doesn't work, which is probably where a vast majority of people encounter Self Repair:

This was a very common problem during the days of removable media, but thankfully most computers don't even have a CD reader anymore. It's still a problem though, because users don't always have access to the company network, or the cache that used to contain the install has been purged. The latter is typical of an environment running the later versions of Microsoft System Center.

Some deployers seem to think Self Repair is the greatest thing since sliced bread, but it isn't. A proper program does NOT rely on Windows Installer for user files and a proper configured computer does NOT need to constantly repair broken installs.

Worse, many badly authored msi triggers unnecessary and sometimes repeating Self Repairs not only for itself but for features belonging to other, completely unrelated, programs. And for the love of God, don't set key paths to any startup locations! Do you hear me, Citrix?

There are a couple of work-arounds if you want to avoid actually solving the problem. The first and easiest is to create a new shortcut to the offending program and see if it launches correctly. Normally, the repair is triggered when the program is called by its advertised shortcut, a special lnk that goes to a launcher i C:\Windows\Installer. Repair is triggered by more events than launching the advertised shortcut though, so this might not always work.

The cause of the Self Repair should be noted in the Event Viewer in the Application Event log with an ID of 1004, and a quick fix could be to create a dummy file or registry key in place of the one missing.

The most brutal one is to use MsiZap to simply clean all the installer metadata, leaving only the program itself, completely unaware about any published features or components. This is a last resort solution that might cause new problems that are hard to troubleshoot further down the road, try to avoid it!

How to deploy an application that needs data in the user space will be covered, I promise.

Success fail

A successful installation should return an exit code of 0, but that is not always the case. These cases need to be handled properly, or I'll get a very red pie-chart in System Center.

The most common exception is 3010, a successfull install that needs a reboot, but there are others. Some more or less retarded.

Just now I needed to deploy an msi that returned 1638 if it was already installed. 1638 is documented as ERROR_PRODUCT_VERSION, "Another version of this product is already installed". This is stupid on many levels. First, if the same version is installed an msi should just install again. If an older version is installed, a proper msi should perform a major upgrade. The exit code might be useful if a newer program exists on the computer, but barely. I would say that installations which return 1638 should be documented as ERROR_MSI_SUCKS. The solution is to always uninstall before installing. This leads to the next problem.

Uninstalling an msi might return 1605, ERROR_UNKNOWN_PRODUCT, "This action is only valid for products that are currently installed." Yes, thank you. Already not there then. Success.

Sometimes you might need to deploy a patch for Windows, usually named kb-something with an msu extension, with your application. Unfortunately a shitload of your computers in your enterprise will report failure 2359302, 0x240006 in hex. This means WU_S_ALREADY_INSTALLED, "The update to be installed is already installed on the system". This is even dumber than 1638. If it is already installed, it is a success!

Related is the msu exit value of 2149842967, 0x80240017 in hex, "The update is not applicable to your computer". You'll get this result if you try to deploy a patch for Windows 7, and you happen to have a few Windows 10 among them, as an example. Not unlikely for many reasons, one of which is the update is included in a larger install where the application needs it on older Windows, but you don't feel like making two different packages for each OS or some other workaround. While the error might be interesting for some reasons, as a deployer I don't care. I filter it to success and I'm just as happy.

Deploying drivers with DPInst is an entire chapter of itself. The return value you get consist of three hexadecimal parts merged with OR like this:

0xYY0000 contains the number of drivers that failed to install.
0x00YY00 contains the number of drivers copied to the driver store.
0x0000YY contains the number of drivers successfully installed.

A return code of 66051 thus means 1 driver failed, two drivers copied to the driver store and 3 drivers installed, because it's 0x010203 in hex.

The simplest way to get a useful value is to do an AND FF0000. If it's zero, it's a success, otherwise you'll get the number of fails times 65536.

But so far the exit codes have at least been valid and have their reasons. Some badly written installers give all kinds of weird return values. Adobe was notorious for a while, returning 255 for a success.

But of all the moronic exit codes to indicate success there is one particularly stupid from msiexec;

1707 - Installation operation completed successfully.