SQL Server 2008 + PowerShell = NO NO NO NO NO!

Home » Windows PowerShell

SQL Server 2008 + PowerShell = NO NO NO NO NO!

Submitted by Don Jones on Wednesday, 11 June 2008 Comments

(1 votes, average: 5 out of 5)

Loading ...

Note: I’ve posted a follow-up with some additional thoughts. Uses SQL Server 2008 RC0.

This blog post has me seeing red. In it, the SQL Server 2008 team demonstrates their complete and utter lack of “get it” when it comes to Windows PowerShell. As you may know, SQL2008 is in Community Technology Preview (CTP) number 6, and they’re delivering a Windows PowerShell provider and cmdlets. The point of the cmdlets is for administration, not data manipulation; that’s fine, because SQL has a great scripting language (T-SQL, which it’s had forever, literally) for data manipulation (and it’s not so bad at most admin tasks, either, really).

The PowerShell cmdlets are likely being built on SQL Management Objects (SMO), a .NET Framework class set that was introduced in SQL2005. You’ll apparently be able to use PowerShell in SQL Server Agent job steps, which is mega-cool, and PowerShell v1 is a pre-requisite for installing SQL2008.

But they have created a SQL Server-specific version of Windows PowerShell, which is what you use if you want to use SQL Server 2008 cmdlets or the new provider. And this new console is closed - you cannot add more functionality to it by using Add-PSSnapin.

To say that this is “stupid” would be unkind to all the stupid people out there. This “closed console” is stupid on a level heretofore unknown. The SQL team is basically taking a great, all-purpose administrative tool and locking it down. They’re returning us to the good old days of Windows NT, when everything was administered by its own, separate, non-integrated admin tool. THIS SUCKS.

Even better? Some collection names - e.g. ,”Databases,” as in $server.Databases - are case-sensitive, in defiance of everything else PowerShell does. Some of PowerShell’s built-in discoverability features are broken in this closed console, removing the ability to work with individual snap-ins, for example. COULD THIS SUCK ANY MORE?

The SQL team seems to be so inwardly-focused and out of touch with what administrators do that they’ve really limited the possibilities for their work to be, um, useful. For example, by forcing me to use a closed console, they’re eliminating the ability to make SQL-related tasks a part of broader provisioning processes and other business processes. To mess with SQL, you have to be in the Special SQL Shell, and when you’re there you can’t have any other functionality. Just SQL. WHY??????

I wish I were kidding. The SQL team is clearly not only talking to other teams which have done a great job of working with PowerShell - System Center, Exchange, etc - they don’t even seem to know that these other teams exist within Microsoft. Right on campus. Just down the road. Go eat lunch with them for heaven’s sake. Order a side of clues.

This “closed console” business is depressing. I’m hoping someone at Microsoft with some clout can make folks on the SQL team see reason. They’re doing things that don’t make sense, don’t fit the model, and just… ugh. You know, it’s just hubris. Did anyone on the SQL team think to ask, “gosh, why is everyone else using the base shell instead of making their own closed shell?” Or did they think they’d discovered a solution to a problem that… um… nobody else has ever heard of?

Your comments, please. Maybe a public outcry will help folks in Redmond see reason.

(BTW, I basically asked “WTF?!?!” about this on the private Admin Frameworks MVP mailing list - hoping that there was a logical reason for this closed console decision, and that I was missing something. The responses were basically along the lines of “Yeah, they don’t get it,” so if there IS a logical reason, none of the PowerShell MVPs have been let in on the secret, yet).�

Technorati Tags: amazingly stupid, sql server 2008, Windows PowerShell

Rate this Post

(1 votes, average: 5 out of 5)

Loading ...

Comments »

Keif said:

It goes against every other facet of powershell design! I was quite impressed with the improvements of the management interface in SQL 2005 over 2000, and whilst I’ve not had a chance to look at 2008 yet I was hoping that they’d manged to make my life even easier still.

- 11 June 2008 at 8:51 am

Mark Ayers said:

If what you say is true (as I haven’t looked yet), then they cannot even have taken it to Usability for a sanity check.

