destination directory for SQL Server 2012 is greyed out

Question

I tried to install SQL Server 2012 Standard on Windows 2008 and on Windows 7 (I only wanted to install management studio on Win7). Same ISO; both machines are newly built. However, on Windows 7 Shared features directories are set to C:\Program Files... and greyed out even though none of the options are checked. C: is OS drive; however, it's a rather small SSD, so I am trying to install everything I can to another drive.

On Win2008 it is not greyed out (unfortunately, I don't need to change anything there).

What could cause Shared directories to be greyed out on Windows 7?

Answer 1

The shared features directory is set by the first install of SQL and cannot be changed afterwards without uninstalling everything from that SQL version in add/remove programs and then re-installing with the correct directory.

Expanding on my comment, the approximate synx and config file for a command line install.

rem setup call
setup.exe /IAcceptSQLServerLicenseTerms=TRUE /CONFIGURATIONFILE="Config_File_Instance.ini" /q

rem configuration (ini) file contents
;SQLSERVER2008 Configuration File
[SQLSERVER2008]

; Media and Shared locations
INSTALLSHAREDDIR="D:\Apps\Program Files\Microsoft SQL Server"
INSTALLSHAREDWOWDIR="D:\Apps\Program Files (x86)\Microsoft SQL Server"

; Install options
ACTION="Install"
FEATURES=SQLENGINE,REPLICATION,FULLTEXT
HELP="False"
INDICATEPROGRESS="False"
X86="False"
ERRORREPORTING="False"
SQMREPORTING="False"
FILESTREAMLEVEL="0"
SECURITYMODE="SQL"
FTSVCACCOUNT="NT AUTHORITY\NETWORK SERVICE"
AGTSVCSTARTUPTYPE=Automatic
SAPWD="ILGT@Oeo845684e09S0R$%E$eOdtedtyeoryi"
ASSVCACCOUNT="DOMAIN\USER"
ASSVCPASSWORD="<MY SECURE PASSWORD>"
ASSYSADMINACCOUNTS="DOMAIN\USER"
AGTSVCACCOUNT="DOMAIN\USER"
AGTSVCPASSWORD="<MY SECURE PASSWORD>"
SQLSVCACCOUNT="DOMAIN\USER"
SQLSVCPASSWORD="<MY SECURE PASSWORD>"
FEATURES=SQLENGINE,REPLICATION,FULLTEXT,AS
SQLSYSADMINACCOUNTS="DOMAIN\USER"
SQLCOLLATION="SQL_Latin1_General_CP1_CI_AS"
INSTANCEID="<INSTANCE_NAME>"
INSTANCENAME="<INSTANCE_NAME>"
INSTANCEDIR="D:\Apps"
INSTALLSQLDATADIR="D:\Apps"

Answer 2

This is poor design limitation, and it is still the case for SQL Server 2014. The SQL Server installer should be able to move everything!

However, you can work around it by creating folders where you want (still separate 32/64 bit), moving everything there from the original to the new, then creating junctions that map the new locations to the old. You'll need to have administrator privileges, close all SQL programs and connections, and stop all SQL services.

Here's how I did it on Windows 7, with explanations for each step. I've done the similar things with other programs I didn't want to reinstall on Server 2012R2.

Be sure you understand what each step does before you do this! Also note any wrapped lines.

0) Make sure you have a current backup of your system drive, in case you fatfinger something or something fails that I haven't taken into account.

1) Stop all running SQL Server services, either use system management or from command line:

sc stop SQLBrowswer
sc stop SQLWriter
sc stop MSSQL$SQLSERVER2012E

2) Make folders on the drive where you want the program files to live:

mkdir e:\SqlServer\x64
mkdir e:\SqlServer\x86

3) Move the 64-bit programs. Check the output to see if any files were copied instead of moved!

robocopy "C:\program files\Microsoft SQL Server\100" "E:\SqlServer\x64\100" /e /copyall /move
robocopy "C:\program files\Microsoft SQL Server\110" "E:\SqlServer\x64\110" /e /copyall /move

4) Move the 32-bit programs: Check the output to see if any files were copied instead of moved!

robocopy "C:\program files (x86)\Microsoft SQL Server\100" "E:\SqlServer\x86\100" /e /copyall /move
robocopy "C:\program files (x86)\Microsoft SQL Server\110" "E:\SqlServer\x86\110" /e /copyall /move

5) For me, this file was copied when moving the 110 tree, so I had to move it before deleting the folders. Using Process Explorer (Find), I determined it was open by WmiPrvSE.exe, which I'll restart near the end. For now, to get it out of the way so the SQL server folders can be deleted, I simply moved it to the root of c::

move "C:\program files\Microsoft SQL Server\110\Shared\instapi110.dll" c:\instapi110.dlx

6) Delete the folders from program files:

rmdir /s "c:\program files\Microsoft SQL Server"
rmdir /s "c:\program files (x86)\Microsoft SQL Server"

7) If either of these fail, you probably missed a file in 3) or 4) that was copied instead of moved. Return to step #5 and handle the file(s) similarly to the way I handled instapi110.dlx.

8) Make junctions so the files in the new location appear in the old as well:

mklink /J "C:\Program Files\Microsoft SQL Server" E:\SqlServer\x64"
mklink /J "c:\Program Files (x86)\Microsoft SQL Server" "e:\SqlServer\x86"

9) Restart the SQL services, using either System Management, SQL Server Configuration Manager, or the command line:

sc start MSSQL$SQLSERVER2012E
sc start SQLBrowswer
sc start SQLWriter

10) I used System Management to restart the WMI service, since it also restarts any dependent services automatically. For other components, or if you can't figure out what has it open, you can reboot.

del c:\instapi110.dlx

11) Make sure that when you backup your system drive, you also backup the drive with these on it (or at least the folders). Image backups will not backup files from junction targets on other disks.

Answer 3

I got this to work on a SQL Server 2014 Standard install. It should work on 2012 as well since the parameter is the same for a command line setup. You need to add the /INSTANCEDIR="your_path_here" parameter to a command line install. Run this from an admin powershell prompt:

.\setup.exe /Action=Install /INSTANCEDIR="D:\Microsoft SQL Server"

Here is the list of SQL Server 2012 setup paramters:

https://technet.microsoft.com/en-us/library/ms144259(v=sql.110).aspx