PowerShell Benefits Over COM Scripting

  • Comments 7

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 3rd 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 3rd 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:
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

Leave a Comment
  • Please add 4 and 8 and type the answer here:
  • Post
  • I thought PowerShell for Vista was coming yesterday... not even a blog post to say "it's coming" or "we're late because..."


    I keep drooling over all the bloggers talking about PowerShell, but I can't use it yet!

  • > I thought PowerShell for Vista was coming yesterday...

    Your wait is over:


    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

  • Hi Jeffrey,

    What would be really interesting -- both for powershell fans and vista developers -- is: what exactly had to be changed for PowerShell to run smoothly on Vista?

    - Oisin



  • Is it possible, in some way/shape/form, to replace CMD.EXE with PowerShell system-wide? As in, use PowerShell as a default command prompt?

  • Chris;

    That would depend -- truthfully, it's probably not something you want to remove completely. It's an operating system component, so lots of little programs (i.e.: shareware, etc) assume that it exists. See some background here: http://www.leeholmes.com/blog/NothingSolvesEverythingPowerShellAndOtherTechnologies.aspx. You've also got situations where applications ship with batch files to help you work with them -- such as the vsvars32.bat that ships with Visual Studio. PowerShell can't interpret .bat or .cmd files, so you'd be out of luck there.

    That said, it is absolutely possible to use PowerShell for all of your command prompt needs. For that, you just type Start | Run | "powershell" instead of Start | Run | "cmd". If you use a shortcut to launch cmd.exe, have it launch PowerShell instead.

    Glad to hear you're kicking the tires :)


    Lee Holmes [MSFT]

    Windows PowerShell Development

    Microsoft Corporation

  • Cool. Was the question to Vivek from the AD team?

    Serious question - what's the state of the AD team's support for PowerShell; and if it isn't going to be "any day now" what can I do as a customer to speed up the process?



  • I've been doing interactive JScript for years, using a simple read-eval-print loop. Some COM automation works very well. Others, not so much. Powershell is so much better.

Page 1 of 1 (7 items)

PowerShell Benefits Over COM Scripting