The SQLPS Firestorm

Within the PowerShell community there's a firestorm raging over SQLPS.exe our mini-shell that we're introducing in SQL2K8. In his blog Michiel does a good job explaining the mini-shell and provides a script you can use to register the SQL Server provider extensions in a vanilla PS environment.

I love it when people who obviously have zero commercial software experience pontificate about what's right and wrong. Actually I don't love it. It something that pisses me off big time. These individuals think they're "helping" but they're not. They make claims that they want to understand but they don't really. To them the world is binary - they're TRUE and everyone who disagrees with them is FALSE. In elementary school we called these people bullies.

I'm purposefully not naming names here as it will do no good. I have no interest going head to head with them. It's a no win proposition - in fact everyone ends up loosing.

I don't like using this blog to air my opinions, I much rather focusing purely on technology and SQL Server. But they're defamation of the SQL Server team is simply uncalled for.

I'm very proud of the work the team did in SQL2K8. Is everything perfect? Absolutely not. Are we adding a ship load of value to the product? Absolutely.

If you don't like what we've down with PowerShell you're free to roll your own. PowerShell is an open environment for which you can register your own providers and build your own cmdlets. There's no restriction that states you must use sqlps.exe. Even within SQL Server Agent you can use the cmdshell subsystem to call powershell.exe directly. But we believe the vast majority of people will find value in sqlps.exe and the PowerShell subsystem in Agent. Hence why we built it.

Send us your feedback through and I promise we'll listen. It doesn't mean we'll implement every suggestion but we'll listen. I've been developing software @ MS for over 4 years and the amount of debate and discussion that goes into key decisions is often mind numbing. Maybe it looks like we simply pull the answer out of our ass but that's not the case. We look at it from every angle and consider all of our constraints to arrive at the most optimum solution.

Comments (11)

  1. Jason says:

    Since you were being so nice, I will call them kooks. One thing that they don’t like and they begin to bash and go on about how the Unix admins are going to laugh at them for being < l33t.

  2. X says:

    So you’re basically saying "to hell with our ignorant users — we know better".

    Nice attitude.  

    Know what I hate?  PMs with no field experience who try to define the user experience for all of the people out there who actually do have to use the product every single day of their lives, and then whine when the users aren’t happy.

  3. Mr. X, That’s a very strange comment since a) you assume I’ve never spent time in IT and b) you take my comments to be whining. Both of these couldn’t be further from the truth.

    Anyone who has spent any time with me knows that I couldn’t have more passion for doing what’s best for SQL Server customers.

    Finally, I appreciate and welcome feedback on the product. Everyone has an opinion and should have a forum to share it. What I don’t like are personal attacks. State your opinion intelligently and we’ll have a conversation about it. But there’s no need to make it personal. That’s what the person did in their blog on sqlps.

  4. Firewalker96 says:

    I’ve read a bunch of blog posts on SQLPS and most of them revolve around the same thing: if you can add the SQL cmdlets into regular PowerShell, why have a closed console? Any admin using PowerShell is likely already going to have it open to run any cmdlets, so why have another shell in the first place? I don’t see any of those blogs as being attacks on the SQL Team, since I haven’t read anything from the SQL Team, except your post here, that tries to explain the reasoning behind it. But even your post still doesn’t really explain that. Just explain your reasoning behind the decision to make people understand.

    Also, to your comment "But we believe the vast majority of people will find value in sqlps.exe and the PowerShell subsystem in Agent." What is the value of having the closed console that people will benefit from?

    I’m asking only because I don’t understand yet. Please help me to understand.

  5. iamtig says:

    You mention that in SQL Server Agent you can use the cmdshell subsystem to call powershell.exe. I am using SQL 2005, how can I that advantage of this method to utilize powershell functionality.

  6. First you’ll need PowerShell installed and register SMO with the shell (unless you have the SQL2K8 tools installed, then you’ll call sqlps.exe). In SQL Server Agent you’ll need to use the cmdshell subsystem which can run any executable on the local machine. In the job step you’ll call powershell.exe and pass in your script file. Allen White has a sample of this on his blog:

  7. Orrin says:

    I would love to see a stand-alone SQLPS.exe install.  I know the script that Michiel provides works but to ease scripting (less moving parts) it would be nice to be able to just call sqlps.exe and run a script.

  8. It became available with the October 2008 release of the SQL Server Feature Pack which can be downloaded here:

    Just do a search on that page for PowerShell and you’ll find the right download for your platform

Skip to main content