SQL Server and Other Topics


I got my start with SQL Server in 1997 with SQL Server 6.5 at BellSouth Cellular. From that point on I've had the opportunity to work on Versions 6.0 to 2014. I specialize in Performance Tuning, High Availability and SQL Development. Contact me through this site or through my Twitter handle @SQLDiver

Part 1 > Part 2 > Part 3

 In the last post, part 2, I talked about the the plan and project for implementing Availability Groups.Today I will discuss the creation of an unattended install.

First, what is an unattended install, well, simply it is the ability to use a "template" configuration file to automatically complete all of the possible parameters required to install, in this case, SQL Server. It is critical to adopt a standard configuration setup, where to put the data and log files, etc., so you're unattended install will configure all servers the same.

 The easiest way to create the configuration file "ConfigurationFile.ini" is to do an install, make sure you chose all of the parameters as you would like them to be saved and used for every install. Once you get to the end of the install, on the "Ready to Install" screen prior to clicking the Install button you will see the path to the "ConfigurationFile.ini". Copy the path and file name from the text box so we can get to it later. You can now cancel the install as you've captured all of the parameters need to install SQL Server.


That was easy!

 Now lets make sure all of the configuration settings are correct. At this point paste the path in File Explorer to open the file in Notepad (or your favorite text editor). It should look something like the following, keep in mind that I would not copy my example as it is for another environment.

 Unattended Install ConfigurationFile.ini

Look at each parameter in the configuration file and change the ones that you want to change. You will want to test the file until it is exactly what you want, then you can put it on a network drive somewhere and run it quiet when you want to install SQL Server.

   ;SQL Server 2014 Configuration File  
; Specifies a Setup work flow, like INSTALL, UNINSTALL, or UPGRADE. This is a required parameter.  
  ;Accept Terms <- Saves you from having to accept the license terms   
  ; Use the /ENU parameter to install the English version of SQL Server on your localized Windows operating system.   
; Parameter that controls the user interface behavior. Valid values are Normal for the full UI,AutoAdvance for a simplied UI, and EnableUIOnServerCore for bypassing Server Core setup GUI block.  
; Setup will not display any user interface. (when set to true)   
  ; Setup will display progress only, without any user interaction. (when set to true)   
  ; Specify whether SQL Server Setup should discover and include product updates. The valid values are True and False or 1 and 0. By default SQL Server Setup will include updates that are found.    
; Specify if errors can be reported to Microsoft to improve future SQL Server releases. Specify 1 or True to enable and 0 or False to disable this feature.  
; If this parameter is provided, then this computer will use Microsoft Update to check for updates.  
  ; Specifies features to install, uninstall, or upgrade. The list of top-level features include SQL, AS, RS, IS, MDS, and Tools. The SQL feature will install the Database Engine, Replication, Full-Text, and Data Quality Services (DQS) server. The Tools feature will install Management Tools, Books online components, SQL Server Data Tools, and other shared components.    
  ; Specify the location where SQL Server Setup will obtain product updates. The valid values are "MU" to search Microsoft Update, a valid folder path, a relative path such as .\MyUpdates or a UNC share. By default SQL Server Setup will search Microsoft Update or a Windows Update service through the Window Server Update Services.  <-- where are the SPs or CUs?   
; Displays the command line parameters usage  
  ; Specifies that the detailed Setup log should be piped to the console.  <- Good for when the install errors   
; Specifies that Setup should install into WOW64. This command line argument is not supported on an IA64 or a 32-bit system.  
  ; Specify the root installation directory for shared components.  This directory remains unchanged after shared components are already installed.    
 INSTALLSHAREDDIR="C:\Program Files\Microsoft SQL Server"  
 ; Specify the root installation directory for the WOW64 shared components.  This directory remains unchanged after WOW64 shared components are already installed.   
INSTALLSHAREDWOWDIR="C:\Program Files (x86)\Microsoft SQL Server" 
  ; Specify a default or named instance. MSSQLSERVER is the default instance for non-Express editions and SQLExpress for Express editions. This parameter is required when installing the SQL Server Database Engine (SQL), Analysis Services (AS), or Reporting Services (RS).    
