THE SQL Server Blog Spot on the Web
Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search
Home Blogs Downloads   Opml View as RSS news feed in XML

Allen White

PowerShell's "Mini-Shell" Is Not A "Mini" Shell

I just learned about a Connect item entered on Friday: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=475337. Here's the description in the item.

Please invoke the full powershell not a "mini-shell". Powershell is very powerful
but the mini-shell you get when invoking Powershell from the Management Studio is
missing a lot of functionality.

I'm not sure how the submitter determined that there was any missing functionality, because there isn't. SQLPS.exe is PowerShell 1.0 with the SQL Server Snapins included. All of the existing PowerShell functionality is still there. You can add the SQL Snapins by running the script Michiel Wories provided in his blog post here. (And I cited that in the whitepaper I wrote.)

Calling SQLPS.exe a mini-shell is a convenience, not a representation of its capabilities, so please take advantage of everything that PowerShell and SQL Server can do together.

Allen

Published Monday, July 20, 2009 12:27 PM by AllenMWhite

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Laerte said:

Hi Allen, i had a "problem" with sqlps because i´m using a powershell job type and it call sqlps.exe.

So in one moment i need use a quest snapin to manage AD, and i cannot add in SQLPS.

So all my jobs i need to change to cmd type , add sqlserver anpins and quest and execute powershell.exe calling mu ps1.

Was a little "wonrking", but everuthing works fine now...

But the sql team can put this (add snapin) in next versions o sqlps.exe

Thanks a lot

July 20, 2009 2:47 PM
 

Chad Miller said:

A more accurate description of sqlps is a alternate Powershell host. Any developer can implement a alternate Powershell host like sqlps by creating their own RunspaceConfiguration using the Powershell SDK. The base RunspaceConfiguration class does not have an Add-PSSnapin method. So, you can not add your own or 3rd party compiled cmdlets and providers to sqlps. You still can load any .NET assembly you'd like and write Powershell scripts within sqlps. You just can't load say the Quest Active Directory or Powershell Community Extensions cmdlets.

Because of this restriction a closed shell i.e. not allowing additional compiled cmdlets is also an accurate description. I have short blog post about it here:

http://chadwickmiller.spaces.live.com/blog/cns!EA42395138308430!181.entry

I tend not to use 3rd party cmdlets very much, so I don't feel having a closed shell is a big deal. I can see the point in having alternate host for SQL Server to do just SQL Server management. If I need to use 3rd party cmdlets or ones I create myself I'll simply use the regular Windows Powershell host.

July 20, 2009 3:02 PM

Leave a Comment

(required) 
(required) 
Submit

About AllenMWhite

Allen White is a consultant and mentor for Upsearch Technology Services in Northeast Ohio. He has worked as a Database Administrator, Architect and Developer for over 30 years, supporting both the Sybase and Microsoft SQL Server platforms over that period.

This Blog

Syndication
©2006-2012 SQLblog.comTM
Brought to you by Adam Machanic & Peter DeBetta
Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement