I recently had cause to change the SQL Collation of the tempdb database on a SQL 2005 Cluster. The installed collation was SQL_Latin1_General_CP1_CI_AS and I needed to change it to Latin1_General_CI_AS. After some brief research it became apparent that the process isn’t as straightforward as you’d imagine.
My first attempt, based on a couple of blog posts I’d read, suggested restoring the model database from an alternative SQL installation with the desired collation. This worked in that once I’d restarted SQL, tempdb had the correct collation, but unfortunately this caused errors in Management Studio. I think this was because the master database had a different collation to that of tempdb.
Apparently the only way to change the collation of the master database is to rebuild all the system databases. So, in preparation, I detached all the user databases and took a copy of syslogins. Apparently you can only rebuild the system databases from the command line and it took some experimentation before I hit on the right combination of arguments. These were as follows;
setup.exe /qn VS=<virtual server name> INSTANCENAME=<instance name> REINSTALL=SQL_Engine REBUILDDATABASE=1 SQLCOLLATION=Latin1_General_CI_AS GROUP=<cluster group> SKUUPGRADE=1 SQLACCOUNT=<sql service account> SQLPASSWORD=<sql service account password> ADMINPASSWORD=<logged in user password> SAPWD=<sa password>
SKUUPGRADE was required because the server was running service pack 1 but setup.exe was from the RTM version. I don’t know a way around this as you can’t slipstream a SQL 2005 SP1 installation.
ADMINPASSWORD specified the password of the logged in user. I had initially omitted this option but was getting an error “The installation was cancelled by the user” in the logs. After some investigation I discovered that the installer was trying to create a scheduled task on each of the cluster nodes, but was failing because it couldn’t authenticate. As an added bonus this would also lock out my domain account. Nice one Microsoft!
SAPWD was required (despite the SA account being disabled), otherwise I would get the following error in C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Summary.txt.
Error: Action "LaunchPatchedBootstrapAction" threw an exception during execution. Error information reported during run:
"C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\setup.exe" finished and returned: 1602 Aborting queue processing as nested installer has completed Message pump returning: 1602
Once the installation had completed I attached the user databases and restored the syslogins. See here for details on how to do this.
The moral of the story is to check and double check you have the correct collation at the point of installation. It’s a right pain to change afterwards. Lesson learnt.