PowerSQL

SYSTEM Permissions in SQL Server

randomnote_1 — Sun, 09 Sep 2018 20:04:51 GMT

Okay folks, we need to have a conversation about SYSTEM permissions in SQL Server. SYSTEM is constantly over-permissioned in SQL Server . Some of the reasons given for why SYSTEM is over-permissioned are:

My backup application runs as SYSTEM and needs to log into SQL.
This application or service runs as SYSTEM and needs access to SQL.
Windows Server Failover Clustering (WSFC) needs access to SQL, therefore I need to grant SYSTEM access.
Always On Availability Groups use WSFC, therefore SYSTEM requires access to SQL.

While these reasons are legitimate, there are better ways to grant permissions. This article will discuss what SYSTEM is, why granting SYSTEM additional permissions in SQL Server is bad, and the appropriate methods to grant permission to system resources.

What is SYSTEM?

SYSTEM (NT AUTHORITY\SYSTEM in en-us) is the account the operating system runs as. Any process that is executed as SYSTEM is running in the highest level permissions that can be granted.

The History of SYSTEM in SQL Server

Prior to SQL Server 2012, SYSTEM was a member of the sysadmin server-level role. SQL Server 2012 introduced drastic changes to the permissions granted to SYSTEM. SYSTEM has the following permissions and group memberships in SQL Server version 2012 through current (SQL 2017 as of this writing):

Server Role Memberships
- public
Server Permission Grants
- Alter any availability group
- Connect SQL
- View Server State

As you can see, the only changes SYSTEM can make in SQL is to Availability Groups. This is far more restrictive than it used to be.

Why Were the Permissions Changed?

A large portion of the running processes on a server are executing with SYSTEM as the owner. When a process is executing as SYSTEM, the process can do anything on the server. Members of the Local Administrators group can easily configure workloads to execute as SYSTEM. Some examples include Services, Scheduled Tasks, and utilities like PsExec. An Administrator could unintentionally or intentionally configure a rogue workload to execute as SYSTEM. When a workload is running as SYSTEM, it is difficult (if not impossible) to trace the actions taken by SYSTEM back to the workload because all the actions show they were run as SYSTEM in the audit logs.

Demos

The following demos will demonstrate the permissions differences between SQL Server 2008 R2 and SQL Server 2017.

Setup

The following items were used in the demos:

A SQL Server 2017 Instance. I spun up a VM in Azure using the SQL Server 2017 template from the Azure Marketplace.
A SQL Server 2008 R2 Instance. I used the Windows Server 2008 R2 SP1 template from the Azure Marketplace and installed SQL Server 2008 R2 RTM.
Configure a SQL Server Audit on both instances.
Obtain a copy of PsExec64.

SQL Server Audit

