# destination directory for SQL Server 2012 is greyed out

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?

-

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

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"
AGTSVCACCOUNT="DOMAIN\USER"
SQLSVCACCOUNT="DOMAIN\USER"
FEATURES=SQLENGINE,REPLICATION,FULLTEXT,AS
SQLCOLLATION="SQL_Latin1_General_CP1_CI_AS"
INSTANCEID="<INSTANCE_NAME>"
INSTANCENAME="<INSTANCE_NAME>"
INSTANCEDIR="D:\Apps"

-
as I said, both machines are newly built. Both situations are "first install". Sorry, if it wasn't clear in my original post. –  Felix Mar 13 '12 at 19:17
Ah I see, sorry about that, I have not run into that before. Have you tried running setup.exe as Administrator to see if it's the UAC giving you trouble? –  Jason Cumberland Mar 13 '12 at 20:43
yep, did that... oh well - braced myself and dedicated another 2GB of my SSD drive to Microsoft. It's for a good cause, isn't it ;) –  Felix Mar 14 '12 at 4:11
As a last ditch effort you could try a command line install, beause that allows you to specify these even though the HUI may lock them out. It may throw an error at trying to use them but it's worth a shot. –  Jason Cumberland Mar 14 '12 at 21:00
Thanks, Jason. I'll try when the next RC or the final version comes out... for now I have it on SSD :) –  Felix Mar 15 '12 at 1:19

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.

-