SQL Use of MiniShells

SQL Use of MiniShells

  • Comments 20

The SQL team has been receiving a lot of bashing lately over some of the decisions they made integrating PowerShell into SQL 2008.  I thought I would take a couple minutes to clarify a few things, eat some sin and talk about a constructive engagement model between the community and the feature teams implementing PowerShell cmdlets.

First let me declare my long standing admiration for the SQL team.  Those superstars have consistently been one of the teams that really GOT what it meant to release software for production environments.  They have a great quality culture and process and they have top-shelf leadership that reinforces this across the board.  SQL has been the gold standard of great scripting because their GUIs produce scripts that you could harvest for reuse (yes it wasn't full coverage but they GOT IT years before anyone else).  They are a great team - full stop.

The majority of the heartburn has come from SQL's use of MiniShells.  A MiniShell is a non-extensible version of PowerShell with a set of baked in Cmdlets and providers.  Some of my best community friends have pointed to SQL's use of MiniShells as evidence that they "don't get it".  This is not correct.  I told the SQL team about MiniShells and recommended that they use them because I thought they were a good fit for the sort of production-oriented value proposition they provide their customers.  So direct your criticisms at me on this one.

First let's talk about MiniShells and why they exist.  During the Vista reset, there was a great deal of anxiety about .NET versioning and general angst about instability arising from plugin models where code coming from the various sources run in the same process.  Imagine the case where you load plugins from 10 different sources and then something goes wrong - who is responsible?  Who do you call for support?  MiniShells allow teams to address these issues by creating fixed execution environments that built in our labs and fully tested/verified before release.  If you have a problem with a SQL PowerShell and call PSS, the first thing they are going to do is to have you try to reproduce the problem using the SQL MiniShell.   (NOTE:  In my experience, 9 out of 10 times that you have a problem with multiple plugins in a process comes from bad memory management  - a problem largely [but not completely] managed out of existence by the CLR.)

The problem is not that SQL shipped a MiniShell but rather that there are SQL UX scenarios that use the MiniShell instead of a general purpose PowerShell.  The SQL Management Studio GUI has context menus which launch their MiniShell.  This is where we made a mistake.  By definition, this is an escape out to an environment to explore and/or perform ad hoc operations.  This environment does not benefit from the tight production promises that a MiniShell provides, in fact it is hampered by them.  Because the MiniShell is a closed environment, you can't even manually add snap-ins.  This is what sent people’s meters into the red - and understandably so. 

Sadly it is too late to make this change for SQL 2008 but the SQL team will change this at their next opportunity.  In the meantime, when you are at the MiniShell prompt, you can just launch regular PowerShell with a console file that contains whatever snapins you want to use (including the SQL snapins - they can be added to a PowerShell session).  Clearly this is less than optimal but it is not onerous either.  We are working with the SQL team on the PowerShel V2 designs to make sure that we can offer teams like SQL the safety/production quality they need while providing the customers the flexibility they want.

 

Let's take a minute and talk about the engagement model.  I've encouraged the community to complain loudly when we screw up and aren't giving you want you want/need.  No one benefits by you suffering in silence.  In that regard, I can say that the MiniShell firestorm has been a big success.  That said, for complaints to be actionable, they need to arrive in time to be acted upon.  I'm sure that someone can point to a blog or email somewhere that pointed this out a long time ago but the reality is that it didn't pop as a problem until recently and now it is going to have to wait until the next cycle to get fixed.  The good news is that the community feedback mechanism works, we just need to improve the timing.

One last note about tone.  I've often joked that complaints were critical and politeness was desirable but optional (in other words, I'd rather get a rude complaint than polite silence).  Let me take a moment to tweak that guidance a little.  PowerShell is our passion and our day jobs and we'll endure almost anything to get the information we need to make this the best product ever.  So that engagement model is totally applicable to the PowerShell team.  That said, PowerShell is not the feature teams day jobs.  In the case of the SQL team, it was a stretch goal pursued because of the passion of a small set of individuals (Michiel Wories in particular).  The bottom line is that it is still critical to complain but when you complain about the feature team's support of PowerShell, just double check the tone and try make it constructive.  Above all, let them know that you appreciate their efforts (just don’t get so wrapped up that you forget to include the complaint J)

Cheers!

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

 

Leave a Comment
  • Please add 1 and 4 and type the answer here:
  • Post
  • Tialen,

    You'll need to be more specific.  I've never seen anyone have any problems running any regular DOS commands.

    Best place to ask for help is either the microsoft.public.windows.powershell newsgroup

    or the online forums:

    http://forums.technet.microsoft.com/en-US/winserverpowershell/threads/

  • I get very worried when you say that Powershell was not one of the design goals or regular work of the SQL designers. Shouldn't implementing easy administration with Powershell be a priory for all Microsoft product groups? After all, from now on it is included in the common engineering criteria, isn't it? Powershell should be implemented as much as possible by all Microsoft teams. Failure to do so marginalizes it and makes it looks as if Microsoft is made up of many little companies with different goals. In other word it creates a mess. I know that product teams have other priories but leaving Powershell out and making it into a side project for some pationate employees is shamefull, firstly for your team and all the hard work you have put in it and secodnly for all your customers. Why should you convince other product groups to adopt Powershell when Steve Ballmer himself said that all products would be made accessible from the command-line within 5 years. He said that 3 years ago I think. Have him to put force behind his words then.

  • i think that it is good to have a power shell!

    Nice and just started!

    the ice of it is being melted!

  • Of course, some support for PowerShell in SQL2008 is better than none - however, to me it appears to be a beta feature. Maybe it will actually be done right in time for SQL2008 SP1 ?

  • So in SQL 2008 R2 you are going to ba able to add arbitrary snap-ins into the Powershell shell used by Sql Server Agent Jobs?

    I want to be able to schedule consistency-check tasks which we have written as powershell cmdlets within a snap-in of our own

Page 2 of 2 (20 items) 12