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.