If it goes out the door like this Microsoft gets the mud, not just the SQL Server Team. We admins generally don’t bother to lay blame at the feet of teams when we have a wider target to toss our aggravation at.

- 11 June 2008 at 11:57 am

Don Jones (author) said:

Amen, brother.

- 11 June 2008 at 2:44 pm

Don Jones (author) said:

Yeah, it’s depressing. I just can’t fathom why the SQL Server team feels the need to take this approach. It honestly feels like they’re trying to jump on the bandwagon without seriously designing it first, or there’s just a couple of PowerShell “guys” in the team who are doing this work, perhaps without really understanding what the big picture should look like. The closed console - I just can’t justify it.

- 11 June 2008 at 2:48 pm

/\/\o\/\/ said:

I don’t get it either.
they even added there own escaping ( that does not fit in so is buggy )

Greetings /\/\o\/\/

- 11 June 2008 at 3:44 pm

klumsy said:

You know, I totally agree. But maybe we’ll be able to load their cmdlets into real powershell with some technique later, but even their design, the way they did their provider, and so many other things sceams powershell ANTIPATTERN. I could understand a closed shell (as an option for one thing, and that would be a hosted/sandboxed powershell that can be called from inside stored procedures, but you can’t sandbox/constrain powershell properly anyhow. Somebody in Microsoft needs to VETO this. take powershell support out of sql server 2008 , and add it back in as a seperate install, or a SP1.

- 11 June 2008 at 4:40 pm

Jason said:

Can’t you just load the provider and formet files in the regular powershell for full functionality?

- 11 June 2008 at 4:55 pm

Jason said:

btw, it looks like they fixed case sensitivity in RC0.

- 11 June 2008 at 5:00 pm

Rob Farley said:

I blogged about how to add SQL as a snapin in your regular PS window here:
http://msmvps.com/blogs/robfarley/archive/2008/03/04/sql-server-2008-powershell-snapin.aspx

Does this fix it?

Rob

- 11 June 2008 at 6:07 pm

Dennis O said:

Don, this threw me for a loop as well when I mentioned it on Minasi’s forum. I can’t understand why they would do something like this!! I was getting so geeked about learning PowerShell after the Forum meet that this felt like getting cold water thrown at me. I started thinking, should I waste my time learning PowerShell now if Microsoft is going to play games with the admin tools again (OK, I know it’s just the SQL Server Team, but Microsoft seems to be letting them do this)? If Microsoft lets the SQL Server Team do this, then the Unix guys have a right to laugh at the Windows command line, like they always seem to do.

- 11 June 2008 at 6:17 pm

Joel "Jaykul" Bennett said:

Even if you can load their snapins into a normal host, releasing a crappy proprietary host with limited functionality would be an all-out embarrassment and would potentially wound PowerShell severely. I can’t imagine that will fly.

- 11 June 2008 at 9:00 pm

Hal Rottenberg said:

Hey Don…you were missed tonight at the dinner. Had you been there, you would know more about this blog post than you did yesterday.

- 11 June 2008 at 9:21 pm

MatthewG said:

wow. that is insane. who would have thought up such a retarded approach. Can the product team speak to this silliness?

- 11 June 2008 at 10:42 pm

Xaegr said:

This is awful. If PowerShell implementation in SQL 2008 cannot be rewrited (because there is not much time left till the release), then it should be removed completele. Just for not disgrace PowerShell.

- 12 June 2008 at 12:16 am

Georg Begerow said:

A perfect drop of insanity. They missed the big chance. This closed powershell design would be one point if they host it inside sql server but as an general interface it sucks. If they don’t change it, maybe it is time for the comunity to show them the way to the light

- 12 June 2008 at 1:09 am

Tim Bolton said:

In my humble opinion… If Microsoft allows this to happen it’s not a case of them shooting themselves in the foot. It’s a case of them blowing their collective brains out.

If they allow this to happen you will hear the Exchange team - and all of the other teams - screaming across the globe.

PowerShell support will drop off of the map. Yet another cute way to write code, like Jython and VB and C#…

The UNIX guys are rolling on the floor. The Microsoft bashers are warming up their keyboards.

So is PowerShell over VB or C# now a waste of time..?

Will it be easier to - I cannot believe I am writing this - to use a GUI..?

Can they be this dumb..? Really..? I mean REALLY??

- 12 June 2008 at 4:32 am

Oisin G. said:

Yeah - they use url-escaping - yep. A space is %20 for example. In PowerShell. Insane.

The one thing that will come out of this is that someone will write a free one that does all theirs does, and better. It won’t be in a closed shell either, let me tell you.

- Oisin

- 12 June 2008 at 5:52 am

Airjunkie said:

I’m dumb founded why the SQL team would do something this stupid. They need to be brought out of their ivory tower and sat down in front a computer and forced to manage 1000 systems. PowerShell has made doing that so much simpler, the community is extremely supportive and inventive, and it’s all because PowerShell ties together all aspects of the M$ world.

The SQL team needs to highly reconsider this.

Get with the program, or stay out of powershell until you (SQL Team) get it.

There’s no reason to re-invent the wheel, make it square and call it an improvement.

- 12 June 2008 at 5:58 am

Robert Smith jr. said:

Hello,

I was surprised to read this. Microsoft has done a great job (so far, anyway) in improving systems administration with Powershell. This custom,limited functionality shell for SQL would be a big step IN THE WRONG DIRECTION!

I have found Powershell to be a fairly steep learning curve (as far as writing scripts goes), this would only complicate matters worse when it came to writing SQL specific scripts and trying to integrate this with other products/technologies that employ Powershell.

It would be a shame to have to regress back to the GUI for SQL administration. Geeze, look at the wonderful examples set by Vmware, Quest and even Microsoft itself when it has come to integrating support for additional products / technologies.

It seems to go against all the reasons why Powershell was invented in the first place!

I wonder what Jeffrey Snover or Bruce Payette would think of this?

Bob

- 12 June 2008 at 7:42 am

Tom Glowacki said:

This could be one of the most bone-headed design choices Microsoft has made since Microsoft Bob. Clearly, the SQL team just doesn’t GET PowerShell.

- 12 June 2008 at 10:58 am

Dennis O said:

It’s starting to look like instead of learning just one shell language, you’ll have to learn PowerShell, then each of the closed systems (if Microsoft lets one team get away with, there will likely be more), then you need to remember what works in what shell. Then you need to modify each of your scripts, depending on what shell you want to run them in…

This is crazy!!

- 12 June 2008 at 12:45 pm

Michael Koehler said:

If we are taking votes on this, put me down as aghast. Jeffrey Snover needs to sick that robot he adopted from Windows 2008 on whoever on the SQL team dreamt this up.

- 12 June 2008 at 2:26 pm

Dennis O said:

I remember an interview somewhere with Jeffery Snover where he said that they were letting the product teams write cmdlets for the product (AD Team writing the AD cmdlets, Exchange Team writing the Exchange cmdlets, etc.) becuase they were more familiar with the product than the PowerShell Team. I’m guessing that this was partly due to that decision, since it looks like the SQL Server Team, decided to do their own thing. I’m guessing the PowerShell Team is regretting that decision now.

- 12 June 2008 at 6:07 pm

Rick said:

OMG. They must be kidding. What does CTP stand for these days? Create Ten PowerShells? These guys are crazy. Clearly the have looked no further at PowerShell design guides than the title “PowerShell”. It will render PowerShell useless and this way a great technology will die before it even gets momentum - just when I though we were getting there.

Redmond, Wake up! Hello?! Goodmorning?!?! Hello? Hello… ? Anybody home?!?

I sure hope they are. Perhaps they are in the bathroom. Flushing out this terrible idea.

- 13 June 2008 at 12:51 am

Michiel Wories (Microsoft) said:

The long and the short of it is explained in my recent post overr here: http://blogs.msdn.com/mwories/archive/2008/06/14/SQL2008_5F00_Powershell.aspx. The ‘closed’ custom is a form of prepackaging that is specifically focused on our DBA community, but it does not stop anyone to create your own initialization script to create your own custom Powershell environment. In fact this is what you normally have to do to combine Exchange (as an example) and SQL Server into one enviroment. I the above blog post I have added a script that exactly gives you this starting point. And it is the OPEN shell environment that you have been looking for.

Please keep the feedback coming

- 14 June 2008 at 4:04 pm

Don Jones (author) said:

Thanks much. I’m still not sure you’re serving your customers well that way. If you want to simply have a SQL-focused shell… well, it’s easy enough to do - simply provide a PSC1 that preloads the SQL snap-ins. There’s no reason to cripple the core shell functionality (e.g., removing the *-PSSnapin cmdlets) in order to create a “focused” shell. It’s also kind of short-sighted to assume DBAs would want a crippled environment, I think. If you’re open to having the SQL snap-in added to a normal shell, then why not simply start with a normal shell in the first place? What’s the business or operational advantage in crippling the shell? Exchange, System Center, et al manage to “prepackage” a product-specific shell without removing core functionality, and their audience seems very happy with what they’ve done.

- 15 June 2008 at 9:44 am

Don Jones (author) said:

Well, there’s a difference between authoring your own cmdlets - which each product team does, in fact, take responsibility for - and creating a custom shell. There’s no need for a custom shell; you create your cmdlets in a snap-in and just add it into the standard, core shell.

- 15 June 2008 at 3:02 pm

Don Jones (author) said:

Agreed. I’m hoping the PowerShell team is trying to provide more sensible guidance as we speak.

- 15 June 2008 at 3:03 pm

Stacy Hein said:

I am shocked that Microsoft, who is betting the farm on this technology, would allow one team to bastardize their base product. I am a DBA, SQL and Oracle. I love the idea of PowerShell. When I heard about it, I thought, “Wow! Microsoft finally gets it.” Allowing one team to setup a proprietary version of what is supposed to be their admin interface to the OS, is rdiculous. I’m disgusted.

I have been defending PowerShell to all the other lesser geeks I come across who tell me this is just batch all over. I tell them that they just don’t get it. If Microsoft allows the SQL team to move forward with this closed, proprietary version of PowerShell that works only for SQL Server and doesn’t allow expansion via snapins and is completely untethered to the admin product of PowerShell, they make those accounts of this just being batch right. They will have ruined a great thing.

Way to go. Allow a small lobby ruin it for the rest of us. Looks like I will have to concentrate on my Oracle. Microsoft will give back the share of the database world that they took. Ellison will be thrilled.

- 17 June 2008 at 8:41 am

Jason Jarbo said:

I couldn’t agree more. I have been touting the universal functionality of Powershell to all of my clients over the past 3 months. I have even got some Unix guys who were huge Microsoft haters to take a look and they (for the first time in their lives) liked what they saw. If Microsoft doesn’t just provide a PSC1 that pre-loads the snap-ins it will be a tragedy.

- 17 June 2008 at 11:30 am

Curt Spanburgh said:

I read that technet was ga ga over this as a replacement for the SQLCMD functions we have now. But to put a wrapper on it is perhaps paranoid delusional?

And what fun it is to do the osql scripts now.

The clients don’t want to pay for them anyway. We will have to make $$ on the developement of the PS cmdlets and make some coin on the reuse.
/:<

- 17 June 2008 at 4:23 pm

Marcus Farmer said:

Precisely. What happened to PoSh being THE shell and every bit of functionality being a snap-in? This scenario is more like a break-out. Or, better, just broken. Great idea, SQL team, to break the shell so much that I can’t use your (do I even call them snapins at this point?) cmdlets to query my data and create Active Directory users because I can’t load Quest’s cmdlets into the broken shell.

There are 4 distinct PoSh profiles on a computer - surely they could use one of those to preload their cmdlets.

- 20 June 2008 at 8:05 am

Jeffrey Snover said:

Interesting blog and thread. I’ve tried to clarify things with this blog entry:

http://blogs.msdn.com/powershell/archive/2008/06/23/sql-minishells.aspx

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

- 22 June 2008 at 9:27 pm

SQL Server 2008 + PowerShell = NO NO NO NO NO!

Related Posts

Rate this Post

Feeds

Archive

Blogroll

Topics

Highest Rated

Tag Sphere

Most Commented

Most Popular