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)


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 2 and 2 and type the answer here:
  • Post
  • Thanks for a clear, sincere and honest explanation/justification for this.

    Yes, the SQL team does put out great products and work very hard.

  • Jeffrey Snover posted a very clear article about minishells and SQL Server's use of it: http://blogs.msdn.com/powershell/archive/2008/06/23/sql-minishells.aspx

  • Tone?  Sorry, Microsoft, but I've noticed that polite questions and comments are ignored, and snippy comments are not.  Consequently, you've trained me to never ask a polite question on a Microsoft forum -- I always start out rude, and continue to get ruder.

    Not because I'm rude.  People around me think I'm the very paragon of niceness and patience.  But with Microsoft, rude==success and polite==fail.

  • Mea culpa, where appropriate: http://concentratedtech.com/content/index.php/2008/06/23/powershell-sql-server-2008-the-official-word/

  • Jeffrey - your explanation does seem to imply that it was the communities fault that the GUI design problem was not caught. Doesn't Microsoft need to take the bulk of the "blame" as you (Microsoft) control the design, development and code review cycle? I think the community began to complain when the issue became apparent. Is this a case for a "PowerShell minishell design policy" at Microsoft - this seems sensible to me?


  • Thank you very much for addressing this, Jeffrey.  It's also important to reinforce (and the SQL team mentions this also on their blog, as did you) -- you can add the SQL snapins in a "regular" PS session!  This minishell thing isn't quite so bad as it first seemed as long as we retain that add-pssnapin abaility (from outside the minishell).

  • @Pete: My goal was not to assign blame.  Sorry that it come out that way.  As an engineer, I haven't found blame to be a tool that solves many problems.  I'm more than happy to accept 100% of the blame if it allows us to move past that and discuss what things we can do to improve things in the future.  

    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

  • I want something to blame.

    I want to blame that Get-ChildItem doesn't have like -Mode parameter which select files by its Mode,

    and does'nt give symbolic link and hard link special treatment.

    User side wouldn't be able to solve this, so I think this issue doesn't suit forums or newsgroups and so on.

    (Of course, we can solve this issue if we use longer alternative.)

    Where should I blame?

  • Smith,

    You need to record all of this on https://connect.microsoft.com.

    See if you can manage your way through finding "Windows PowerShell".  I know the feedback process for PowerShell on the connect site is hard to find.

    Email me at marco UNDERSCORE shaw _AT_ hotmail _DOT_ com if you need help or have difficulty.  I can send that feedback on connect back to Microsoft.

  • Thanks JS for your notes .. almost 'lost' my dedication to PowerShell.


  • On the PowerShell team's blog Architect Jeffrey Snover addresses the recent firestorm on SQLPS. BTW:

  • thanks for the clarification. If it is indeed the result of a make-shell, then i have no problem with it, but infered from various communications that it was fully self contained, and infered that it contained its own copy of the whole PowerShell engine, and could never get clarification if this was the case or not.

    Despite the minishell being the loudest complaint, i think the biggest complaints were to do with urlencoded case sensitive provider paths, especially odd when in powershell it wouldn't be case sensitive, and in SQL it wouldn't either.

  • Tank you for your help.

    I registered instantly.

  • so I installed powershell v2 and it errors out on basic commands such as ipconfig....

    any idea?

  • Thank you so much for addressing this.

Page 1 of 2 (20 items) 12