As I mentioned earlier in this series, it is possible to use the SQL Server Agent to execute PowerShell scripts. If you’ve worked with the SQL Server Agent to run jobs on your server, you already know that whenever you define a job step, you have to define a job step “type”. In SQL Server 2008 (and later), when you create a new job step, and click on the Type drop down, you see the following menu.
The most frequently used step types are T-SQL and the SQL Server Integration Services Package; however, you can see now that we have the PowerShell type. Selecting this tells the SQL Agent to invoke the SQLPS environment to run whatever commands are entered in the job step.
This screenshot simply shows the Job Step dialog box with some sample PS code. One thing to be very cognizant of: When creating a PowerShell job step, there is only one security context available, which is the “SQL Server Agent Service Account”. That means that if you intend to execute PowerShell scripts/commands from SQL Agent Job steps, the service account that the SQL Server Agent is running as must have appropriate permissions. This includes access to the folder where the scripts actually live, as well as any output directories. This also means that the you have to set the signing and restriction permissions on the SQL Server itself (as discussed earlier in this series). Once all of that is done, getting the SQL Server Agent Job setup to run your script is just like creating any other SQL Agent Job.
There’s one other “gotcha” to keep in mind. Everytime a SQL Agent Job step executes PowerShell code, it opens it own SQLPS.exe process. This process alone consumes about 20MB of memory (not counting any work its doing). If you have a server executing quite a few PowerShell job steps, this could get ugly. Be sure to keep tabs on how many PowerShell job steps are running on a server; try to avoid running too many of these types of jobs on very busy production servers. In fact, since the primary use for PowerShell for most DBAs is administrative in nature, try to use a “Admin” server for your PowerShell jobs. This will help logically separate the workload as well as prevent SQLPS.exe processes from using precious memory on your production SQL Servers.
That’s it; you can use many of the scripts and commands discussed in this series to create jobs to help you manage your servers, gather information, and keep you informed on your environment.
In my last post, we talked about using some simple cmdlets in SQLPS to explore policy objects in a SQL Server. Now, let’s look at a couple of practical examples of using policies from the PowerShell environment.
First off, you’re very likely going to want to be able to evaluate policies against a server. Conveniently, there’s a cmdlet for this, Invoke-PolicyEvaluation. This cmdlet takes a policy and evaluates a specified target server, and outputs the result. The syntax for this cmdlet is:
Invoke-PolicyEvaluation [-Policy] <PSObject> [-AdHocPolicyEvaluationMode <AdHocPolicyEvaluationMode>] -TargetServerName <PSObject> [-TargetExpression <String>] [-OutputXml] [<CommonParameters>]
Invoke-PolicyEvaluation [-Policy] <PSObject> [-AdHocPolicyEvaluationMode <AdHocPolicyEvaluationMode>] -TargetObjects <PSObject[]> [-OutputXml] [<CommonParameters>]
You can see here that it takes a policy (either explicitly or from a file), the evaluation mode (audit or enforce), a target server, an optional expression for the policy to use (more on this later), and a location to output the results. Finally, it’ll take one of the following two parameters:
These two parameters are mutually exclusive. There’s also support for the common parameters that all cmdlets accept, i.e. Verbose, Debug, etc. If you need to see these parameters at any time, remember you can always get the detailed list by issuing get-help Invoke-PolicyEvaluation –detailed.
Using Invoke-PolicyEvaluation is fairly simple; if you have your policies (in XML format, which you can just right-click and export from SSMS) in a folder, you can simply change your working location to that folder and execute the policy:
#use sl (set-location cmdlet) and go to the default policy location
sl "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Policies\DatabaseEngine\1033"
Invoke-PolicyEvaluation -Policy "Some Policy.xml" -TargetServer "MyServer"
The results are then output to the console. If you want to run multiple policies, you can literally pass them in as a comma separated list (i.e. –Policy “Some Policy.xml”, “Some Other Policy.xml”)
However, once you’ve started using policies, you’ll have more than 1 or 2 to evaluate. So, you could pass a list of policies into Invoke-PolicyEvaluation using the Get-ChildItem command and a pipe (from within a directory containing XML formatted policy files):
Get-ChildItem | Invoke-PolicyEvaluation -TargetServer "MyServer"
Using Get-ChildItem cycles the list of policies in the directory, and then hits the server specified. When you combine this with the out-file cmdlet, you can pass in a list of policies, evaluate them against a server, and then output the results for perusal later.
Finally, let’s talk automation: As of SQL Server 2008, the SQL Server Agent supports the PowerShell job step type. Using this, you could actually build a job on each server (or one central server) to run your policy evaluations and output the results to a central repository. Here’s what the job step would look like:
This evaluates all of the policies in the default directory (obviously most of us will use a custom list) against my server, and then outputs the results. On my machine, here is a sample of the results:
The true power here is that you could evaluate policies against SQL 2000 and SQL 2005 servers (where applicable). You could centralize policy management for all servers in a single location, and start reporting on the results regularly. You could even import the results into SQL Server, and use a Reporting Services report! There’s a lot of power here, so explore and see what you can come up with. Have fun!
In my last post we discussed creating a script that can retrieve configuration settings from a list of SQL Servers and place that data into a SQL Server table. Now, let’s take a look at another technology in SQL Server; Policy Based Management.
As part of the SQL Server Management Objects (SMO), DBAs have access to the wonderful world of policies. From here, we can assess the condition of our server configurations, as well as create policies to enforce business specific configurations and apply those policies across our entire environment. And fortunately, we can use PowerShell to help us along.
NOTE: This post won’t be an in-depth discussion of Policy Based Management (PBM), but will touch on aspects related to managing PBM. If you aren’t familiar with PBM, you should check out the Books Online entry, as well as some searches on Google, to get caught up to speed on this cool new feature.
Now, in this post, we’ll look at commands that can help us look at the policies (and related objects).
First, we’ll want to see what we’ve got out on our server. From the SQLPS command line, change to the SQLPolicy directory. You can see a list of the directories available by using the good old fashion command line command DIR.
You can see the SQLPolicy folder. So, issue a change directory command (cd SQLPolicy):
Now you can see the MachineName. You’ll need to cd to that, as well as to the instance you wish to look at:
Here we are; the policy folders! Notice that you can explore all of the objects related to policies, including facets (under the ObjectSets folder), conditions, and categories.
Now, want to see the policies on the instance? Again, just list the contents:
Well, you can see the policy there, but its cutoff. So let’s list the contents a little differently, using the correct cmdlet for the job, Get-ChildItem (in PS, dir is really just an alias for Get-ChildItem). We’ll use the –Name parameter to just show us the name(s):
As you can now see, this is much easier to read. Using this simple navigation you can quickly see what policies have been installed. Remember, if you want to save the list for later use, you could always pipe the output to a text file using the Out-File cmdlet:
Get-ChildItem –Name | Out-File C:\MyPath\MyPolicies.txt
That’s about it for this post. In the next post, we’ll look at actually evaluating policies. Until then, have fun!
My last few blog posts have dealt with the basics of setting up PowerShell and creating a script. The remainder of the posts in this series will cover a few specific areas where PowerShell scripting can help a DBA/SQL Server Administrator automate some common tasks in PowerShell.
For the next few posts, we’ll look at retrieving and storing SQL Server configuration information. This can be a quick and easy way to audit your servers, and will be flexible across different versions and editions of SQL Server.
The data we will be gathering is:
This script will take the info, and shove it into a SQL Server table (in an Admin database). Here’s the rather simple table that the script below works with:
use Admin go
create table ServerInfo ( ServerID int IDENTITY(1,1) PRIMARY KEY CLUSTERED, Name sysname NOT NULL UNIQUE NONCLUSTERED, SQLVersion varchar(30), SQLEdition varchar(30), WindowsVersion varchar(50), clrenabled bit, DatabaseMailXPs bit, xp_cmdshell bit )
Notice that I am managing duplicates the easy (aka cheap) way; a UNIQUE constraint on name. In a larger environment, you’ll likely need to think about situations where you have multiple instances, and handle the data fields appropriately.
First, let’s build a script to retrieve data from a single server. Here’s the version 1 script (screenshot used for color-coding goodness):
Now let’s break it down into some components.
The first line is simply loading the correct namespace.
#make sure we are loaded correctly [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SqlServer.SMO') | out-null
This is actually only necessary if you are running the script from the vanilla installation of PowerShell. If you’re running it from SQLPS.exe, this line can be left out. I have it here because I was using the PowerShell_ise.exe editing environment (which doesn’t automatically use the SQLPS extensions).
Then we have the meat of our work. First, we need to declare some server level variables and point them to the correct namespace so that we can step through the properties as needed. We also need to define which server we are working with.
#Create and populate server variables ##Connect to the SMO and set a "server" objects.
$servername = 'JJONESLT7'
$serverinfo = new-object ('Microsoft.SqlServer.Management.Smo.Server') $servername $wininfo = get-wmiobject Win32_OperatingSystem -computername $servername
Notice that we’re setting the $serverinfo to the SQL Server SMO namespace, but for Windows info, we’re querying WMI directly. This is a personal preference, because I don’t like the Windows information available in the SQL SMO. You could easily use the property OSVersion and get the numeric version number. I prefer the plain English value.
Next, we set our values.
#grab values from the server SMO object $winver = $wininfo.Caption $sqled = $serverinfo.Edition $sqlver = $serverinfo.Version $clrenabled = $serverinfo.Configuration.IsSqlClrEnabled.RunValue $dbmail = $serverinfo.Configuration.DatabaseMailEnabled.RunValue $xpcmdshell = $serverinfo.Configuration.XpCmdShellEnabled.RunValue
While this is a small representation of the data you might actually want to collect, it gives you an idea of how to get at the values you are looking for. When looking for high level server information, we simply look at the value in the corresponding property, i.e. Edition or Version. However, for the server configuration information, we have to look a bit deeper because of how the hierarchy in the namespace works. For the “sp_configure” type info, we have to look at the “.Configuration” space, and then reference a specific property (DatabaseMailXPs), and then pull the value out of the RunValue property. For each of the configuration properties, there are four potential values: maximum, minimum, current, and new (or running). For an in-depth exploration of the various configuration values, check out these MSDN articles:
· http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.management.smo.configuration_properties.aspx (for Configuration properties)
· http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.management.smo.configproperty_members.aspx (for ConfigProperty members)
Now, we can open a connection to the SQL Server of our choice, create a command and execute it to insert the data.
#put the data we have into SQL Server ## open database connection and insert our data $connection = New-Object System.Data.SqlClient.Sqlconnection("Data Source=JJONESLT7; Initial Catalog=Admin; Integrated Security=SSPI") $connection.Open() $cmd = $connection.CreateCommand() $cmd.CommandText ="INSERT ServerInfo VALUES ('$servername' , '$sqlver', '$sqled', '$winver', '$clrenabled', '$dbmail', '$xpcmdshell')" ##uncomment the next line to echo the command being executed back to the console #echo $cmd $cmd.ExecuteNonQuery() $connection.Close()
This is fairly simple for anyone who’s done scripting (particularly for VB and VBScript folks), but if you’re just now getting into a scripting language, here’s the breakdown.
I left out a few lines there that are basically for troubleshooting:
##uncomment the next line to echo the command being executed back to the console #echo $cmd
ECHO can be used to show the output of the variables you are populating in a script when you are developing it interactively. Obviously, you’d remove the hash (or pound sign) when saving this for everyday use.
Obviously, you can take this premise and expand it for your use. And in the next post, I’ll show you how to create an iterative version of this script. Until then, have fun!
Much like batch files for the DOS command prompt, PowerShell scripts give administrators a great way to automate routine processes and gather data. PowerShell scripts, unlike batch files, have a great deal of flexibility because PowerShell can access a great deal of system objects, and support various advanced parameterization and logic control features. In this post, we’ll look at creating a PowerShell script from scratch by accessing and manipulating objects on a SQL Server.
First things first; you’ll need to ensure that your environment will run your scripts. You see, with great power comes great responsibility; PowerShell can do a lot of things, but how do you make sure the script is executed in a safe and secure environment so its power can’t be abused? Fortunately, PowerShell has some built in security that you’ll need to set before you can start running scripts.
Probably the first thing you need to look at/think about is the Execution Policy. If you open a PowerShell prompt and type executionpolicy (which is an alias for the cmdlet Get-ExecutionPolicy), you’ll get one of the following responses:
Before you can run any scripts, you’ll need to change this. For initial development purposes, I’d suggest using RemoteSigned, because it will at least protect you from running something on your machine that was downloaded from the Internet. If you’re confident in what you are doing, go ahead and use Unrestricted, but ONLY for development. And even then, its always best to develop your scripts with the same security settings you’ll eventually use in production, that way you can be sure to develop a secure script!
One other note: There are separate execution policy settings for scripts run from SQLPS and PowerShell; be sure to set the correct environment. For our purposes, we’ll be working from SQLPS, so be sure to work from the SQLPS prompt from this point on.
Setting the policy is easy:
Set-ExecutionPolicy RemoteSigned
Easy enough. So now that the environment is setup, its time to create a script!
A PowerShell script is simply a text document that contains a series of cmdlet executions (with some control logic around it). So to create a PowerShell script, simply create a new text file, and name it something obvious, such as “MyFirstPowerShellScript.ps1”. Note the extension;PowerShell scripts are recognized by the extension *.ps1, so be sure to change this from the default *.txt extension.
In order to get your feet wet, let’s create a script that does some very basic tasks:
First, let’s retrieve the list of services from a remote server (if you read the post previous to this, it should look familiar):
get-service –computername CSSRVSQLTST |
where-object {$_.DisplayName –match “^SQL.*”}
From the command line, you should see the same thing as the above screenshot. But what about a script?
As of PowerShell 2.0, PowerShell ships with a nice new integrated scripting environment (ISE). You can get to this environment (if you have PS2.0) by typing powershell_ise.exe at the command prompt, run box, or Start menu. So, you can use the ISE if you’d like, but if not, you can literally create a new file on your disk somewhere, and give it a *.ps1 extension, and then edit the file in any text editor you’d like. I’ll be using powershell_ise.exe, so that’s the screenshots you’ll see.
Let’s look at getting our service list and outputting it to a file. Along the way, we’ll talk briefly about variables and outputting results. Here’s a quick script:
First off, notice the commented lines, prefixed with the pound (or hash) sign (#). This gives you a convenient way to document your code as you go along. If you aren’t a strong programmer or scripting guru (I’m not), you should use a lot of comments to help guide you through the script. This can help with troubleshooting later on down the line.
Next you see a few lines prefixed with dollar signs ($). These are variables. If you are familiar with variables, skip to the next paragraph. If not: Variables allow you place reusable objects into your scripts that can contain differing values. That way, you can assign values to a variable, and use that variable in a command that otherwise needs some specific string input, and then later update that value and do it all again if needed. Above, you can see that I’ve created a variable named $computer to hold the name of the computer I am connecting to in the get-service command. I’ve also created a variable named $string to hold the matching pattern for the where-object cmdlet that helps me do some regular expression matching against my results.
After the variables, you see the actual command. First is get-service, which you are already familiar with. Then comes where-object, which is essentially a WHERE clause (similar to T-SQL) allowing me to filter on some input. Notice that this line has a block of code as an input:
where-object {$_.DisplayName –match $string}
The dollar sign represents, in this case, a placeholder for each value being returned by the DisplayName object in the initial get-service result. The parameter, –match, then tells the cmdlet that we are searching for a specific string, and then we include our placeholder $string, which equates to “^SQL.*”, which is essentially a regular expression type match that gives us all processes with the letters SQL in them.
Finally, you see the cmdlet out-file, which simply tells the script where to send the results. This can literally be any path (that we have rights to). Notice that we’ve used the pipe (|) between each cmdlet; this is what passes the data (and control) to the next cmdlet. If we omit the pipe, the results are returned and the next cmdlet is executed without any “incoming” objects, which will usually cause an error.
Now save the script file, and try executing it from the command line. You should end up with a very simple text document that has the output we expect, which is a list of SQL services on the target machine.
This is a very basic script; there’s a lot more that can be done, which is what the rest of this series will entail. For now, look at creating some scripts of your own, and have fun!
In my last blog post, I discussed how to get PowerShell and SQLPS up and running on your machine(s). And much like my dog chasing its tail, you’re probably asking yourself, “Now that I have it, what do I do with it?”
The first thing you’ll want to learn is how to actually connect to, and get information about, your servers. So, go ahead and go to your Start>Run or Start>Search box and type SQLPS. If everything is installed correctly, you should see:
Alright, let’s start off with looking at the SQL Server services running on a given machine. Use the cmdlet “get-service” to find out about services on either your local or a remote machine. This is not a SQLPS specific command, but rather a PowerShell command:
get-service –computername CSSRVSQLTST –displayname *SQL*
Not bad. We passed in a few parameters: –computername tells the command what computer to connect to (the default is localhost), and –displayname helps us filter on the name of the service (with the help of the asterisk as a wildcard). This corresponds to the displayed name in the Services control panel. If you want to look for the actual service name, use –name. If you want to get fancy, and see how cmdlets can interact, we can sort the output of the query:
get-service –computername CSSRVSQLTST –displayname *SQL* | sort-object status
If you want to find out what else you can do with get-service, just type get-help get-service –examples.
Now, what about actually executing some T-SQL? Most DBAs are already familiar with SQLCMD, introduced with SQL Server 2005 to replace the old OSQL command line query interface. SQLPS uses a cmdlet called invoke-sqlcmd to call SQLCMD and pass a query to it. It supports both T-SQL and XQuery and a variety of parameters. Here’s a simple query:
invoke-sqlcmd -ServerInstance CSSRVSQLTST -Database msdb –Query "Select top 2 * from sys.objects"
So you should take two things away from that screenshot: 1. It’s an easy command, and 2. That is not a great way to get data back if you’re going to do anything with it. If you’re going to be executing a stored procedure, or querying for one or two very specific rows from a table/view, this method is fine, and very easy. However, if you’re looking at a bunch of rows coming back, there’s a better way. PowerShell provides some cmdlets that you can pipe the result set to in order to get a better looking format. For example, you could export the results to a CSV file:
invoke-sqlcmd -ServerInstance CSSRVSQLTST -Database msdb –Query "Select top 2 * from sys.objects" | Export-Csv –path C:\MyFiles\results.csv
When run, this command returns no output to the command line screen, but dumps the file to the specified directory. Using this method will get you a slightly more usable list of rows to review. Again, use get-help invoke-sqlcmd to get more info.
At this point, you have enough information to be dangerous! Be sure you’re careful when querying any production servers, because if you have the right credentials, you could do a lot of damage. In the next post, I’ll talk about how to create scripts using basic PowerShell and SQLPS cmdlets that access system objects in SMO and Windows. Until then, have fun!
Many DBAs have heard about the new scripting technology from Microsoft, but have yet to really dive right in. You may have heard about a new scripting language for Windows Admins; PowerShell. However, PowerShell holds a lot of benefit for SQL Server DBAs. In this series of blog posts, I’ll guide you through getting your feet wet with PowerShell, understanding what it can and can’t do, and take an in depth look at many of the specific areas PowerShell can make your life easier.
For those of you who are unfamiliar, let me give you a (very) brief overview of PowerShell as a technology. PowerShell is, for lack of a better word, the next generation of scripting and command line functionality from Microsoft. At first glance, it looks like an old fashioned DOS prompt on steroids, but really it’s much more than that. Where the old command prompt provided very limited scripting and the ability to call other executables, PowerShell functions more like an entire subsystem that happens to be a command shell. The root of its usefulness is the .NET Framework. Because PowerShell relies on the .NETFX, it has the ability to access and manipulate almost any object in Windows (via WMI), as well as other Microsoft products, such as SQL Server. This allows administrators and programmers a great deal of flexibility in creating automated processes from the command line. PowerShell comes with a plethora of applications, called cmdlets (commandlets) that let you execute any number of tasks, and provide the basis for much of the scripting capabilities of the platform. Additionally, the PowerShell shell supports all of your favorite commands from the old DOS command prompt, so you can start using the PowerShell command line right away.
While PowerShell is a Windows technology, SQL Server 2008 introduced the new mini-shell, SQLPS. SQLPS is a collection of extensions for PowerShell that are designed to work specifically with SQL Server. In addition to those extensions, the SQL Server Agent in SQL Server 2008 has the ability to call the PowerShell subsystem to execute script steps, much the way it can with ActiveX and command line scripts.
And while there’s a lot to learn about PowerShell and SQLPS, it’s all a bit much for one blog post. Before we can move into the more advanced material, you’re going to need to get PowerShell up and running in your environment (because learning a scripting language is really hard if you don’t have the right script engine in the first place). Unfortunately, since the introduction of PowerShell 1.0 a few years ago its gotten a little confusing which operating systems ship with PowerShell, and which version of PowerShell they come with if any at all. So here are the basics:
· If you have Windows 7 and/or Windows Server 2008 R2, you have PowerShell 2.0 already.
· If you have any earlier version of Windows, you have to install PowerShell.
However, if you have Vista, you may already have PowerShell 1.0, as it was distributed as a Windows Update.
One quick test to find out if you have PowerShell installed is to open a standard command line and type
C:\>powershell
If it tells you that “powershell” is an unrecognized command or application, then you need to install PowerShell. Otherwise, you should get a new prompt in the window:
If you use the “Run…” box (or the all purpose search box in the Start menu on Vista and later), you should see:
If you need to install, here are the links to the downloadables:
PowerShell 1.0
http://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx
PowerShell 2.0 is only currently available on Windows 7 and Windows Server 2008 R2. Microsoft is working on back porting it to the earlier platforms, but those are only available as a CTP as of this writing:
Here’s a blog post outlining what’s available: http://blogs.msdn.com/powershell/archive/2009/08/14/powershell-2-0-for-windows-vista-and-windows-server-2008-release-candidate.aspx
And here’s the direct link to the download:
https://connect.microsoft.com/windowsmanagement/Downloads
Notice that this last bit is actually part of the new Windows Management Framework, which will be the “new” management software to install on Windows Vista and Windows Server 2008 to bring the functionality current with Windows 7 and Server 2008 R2.
Finally, if you’re ready to go ahead and get SQLPS running, you should already have it if you’ve installed the SQL Server 2008 client tools on your (or any) machine. However, if you would like to use the SQLPS extensions on a machine without installing the SQL tools, you can go get it from the SQL Server 2008 Feature Pack:
http://www.microsoft.com/downloads/details.aspx?FamilyID=228de03f-3b5a-428a-923f-58a033d316e1&DisplayLang=en
Scroll down and you’ll see the downloads for both the SQLPS extensions as well as the SQL Server Management Objects (SMO), which is required to make the whole thing work.
In my next post, we’ll actually start using these bits and pieces, but until then, you can get started getting familiar with what PowerShell can do, by simply typing:
PS C:\>get-command
Have Fun!
If you haven't already heard, Microsoft is upping the ante in the certification arena by introducing a new line of certs called the Microsoft Certified Master Program. The gist of it is that these are certifications (currently only for SQL Server 2008, Exchange Server 2007, and Windows Server 2008) that represent the highest skill level in building solutions based on the specific product. A much more detailed blog post from the program owner HERE.It's a lengthy post, be sure you have a minute to digest all of that information.
Here's the rub: many people already feel that certifications, particularly MS certs, aren't all that valuable in the real world, because the certs can be obtained by anyone patient enough to read the study materials and take the test, without having any actual, useable, real world experience. And on top of that, with the changes in recent certifications from MS, many managers and HR reps don't even know what the certs represent. So, how can adding a higher level cert be helpful in any way?
Well, personally speaking, I think they've got a good deal with this one, with one caveat I'll speak to in a minute. This particular certification, much like the Microsoft Certified Architect, requires (as in MANDATORY) classroom training. For the SQL Server Masters Cert, they are going to require that you already hold the MCTS:2005 cert, as well as both the MCITP (Microsoft Certified IT Pro) SQL Server certs for DBA and Developer. And, they will need an application, as well as a resume to see if they will accept you into the program in the first place. All of which seems to, in my opinion, make the cert a little more "weighty" than it's predecessors. Primarily because this will make it hard for the cert to become watered-down by literally hundreds of thousands of people holding it. Plus,once accepted to the program, you have to pass 3 written exams AND a lab based exam (similar to the Cisco CCIE).Again, I think that's a huge plus. The idea behind all of this is that if you encounter someone that holds the MCM for a given product, you should be able to reasonably assume that they know, very well, what they are talking about. This increases their value to a company, as well as value in their career.
However.
The blog post says (and it may be an early report, but I don't imagine it's too far off), that the program fee, IF you are accepted, will be in the neighborhood of $18,500USD. This includes the mandatory 3 WEEK course and ONE round of exams. If you fail any exam, retakes are extra: $250 for written tests and $1500 for the lab exam. In other words, this is not likely to be a cert you can afford on your own. In fact, just to meet the pre-requisites, you or your company has already forked over at least $225-$250 in exam fees for the earlier exams, not to mention training. Not only would an individual find this expensive, even a small or medium business might find this to be too much to fork over. The argument, of course, is that a business that employs someone that holds a cert of this level has not only a strong technical resource, but a good marketing tool (particularly those companies that are MS Partners). So the question is not only "Am I good enough?", but "Who's going to pay for this?".
I would love to acheive this cert. I currently have the MCITP:DBA, but never pushed on for the Dev MCITP (or any others) because I felt like it was pointless. I really felt that if you've spent more than 6 months with SQL Server, you could probably pass the test(s). And if you've already built up a healthy resume of experience, the MCITP cert doesn't really impress anyone as much as your background and references will. However, I think the MCM would be a much more difficult certification to earn, not only requiring you to demonstrate expertise but probably deepen it during the training courses.
If nothing else, think of it this way: Many experts in our field (think Kalen Delaney, Kimberly Tripp, Itzik Ben-Gan) have made careers out of sharing their deep knowledge, and don't generally advertise or glorify certifications (I don't know if they do or don't hold any MS certs, but they certainly don't advertise it if they do). Their body of work shows what they know. But, for those of use somewhere in between "Senior DBA at XYZ Corp." and "SQL Server Community Guru", a cert like this might help us get that slightly higher paying job or even help us branch out on our own as consultants, authors, and trainers.
I'm curious to hear if anyone else out there has any thoughts. Please feel free to respond, thanks for stopping by!
--Josh
Hi! My name's Josh Jones, and I'm a new blogger here at SQL Server Central. Steve Jones graciously let me start blogging here, so I figured the first thing I ought to do is introduce myself. But before anyone asks, Steve and I are not related. We just share one of the most common surnames around.
I've been working in IT for about 8 years now, with the last 6 years focused on SQL Server. Prior to life as a DBA, I ran the gamut of the networking side of the house; everything from Help Desk to Server Support to networking and telephony infrastructure & support. Since being a DBA, I've been lucky enough to work with (learn from) and meet some very talented folks such as Paul Nielsen, Bill Wunder, Eric Johnson and of course Steve Jones (all past or present SQL Server MVPs). Now I'm trying to share my experiences as well as learn from the community; I am one of the VP's of the Colorado Springs SQL Server Users Groups, and a regular speaker at both the Colorado PASS Camps and a number of other online conference and informational outlets. Plus, (warning: shameless plug coming) Eric Johnson and I just published our first book, "A Developers Guide to Data Modeling for SQL Server" from Addison-Wesley. So if you're interested in a practical take on Data Modeling with an eye towards deploying on SQL Server, make sure to check it out (if you're in Colorado, attend the Boulder, Denver, or Colorado Springs SQL Server Users Group and you might win a copy for free!). One more plug: I am also a co-host of an IT Professional focused podcast at www.cstechcast.com. It's a 30 minute show, where we talk about news and trends, bring a weekly tech tip, and feature interviews with authors and experts on a broad variety of topics (everything from SQL Server to Cloud Computing to IT Compliance). Check us out if you have the time.
But that's enough about me. I plan on using this blog to post thoughts and experiences on day to day, practical usage of SQL Server. I also tend to be somewhat of a new tech geek, so I'll try to post interesting and (hopefully) thought provoking entries on the new features of SQL Server, as well as some industry trends that I think DBAs should pay attention to. So hopefully you'll find this blog useful, and please, PLEASE leave me feedback and comments as you see fit. Thanks, and see you all online!
