Scorecarding My 2009 Resolutions

  • Comments 14

A year ago I broke my habit and made a set of News Years resolutions and then published them on the team blog HERE.  Lee Holmes suggested I go back and review how I did on those.  Glug!  Let’s give it a go:

  1. Ship a great PowerShell V2, WSMAN, BITS, WMI, and Server Manager with W7 & WS08R2.
    • Nailed it.  I am super happy with what we delivered in W7 and WS08R2.  You like to say that “no one cares about your first million lines of code’ but they then allow you to write a couple hundred (or thousand) lines of code and deliver amazing functions.  The stuff we delivered really proved that point.  I am absolutely amazed but the amount of functions were are able to deliver.  I need to quickly add:
      1. We still need more.  We are digging ourselves out of a 30 year hole and that takes a while.  Still, I think we and our partners (within the company and in the industry) have delivered enough that it delivers critical mass of functions such that it makes sense for all but the lowest skilled/lowest ambition admins (the people that will eventually leave IT to start a band, work as a hair stylist, or work the drive-thru window at a fast food restaurant) to jump on board and use the technologies.
      2. I talked to an PowerShell MVP recently who said that with V2, they no longer felt like they knew everything about PowerShell.  My response was that given how much we delivered in V2, no one knew everything about PowerShell anymore – not me, not Bruce, not Lee – no one!
      3. We delivered a ton of new code that we can do the same trick for the next version of the technologies.  We are in the process of working on the next version of  Microsoft BaseLine Configuration Analyzer (MBCA).  You’ll have to wait a while to hear the details but let me say this – we were able to do the trick of writing a small amount of code to stitch together what was already there to deliver mind-bending results.  The future looks VERY bright!
  2. Bundle PowerShell V2, WSMAN, and BITs into a single management platform download that supports downlevel machines.
    • Nailed the delivery.  This topic deserves a blog entry all of by itself.  We delivered the Windows Management Framework for XP and above.  You have NO IDEA how difficult this was to do.  A few of us have been trying to do this for over 5 years!  
    • Weak on the rollout.  We did a poor job of rolling this out.  We announced it via a set of blog postings without any real marketing/evangelization push.  We gave it a new name (which was the right thing to do) but without marketing the awareness of this new name, it has lead to confusion.
  3. Encourage the industry adoption of WSMAN by educating people on the value of the protocol and PowerShell's use and support for the protocol.
    • Mixed.  I think we’ve done a reasonable job delivering and communicating our support and usage of WSMAN.  I think that PowerShell’s support of WSMAN is the critical element here because it means that device vendors can immediately benefit by implementing WSMAN agents.  In the past, these vendors had to wait for the management products to support the new protocol (and then wait until customers bought that new generation of products) before there was any payback on their investment.  Because PowerShell V2 has a set of WSMAN cmdlets, IT pros can write scripts to manage these new devices.  That said, we have more work to do to fully support the latest version of the standard.
  4. Encourage the writing of WMI providers by educating people on the value of WMI and PowerShell's support for WMI.
    • Poor.  We improved the PowerShell experience of working with WMI which dramatically increased the value of writing WMI providers.  I don’t think we have done a good job communicating this.
  5. Encourage the community to write and share PowerShell scripts and educate them on the features we put into V2 to make this easier/better.
    • Mixed.  On the plus side we delivered a number of features (like Modules, comment-based help, etc) that make it easy to deliver and share high quality scripts and I think we’ve been very consistent and clear about communicating the need for the community to work together to share scripts.  There are a number of script sharing sites but I don’t have a good feel for how much IT Pros are using them.
  6. Seek out complainers and listen carefully for what we should be doing better.  Encourage people to tell us when and where we screw up.
    • Great.  Our heads and our hearts are in the right place on this one.  We do a good job encouraging people to tell us when and where we need to do better and listen to this input without our egos getting in the way.  I’ve never worked with a team so open to tough feedback.
      • That said, we understand the difficulties caused by having to respond to this feedback on the Windows release cycle.  That is inescapable cost of ubiquity.
  7. Get us on a plan to deliver solutions on a faster pace then OS releases.
    • Fail.
  8. Figure out the right long-term architecture for the optimal integration of PowerShell, distributed job scheduling and workflow.
    • In progress.  If I was being hardcore, I’d give myself a FAIL on this because it isn’t figured out yet.  That said, we’re working on it and I’m really happy with the direction so while there are no promises - watch this space.
  9. Figure out the right mechanism for Rich Internet Applications (RIAs - e.g. Silverlight or AJAX apps) to talk to PowerShell across the web.
    • Fail.  Watch this space.
  10. Promulgate the benefits and techniques of metaprogramming using PowerShell.
    • Mixed.  I don’t think we have done a good job educating people on the power of PowerShell.  That said, I did contact Jaykul and showed him how to use some metaprogramming for PowerBoots to reduce the coding required by maybe an order of magnitude.  He did a great job running with that.  We just need a couple hundred more examples.
  11. Develop or encourage the development of one or more PowerShell-based GUI scripting libraries (ala TK).
    • Success.  I’m pleased to see both PowerBoots and WPK in this space.  Both of these efforts are awesome and show what I knew was going to be the case – Scripting GUIs in PowerShell is going to ROCK!
  12. Ensure that everyone knows how easy it is to develop Delegated Web-Based Self-Service Portals using PowerShell.
    • Mixed.  Ok – as read – it should be “Fail” because I said “everyone” and that is clearly not the case.  That said, this was the highlight of my talk at TechEd and we had an entire session on this at the PDC so we are getting the story out there.  We have Exchange which is using this model in production and we have at least one other large server product using this (but not discussing it publically). 
  13. Ship our internal Cmdlet Designer tool so that everyone can design large sets of Cmdlets in a consistent coherent fashion.
    • Success.  We shipped this in Oct.  The announcement is HERE.  Sadly I haven’t seen much feedback on it.


