loginServer.ps1<\/span> script, shown below, is the one I use to connect to a SQL Server instance when I need to do some management operations.<\/p>\n<\/pre>\nparam($server, $user, $password)
$conn = SMO_ServerConnection
$conn.ServerInstance = $server
$conn.ConnectAsUserName = $user
$conn.ConnectAsUserPassword = $password
$conn.ConnectAsUser = $true
$conn.ApplicationName =”Ad hoc Management”
$conn.WorkstationID = $ENV:ComputerName
$conn.MinPoolSize=1
$conn.PooledConnectionLifetime=3600
$conn.AutoDisconnectMode=’NoAutoDisconnect’
$server = SMO_Server $conn<\/p>\n
I run this script as follows (be sure to run initPowerSMO.ps1<\/span> before trying this):<\/p>\n<\/pre>\nPS C:\\SimpleTalk>. .\\loginServer.ps1 CANOPUS5 ‘SqlAdmin’ ‘P@ssw0rd’<\/p>\n
Be sure to include the “. ” at the beginning of the command line. This script adds a $conn<\/span> and a $server<\/span> variable to the context in which you run it. The script uses SMO_ServerConnection<\/b> make the $conn<\/span> variable, which specifies how the connection is to be made, and then passes $conn<\/span> to SMO_Server to create the $server<\/span> variable.<\/p>\nNOTE<\/b>:
This script seems to be using some new functions; <\/i>SMO_ServerConnection<\/span><\/i> and <\/i>SMO_Server<\/span><\/i>. These are not really new functions that are just making use of a feature of PowerShell that can save you some typing. You can skip typing the “<\/i>get-<\/span><\/i>” prefix for a command as long as it does not produce a conflict with some other command, so <\/i>SMO_Server<\/span><\/i> is the equivalent of <\/i>get-SMO_Server<\/span><\/i>.<\/i><\/p>\nThe loginServer.ps1<\/span> script starts by creating an empty ServerConnection and follows this by filling out the pertinent information for the connection. It gets the server instance name, user name, and password from the command line. It fills out the ApplicationName<\/span> and WorkstationID<\/span> to make it easier to identify this connection; we will make use of this shortly.<\/p>\nThe $conn.ConnectAsUser = $true<\/span> part of the script is what is making SMO impersonate a Windows user, using ConnectAsUserName<\/span> and ConnectAsUserPassword<\/span> when connecting to SQL Server. The $true<\/span> variable is a built-in variable that returns a Boolean true value; likewise $false<\/span> returns a Boolean false value.<\/p>\nThe $ENV:ComputerName<\/span> is a special built-in variable of PowerShell. Any variable that starts with a $ENV<\/span>: prefix accesses the Windows environment variable whose name makes up the suffix of the variable name. In this case the name of the computer the script is running on is accessed. <\/p>\nWhen performing management operations, my preference is to make sure there is a ready-to-go connection in the pool while I am working, which is why the minimum connection pool size is set to one.<\/p>\n
The end of the loginServer.ps1<\/span> creates a $server<\/span> using $conn<\/span> to initialize it.<\/p>\nSQL Login <\/h2>\n
You can also use a ServerConnection to connect using a SQL Server login. The loginSeverSql.ps1<\/span> script, shown below, does this.<\/p>\n<\/pre>\nparam($server, $user, $password)
$conn = SMO_ServerConnection
$conn.ServerInstance = $server
$conn.LoginSecure = $false;
$conn.Login = $user
$conn.Password = $password
$conn.ConnectAsUser = $false
$conn.ApplicationName =”Ad hoc Management”
$conn.WorkstationID = $ENV:ComputerName
$conn.MinPoolSize=1
$conn.PooledConnectionLifetime=3600
$conn.AutoDisconnectMode=’NoAutoDisconnect’
$server = SMO_Server $conn<\/p>\n
The $conn.LoginSecure = $false<\/span> and $conn.ConnectAsUser=$false<\/span> part of the script is what is making SMO use a SQL login instead of a Windows login.<\/p>\nChecking activities <\/h2>\n
A fairly common management task is to find out which activities are running on a server. In fact SSMS (SQL Server Management Studio) has a Management->Activity Monitor for just this purpose. You can get equivalent functionality from PowerSMO using a SMO_Server to enumerate the processing running on a SQL Server instance, as shown below:<\/p>\n
<\/pre>\nPS C:\\SimpleTalk >$server = SMO_Server EARTH5
PS C:\\SimpleTalk >$server.EnumProcesses()
| format-table -property Spid,Program,Host,Command -autosize
Spid Program Host Command
—- ——- —- ——-
1 RESOURCE MONITOR
2 LAZY WRITER
3
4 LOCK MONITOR
5 SIGNAL HANDLER
6 TASK MANAGER
7 TRACE QUEUE TASK
8
9 BRKR TASK
10 TASK MANAGER
11
12 TASK MANAGER
13 TASK MANAGER
14 TASK MANAGER
15 TASK MANAGER
16 TASK MANAGER
17 TASK MANAGER
18 TASK MANAGER
19 TASK MANAGER
20 BRKR EVENT HNDLR
21 BRKR TASK
22 BRKR TASK
23 TASK MANAGER
24 TASK MANAGER
51 Microsoft SQL Server Management Studio EARTH5
52 Ad hoc Management EARTH5 SELECT <\/p>\n
A SMO_Server has a function, EnumProcesses<\/span>, which lists all of the processes running on its instance of SQL Server. We are piping those results to the built-in cmdlet, format-table<\/span>. This outputs a row for each process passed into it so that the results look like at table with column per property of the process. We didn’t want to see all of the properties, so we used the –property<\/span> parameter of format-table<\/span> to restrict the results to just the Spid, Program, Host, and Command properties of the process. The –autosize<\/span> makes each column as narrow as possible.<\/p>\nNOTE<\/b>:
The <\/i>Format-table<\/span><\/i> cmdlet, and its companion cmdlet <\/i>format-list<\/span><\/i>, are very useful. You can type <\/i>help format-list -full<\/span><\/i> to see all of their capabilities.<\/i><\/p>\nWe can see that there are quite a few system processes running along with two connections from my machine, EARTH5. SSMS is running on SPID 51 and our “Ad hoc Management” PowerSMO is running on SPID 52. The ApplicationName<\/span> we set in the loginSever.ps1<\/span> script appears as the Program<\/span> in the properties of a process. The WorkstationID appears as the Host.<\/p>\nWell, now that we have PowerSMO we won’t need SSMS anymore so let’s kill its connection to the server. That is shown next.<\/p>\n
<\/pre>\nPS C:\\SimpleTalk >$server.KillProcess(51)<\/p>\n
Now let’s check to see if SSMS still has a connection, as shown below<\/p>\n
<\/pre>\nPS C:\\SimpleTalk >$server.EnumProcesses($true)
| format-table -property Spid,Program,Host,Command -autosize
LogonUser succedded<\/p>\n
Spid Program Host Command
—- ——- —- ——-
51 Ad hoc Management EARTH5 SELECT<\/p>\n
We didn’t need to list all of the system processes to check the status of the SSMS connection. Passing a $true<\/span> into the EnumProcesses<\/span> function limits it to user processes. Here, we can see that Spid 52 is no longer running.<\/p>\nMonitoring activities <\/h3>\n
One of the nice things about the SSMS Activity Monitor is that you can configure it to poll the status of the server every few seconds to get a sort of real time display. The script, ActivityMonitor.ps1, shown next, works in a similar way.<\/p>\n
<\/pre>\nparam($server, $user, $password)
$local:conn = SMO_ServerConnection
$local:conn.ServerInstance = $server
$local:conn.ConnectAsUserName = $user
$local:conn.ConnectAsUserPassword = $password
$local:conn.ConnectAsUser = $true
$local:conn.ApplicationName =”Ad hoc Management”
$local:conn.WorkstationID = $ENV:ComputerName
$local:conn.NonPooledConnection = $true
$local:server = SMO_Server $conn
while($true)
{
$local:server.EnumProcesses($true) |
format-table -property Spid,Program,Host,Command -autosize;
[System.Threading.Thread]::Sleep(10000)
if([System.Console]::KeyAvailable)
{
break;
}
}<\/p>\n
The results of running it are shown below. About every ten seconds the script polls the CANOPUS5 server to see what non-system processes it is running. Between the second and third pass I started up SSMS.<\/p>\n
<\/pre>\nPS C:\\Simpletalk > .\\ActivityMonitor.ps1 EARTH5 SqlAdmin P@ssw0rd<\/p>\n
Spid Program Host Command
—- ——- —- ——-
51 Ad hoc Management EARTH5 SELECT<\/p>\n
Spid Program Host Command
—- ——- —- ——-
51 Ad hoc Management EARTH5 SELECT<\/p>\n
Spid Program Host Command
—- ——- —- ——-
51 Ad hoc Management EARTH5 SELECT
52 Microsoft SQL Server Management Studio EARTH5<\/p>\n
The ActivityMonitor.ps1<\/span> script starts in way similar to the way that loginServer.ps1<\/span> does, it just makes a Server that is connected to the SQL instance you want to monitor. However, there are a couple of differences. Firstly, it is creating $local:conn<\/span> and $local:server<\/span> variables. When a variable has a “$local:<\/span>” prefix it is local to the PowerShell context in which it is run, which prevents it from interfering with the variables in the PowerShell that invoked it. Secondly, $local:conn.NonPooledConnection=$true<\/span>, which means it gets its own connection rather than using one from the pool.<\/p>\nAfter the $local:server<\/span> variable has been created the script creates an infinite loop that is broken after you press a key on the keyboard. PowerShell can use any capability provided by .NET, so we make use of a static property of the System.Console class to see if a key has been typed. In the previous PowerSMO article we learned that when PowerShell sees text inside of square brackets it interprets it as a type definition. A type definition followed by “::” means “access a static member of the type”. So [System.Console<\/span>]::KeyAvailable<\/span> accesses the static KeyAvailable<\/span> property of the System.Console<\/span> class in .NET.<\/p>\nInside this loop, PowerSMO runs the same command we used earlier to enumerate the processes running on SQL Server. It follows the command by a ten second delay. The static Sleep<\/span> method of the System.Threading.Thread<\/span> class provides a delay specified in milliseconds.<\/p>\nChoosing process properties <\/h3>\n
The Spid, Program, Host, and Command properties of a SQL Server process are fairly common things to monitor, but you might want to choose a different set. The script, ActivityMonitorSel.ps1<\/span>, shown below, is an enhancement to ActivityMonitor.ps1<\/span> that allows the properties to be specified on the command line.<\/p>\n<\/pre>\nparam($server, $user, $password, $properties)
$local:conn = SMO_ServerConnection
$local:conn.ServerInstance = $server
$local:conn.ConnectAsUserName = $user
$local:conn.ConnectAsUserPassword = $password
$local:conn.ConnectAsUser = $true
$local:conn.ApplicationName =”Ad hoc Management”
$local:conn.WorkstationID = $ENV:ComputerName
$local:conn.NonPooledConnection = $true
$local:server = SMO_Server $conn
$local:conn.Connect()
while($true)
{
$local:server.EnumProcesses($true) |
format-table -property $properties -autosize
[System.Threading.Thread]::Sleep(10000)
if([System.Console]::KeyAvailable)
{
break;
}
}<\/p>\n
This script has modified ActivityMonitor.ps1<\/span> in two ways; it adds the $properties<\/span> argument to the script and it uses that argument in the format-table cmdlet.<\/p>\nWe use this script as follows (the first two lines are actually a single line):<\/p>\n
<\/pre>\nPS C:\\SimpleTalk> .\\ActivityMonitorSel.ps1 CANOPUS5
SqlAdmin P@ssw0rd spid, cpu, status, memusage<\/p>\n
Spid Cpu Status MemUsage
—- — —— ——–
51 0 1
52 187 1
53 0 running 1<\/p>\n
Spid Cpu Status MemUsage
—- — —— ——–
52 187 1
53 0 running 1<\/p>\n
After the password on the command line, we passed in the properties that we wished to monitor, as a comma-separated list. Up until now we have been careful to separate arguments by spaces, not commas. PowerShell treats a sequence of values separated by commas as a single argument. The argument itself is an array with an entry for each of the comma separated values.<\/p>\n
The format-table<\/span> cmdlet interprets an array after -property as the list of properties it should display. In fact, if you look at how we specified the properties when we first used format-table<\/span> they were in the form of a comma separated list. PowerShell turned this into an array and then passed it to the format-table<\/span> cmdlet.<\/p>\nChoosing user processes <\/h3>\n
Let’s make one more change to our activity monitor script so that we can use another feature of PowerShell, namely default arguments. Below are the changes we need to make in order to turn ActivityMonitorSel.ps1<\/span> into ActivityMonitorOpt.ps1<\/span>, which allows us to select whether or not we want to monitor system processes.<\/p>\n<\/pre>\nparam($server, $user, $password, $properties, $userOnly = $true)
…
$local:server.EnumProcesses($userOnly) |
format-table -property $properties -autosize<\/p>\n
We have added a $userOnly<\/span> argument and specified its default value as $true<\/span>. If we don’t include this value on the command line then ActivityMonitorOpt.ps1<\/span> will produce the same output as ActivityMonitorSel.ps1<\/span>. We can see this below (the first two lines are a single line):<\/p>\n<\/pre>\nPS C:\\SimpleTalk> .\\ActivityMonitorOpt.ps1 CANOPUS5
SqlAdmin P@ssw0rd spid, cpu, status, memusage
Spid Cpu Status MemUsage
—- — —— ——–
51 0 running 1<\/p>\n
However if we include the $false<\/span> value on the command line we will get all the processes, including the system processes (the first two lines are a single line):<\/p>\n<\/pre>\nPS C:\\SimpleTalk> .\\ActivityMonitorOpt.ps1 CANOPUS5<\/p>\n
SqlAdmin P@ssw0rd spid, cpu, status, memusage $false
Spid Cpu Status MemUsage
—- — —— ——–
1 0 background 0
2 0 background 0
3 0 0
…
20 0 background 0
21 0 background 0
22 0 background 0
23 0 sleeping 0
51 0 1
52 0 1
53 0 running 1<\/p>\n
Standalone scripts <\/h2>\n
So far we have been running our scripts inside of a PowerShell that has run the initPowerSMO.ps1<\/span> script. There are a couple of issues with this. One is that initPowerSMO.ps1<\/span> is really just meant to be used for tutorial purposes and has not been put through the kind of testing that something used in a production environment requires. Another is that it takes quite a long time to run… if all you want to do is a quick activity check you wouldn’t want to wait for the 20 or more seconds for it to start.<\/p>\nTo see how to make our scripts standalone, i.e.<\/i> run without first running initPowerSMO.ps1<\/span>, we have to look at how a command like get-SMO_Server<\/span> works. Look at the line below:<\/p>\n<\/pre>\n$server = get-SMO_Server CANOPUS5<\/p>\n
In effect, when the script is run this line is converted to:<\/p>\n
<\/pre>\n$server = new-object
“Microsoft.SqlServer.Management.Smo.Server” CANOPUS5<\/p>\n
The new-object command makes a new instance of a Microsoft.SqlServer.Management.Smo.Server<\/b> object and passes the string “CANOPUS5” to the constructor it uses to do this. To convert the ActivityMonitorOpt.ps1<\/span> script to a standalone version, named ActivityMonitorSA.ps1<\/span>, the first thing we have to do is to replace the SMO_ServerConnection and SMO_Server as is shown below.<\/p>\n<\/pre>\n$local:conn = new-object
“Microsoft.SqlServer.Management.Common.ServerConnection”
…
$local:server = new-object
“Microsoft.SqlServer.Management.Smo.Server” $conn<\/p>\n
It turns out that is not enough. By default, PowerShell only loads a few .NET assemblies, the most common ones. In order for our standalone script to work we must load the SMO assemblies. If you look at the initPowerSMO.ps1<\/span> script you will see that it starts by loading the SMO assemblies:<\/p>\n<\/pre>\n[System.Reflection.Assembly]::Load(“Microsoft.SqlServer.Smo,
Culture=Neutral,Version=9.0.242.0,
PublicKeyToken=89845dcd8080cc91″)
| out-null
[System.Reflection.Assembly]::Load(“Microsoft.SqlServer.ConnectionInfo,
Culture=Neutral,Version=9.0.242.0,
\t\t\t\t PublicKeyToken=89845dcd8080cc91″)
\t\t\t\t | out-null
[System.Reflection.Assembly]::Load(“System.Data,Culture=Neutral,
\t\t\t\t Version=2.0.0.0,
\t\t\t\t PublicKeyToken=b77a5c561934e089″)
\t\t\t\t | out-null
[System.Reflection.Assembly]::Load(“Microsoft.SqlServer.SqlEnum,
\t\t\t\t Culture=Neutral,Version=9.0.242.0,
\t\t\t\t PublicKeyToken=89845dcd8080cc91″)
| out-null<\/p>\n
We will save the details of how this loads the needed assemblies for a later article; for now all we will do is make sure that this is part of any standalone assembly. The beginning of our ActivityMonitorSA.ps1<\/span> script now looks like:<\/p>\n<\/pre>\nWith this modification, ActivityMonitorSA.ps1<\/span> will run without needing to first run initPowerSmo.ps1<\/span>. One of the nice things about a standalone PowerSMO assembly like this is that it can be run directly from a Windows command shell command line, as shown below. You will also notice that this starts much faster than running initPowerSMO.ps1<\/span>.<\/p>\n<\/pre>\nC:\\SimpleTalk>PowerShell .\\ActivityMonitorSA.ps1 CANOPUS5
\t\t\t SqlAdmin P@ssw0rd spid
,program<\/p>\n
Spid Program
—- ——-
51 Ad hoc Management
52 Ad hoc Management
53 Ad hoc Management
54 Ad hoc Management<\/p>\n
Converting to standalone scripts <\/h3>\n
So, the way to create your standalone scripts is first to get them working using all the PowerSMO functions like get-SMO_Server, and then to convert the script to using new-object and the class names that correspond to the PowerSMO functions. To do this you will have to know the full name of the classes that SMO functions are using. You can look these up in BOL, but you’ll find it is easier to just ask PowerShell to tell you what the full names are. For every PowerSMO function like get-SMO_Server<\/span> there is a corresponding function named get-SMOT_Server<\/span> that returns the type definition the function uses. This can be used to get the full name of the type, as shown in the example below.<\/p>\n<\/pre>\nPS C:\\SimpleTalk> (get-SMOT_Server).FullName
Microsoft.SqlServer.Management.Smo.Server
PS C:\\SimpleTalk><\/p>\n
Automatic conversion to standalone scripts <\/h3>\n
PowerShell is a full-fledged scripting engine so we might as well just write a script that will automatically convert an initPowerSMO.ps1<\/span> based script to a standalone one.<\/p>\nTo get started we will need a script that can convert something like:<\/p>\n
<\/pre>\nget-SMO_Server<\/span> or SMO_Server<\/span><\/p>\ninto:<\/p>\n
<\/pre>\nnew-object “Microsoft.SqlServer.Management.Smo.Server”<\/span><\/p>\nThe following script, in replace.ps1<\/span>, can do that:<\/p>\n<\/pre>\nparam ([String]$smo_fcn)
$t = $smo_fcn.Insert($smo_fcn.IndexOf(‘SMO’)+3, ‘T’)
$c = (&$t).FullName
“new-object “”$c”””<\/p>\n
This script inserts a “T” after the SMO in the input string, which makes the function name that returns the type definition for the function. You can execute a string in PowerShell by prefacing it with a “&<\/span>” character; think dynamic SQL… you’ve done this before. This returns the type definition from which we extract the full name. Lastly we preface the full name of the class with new-object<\/span> and return the result. Some examples of its usage shown below:<\/p>\n<\/pre>\nPS C:\\SimpleTalk> .\\replace.ps1 SMO_Server
new-object “Microsoft.SqlServer.Management.Smo.Server”
PS C:\\SimpleTalk> .\\replace.ps1 get-SMO_Server
new-object “Microsoft.SqlServer.Management.Smo.Server”<\/p>\n
To do an automatic conversion we must find all of the SMO functions in a script and replace them with an equivalent new-object<\/span>. We can use the regular expression support built into PowerShell to do this. The –match<\/span> operator in PowerShell uses a regular expression to find patterns in strings, as shown below.<\/p>\n<\/pre>\nPS C:\\SimpleTalk> ‘$local:conn=SMO_ServerConnection’ | %{$_ -match “SMO_\\w*”}
True
PS C:\\SimpleTalk> $matches.Values
SMO_ServerConnection<\/p>\n
The –match<\/span> returns a Boolean true if any patterns were found in the input it tested. It also fills the built-in $matches<\/span> variable with an array of all of the patterns that matched it. As is shown above, the Values<\/b> property of the $matche<\/b>s variable contains the SMO functions from the input string.<\/p>\nThe get-content cmdlet will parse a text file into individual lines. To use it to do this, the path to the file is passed to the -path property of get-content. The makeSA.ps1<\/span> script, shown below, uses get-content to parse a file into lines, and then replaces each SMO functions with its new-object<\/span> equivalent, i.e.<\/i> it creates a standalone version of the input script.<\/p>\n<\/pre>\nparam ($file)
$assemblies =
‘
[System.Reflection.Assembly]::Load(“Microsoft.SqlServer.Smo,
\t\t\t\tCulture=Neutral,Version=9.0.242.0,
\t\t\t\tPublicKeyToken=89845dcd8080cc91″)
\t\t\t\t| out-null
[System.Reflection.Assembly]::Load(“Microsoft.SqlServer.ConnectionInfo,
\t\t\t\tCulture=Neutral,Version=9.0.242.0,
\t\t\t\tPublicKeyToken=89845dcd8080cc91″)
\t\t\t\t| out-null
[System.Reflection.Assembly]::Load(“System.Data,Culture=Neutral,
\t\t\t\tVersion=2.0.0.0,
\t\t\t\tPublicKeyToken=b77a5c561934e089″)
\t\t\t\t| out-null
[System.Reflection.Assembly]::Load(“Microsoft.SqlServer.SqlEnum,
\t\t\t\tCulture=Neutral,Version=9.0.242.0,
\t\t\t\tPublicKeyToken=89845dcd8080cc91″)
| out-null
‘
$assembliesIncluded = $false;
get-content -path $file |
%{
if($_ -match “SMO_\\w*”)
{
if(!$assembliesIncluded)
{
$assemblies
$assembliesIncluded = $true
}
foreach($m in $matches.Values)
{<\/p>\n
$t = $m.Insert($m.IndexOf(‘SMO’)+3, ‘T’)
$c = (&$t).FullName
$r = “new-object “”$c”””
$_ = $_.Replace($m, $r)
}
}
$_
}<\/p>\n
The file path is passed into the script in the $file<\/span> argument. The $assemblies<\/span> variable holds the instructions that will load the assemblies that SMO requires. The $assembliesIncluded<\/span> variable is a marker used so that the assemblies are loaded only once.<\/p>\nNext the get-content<\/span> cmdlet is used to pipe the lines of the input file into a script block. The script block uses –match<\/span> find all the SMO functions in the line. If the line does include any SMO functions they are replaced using the script we looked at earlier, replace.ps1<\/span>. Lastly the input line, with any SMO function replaced, is output.<\/p>\nBelow is an example of using makeSA.ps1<\/span> to convert ActivityMonitorOpt.ps1<\/span> into a standalone script named AM_Standalone.ps1<\/span>:<\/p>\n<\/pre>\nPS C:\\SimpleTalk> .\\makeSA.ps1 .\\ActivityMonitorOpt.ps1
\t\t\t\t| out-file AM_Standalone.ps1<\/p>\n
The out-file<\/span> cmdlet is used to pipe the result of the makeSA.ps1<\/span> to a file. We can test things out by running AM_Standalone.ps1<\/span> in a new instance of PowerShell that has not had intiPowerSMO.ps1<\/span> run in it, as shown below.<\/p>\n<\/pre>\nPS C:\\SimpleTalk> .\\AM_Standalone.ps1 CANOPUS5
\t\t SqlAdmin P@ssw0rd spid, program<\/p>\n
Spid Program
—- ——-
51 Ad hoc Management
52 Ad hoc Management<\/p>\n
Here we see that AM_Standalone.ps1<\/span><\/b> worked without first running initPowerSMO.ps1<\/span> and ran immediately.<\/p>\nConclusion <\/h2>\n
We started off by looking at how we can control the identity that SMO uses to login to SQL Server. Next, we built an activity monitor that gave us capabilities similar to those provided by the SSMS Activity Monitor.<\/p>\n
The initPowerSMO.ps1<\/span> script creates a shell in which we can easily interact with and exploit all the features of SMO, but it really isn’t really practical for production management scripts. However, we can automatically convert any script we write that uses the PowerSMO functions to an equivalent one that does not depend on the initPowerSMO.ps1<\/span> script.<\/p>\nSo, we can use a PowerShell initialized with initPowerSMO.ps1<\/span> in an ad hoc<\/i> and development environment, but we make standalone scripts for production use.<\/p>\nSome of the topics in this article are covered in the Pluralsight.com <\/em>Applied SQL Server 2005<\/em><\/a> course.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"In part 3 of Dan Sullivan’s in-depth exploration of PowerSMO, the versatile command line utility for managing SQL Server databases, he describes how to control the identity that SMO uses to login to SQL Server, how to set up Server activity monitoring, and how to create standalone PowerSMO scripts, suitable for use in a production environment.…<\/p>\n","protected":false},"author":221818,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143527],"tags":[4168,4170,4659,4658,4638,4364,4637,4657,4701,4336,4179,4150,4151,4702],"coauthors":[],"class_list":["post-235","post","type-post","status-publish","format-standard","hentry","category-database-administration-sql-server","tag-database","tag-database-administration","tag-dba","tag-functions","tag-managing-sql-server","tag-monitoring","tag-powersmo","tag-scripts","tag-server-activity-monitor","tag-smo","tag-source-control","tag-sql","tag-sql-server","tag-sql-server-logins"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/235","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/221818"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=235"}],"version-history":[{"count":3,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/235\/revisions"}],"predecessor-version":[{"id":39797,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/235\/revisions\/39797"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=235"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=235"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=235"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=235"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}