Apologies To Buck for generalizing a little too much. The struggle with an editorial is to make a point in as short a space as possible. Of course, I have a high regard for the amazing influence that Buck has made in SSMS, and the influence he has bought to bear on the development of SQL Server tools. I had no intentions at all of causing him personal offense by criticizing Microsoft. I also have a huge regard for Bill Ramos, and the SQL Server team. I was looking more broadly at the pervasive culture.
Among the points I was trying to make was this: A lot of Sysadmins are nervous about the way that Exchange 2010 assumes an expertise in Powershell, and that some of the functionality for routine admin tasks can only be reached through Powershell. By contrast Windows Server 2008 R2 at least duplicates all admin functions in GUI tools, but still, the Lingua Franca is Powershell. Some of this anxiety is percolating to Production DBAs.
Powershell v2 looks good, and I'm happy to use it, but I'm acutely aware that we must ensure that all functionality that it brings can be reached through the GUI. Also, I'd suggest that Microsoft would encourage the use of other available scripting mechanisms. How could I possibly think that they aren't currently doing that?
I suspect that http://www.microsoft.com/windowsserver2008/en/us/server-management.aspx is fairly close to the current Microsoft line...
Windows PowerShell is a command-line shell and scripting language that helps IT professionals achieve greater productivity and control system administration more easily. Windows PowerShell accelerates automation of system administration tasks and can help improve your organization’s ability to address the unique system-management problems of your server environment.
Windows PowerShell is easy to adopt, learn, and use because it does not require a background in programming, and it works with your existing IT infrastructure, existing scripts, and existing command-line tools. Unlike most shells which accept and return text, Windows PowerShell is built on top of the .NET common language runtime (CLR) and the .NET Framework, accepting and returning .NET objects. This fundamental change in the environment brings entirely new tools and methods to the management and configuration of Windows.
You could be forgiven for understanding from this statement that here was little in the way of alternatives here. Well, there are several .NET-based scripting languages that are ' built on top of the .NET common language runtime (CLR) and the .NET Framework, accepting and returning .NET objects'. IronPython and IronRuby come to mind immediately, but the the DLR will encourage more in time, such as poor JScript. We may even see VB.NET return to its roots as an interpreted language. I even raise my eyebrows slightly at the statement 'Windows PowerShell is easy to adopt, learn, and use because it does not require a background in programming'.
Microsoft has had, for a long time, a very sensible policy of repeating .NET code examples from MSDN in both C# and VB.NET. It could easily do the same thing with Powershell admin code by repeating examples that use Powershell with, for example, IronPython or IronRuby. (IronPython can invoke the PowerShell APIs directly. see http://ironpython.codeplex.com/Wiki/View.aspx?title=Samples). I'd love to see more copy-and-use scripting example in other languages than Powershell. For doing really complicated scripting, I still find VB.NET the best tool for the job.
There are always going to be possible improvements to the GUI management tools. I don't buy the idea that the SSMS that we see today is the culmination of all the man-years of experience by the 'folks(who) have advanced degrees in Human Computer Interaction, Computer Science, and even Psychology!'. SSMS isn't perfect. Surely, improvements are possible to reflect the range of roles and experiences of the users? Is it still even correct to believe that all the administrative requirements of all users can be achieved though one GUI?
Best wishes,
Phil Factor