; Specify that SQL Server feature usage data can be collected and sent to Microsoft. Specify 1 or True to enable and 0 or False to disable this feature.  
; Specify the Instance ID for the SQL Server features you have specified. SQL Server directory structure, registry structure, and service names will incorporate the instance ID of the SQL Server instance.  
  ; Specify the installation directory.    
 INSTANCEDIR="C:\Program Files\Microsoft SQL Server"  
  ; Agent account name  
; CM brick TCP communication port  
; How matrix will use private networks  
; How inter brick communication will be protected  
; TCP port used by the CM brick  
; Startup type for the SQL Server service.  
; Level to enable FILESTREAM feature at (0, 1, 2 or 3).  
; Set to "1" to enable RANU for SQL Server Express.  
; Specifies a Windows collation or an SQL collation to use for the Database Engine.  
   ; Account for SQL Server service: Domain\User or system account. (Remember your password will be clear text) <- these parameters can be passed in the command execution   
   ; Windows account(s) to provision as SQL Server system administrators. (Remember your password will be clear text) 
; The default is Windows Authentication. Use "SQL" for Mixed Mode Authentication.  
  ; The Database Engine root data directory.    
  ; Default directory for the Database Engine user databases.    
  ; Default directory for the Database Engine user database logs.    
  ; Directory for Database Engine TempDB files.    
  ; Directory for the Database Engine TempDB log files.    
; Provision current user as a Database Engine system administrator for %SQL_PRODUCT_SHORT_NAME% Express.  
; Specify 0 to disable or 1 to enable the TCP/IP protocol.  
; Specify 0 to disable or 1 to enable the Named Pipes protocol.  
; Startup type for Browser Service.  

Pre-Installation Script File

I usually create a script that runs prior to the install and one that runs after the install. This will allow you to automate some prep work. For instance, create folders for the data and log files on the drive.

I named my file PreInstallationScript.ps1 and this one contains the creation of the file folders for the data and log files. This script can be used to set many different configurations.

 New-Item D:\SQLServer\SQLData -type directory 
New-Item D:\SQLServer\SQLLogs -type directory 
New-Item F:\SQLServer\SQLData -type directory 
New-Item F:\SQLServer\SQLLogs -type directory 
New-Item G:\SQLServer\SQLData -type directory 
New-Item G:\SQLServer\SQLLogs -type directory 
New-Item G:\SQLServer\TempDb\SQLData -type directory 
New-Item G:\SQLServer\TempDb\SQLLogs -type directory 

Post-Installation Script File