The following query can be used to create a server audit and specify which events to log. Ensure the SQL Server service has full control to the audit log directory. [sql]USE [master] GO CREATE SERVER AUDIT [TestAudit] TO FILE ( FILEPATH = N'C:\AuditLogs\' ,MAXSIZE = 20 MB ,MAX_ROLLOVER_FILES = 10 ,RESERVE_DISK_SPACE = OFF ) WITH ( QUEUE_DELAY = 1000 ,ON_FAILURE = CONTINUE ) CREATE SERVER AUDIT SPECIFICATION [TestAuditSpecification] FOR SERVER AUDIT [TestAudit] ADD (APPLICATION_ROLE_CHANGE_PASSWORD_GROUP), ADD (AUDIT_CHANGE_GROUP), ADD (BACKUP_RESTORE_GROUP), ADD (DATABASE_CHANGE_GROUP), ADD (DATABASE_OBJECT_CHANGE_GROUP), ADD (DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP), ADD (DATABASE_OBJECT_PERMISSION_CHANGE_GROUP), ADD (DATABASE_OPERATION_GROUP), ADD (DATABASE_OWNERSHIP_CHANGE_GROUP), ADD (DATABASE_PERMISSION_CHANGE_GROUP), ADD (DATABASE_PRINCIPAL_CHANGE_GROUP), ADD (DATABASE_PRINCIPAL_IMPERSONATION_GROUP), ADD (DATABASE_ROLE_MEMBER_CHANGE_GROUP), ADD (DBCC_GROUP), ADD (FAILED_LOGIN_GROUP), ADD (LOGIN_CHANGE_PASSWORD_GROUP), ADD (LOGOUT_GROUP), ADD (SCHEMA_OBJECT_ACCESS_GROUP), ADD (SCHEMA_OBJECT_CHANGE_GROUP), ADD (SCHEMA_OBJECT_OWNERSHIP_CHANGE_GROUP), ADD (SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP), ADD (SERVER_OBJECT_CHANGE_GROUP), ADD (SERVER_OBJECT_OWNERSHIP_CHANGE_GROUP), ADD (SERVER_OBJECT_PERMISSION_CHANGE_GROUP), ADD (SERVER_OPERATION_GROUP), ADD (SERVER_PERMISSION_CHANGE_GROUP), ADD (SERVER_PRINCIPAL_CHANGE_GROUP), ADD (SERVER_PRINCIPAL_IMPERSONATION_GROUP), ADD (SERVER_ROLE_MEMBER_CHANGE_GROUP), ADD (SERVER_STATE_CHANGE_GROUP), ADD (SUCCESSFUL_LOGIN_GROUP), ADD (TRACE_CHANGE_GROUP) WITH (STATE = ON) ALTER SERVER AUDIT [TestAudit] WITH (STATE = ON) GO[/sql]

Get SYSTEM Permissions

Execute the following query to get the permissions granted to SYSTEM in each instance: [sql]EXECUTE AS LOGIN = 'NT AUTHORITY\SYSTEM' SELECT * FROM fn_my_permissions(NULL,NULL) REVERT[/sql] Note that SQL Server 2008 R2 grants everything to SYSTEM by default and SQL Server 2017 instance only grants CONNECT SQL and VIEW ANY DATABASE to SYSTEM by default.

Create a Database

Log into the instance using SQL Server Management Studio (SSMS).
Open a new query editor.
Execute the following query to create a database:

[sql]USE master; GO CREATE DATABASE AccessDemo; GO USE AccessDemo; GO CREATE TABLE dbo.Employee ( EmployeeID int PRIMARY KEY CLUSTERED ); GO[/sql]

Query the audit log by executing the following query:

[sql]SELECT event_time ,session_server_principal_name ,server_principal_name ,database_name ,schema_name ,object_name ,statement FROM sys.fn_get_audit_file('C:\AuditLogs\*.sqlaudit',default,default) WHERE statement LIKE 'CREATE%'; GO[/sql]

Note the session_server_principal_name and the server_principal_name are the SQL Server login account used to log into the instance.

Delete a Table Using SYSTEM

Run PowerShell as Administrator and change directories to the directory where PsExec64.exe is stored. Launch PowerShell as SYSTEM using the following command. A new PowerShell window will open. [powershell].\PsExec64.exe -i -d -s powershell.exe[/powershell] In the new PowerShell window, execute the following command: [powershell]sqlcmd -Q 'SELECT name FROM sys.databases'[/powershell] This will return a list of all the databases in both SQL Server 2008 R2 and SQL Server 2017. Now try dropping the Employee table from the AccessDemo database [powershell]sqlcmd -d AccessDemo -Q 'DROP TABLE Employee[/powershell] SQL Server 2008 R2 provides no feedback, indicating a successful operation. SQL Server 2017, on the other hand, throws a "Login failed for user" error message. To validate the table has been deleted from the AccessDemo database in SQL Server 2008 R2, execute the following query: [sql]USE AccessDemo; GO SELECT name FROM sys.tables; GO[/sql] Note the Employee table is not returned in SQL Server 2008 R2 and it is returned in SQL Server 2017. Execute the following query to see what actions SYSTEM performed: [sql]SELECT TOP 2 event_time ,session_server_principal_name ,server_principal_name ,database_name ,schema_name ,object_name ,succeeded ,statement FROM sys.fn_get_audit_file('C:\AuditLogs\*.sqlaudit',default,default) WHERE server_principal_name = 'NT AUTHORITY\SYSTEM' ORDER BY event_time DESC; GO[/sql] The audit log clearly shows in SQL Server 2008 R2 that SYSTEM was able to drop the table where in SQL Server 2017, SYSTEM was denied access to the AccessDemo database. Note, if the investigation into the audit logs is done forensically after-the-fact, the investigator would not know who or what initiated the DROP TABLE command when executed as SYSTEM.

A Better Way to Grant Permissions

SQL Server 2008 introduced the use of per-service Security Identifiers (SID) to allow permissions to be granted directly to a specific service. This is the method used by SQL Server to grant permissions to the engine and agent services (e.g. NT SERVICE\MSSQL$ and NT SERVICE\SQLAGENT$ respectively). Using this method, those services can access the database engine only when the services are running. This same method can be utilized when granting permissions to other services. Some examples I have used include:

NetBackup services (NT SERVICE\NetBackup Client Service and NT Service\NetBackup Legacy Client Service)
System Center Operations Manager (SCOM) Health Service (NT SERVICE\HealthService)
Windows Server Failover Clustering (WSFC) service (NT SERVICE\ClusSvc)

Some services will require the creation of the service SID using SC.exe. This method has been adopted by Microsoft System Center Operations Manager (SCOM) administrators to grant permission to the HealthService within SQL server.

Create a Service SID

The following command will create a service SID on the NetBackup Client Service. [powershell]sc.exe --% sidtype "NetBackup Client Service" unrestricted[/powershell] Note: --% tells PowerShell to stop parsing the rest of the command. This is particularly useful when using legacy commands and applications.

Query a Service SID

To check a service SID or to ensure a service SID exists, execute the following command. [powershell]sc.exe --% qsidtype "NetBackup Client Service"[/powershell] Note: --% tells PowerShell to stop parsing the rest of the command. This is particularly useful when using legacy commands and applications.

Add a Service SID as a Login

Once the service SID has been created and confirmed, it must be granted permission within SQL Server. This is accomplished by creating a Windows login using either SSMS or a query. The following example creates a login for the NetBackup Client Service using T-SQL: [sql]CREATE LOGIN [NT SERVICE\NetBackup Client Service] FROM WINDOWS GO[/sql] Once the login is created, it can be granted permissions, added to roles, and mapped to databases just like any other login. Note: If the service SID has been created on the service and login failures are still occurring for SYSTEM, ensure the login for the service SID was created and has been permissioned correctly.

Conclusion

In the world we live in it is imperative we limit access to our data, and can track who is accessing it. By limiting SYSTEM's access to the data and utilizing service SIDs, a DBA can accomplish both of these tasks with little to no effort.

Decode PowerShell Command from Running Processes

randomnote_1 — Thu, 14 Dec 2017 20:14:41 GMT

There are times when I've found a PowerShell process running that is taking up a bunch of resources. Sometimes they've even been my own scripts running in the context of a SQL Server Agent Job with a PowerShell job step. Because I can have multiple PowerShell job steps running at a time, sometimes it's difficult to know what the offending job is. The following method can be used to decode a script block that a PowerShell process is currently running.

Create a Long Running Process

To demonstrate this capability, create the following Agent Job. It executes a PowerShell job step that outputs a number every minute for 10 minutes.

USE [msdb]
GO
DECLARE @jobId BINARY(16)
EXEC msdb.dbo.sp_add_job @job_name=N'PowerShell Job', 
    @enabled=1,
    @notify_level_eventlog=0,
    @notify_level_email=2,
    @notify_level_page=2,
    @delete_level=0,
    @category_name=N'[Uncategorized (Local)]',
    @owner_login_name=N'sa'
GO

EXEC msdb.dbo.sp_add_jobserver @job_name=N'PowerShell Job', @server_name = @@SERVERNAME
GO

EXEC msdb.dbo.sp_add_jobstep @job_name=N'PowerShell Job', @step_name=N'PowerShell',
    @step_id=1,
    @cmdexec_success_code=0,
    @on_success_action=1,
    @on_fail_action=2,
    @retry_attempts=0,
    @retry_interval=0,
    @os_run_priority=0,
    @subsystem=N'PowerShell',
    @command=N'
        powershell.exe -Command {
            $i = 1
            while ( $i -le 10 )
            {
                Write-Output -InputObject $i
                Start-Sleep -Seconds 60
                $i++
            }
        }
    ', 
    @database_name=N'master', 
    @flags=0
GO

EXEC msdb.dbo.sp_update_job @job_name=N'PowerShell Job', 
    @enabled=1, 
    @start_step_id=1, 
    @notify_level_eventlog=0,
    @notify_level_email=2, 
    @notify_level_page=2, 
    @delete_level=0, 
    @description=N'', 
    @category_name=N'[Uncategorized (Local)]', 
    @owner_login_name=N'sa', 
    @notify_email_operator_name=N'', 
    @notify_page_operator_name=N''
GO

Execute the Agent Job that was just created.

USE msdb;
GO
EXEC dbo.sp_start_job N'PowerShell Job';
GO

View the Process

Using Task Manager

Launch the Task Manager and select the Details tab.
Scroll down the list to powershell.exe.

Right-click the column headers in Task Manager and click Select Columns.

Check Command Line in the Select columns dialogue and click OK.

Now the parameters that were passed into powershell.exe are visible. However, the command is still obfuscated as an encoded command.

Using PowerShell

Start PowerShell as Administrator. It is vital that PowerShell is running as administrator, otherwise no results will be returned when querying the running processes.
Execute the following command to obtain all of the PowerShell processes that have an encoded command:

$powerShellProcesses = Get-CimInstance -ClassName Win32_Process -Filter 'CommandLine LIKE "%EncodedCommand%"'

The following command creates a custom PowerShell object that contains the process ID and the encoded command.

$commandDetails = $powerShellProcesses | Select-Object -Property ProcessId,
@{
    name       = 'EncodedCommand'
    expression = {
        if ( $_.CommandLine -match 'encodedCommand (.*) -inputFormat' )
        {
            return $matches[1]
        }
    }
}

Now the encoded command can be decoded. The following snippet iterates over the command details object, decodes the encoded command, and adds the decoded command back to the object for further investigation.

$commandDetails | ForEach-Object -Process {
    $currentProcess = $_
    $decodedCommand = [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($currentProcess.EncodedCommand))
    $commandDetails |
        Where-Object -FilterScript { $_.ProcessId -eq $_.ProcessId } |
        Add-Member -MemberType NoteProperty -Name DecodedCommand -Value $decodedCommand
}

The decoded command can now be reviewed by selecting the decoded command property.

$commandDetails[0].DecodedCommand

There it is! Just another neat trick to add to the toolbox.

Install SQL Server 2017 Using PowerShell Desired State Configuration and SqlServerDsc

randomnote_1 — Wed, 13 Dec 2017 16:44:35 GMT

How many times have you clicked through the SQL Server installation interface just clicking the same old buttons, entering the same old information, not giving it much of a second thought? Then the installation finishes and the realization of "I forgot to specify the DBA group in the sysadmins role" hits. Now you have to spend precious time dropping into single-user mode, adding the appropriate users/groups, bringing SQL back up in multi-user mode, and testing. What's worse is now the confidence of the entire installation is shaken. "What else did I forget?" I for one have been in that situation more than once. Enter PowerShell Desired State Configuration (DSC). Using DSC I can build one configuration template that can be reused over hundreds and thousands of servers. Depending on the build, I may have to tweak a few of the setup parameters, but that's not a big deal because I can still keep all of the standard settings in place. The beautiful thing is it eliminates the possibility that will forget to enter an important parameter after spending a sleepless night caring for my kids. In this article I will explore the initial setup of a standalone instance of SQL Server 2017 on Windows Server 2016 using the SqlServerDsc DSC resource. Some prior knowledge of DSC will be helpful as I will not explore the hows and whys of how DSC works. The following items are required for this walkthrough:

A machine running Windows Server 2016
SQL Server 2017 installation media
The SqlServerDsc DSC resource (version 10.0.0.0 is the current release at the time of this writing)

Prerequisites

In most cases DSC will be used to handle the prerequisite requirements. However, for the purposes of this demo, I will handle the prerequisites manually.

Install the SqlServerDsc DSC Resource

The SqlServerDsc DSC resource can be downloaded from the PowerShell Gallery using the Install-Module cmdlet. Note: Ensure PowerShell is running "As Administrator" to install the module.

Install-Module -Name SqlServerDsc

Obtain the SQL Server 2017 Installation Media

Download the SQL Server 2017 installation media to the server. I downloaded SQL Server 2017 Enterprise from my Visual Studio subscription and copied the ISO to "C:\en_sql_server_2017_enterprise_x64_dvd_11293666.iso". Now the ISO must be extracted to a directory.

New-Item -Path C:\SQL2017 -ItemType Directory
$mountResult = Mount-DiskImage -ImagePath 'C:\en_sql_server_2017_enterprise_x64_dvd_11293666.iso' -PassThru
$volumeInfo = $mountResult | Get-Volume
$driveInfo = Get-PSDrive -Name $volumeInfo.DriveLetter
Copy-Item -Path ( Join-Path -Path $driveInfo.Root -ChildPath '*' ) -Destination C:\SQL2017\ -Recurse
Dismount-DiskImage -ImagePath 'C:\en_sql_server_2017_enterprise_x64_dvd_11293666.iso'

Create the Configuration

Configuration

Create the configuration function which will be called to generate the MOF document(s).

Configuration SQLInstall
{...}

Modules

Import the modules into the current session. These tell the configuration document how to build the MOF document(s) and tells the DSC engine how to apply the MOF document(s) to the server.

Resources

.NET Framework

SQL Server relies on the .NET framework, therefore we need to ensure it is installed prior to installing SQL Server. In order to accomplish this, the WindowsFeature resource is utilized to install the Net-Framework-45-Core Windows Feature.

WindowsFeature 'NetFramework45'
{
     Name = 'Net-Framework-45-Core'
     Ensure = 'Present'
}

SqlSetup

The SqlSetup resource is used to tell DSC how to install SQL Server. The parameters required for a basic installation are:

InstanceName - The name of the instance. Utilize MSSQLSERVER for a default instance.
Features - The features to install. In this example I am only installing the SQLEngine feature.
SourcePath - The path to the SQL installation media. In this example I stored the SQL installation media in "C:\SQL2017". A network share can be utilized to minimize the space used on the server.
SQLSysAdminAccounts - The users or groups who are to be a member of the sysadmin role. In this example I am granting the local Administrators group sysadmin access. Note: This configuration is not recommended in a high security environment.

A full list and description of the parameters available on SqlSetup are available on the SqlServerDsc GitHub respository. The SqlSetup resource is odd because it only installs SQL and DOES NOT maintain the settings that are applied. For example, if the SQLSysAdminAccounts are specified at installation time, an admin could add or remove logins from to/from the sysadmin role and the SqlSetup resource wouldn't care. If it is desired that DSC enforces the membership of the sysadmin role, the SqlServerRole resource should be utilized.

Complete Configuration

Configuration SQLInstall
{
     Import-DscResource -ModuleName SqlServerDsc
     node localhost
     {
          WindowsFeature 'NetFramework45'
          {
               Name   = 'NET-Framework-45-Core'
               Ensure = 'Present'
          }

          SqlSetup 'InstallDefaultInstance'
          {
               InstanceName        = 'MSSQLSERVER'
               Features            = 'SQLENGINE'
               SourcePath          = 'C:\SQL2017'
               SQLSysAdminAccounts = @('Administrators')
               DependsOn           = '[WindowsFeature]NetFramework45'
          }
     }
}

Build and Deploy

Compile the Configuration

Dot-source the configuration script:

. .\SQLInstallConfiguration.ps1

Execute the configuration function:

SQLInstall

A directory will be created in the working directory called "SQLInstall" and will contain a file call "localhost.mof". Examining the contents of the MOF will show the compiled DSC configuration.

Deploy the Configuration

To start the DSC deployment of SQL Server, call the Start-DscConfiguration cmdlet. The parameters provided to the cmdlet are:

Path - The path to the folder containing the MOF documents to deploy. (eg. "C:\SQLInstall")
Wait - Wait for the configuration job to complete.
Force - Override any existing DSC configurations.
Verbose - Show the verbose output. This is handy when pushing a configuration for the first time to aid in troubleshooting.

Start-DscConfiguration -Path C:\SQLInstall -Wait -Force -Verbose

As the configuration applies, the Verbose output will show you what is happening and give you a warm and fuzzy feeling that SOMETHING is happening. As long as no errors (red text) are thrown, when "Operation 'Invoke CimMethod' complete." is displayed on the screen, SQL should be installed.

Validate Installation

DSC

The Test-DscConfiguration cmdlets can be utilized to determine if the current state of the server, in this case the SQL installation, meets the desired state. The result of Test-DscConfiguration should be "True".

PS C:\> Test-DscConfiguration
True

Services

The services listing should now return SQL Server services

PS C:\> Get-Service -Name *SQL*
Status  Name           DisplayName
------  ----           -----------
Running MSSQLSERVER    SQL Server (MSSQLSERVER)
Stopped SQLBrowser     SQL Server Browser
Running SQLSERVERAGENT SQL Server Agent (MSSQLSERVER)
Running SQLTELEMETRY   SQL Server CEIP service (MSSQLSERVER)
Running SQLWriter      SQL Server VSS Writer

SQL Server

PS C:\> & 'C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\130\Tools\Binn\SQLCMD.EXE' -S $env:COMPUTERNAME
1> SELECT @@SERVERNAME
2> GO
1> quit

That's a Wrap

And there you have it. Installing SQL Server in a consistent manner has never been easier.

Dynamically Determine a DSC Configuration Name Inside a Configuration

randomnote_1 — Tue, 31 Oct 2017 08:47:11 GMT

I ran across a scenario where I needed to reference the name of the configuration inside the configuration. I was looking for an automatic variable that contained this information, however I was unable to locate one searching online or by asking colleagues. The suggestions I received were to call the Get-PSCallStack cmdlet or use the $MyInvocation automatic variable. To test these options, I created a small config and wrote the output of the options using Write-Verbose.

Get-PSCallStack

Configuration MyConfig
{
    Write-Verbose -Message ( Get-PSCallStack | Format-Table -AutoSize | Out-String )
}

MyConfig -Verbose

VERBOSE:
Command       Arguments
-------       ---------
              {}
Configuration {ArgsToBody=System.Collections.Hashtable, Name=MyConfig, ResourceModuleTuplesToImport=, Body=...
MyConfig      {Verbose=True}
 {}

The configuration name "MyConfig" is the third item in the array, and therefore would be referenced like `(Get-PSCallStack)[2].Command`. Not terribly bad, but not as simple as I would like.

$MyInvocation

Configuration MyConfig
{
    Write-Verbose -Message ( $MyInvocation | Format-List -Property * | Out-String )
}

MyConfig -Verbose

VERBOSE: 

MyCommand             : 
BoundParameters       : {}
UnboundArguments      : {}
ScriptLineNumber      : 7
OffsetInLine          : 1
HistoryId             : 14
ScriptName            : 
Line                  : MyConfig -Verbose
PositionMessage       : At line:7 char:1
                        + MyConfig -Verbose
                        + ~~~~~~~~~~~~~~~~~
PSScriptRoot          : 
PSCommandPath         : 
InvocationName        : 
PipelineLength        : 0
PipelinePosition      : 0
ExpectingInput        : False
CommandOrigin         : Internal
DisplayScriptPosition :

The "Line" property of $MyInvocation contains the full command that was executed. I could use some string manipulation to retrieve the name of the configuration, however Get-PSCallStack is simpler at this point.

$MyTypeName

At this point, Get-PSCallStack looks like the best option, however I was still curious if there is an automatic variable that contains only the configuration name. To investigate the variables available inside the configuration, I executed the following:

Configuration MyConfig
{
    Write-Verbose -Message ( Get-Variable | Where-Object -FilterScript { $_.Value -match '^MyConfig$' } | Out-String )
}

MyConfig -Verbose

VERBOSE:
Name       Value 
----       -----
MyTypeName MyConfig

Success! There is an automatic variable called $MyTypeName that contains only my configuration name. This is the easy button option I was looking for.

Install SQL Server 2017 Using PowerShell Desired State Configuration

randomnote_1 — Tue, 10 Oct 2017 05:00:12 GMT

Update: The xSQLServer DSC resource has been renamed to SqlServerDsc. An updated version of this article has been created and published here.

How many times have you clicked through the SQL Server installation interface just clicking the same old buttons, entering the same old information, not giving it much of a second thought? Then the installation finishes and the realization of "I forgot to specify the DBA group in the sysadmins role" hits. Now you have to spend precious time dropping into single-user mode, adding the appropriate users/groups, bringing SQL back up in multi-user mode, and testing. What's worse is now the confidence of the entire installation is shaken. "What else did I forget?" I for one have been in that situation more than once. Enter PowerShell Desired State Configuration (DSC). Using DSC I can build one configuration template that can be reused over hundreds and thousands of servers. Depending on the build, I may have to tweak a few of the setup parameters, but that's not a big deal because I can still keep all of the standard settings in place. The beautiful thing is it eliminates the possibility that will forget to enter an important parameter after spending a sleepless night caring for my kids. In this article I will explore the initial setup of a standalone instance of SQL Server 2017 on Windows Server 2016 using the xSQLServer DSC resource. Some prior knowledge of DSC will be helpful as I will not explore the hows and whys of how DSC works. The following items are required for this walkthrough:

A machine running Windows Server 2016
SQL Server 2017 installation media
The xSQLServer DSC resource (version 8.1.0.0 is the current release at the time of this writing)

Prerequisites

In most cases DSC will be used to handle the prerequisite requirements. However, for the purposes of this demo, I will handle the prerequisites manually.

Install the xSQLServer DSC Resource

The xSQLServer DSC Resource can be downloaded from the PowerShell Gallery using the Install-Module cmdlet. Note: Ensure PowerShell is running "As Administrator" to install the module.

Install-Module -Name xSQLServer

Obtain the SQL Server 2017 Installation Media

New-Item -Path C:\SQL2017 -ItemType Directory
$mountResult = Mount-DiskImage -ImagePath 'C:\en_sql_server_2017_enterprise_x64_dvd_11293666.iso' -PassThru
$volumeInfo = $mountResult | Get-Volume
$driveInfo = Get-PSDrive -Name $volumeInfo.DriveLetter
Copy-Item -Path ( Join-Path -Path $driveInfo.Root -ChildPath '*' ) -Destination C:\SQL2017\ -Recurse
Dismount-DiskImage -ImagePath 'C:\en_sql_server_2017_enterprise_x64_dvd_11293666.iso'

Create the Configuration

Configuration

Create the configuration function which will be called to generate the MOF document(s).

Configuration SQLInstall
{...}

Modules

Import the modules into the current session. These tell the configuration document how to build the MOF document(s) and tells the DSC engine how to apply the MOF document(s) to the server.

Resources

.NET Framework

WindowsFeature 'NetFramework45'
{
     Name = 'Net-Framework-45-Core'
     Ensure = 'Present'
}

xSQLServerSetup

The xSQLServerSetup resource is used to tell DSC how to install SQL Server. The parameters required for a basic installation are:

InstanceName - The name of the instance. Utilize MSSQLSERVER for a default instance.
Features - The features to install. In this example I am only installing the SQLEngine feature.
SourcePath - The path to the SQL installation media. In this example I stored the SQL installation media in "C:\SQL2017". A network share can be utilized to minimize the space used on the server.
SQLSysAdminAccounts - The users or groups who are to be a member of the sysadmin role. In this example I am granting the local Administrators group sysadmin access. Note: This configuration is not recommended in a high security environment.

A full list and description of the parameters available on xSQLServerSetup are available on the xSQLServer GitHub respository. The xSQLServerSetup resource is odd because it only installs SQL and DOES NOT maintain the settings that are applied. For example, if the SQLSysAdminAccounts are specified at installation time, an admin could add or remove logins from to/from the sysadmin role and the xSQLServerSetup resource wouldn't care. If it is desired that DSC enforces the membership of the sysadmin role, the xSQLServerRole resource should be utilized.

Complete Configuration

Configuration SQLInstall
{
     Import-DscResource -ModuleName xSQLServer
     node localhost
     {
          WindowsFeature 'NetFramework45'
          {
               Name = 'NET-Framework-45-Core'
               Ensure = 'Present'
          }

          xSQLServerSetup 'InstallDefaultInstance'
          {
               InstanceName = 'MSSQLSERVER'
               Features = 'SQLENGINE'
               SourcePath = 'C:\SQL2017'
               SQLSysAdminAccounts = @('Administrators')
               DependsOn = '[WindowsFeature]NetFramework45'
          }
     }
}

Build and Deploy

Compile the Configuration

Dot-source the configuration script:

. .\SQLInstallConfiguration.ps1

Execute the configuration function:

SQLInstall

A directory will be created in the working directory called "SQLInstall" and will contain a file call "localhost.mof". Examining the contents of the MOF will show the compiled DSC configuration.

Deploy the Configuration

To start the DSC deployment of SQL Server, call the Start-DscConfiguration cmdlet. The parameters provided to the cmdlet are:

Path - The path to the folder containing the MOF documents to deploy. (eg. "C:\SQLInstall")
Wait - Wait for the configuration job to complete.
Force - Override any existing DSC configurations.
Verbose - Show the verbose output. This is handy when pushing a configuration for the first time to aid in troubleshooting.

Start-DscConfiguration -Path C:\SQLInstall -Wait -Force -Verbose

Validate Installation

DSC

PS C:\> Test-DscConfiguration
True

Services

The services listing should now return SQL Server services

PS C:\> Get-Service -Name *SQL*
Status Name DisplayName
------ ---- -----------
Running MSSQLSERVER SQL Server (MSSQLSERVER)
Stopped SQLBrowser SQL Server Browser
Running SQLSERVERAGENT SQL Server Agent (MSSQLSERVER)
Running SQLTELEMETRY SQL Server CEIP service (MSSQLSERVER)
Running SQLWriter SQL Server VSS Writer

SQL Server

PS C:\> & 'C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\130\Tools\Binn\SQLCMD.EXE' -S $env:COMPUTERNAME
1> SELECT @@SERVERNAME
2> GO
1> quit

That's a Wrap

And there you have it. Installing SQL Server in a consistent manner has never been easier.