All and all, I’m very happy with the year but there are still lots of opportunity to improve.

Experiment!  Enjoy!  Engage!

Jeffrey Snover [MSFT]
Distinguished Engineer
Visit the Windows PowerShell Team blog at:
Visit the Windows PowerShell ScriptCenter at:

Leave a Comment
  • Please add 6 and 6 and type the answer here:
  • Post
  • Hi; I'm curious to what you refer by "We are digging ourselves out of a 30 year hole".  What's the 30-year hole?  My first guess is "dependence on shell/scripting languages other than Microsoft ones" (Perl comes to mind)?

  • Good post Jeffrey. Regarding WMI, there's still a fair amount of misplaced optimism out there that powershell is _replacing_ it rather than augmenting it. This will be a tough nut to crack.

  • With #6:

    There were times when I wanted to complain in the Connect site, but since I'm not really a part of the target audience for Powershell, I didn't want to get in the way.

    I'm not really sure how many others like me are out there.

    Happy New Year!

  • @Matthew - 30 year hole is the lack of good command line management and interactive shells.

    @Oisin - I agree that there is confusion about PS replacing WMI.  I've NEVER understood it.  

    @Francis - Provide feedback and trust us to make the judgement call.


  • Hi Jeffrey, good review - I continue to think you guys do a fantastic job given the wide range of inputs coming your way!  

    I love WPK and have used it to write a tabbed application for running a badminton league - excellent.  If James can fix the (BAD) bug and if the doc can be improved then it's a winner.

    What are your resolutions for this year?!  It's been a bit quiet from the team on direction after V2.  Can you tease us some more?

    Thanks guys!


  • Great going PowerShell Team!

    Excellent assessment Jeffery

    I am sure you have already thought of the following but just in case:

    Now that no one person can know all of PowerShell there is more danger of it becoming fragments.  All of the hard work to build and implement a strong design specification will help but constant vigilance is still needed.

    WMI may be an issue in PowerShell for some due to overall  nomenclature of Windows Management parts.  This will sort out when users start using WMI in PowerShell.  To lake this better the team needs to eliminate some inconsistencies and deficiencies in WMI implementation in PowerShell. A better implementation of WMI SDK would go a long way towards getting more vendors and developers to “instrument” their products.  I am sure that this will happen soon as the Windows Management Team has been very busy lately.  What they have been doing is starting to become exciting. Hurrah!

  • Great post and great job for you all.

    As I am working with WMI almost every day I love new WMI cmdlets in v2 and I am looking forward for working with them in 2010.


    P.S.: I like this: "no one knew everything about PowerShell anymore – not me, not Bruce, not Lee – no one!"

  • Great post and great job PowerShell Team.

    In regards to #5, are there script sharing sites you can recommend?  I have found a few but if you recommend it I will trust it to be a useful site.


  • re: Ensure that everyone knows how easy it is to develop Delegated Web-Based Self-Service Portals using PowerShell.

    Sounds great where do I find "the highlight of my talk at TechEd"?  Is there a video or the material for another great post?

    BTW: Great work powershell team.  It is best new tool I have learnt in YEARS!  Scripting is actually enjoyable on Windows.  I never thought I would see the day and didn't imagine it could be SO good.

  • I used to like PowerShell.

    Now I do not. I find your documentation fragmentary and a mess. I don't want to have to search through tens of blogs (most of which I probably don't even know that exist) to find out how to do simplestuff.

  • @Matt,

    Well, the good thing is that what you liked with v1 is still there for you to like in v2.  Yes, v2 gives you more power, but I wouldn't necessarily qualify some of the new features as simple...  Do may require a little bit of research, but once learned, you'll get all the benefits.

  • Good!

    Now, if you could add "Make PowerShell remoting on Windows at least as seamless and flexible as SSH on Unix" to your list for 2010, it would be quite nice!  ;)

  • @L.  I second that.  SSH can be both open (think cygwin, copssh, etc.) and closed (think, pragma, bitvise, etc.) while:

    - providing remote command exectution

    - providing remote file transfer

    - scriptable commands both interactive and non-interactive, password and key-exchange

    - cross platform compatibility (every OS and some mobile OS's have SSH)

    - firewall friendly  (single port, single protocol, no conflicts with other software, etc.)

    - providing secure tunneling and proxy ability for other protocols, especially through firewalls (see above)

    BITS over SSL will never have some of those.  I don't understand the reasoning.  I've been waiting for native SSH from Microsoft for about 10 years now.  We buy and use an SSH server software for every Windows system.  It's a cost of doing business for now.  Of course, we looking for ways to reduce costs... so maybe they'll include SSH in the next version of PowerShell or Windows.  Or take that thread wherever you want.

    Noone wants to shell out more money for SSH than the cost of the OS to install it on.  Especially when the other OS's (Linux, Solaris, Mac, etc.) include it for free.

    If I had a wish-list Jeffrey, that would be number 1 for me.  An included SSH server that plays very well with the rest of my systems, and powershell as the terminal behind it.

  • #13 - there's no download there.  Sounds great, didn't know, immediately went over there.  Currently vaporware.

Page 1 of 1 (14 items)

Scorecarding My 2009 Resolutions