PowerShell Benefits Over COM Scripting

On an internal email thread, someone asked Vivek Sharma why they should implement PowerShell. They knew that PowerShell provided scripting but they had a COM interface which already gave them scripting so the question was – what, if any, were the additional benefits to doing PowerShell. Vivek gave a great answer that I thought I would share with you:

• Rich Cmdline based interface
  • COM == developer experience NOT admin experience. Admins are not programmers. Admins don't want to install Visual studio to "manage" their servers.
  • Cmdline creates a virtuous cycle between the user and the system. Contrary to current scripting engines, you can actually safely experiment through the cmdline to create scripts. Again, without this interactive experience, admins are lost when it comes to scripting.
• More secure scripting engine
  • PowerShell supports cert based signed scripts and by default is super restricted in operation
  • PowerShell support group policy based control of the environment
• 100% consistency between our user interfaces
  • Now that everything runs through PowerShell in our management UIs, users are guaranteed that they see the same validation, errors, behavior across the board. Consistency == happier users
• Its easier and more flexible to build user interfaces as the business logic is encapsulated outside of the user interface layer
  • Since there is one authoritative layer (PowerShell Cmdlets) that contain business logic, we have flexibility in our UI. For example, if we went to wed admin in the future, we only have to rewrite our UI bits, but can carry forward our Cmdlet business logic
• 100% automation for every single management operation in Exchange
  • What we think should be automatable is different than what users expect. Since PowerShell gives us an easier way to develop management software we can get to 100% automation easier than before
• 100% automatable setup
  • Our setup is PowerShell based and is essentially script based. You can do a complete lights-out setup for Exchange on a server using our setup.exe and PowerShell scripts  
• Consistent 3^rd party and partner story
  • We used to have a variety of APIs: COM, WMI etc. None of them were complete or consistent. By forcing ourselves to consume PowerShell, we ultimately shipped one API that is 100% comprehensive---what we use is exactly what 3^rd parties use.
• Faster development for component teams
  • We use a "self-service" model where each team in Exchange builds their own Cmdlets. This a) allows them to develop management of their feature while writing the feature and b) allows better management of the feature as the feature expert is building the Cmdlets. Users benefit from the higher quality, component teams are essentially "in control" of their features.
• Better management testability
  • Since component teams build Cmdlets while they build a feature, they can unblock the test team to test the feature using real code. In the past the GUI team was the long pole in a ship cycle as they built the management for the whole Exchange team. In the self-service model component teams are "unblocked" from this bottle neck and can start their testing much earlier.
• Internal infrastructure improvements
  • Since everything management related is 100% automatable, our daily tests and BVTs actually use PowerShell scripts as part of the Exchange automated testing. This means less one-off code has to be rewritten in order to automatically test Exchange
• Better together
  • We expect our admins to leverage PowerShell to manage other related services / products in a similar fashion as Exchange---since PowerShell has a great cross-product composability model, it is much easier for our admins if everyone is using Powershell.
• Plus it's just plain cool and is constantly winning the hearts and minds of our customers.

Any guesses why I'm a charter member of the Vivek Sharma fan club?

The Exchange team totally got PowerShell when other people looked at us like we had a rat's tail hanging out of our mouths. They are a high IQ team.

Jeffrey Snover [MSFT]
Windows PowerShell/MMC 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