(Uses PoSh script by Eric Humphrey (http://www.erichumphrey.com/category/powershell/)

 # Set the Windows Power Options to High Performance
set-location $PSScriptRoot
#Set Trace Flags 1117, 1118, 3226, 4199
.\Add-SqlServerStartupParameter.ps1 '-T1117'
.\Add-SqlServerStartupParameter.ps1 '-T1118'
.\Add-SqlServerStartupParameter.ps1 '-T3226'
.\Add-SqlServerStartupParameter.ps1 '-T4199'
$compname = $env:computername
Write-Host $compname
Enable-SqlAlwaysOn -ServerInstance $compname -Force
Invoke-Sqlcmd -InputFile ".\AddTempDBFiles.sql"
Invoke-Sqlcmd -InputFile ".\Configs.sql"
Invoke-Sqlcmd -InputFile ".\GlenBerryCriticalAlerts.sql"
Invoke-Sqlcmd -InputFile ".\AlwaysOnNotifications.sql"
Invoke-Sqlcmd -InputFile ".\OlaMaintenanceSolution.sql"
read-host "Press enter to continue"

Then I wrap it Up in a Bow!

I create an UnattendedInstall.bat file to kick off the install. 

 net localgroup administrators /add yourdomainname\SQLEngineSVC 
cd "Z:\Apps\SQLServer2014" 
Setup.exe /ConfigurationFile=ConfigurationFile.INI 


 The unattended install can be customized to your environment using the scripts. I have left out some of the scripts here because the method of calling them is more important that the code.

This concludes Part 3 of this post. Next time we'll look at the Availability Groups.

Part 1 > Part 2 > Part 3


My current client has a very complex environment where up time is extremely important. They are a payment processor handling credit card payments 24x7x365.

They currently are using a combination of SQL Server Mirroring and Failover Cluster Instances for their high availability and disaster recovery across a WAN between data centers.

Current EnvironmentA mirroring failover is known to be a much faster recovery than clustering. This is mostly due to the disk arbitration that takes place during a failover to protect the data on the disk.

For this reason, the client was unhappy with Failover Clustering Instances. They wanted the failover to always be a mirroring failover to result in the smallest downtime.

The Windows Failover Cluster was a multi-subnet cluster traversing both data centers. There were two environments R-710s and R-720s. The R-710s were coming to the end of life. Each had a Fusion-IO solid state drive for the data. The free space on the drives was dwindling.

The mirroring witness resided in Bermuda which encountered irregular network issues causing loss of quorum frequently.

The client decided to rebuild the servers, re-installing Windows Server 2012 R2 so they have a "clean" environment.

The client had the following requirements:

  1. Re-install Windows on the servers.
  2. Increase redundancy.
  3. Use existing equipment.
  4. Keep license cost to minimum.
  5. Failover must be automatic with zero loss of data.
  6. Complete the project with near zero downtime.

 With this information I recommended the following:

  1. Consolidate the two environments, preventing the need to purchase additional licenses1 for the new environment (new licenses hadn't been purchased for SQL Server Enterprise on the R-720s).
  2. Evict the passive nodes from the cluster, re-install, team the NICs for redundancy, create a new cluster (named properly).
  3. Add Fusion-IO drives from R710s to R720s.
  4. Log ship databases to rebuilt machines.
  5. Create Availability groups for each business region.
  6. Flip from Log Shipping to Availability Group.
  7. Tear down the old cluster.
  8. Rebuild the last set of servers.
  9. Add to new Windows Failover Cluster.
  10. Add servers as new availability replicas using PowerShell to minimize downtime.

Each product will have 4 replicas, 2 synchronous (local and across WAN2). Against best practices of only using asynchronous availability mode across the WAN, because the application was unable to handle the prevention of the loss of transactions during failover. The transaction(s) could possibly be committed or rolled back locally but not on the replica. They can't afford for a $100,000 transaction or batch of transactions to be committed at the client but not committed in the database..i.e. the credit card transactions were accepted but not recorded (or be paid for).

1The machines were licensed for SQL Server Enterprise on 2 - 8 core CPUs. With two active and two passive nodes, that is 32 core (16 - 2 pack licenses). They had an extra 2 pack license, so they had to purchase an additional license.

 The client approved the design and the migration plan.

Over the next few weeks I will go into the details about how we migrated the 25 databases with less than 5 minutes of down time. Keep in mind I'm not a PowerShell guru, this is the most PowerShell I've ever written.


This script is very handy to make sure you have your replicas set synchronous and have an automatic failover partner when needed. Put this script in your arsenal!


SELECT ar.replica_server_name, ag.name,
CASE WHEN hags.primary_replica = ar.replica_server_name THEN 'PRIMARY - ' + ar.failover_mode_desc ELSE
CASE WHEN ar.failover_mode_desc = 'AUTOMATIC' THEN ar.failover_mode_desc ELSE ar.availability_mode_desc END
END  as Mode
FROM sys.availability_replicas ar
INNER JOIN sys.availability_groups ag ON ag.group_id = ar.group_id
INNER JOIN sys.dm_hadr_availability_group_states hags ON ag.group_id = hags.group_id
) src
--for name in ([agMISC],[agHK],[agAP],[agEU],[agUS],[agSA],[agPPTables],[agIPAY],[agCSP])
for replica_server_name in ([P-MSSQL01-EF],[P-MSSQL02-DE],[P-MSSQL02-EF],[P-MSSQL01-DE])) piv;