SQL Server 2012 : Enhancing Your Troubleshooting Toolset with Powershell (part 3) - Working Remotely

2.3 Working Remotely

In the first version of PowerShell users were constrained to working on a local computer. This was OK if you had a single computer to manage, but many administrators work with multiple servers in complex computing environments, and it is a major limitation to remote onto each computer in order to use PowerShell. This was recognized and addressed in version 2.0, when WinRM was launched. WinRM is a Windows service that runs on the target computer and allows a remote computer running PowerShell 2.0 to communicate with it and execute PowerShell 2.0 scripts from the local computer.

From an administrator’s perspective, this opens up a wealth of possibilities — from the simplicity of now having a single management computer from which to operate, to being able to construct a full monitoring framework within PowerShell.

To set up PowerShell remoting you must have PowerShell 2.0 installed on all the participating computers. There are a couple of steps that you must perform to have everything running:

PS WSMan:\localhost\Client> Enable-PSRemoting -force
WinRM already is set up to receive requests on this machine.
WinRM has been updated for remote management.
Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on 
this machine.
WinRM firewall exception enabled.

PS C:\> cd wsman:\localhost\client
PS WSMan:\localhost\Client> Set-Item TrustedHosts SQL2012 -Force
PS WSMan:\localhost\Client> Get-Item TrustedHosts
   WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Client
 
Name                      Value
----                      -----
TrustedHosts              SQL2012

After completing these steps you can run remote scripts. You can do this interactively with the New-PSSession cmdlet and then enter the remote session with the Enter-PSSession cmdlet. Alternately, you can invoke scripts on the remote machine with the Invoke-Command cmdlet. I like to test the remote session using Invoke-Command and request the hostname to ensure that I’ve connected to the remote computer correctly, as shown in the following example:

Invoke-Command -Session $sessions –ScriptBlock {Hostname}

2.4 What’s New in SQL Server 2012

Prior to SQL Server 2012, the SQL Server team created a PowerShell mini-shell called SQLPS. This has changed in SQL Server 2012; SQLPS is now a standard PowerShell 2.0 host and imports the SQLPS module. This makes life a lot easier if you are already using a standard PowerShell host because you too can use import-module SQLPS and SQLASCMDLETS to gain all the SQL Server provider functionality within another PowerShell host.

SQL Server 2012 ships with the following 40 cmdlets:

Of these cmdlets, 22 are for managing the new High Availability features and Analysis Services. The other notable cmdlets from a troubleshooting and performance perspective are for backup and restore. SQL Server Backup and Restore cmdlets are a welcome addition to SQL Server 2012; previously, as a script author you had two options:

• Invoke-SQL and write T-SQL that you execute from a PowerShell script.
• Load the SMO objects and use the backup and restore functionality provided through the SMO library. This was my preferred approach but it requires a significant scripting effort, somewhere in the neighborhood of 20–50 lines of script to handle a typical backup or restore scenario.

Backup-SqlDatabase

The following script shows how simple database backups can be using the SQL Provider and the new Backup-SqlDatabase script to iterate through all the databases, creating a folder for each one and then generating a backup based on a timestamp (code file: PS_SQLBackup01.PS1):

foreach($database in (Get-ChildItem))
{
    $dbName = $database.Name
    $timeStamp = Get-Date -FORMAT yyyyMMddHHmmss
    $backupFolder = "c:\backups$dbName"
 
    if((Test-Path $backupFolder) -eq $False)
    {
        New-Item -type directory -path $backupFolder
    }
 
    Backup-SqlDatabase -Database $dbName -BackupFile "$backupFolder$dbName-
    $timeStamp.bak"
}

Restore-SqlDatabase

The new cmdlets also make restoring a database very straightforward. The following script demonstrates how to restore the Adventure Works database:

Restore-sqldatabase -Database AdventureWorks '
-BackupFile "C:\Backups\AdventureWorks\AdventureWorks-20120220005537.bak"

You may notice the “`” character after AdventureWorks. This is not a mistake or a typo. It is a continuation character; which means that you can type a line in the PowerShell command line, press return, and PowerShell will continue accepting input for the previous line. This is very useful when single statements become too long to read comfortably.

More than 40 parameters are available for Restore-SqlDatabase, enabling the creation of some very complex restore scripting. Anything that is possible within the SQL Server Management Studio user interface or through T-SQL is available here, with the added benefit of simple file management. This makes complex restores using multiple files, such as restoring many log files, a relative breeze.