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.

Globally Unique Identifier

Globally Unique Identifier is a genious thing when you need a globally unique identifier! They are not as brilliant when they are used everywhere you would need a human-readable name, because of laziness.

If you've ever been troubleshooting a Windows program, and you have if you are reading this blog, you are fully aware of the frustration you feel trying to find the associated file from a class identifier in the registry or when figuring out which program C:\Windows\Installer\{136688F1-EF42-414E-92D6-BFF4D25EE688}\ARPPRODUCTICON.exe belongs to.

Usually you just copy the GUID into the clipboard and paste it into an appropriate search box. Isn't obvious that {25336920-03F9-11cf-8FD0-00AA00686F13} is the CLSID for "Browse in place"?

It doesn't help then, at all, that there are two ways of storing the GUID, either normally or compressed. And by "compressed" I mean "not really compressed, just a little different to annoy people and make their life harder".

How to convert between a standard and a compressed GUID:

Have you seen anything dumber than this, lately?

Also note that the "Browse in place" GUID, usually found under keys such as HKCR\htmlfile or HKCR\jpegfile, have two lowercase letters for no reason. It's likely true on your Windows too. To be truly globally unique, GUIDs should be generated by an algorithm standardized by ISO, IEC or someone with power to standardize. I am not sure, but I doubt the algorithm is inconsistent with upper and lower case.

Sometimes it is obvious the GUID is not random, as in the case with Microsoft Office;

The product code for Office consists of it's version and language and such, ending in "0FF1CE" as Microsoft describes here. My Office 2016 Pro has a GUID of  {90160000-0011-0000-0000-0000000FF1CE}.

Older Java clients had class IDs starting with "CAFE"; {CAFEEFAC-0013-0000-0003-ABCDEFFEDCBA}, or maybe it should read "Café fuck", because that is how I read it.

Finding the product code for an msi install is trivial when the program is already installed, but often you would like to avoid littering your computer, even your virtual one, with garbage unless you really have to.

I wrote a tool to list the product codes of all msi files in a folder, and also put them in the clipboard for easy pasting into your uninstall-script. Download it here.

If you don't dare to download unknown programs and run them on your computer you are not an application deployer.

What version is this?

Everybody hates versioning. Everybody.

You can easily tell this by the fact that nobody does it unless forced to do so, and mostly not even then.

There is a long and very boring Wikipedia-page about versioning but let me sum it up for you without ever having read it. Your software should have a version number in a format like this:

major.minor.build.revision

Swap build and revision if you like, or disregard them altogether, but keep your major and minor versions consistent! However, there have never been a program that follows this scheme successfully over several versions during it's existence. Let me give some examples:

Windows 10 Version 1709 is version 10.0.16299.192. Windows 8 is version 6.

Java Development Kit 7 for Java 7 is not version 7 but 1.7.0.0.

Two different and incompatible ocx-files with the same name and version, from the last century but somehow still in use in some programs today. That is good work, mr McMahon, but you obviously hate versioning as much as everyone else!

This office plugin is either version 10 or version 1.0.10 depending on who you ask. About Office; Office 2003 is version 11, Office 2007 is version 12, 2010 is version 14. I see what you did there, Microsoft, you don't want any bad luck! But how the hell am I supposed to remember that version 15 is Office 2013? Finally version 16 is actually Office 2016, but then again, Office 365 is ALSO version 16!

Some of the many, many, many vc-redists required, it quickly becomes ridiculous. When you get an error and the Event viewer tells you that Microsoft.VC80.MFC is missing, you immediately know you need to install Microsoft Visual C++ 2005 Redistributable, don't you?

I think I got my point across.

Happy versioning!

Installation failed because reasons

Sometimes installations fail. Often, the reason for failure is logical and easily found in a log file, sometimes you just get an 1603 with no indication whatsoever what went wrong.

And sometimes the install fails by design. A retarded design.

Solid Works 2016 installs Microsoft SQL Server 2008, Microsoft SQL Server 2012 and Microsoft SQL Server 2014.

I think most people see a probable cause for disaster right there. But surprisingly it usually works.

Unless your organisation has done the rare but sensible and rational thing and set a password policy:

As it happens, Microsoft SQL Server adheres to the group policy dictating the password policy for the domain.

There are workarounds found when googleing, but they either require disabling the password policy or modifying the way the database is created. Neither of these methods might be possible for an unattended install from a third party vendor.

Mostly because I don't feel like talking to the vendor, nor to my collegues managing the domain.

So here is how you install an SQL instance without supervision, without modifying the install and without modifying the domain:


; Removing password-requirements with secedit:

RunWait('secedit.exe /export /cfg "' & @TempDir & '\sectmporg.cfg" /quiet',"",@SW_HIDE)

