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


'm continuously mentoring enterprise companies in how they can simplify their lives. The worst comment I hear on a regular basis is, "doing it manually is why I have job security". ARGHHHHH! No it is why you can be replaced in a heartbeat.

So DBAs, wake up! If you do the same task, manually, over and over, you're doing it wrong. When do you have time to study and play with the new features? When do you have time to watch your Pluralsight videos? How do you improve your skills... when you have to take all of your time doing the same thing manually when you can automate it??

Over the next blog posts I'm going to give you some tips and tricks and how to's for automating your installs using PowerShell... the easy way. 

Unattended Install

There have been so many people blog about how to do an unattended install I'm not going to go into great detail. First you must go here and read this article: "Install SQL Server from the Command Prompt"

No joke, this is the best starting point for understanding the unattended install. 

Now you want to go to a friend of mine, Joey D'Antoni's blog and read this one thoroughly! "Are You Still Installing SQL Server from the GUI?"

See, I didn't really need to re-write his blog post. Short and sweet and how I have always started by unattended install process at every employer and now client since the first one. 

The rest is tweaking the passed in parameters from command line or PowerShell script. I highly recommend you pass in the passwords for install. You can save the admin groups in the configuration.ini file. 

Its what follows that takes some work and PowerShell to configure... but, if you have a few PowerShell modules installed and everything is much easier. 


Modules you will need to install on your "management server". Click the link for each of the following for instructions on how to install:







That will be enough work to get you started so I'll end this episode now. Follow the instructions and you'll be off to a good start!

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.

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;

Part 1 > Part 2 > Part 3


In part 1 I started building the framework for moving from SQL Server Database Mirroring (mirroring) to SQL Server AlwaysOn Availability Groups (AGs).

Inventory what you have in all environments, what are you going to need to migrate to the new server (remember this is about moving to new (rebuilt) servers. There are many blogs about how to move mail configuration, sql jobs, users, alerts, operators, database and server configuration, etc., etc.  Don't forget anything. Get the team together to brainstorm all of the things that must be moved and configured.

Complete Inventory

Create a design document. This design document should cover all aspects of what the environment will "look" like after the migration. It is critical to think through the licensing, the availability replica modes, failover  policy, etc. It gives you a chance to think deeply about what needs to be done to configure all aspects of the migration. Know the roadblocks, the requirements for an Availability Group and where AGs will not work. Here are a few:

  1. DTC - Don't do AGs if you're application uses DTC.
  2. Cross Database Transactions - Don't do it! If you have a failover and your app is doing a cross database transaction, the primary could come back in suspect mode. This arfticle will help confirm if you're using cross database transactions.
  3. Domain - A domain is required for the WSFC (that changes in Windows Server vNext).
  4. Cluster - The AG replicas must all be in the same cluster.

 There are more issues you will encounter with Ags... see here.

Determine what the business SLAs are for Recovery Time Objective (RTO) and Recovery Point Objective (RPO) and document in the design document.  You want to be able to tell management how much downtime to expect.

Use Visio to create diagrams, for your own benefit as much as everyone Else's. These diagrams will help keep your head straight with what your design is. It will allow you to plan the number of licenses for management, and it will be your "evidence" after your done when management says, you didn't tell us... oh yes I did, a a matter of fact it is right here in the design document that you approved. Ok, so there is another critical element. Make sure management approves the design document (put a spot for signatures on the cover page), it will prompt them to sign it. Don't deliver the design document until you have tested the migration in a lower environment first. It will expose gotchas that you didn't think about (hopefully you tested prior to getting buy in from management). 

Approved Design

Now that we have the design approved by the client (management), its time to work on the most important step...planning. Without a proper plan not only will you not succeed, but you will probably fail horribly. Let's put that down as a critical component.

Complete Plan

The plan should be a step by step plan with dependencies,  start time of each step (as a calculation based upon the previous step duration), estimate duration step, step status (Completed, In Progress, Cancelled, etc.), responsible party, day of week (calculated from date time column) and step number for quick reference. I usually put my plans in Excel and have a conditional format for the row based upon the status.

This plan should include all steps include server builds, network, stress test, benchmark testing, etc. If you want to be a plan Nazi include the regression testing, etc. Hopefully your company or client has an experienced  project manager for the project. It will take a little longer, but if you have a good project manager your project will have a complete project plan avoiding gotchas at a later date.


I know this is a lot of work, but it will save you in the end. Your job is to eliminate all possibility of accidental downtime and minimize the length of downtime as well as have a highly available environment that works for your company or client. Please take your time and do the work.