SQL Server Installation Folder Setup Log and Command Line Install Information

, 2013-12-11

?The other morning I was commenting during our regular meetings amongst fellow DBAs on where to read up on installation issues, or for simple text validation of what components were added during an installation process. This is the folder I want to point out: \\rootDrive:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\Log

Every install action, whether an Add of a node, settings validation, repair, remove, uninstall appears in this folder, and as soon as you have installation issues, go right to the specific Detail.txt under the Log folder corresponding to the date and time an installation was executed. You will see that Summary.txt has very little information, which is self-evident by its name.

For those of you who have a solid state drive at home (desktop / laptop, etc), to become familiar with how SQL Server is installed, I recommend a download of the SQL 2012 Developer edition ISO and to familiarize oneself with the command line installation - and if we could compare total install times (it's ll in the logs, no need for the stop watch), versus a GUI install that would be cool πŸ™‚ to share.  

For those who are curious regarding command line installs, here are some installation examples. Note that now you can mount your ISO natively in Win 2012/Windows 8 and run this comment directly from the mounted drive letter. 

CMD line install and one for an non-clustered with Analysis Services:
setup.exe /IACCEPTSQLSERVERLICENSETERMS /QS /ACTION="Install" /AGTSVCPASSWORD="19CharacterPassword" /ASSVCPASSWORD="19CharacterPassword" /SAPWD="19CharacterPassword" /SQLSVCPASSWORD="19CharacterPassword" /INDICATEPROGRESS="true" /ENU="True" /UpdateEnabled="TRUE" /UpdateSource="Drive:\FOLDERCONTAININGLatestUpdate/FEATURES=SQLENGINE,REPLICATION,FULLTEXT,DQ,AS,RS /HELP="False" /INDICATEPROGRESS="TRUE" /X86="False" /INSTALLSHAREDDIR="C:\Program Files\Microsoft SQL Server" /INSTALLSHAREDWOWDIR="C:\Program Files (x86)\Microsoft SQL Server" /INSTANCENAME="InstanceName" /INSTANCEID="InstanceName" /ERRORREPORTING="True" /INSTANCEDIR="C:\Program Files\Microsoft SQL Server" /AGTSVCACCOUNT="InstanceSpecificServiceAccountName" /ASSVCACCOUNT="InstanceSpecificServiceAccountName" /ASSVCSTARTUPTYPE="Automatic" /ASCOLLATION="Latin1_General_CI_AS" /ASDATADIR="DriveName:1\olapdb_InstanceName" /ASLOGDIR="DriveName:\olaplog_InstanceName" /ASBACKUPDIR="DriveName:\olapbakup_InstanceName" /ASTEMPDIR="DriveName:\\olaptmp_VInstanceName" /ASCONFIGDIR="DriveName:\OLAP\Config" /ASPROVIDERMSOLAP="1" /ASSYSADMINACCOUNTS="ListOfUsers" "ADDINSTANCESPECIFICCCOUNT" /ASSERVERMODE="MULTIDIMENSIONAL" /FILESTREAMLEVEL="0" /SQLCOLLATION="Latin1_General_CI_AS" /SQLSVCACCOUNT="InstanceSpecificServiceAccountName" /SQLSYSADMINACCOUNTS="InstanceSpecificServiceAccountName" "ADDINSTANCESPECIFICCCOUNT" /SECURITYMODE="SQL" /INSTALLSQLDATADIR="DriveName:\sqlsysdb_InstanceName" /SQLBACKUPDIR="DriveName:\sqlbakup_InstanceName" /SQLUSERDBDIR="DriveName:\mpdbs001\sqlappdb_InstanceName" /SQLUSERDBLOGDIR="DriveName:\sqlapplog_InstanceName" /SQLTEMPDBDIR="DriveName:\sqltmpdb_InstanceName" /RSSVCACCOUNT="NT Service\ReportServer$InstanceName" /RSSVCSTARTUPTYPE="Automatic" /FTSVCACCOUNT="NT Service\MSSQLFDLauncher$InstanceName"

And a command line instance Repair:
setup.exe /IACCEPTSQLSERVERLICENSETERMS /QS /ACTION="repair" /ENU="True" /INSTANCENAME="NAME" /ASSVCACCOUNT="19CharacterPassword" /ASSVCPASSWORD="19CharacterPassword" /SAPWD="19CharacterPassword" /SQLSVCPASSWORD="19CharacterPassword"

For the most part, the cluster installation is exactly the same as the standalone SQL Server installation with the exception of a few screens in the GUI, and I would not recommend a Failover Cluster installation from the CMD prompt since you miss all the steps of whether parameters are valid for installation - unless you run CMD without the /QS parameter, which means an attended installation launched from the command link. I find this is a faster way of feeding the GUI installation procedure, and validating as you go along that the parameters actually work within the installation procedure before clicking Next (or equivalent) on each step.

Adding a node, however, is straightforward unattended and a real time-saver, NB when you add a node, you must provide again the passwords for service accounts.

setup.exe /IACCEPTSQLSERVERLICENSETERMS /QS /ACTION="AddNode" /AGTSVCPASSWORD="StrongPassword" /SQLSVCPASSWORD="StrongPassword" /INDICATEPROGRESS="true" /ENU="True" /UpdateEnabled="False" /UpdateSource="Drive:\FOLDERCONTAININGLatestUpdate" /HELP="False" /INDICATEPROGRESS="TRUE" /X86="False" /INSTANCENAME="InstanceName" /FAILOVERCLUSTERGROUP="ClusterRoleName" /FAILOVERCLUSTERIPADDRESSES="IPv4;159.208.196.63;Public;255.255.252.0" /FAILOVERCLUSTERNETWORKNAME="SQLVirtualClusterName" /CONFIRMIPDEPENDENCYCHANGE=1 /AGTSVCACCOUNT="domain\InstanceSpecificServiceAccount" /SQLSVCACCOUNT="domain\InstanceSpecificServiceAccount"

---this one is when you have to add AS also on the second node

setup.exe /IACCEPTSQLSERVERLICENSETERMS /QS /ACTION="AddNode" /AGTSVCPASSWORD="StrongPassword" /SQLSVCPASSWORD="StrongPassword" /INDICATEPROGRESS="true" /ENU="True" /UpdateEnabled="False" /UpdateSource="MU" /HELP="False" /INDICATEPROGRESS="TRUE" /X86="False" /INSTANCENAME="InstanceName" /FAILOVERCLUSTERGROUP="ClusterRoleName" /FAILOVERCLUSTERIPADDRESSES="IPv4;IPADDRESSFORSQLVIRTUALSEVER;Public;255.255.252.0" /FAILOVERCLUSTERNETWORKNAME="DNSVirtualServerEntry" /CONFIRMIPDEPENDENCYCHANGE=1 /AGTSVCACCOUNT="domain\InstanceAccountName" /SQLSVCACCOUNT="domain\InstanceAccountName" /ASSVCACCOUNT="domain\user" /ASSVCPASSWORD="StrongPassword"

Using a Configuration file to add a second node to a cluster:

setup.exe /IACCEPTSQLSERVERLICENSETERMS /qs /ACTION="AddNode" /CONFIGURATIONFILE=”DRIVEONOTHERNODE:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\ConfigurationFileINSTANCENAME.ini” /AGTSVCPASSWORD=”15CharacterPassword" /ASSVCPASSWORD=”15CharacterPassword" /SQLSVCPASSWORD=”15CharacterPassword" /INDICATEPROGRESS="TRUE"

Changing Database Server Collation:, err, if you set it wrong by accident (works exclusively for standalone from my experience):
Setup /QS /ACTION=REBUILDDATABASE /INSTANCENAME="InstanceName" /INDICATEPROGRESS="TRUE" /SQLSYSADMINACCOUNTS="ML\oth_mlsqldbms" "listOfAccounts" "domain\userGroup" /SAPWD="StrongPassword" /SQLCOLLATION=SQL_Latin1_General_CP1_CI_AS

References (for all the other options):
http://msdn.microsoft.com/en-us/library/ms144259.aspx

Rate

β˜… β˜… β˜… β˜… β˜… β˜… β˜… β˜… β˜… β˜…

Share

Share

Rate

β˜… β˜… β˜… β˜… β˜… β˜… β˜… β˜… β˜… β˜…

Related content

Database Mirroring FAQ: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup?

Question: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? This question was sent to me via email. My reply follows. Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? Databases to be mirrored are currently running on 2005 SQL instances but will be upgraded to 2008 SQL in the near future.

β˜… β˜… β˜… β˜… β˜… β˜… β˜… β˜… β˜… β˜…

2009-02-23

1,567 reads

Networking - Part 4

You may want to read Part 1 , Part 2 , and Part 3 before continuing. This time around I'd like to talk about social networking. We'll start with social networking. Facebook, MySpace, and Twitter are all good examples of using technology to let...

β˜… β˜… β˜… β˜… β˜… β˜… β˜… β˜… β˜… β˜…

2009-02-17

1,530 reads

Speaking at Community Events - More Thoughts

Last week I posted Speaking at Community Events - Time to Raise the Bar?, a first cut at talking about to what degree we should require experience for speakers at events like SQLSaturday as well as when it might be appropriate to add additional focus/limitations on the presentations that are accepted. I've got a few more thoughts on the topic this week, and I look forward to your comments.

β˜… β˜… β˜… β˜… β˜… β˜… β˜… β˜… β˜… β˜…

2009-02-13

360 reads