Problems using the Command Line Install on SQL Server 2014 Express

The installation sets for SQL Server Express are actually wrapper executable, which basically means they are large zip files which contain the setup files. So, the first thing that happens after running it is that all the files are extracted to a temporary directory and then the Setup.exe is executed using the command line parameters passed to the wrapper.

Unfortunately, there are a few bugs in the wrapper executable for SQL Server 2014 RTM. These seem to be exclusive to SQL Server 2014 RTM, and according to Microsoft will be fixed in service pack 1. In previous versions of the SQL Server Express installation sets, the extract folder is randomly generated and the files are automatically extracted.

Because of this, you can run the wrapper in one of two ways.

1. Using the same command line parameters as I used in SQL Server 2008 Express and 2012 Express, I am prompted for an extract folder. Once extracted, the Setup.exe is correctly executing using command line parameters passed to the executable. This has the down side of making completely automated installs impossible. 
2. Using command line parameters exclusive to the wrapper, I can specify an extract folder. This has the down side of ignoring any other command line parameters. So, I'm going to have to extract the files and then run Setup.exe separately.

Command line parameters supported by the wrapper

• /Q - Quiet mode. This is the same as Quiet mode for Setup.exe
• /U - Progress Bar mode. This displays a progress bar as the files are extracted.
• /X:<PATH> - The Extract Folder where the files are extracted. This last parameter has a few caveats. 

Extract Folder Parameter

• The parameter must be the last parameter. Anything after that is considered part of the path.
• The parameter must be followed by a colon and then followed by the path.
• There must be no space between the X and the colon or the colon and the path.

What this means is that anyone wanting to automate the installation of SQL Server will need to first extract the files. Then, run Setup.exe separately.  Afterward, any temporary folder and files will need to be cleaned up.

While this isn't a huge burden for developers, it definitely qualifies as annoying. It did involve a couple of extra days worth of testing to make sure I covered all the bases.

SQL Server 2012 Install Fails on Server Core 2008 R2 VHD - Object reference not set to an instance of an object.

So, I'm going through the Administering Microsoft SQL Server 2012 Databases book for the 70-462 certification exam. The only way, I could quickly get access to Windows Server Core for the test exercises was to download the VHD provided by Microsoft.

Well, strange thing. It is missing a critical registry key. Without this key, SQL Server fails with a horribly vague error. To make it more fun, while the description tells me to look in a file named summary.txt, there is no file named summary.txt anywhere.

The following error occurred:
Object reference not set to an instance of an object.

Error result: -2147467261
Result facility code: 0
Result error code: 16387

Please review the summary.txt log for further details

Slightly more - but also unhelpful - information can be found in the Component Updater log file generated by the installer.

Exception summary:
The following is an exception stack listing the exceptions in outermost to innermost order
Inner exceptions are being indented

Exception type: System.NullReferenceException
    Message: 
        Object reference not set to an instance of an object.
    Data: 
      DisableWatson = true
    Stack: 
        at Microsoft.SqlServer.Configuration.MsiExtension.ArpRegKey.CleanupPatchedProductRegistryInfo()
        at Microsoft.SqlServer.Configuration.MsiExtension.SetPatchInstallStateAction.ExecuteAction(String actionId)
        at Microsoft.SqlServer.Chainer.Infrastructure.Action.Execute(String actionId, TextWriter errorStream)
        at Microsoft.SqlServer.Setup.Chainer.Workflow.ActionInvocation.ExecuteActionHelper(TextWriter statusStream, ISequencedAction actionToRun, ServiceContainer context)

Anyway, after a couple of hours of messing around with it, I find a post on the Microsoft Forums that finally sheds some light on it.  Apparently the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Uninstall registry key doesn't exist in the distributed virtual hard drive. Either adding this key or running an installer that creates it seems to fix the problem.

Hopefully, this will save others some debugging time and effort.