FileCopy(@TempDir & '\sectmporg.cfg', @TempDir & '\sectmpcpy.cfg',1)
IniWrite(@TempDir & '\sectmpcpy.cfg',"System Access","MinimumPasswordLength","0")
IniWrite(@TempDir & '\sectmpcpy.cfg',"System Access","PasswordComplexity","0")

RunWait('secedit.exe /configure /db secedit.sdb /cfg "' & @TempDir & '\sectmpcpy.cfg" /quiet',"",@SW_HIDE)
RunWait("gpupdate.exe","",@SW_HIDE)

; **********************
;
; THE INSTALL GOES HERE!
;
; **********************

; Restoring password-requirements:

RunWait('secedit.exe /configure /db secedit.sdb /cfg "' & @TempDir & '\sectmporg.cfg" /quiet',"",@SW_HIDE)
RunWait("gpupdate.exe","",@SW_HIDE)

Code is AutoIt, but I'm sure you figure it out in any language.

Did you find this article helpful

Did you find this article helpful?

Has anyone ever?

No.

Information is key

You are the greatest application manager and the best security supervisor in the IT industry! Your clients are Applocked and secure, your users lack any higher level of permissions, the firewall blocks anything even remotely suspicious and the antivirus catches everything and then some.

You sit back and sip your cup of coffee.

Suddenly your boss storms in! He's been "offered" to pay a million bucks or all your secrets will be sold to the highest bidder! A stack of pdf-files shows they mean business.

How the hell did somebody get their hands on all your documents when your environment is so secure?

Wait, what is this at the bottom of every page?

Oh. A user gave away all the secret documents willingly.

Maybe somebody ought to inform the users they have a local pdf-converter installed on the computer.

Information is the key.

Unfortunately, it's hard to find.

Windows on Windows action

If you are running a 64 bit Windows, and you are aren't you, you are actually running two operating systems, one 64 bit, and one 32 bit. While this is an extreme simplification, it is for all intents and purposes true enough, while at the same time maybe not true at all. But it is.

Anyway, an Intel processor runs 16, 32 or 64 bit code in different modes, thus a process can only run in either mode, not several. If I designed a CPU I would make sure future modes could run current code, but I don't design CPUs, probably because I don't have a clue. To Intels defense, the x86 range of CPUs are backwards compatible back into a different century. Hilariously it was AMD, not Intel, who designed the 64 bit mode and thus it is sometimes called AMD64.

The consequence of these modes is that 32 bit binaries and 64 bit binaries are pretty incompatible. 32 bit processes cannot load 64 bit binaries and vise versa. To run both kind of programs, Windows therefor has an almost full set of both 32 and 64 bit components.

The system files of Windows have since Windows 95 been stored in the "System32" folder. In 32-bit Windows, which can natively run 16 bit code, there is also a "System" folder, pretty much containing a Windows 3.11 set of 16 bit files. But 64 bit Windows dropped the 16 bit support, so the "System" folder is no longer present. Well, it's there, but pretty much empty.

For stupid reasons Microsoft decided to keep the name of the system folder as "System32" even on a 64 bit Windows.

The System32 folder contains the 64 bit system files.

I can see why, but I believe it's stupid because we are going to run 64 bit for much longer than the 20 years we used 32 bit operating systems. Then again, the future plans for Windows executables are uncertain.

But as you've figured out, 32 bit programs can't use these 64 bit system files, how does that work? Misdirection! Or rather, redirection. Or virtualization, if you prefer.

A 32 bit program trying to access System32 will be redirected to the "SysWOW64" folder. The program believes it loads from System32, but it isn't. It's running a 32 bit System Windows On Windows 64. SysWOW64.

The SysWOW64 contains the 32 bit system files.

There are ways to get around this if your program needs to for some reason, but this is the default behaviour. You can access the true System32 folder from a 32 bit process by the alias C:\Windows\Sysnative.

The registry is divided in much the same way. 32 bit programs accessing HKLM\Software are redirected to HKLM\Software\Wow6432Node. They couldn't choose a consistent name such as RegWOW64, because why would they. Also note that HKEY_CLASSES_ROOT is actually a mirror of HKLM\Software\Classes and HKCU\Software\Classes, therefor 32 bit and 64 bit class registrations can exist at the same time, the 32 bit under HKLM\Software\Wow6432Node\Classes.

The Program Files folders are not redirected, you can install a 64 bit program in Program Files (x86) and a 32 bit program in Program Files without much trouble. However, the environment variables are different for each architecture, the %ProgramFiles% points to a different folder depending on the process.

You can try all this by launching one 64 bit CMD from C:\Windows\System32 and one 32 bit CMD from C:\Windows\SysWOW64.

I made a tool, CheckArch, that shows the architecture of a file, sometimes needed for troubleshooting. How you managed so far without it, I don't know.

Download CheckArch.exe