Tag: PowerGUI

Celebrate St. Patrick’s Day with PowerGUI®!

Kirk MunroLeave a comment

Our creative design team has just provided me with another fun desktop wallpaper to share with you, just in time for St. Patrick’s Day.  If shamrocks and gold are your thing this time of year, download the St. Patrick’s Day PowerGUI wallpaper from PowerGUI.org and show your pride!

As usual, it comes in two different flavors: one with the freeware train and one with the PowerGUI Pro train.  Each screenshot has 8 different resolutions available, so pick whichever one suits you best.  I already have the PowerGUI Pro version installed on my laptop.

Enjoy!

Kirk out.

P.S. I can’t help but wonder what the little PowerGUI train had to drink that made gold bubbles come out of his smokestack. Smile

PowerShell Deep Dive Conference: April 17-19, 2011 in Las Vegas

Kirk Munro4 Comments

In case you haven’t heard already, there is a huge opportunity coming up to learn a lot more about PowerShell very quickly and interact directly with dozens of PowerShell experts face to face at the same time.  Next month marks the first ever PowerShell-specific conference, the PowerShell Deep Dive.  This conference will be held in the Red Rock Resort in Las Vegas, Nevada from April 17-19, 2011, and it will be an amazing experience for anyone interested in learning more about PowerShell.  The Deep Dive sessions will all be presented on April 18 and 19, following the welcome reception on the night of April 17.

Don’t be too intimidated by the name “Deep Dive” though.  The sessions will be a deep dive into PowerShell, that’s true, but there is a half-day 300-level Windows PowerShell Pre-Deep Dive Crash Course with Don Jones on April 17, 2011 that can help bring you up to speed if you’re close but not quite there yet.

Also, if you act now by emailing TEC2011@quest.com and sign up before the end of March, your Deep Dive conference fee will only cost you $850 US.  For the depth of knowledge covered and the calibre of the presentations and the attendees who will be attending, this conference is going to be worth every penny.

Speaking of attendees, you really should check out who’s already confirmed they will be attending this event.  Here’s a list of only a few of the speakers and attendees who have signed up so far:

    What’s incredible is that this list is only showing some of the amazing talent that will be at this event.  I would have recommended it as a must-attend event even with only a small fraction of the superstars I have listed above attending, but with this line-up, plus many, many more PowerShell superstars, this is going to be one truly memorable experience.
    I’ll be attending as well of course (I wouldn’t miss it!), and while there I will be presenting a full session on “Managing Hyper-V with PowerShell” and a Deep Dive talk on “Defining domain specific vocabularies using Windows PowerShell” as well.

Have I sold you on the idea yet?  If you want to learn more, head on over to the PowerShell Deep Dive page and read more about the event, or if you’ve already decided send an email to TEC2011@quest.com today to make sure you can take advantage of the $850 US pricing before the end of March!

Hope to see you in Vegas!

Kirk out.

PowerGUI® Script Editor Essentials 2.0

Kirk Munro3 Comments

Last week I had an absolutely incredible week at the 2011 MVP Summit.  It was without a doubt the best business trip I have ever taken, bar none.  What makes a conference great for me is not the sessions (although the sessions were awesome).  For me it’s all about the attendees.  Being able to interact every day for an entire week with PowerShell MVPs and Microsoft PowerShell team members was truly an incredible experience, something that you just don’t get day to day when you’re in the office dealing with so many distractions.

While at the Summit I was meeting with some PowerShell MVPs, chatting about PowerGUI and PowerGUI Pro, and getting feedback on the two products (and taking a lot of notes!).  Claus Nielsen, a fellow PowerShell MVP from Denmark was sharing some of his ideas with me and one feature he requested was scroll buttons for our tabbed document interface to allow you to scroll the view to other tabs.  This is useful when you have many tabs open and you want to reorganize them or just scroll through the ones you have open.

I get a lot of requests from the online community as well, some of which come via twitter.  These don’t necessarily come from MVPs, although the one I’m about to use as an example does.  Brian H. Madsen (@csharpzealot) tweeted about having issues when running PowerGUI and not realizing he was in the 32-bit version of the console on a 64-bit machine.  Since you can run PowerGUI in 32-bit or 64-bit, elevated or not, it can be very useful to know how you opened it when you are working with the product.

Other feedback comes in the form of direct email.  One of our internal support reps was trying to figure out how to tell what encoding was used when saving a ps1 file because he was working with another product that didn’t seem to support that encoding.

A lot of this feedback turns into enhancement requests for the core product, but there are also many ideas that turn into features I can quickly implement in an Add-on.  All of the ideas I just mentioned in this post fall into the latter case, and between early mornings in my hotel room in Bellevue last week and a little time yesterday afternoon, I have finished implementing these (and more) in version 2.0 of the PowerGUI Script Editor Essentials Add-on.  This Add-on is definitely one of my favorites, right up there with the Blue Console Add-on and the Script Signing Add-on.  It comes with an indispensible feature set and whenever I install PowerGUI on a new system I immediately notice that it is missing and have to install it right away.

PowerGUI Script Editor Essentials 2.0 includes the following enhancements:

  • You can now view and change the current file encoding by using the File | Encoding submenu.  The menu items in this submenu will automatically save the current file and the checked item indicates the current encoding for the current file.
  • You can now use scroll buttons to view all of the tabs that you have open.  These scroll buttons are enabled by default, but you can always hide them or bring them back by using the View | Tab Scroll Buttons menu item.
  • You can now see more useful status information in the status bar.  This includes:
    • the current file encoding for saved files;
    • the current process architecture (64-bit or 32-bit) for 64-bit machines; and
    • the current elevation status if you are running PowerGUI in an elevated process.
      Here’s a screenshot showing you what the Script Editor looks like in an elevated process on a 64-bit system once you have this Add-on loaded:

image

I also fixed an issue preventing the shortcuts in this Add-on from working on some non-English operating systems, and I added icons that were missing for the Increase Indent and Decrease Indent menu items so that they show up as regular buttons if you add them to your toolbar.

These features are in addition to the features that came in the first version of this Add-on, which include support for :

  • enabling Word Wrap in your documents;
  • showing Whitespace in your documents;
  • using Virtual Whitespace when editing documents;
  • Zoom in and Zoom out while working with a document;
  • opening multiple files at once from the File | Open dialog; and
  • filtering for *.ps1xml, *.psc1, *.xml and *.txt files in the File | Open dialog.
    If you’d like to try this Add-on, follow these three steps:

1. Open the PowerGUI Script Editor and select Tools | Find Add-ons Online… in the menu.

2. In the dialog that appears, enter “Script Editor Essentials” into the text box and click on the Search button.

3. Once the Script Editor Essentials Add-on shows up in the results, click on the Add-on to select it and then click on the Install button to install the Add-on. This will download, unblock, install and load the Add-on in your Script Editor, and you’ll have these features in your favorite Script Editor in no time!

If you’re not connected to the web, you can also install this manually by following the steps outlined on the Script Editor Essentials Add-on page on PowerGUI.org.

    Now that this update is released, what else do you think qualifies as a Script Editor Essential feature?  As you can see, community feedback drives what we do, so please share your ideas!  We are listening.

Kirk out.

Create your own color theme for the embedded console in PowerGUI®

Kirk MunroLeave a comment

I really like the native PowerShell console look and feel.  Something about the blue theme applied to the native console puts me in a comfort zone, and it just works for me.  For a long time I have wanted to have the exact same color theme to be applied to the embedded PowerShell console in PowerGUI, and with the release of PowerGUI 2.4 I can finally create that theme.

Here’s what the themed console looks like in PowerGUI now that we have full color support:

image

If you would like the same experience in your embedded console, all you need to do is install the Blue Console Add-on in PowerGUI by following these three steps:

1. Open the PowerGUI Script Editor and select Tools | Find Add-ons Online… in the menu.

2. In the dialog that appears, enter “Blue Console” into the text box and click on the Search button.

3. Once the Blue Console Add-on shows up in the results, click on the Add-on to select it and then click on the Install button to install the Add-on.  This will download, unblock, install and load the Add-on in your Script Editor, and you’ll have a native blue theme applied in no time!

If you’re not connected to the web, you can also install this manually by following the steps outlined on the Blue Console Add-on page on PowerGUI.org.

Now that the PowerGUI Script Editor SDK supports any color in the embedded console, you can even create your own themes.  The Add-on is just a PowerShell module and you can look at how it sets the colors internally to see how you could create your own theme.  If you’re feeling ambitious, you could even build a theme-chooser Add-on something like the Script Colors Add-on by Denniver Reining and allow people to import/export color themes so that they can share them with one another.  I think an Add-on like that would be fantastic for the Script Editor, and I can already think of a half dozen features I’d like to see in it.  If you’re going to create an Add-on, be sure to install the Authoring Toolkit Add-on that I blogged about yesterday so that you’re working with all of the tools available to make it easier for you.

Enjoy!

Kirk out.

PowerGUI® Script Editor Authoring Toolkit Add-on 2.0

Kirk Munro1 Comment

Have you ever thought of a feature that you wished was included as part of the PowerGUI Script Editor?  When thinking about features you would like to see, did you realize that you can create many features yourself and share them with others?  The rich Add-on SDK that is included in the PowerGUI Script Editor allows you to do just that.  This SDK allows you to customize the Script Editor to your hearts content, adding, modifying or removing menus, submenus, menu items, toolbar, toolbar buttons, editor commands, or dockable windows.  It also allows you to work directly with the contents of documents that are open in the editor, or use events to control editor behaviour.

Today Add-on creation with the PowerGUI Script Editor SDK just got even easier.  I just published version 2.0 of the Authoring Toolkit Add-on on PowerGUI.org.  This Add-on adds a File | New | Add-on… menu item as well as a toolbar button to facilitate the creation of the Add-on itself, just like it did before.  What it also includes now though is a set of 49 snippets that facilitate working with the Script Editor SDK.  Want to create a new menu item?  There’s a snippet for that.  How about a toolbar button?  Or a dockable window?  There are snippets for those too.  There are even snippets for adding invoking and invoked events to commands included in the editor, allowing you to override or extend the behaviour of commands that are included in the Script Editor by default.  Some of these snippets were previously published as a separate download that you had to manually install on your system.  In the new 2.0 release, there are about 50% more snippets than in the past, the existing snippets have been updated to support new features added to PowerGUI 2.4, and these snippets are automatically installed with the Authoring Toolkit Add-on so that you can get started with your own Add-ons much more quickly.

To experiment with Add-on creation, all you need to do is follow four easy steps:

1. Open the PowerGUI Script Editor and select Tools | Find Add-ons Online… in the menu.

2. In the dialog that appears, enter “Authoring Toolkit” into the text box and click on the Search button.

3. Once the Authoring Toolkit Add-on shows up in the results, click on the Add-on to select it and then click on the Install button to install the Add-on.

4. Wait a moment while the Add-on downloads, unblocks, installs and loads in the Script Editor.  Now select File | New | Add-on… to start creating an Add-on and then with your Add-on psm1 file open, select Edit | Insert Snippet… to start inserting Add-on snippets in your Add-on.

Once you have the Authoring Toolkit Add-on installed, I recommend watching the “Create an Add-on in 10 Minutes” screencast to see how you can create your own Add-on.  Fast forward the parts that show you how to set-up the Add-on and the snippets because you just did that, and watch the rest of the demo showing how you can create your own Add-on in only 10 minutes.

At this point you should be pretty much ready to get started with your first Add-on, but extra documentation never hurts.  If you would like to read more about Add-on creation, I recommend the Add-on SDK documentation and the Building Your First PowerGUI Script Editor Add-on tutorial.  Both of these resources may come in handy as you experiment with the Add-on SDK.

Thanks for listening, and if you have any feedback or suggestions that you would like to share, or questions you would like to ask about Add-on creation or anything else PowerShell or PowerGUI related, I’m always listening.

Kirk out.

PowerGUI® Pro and PowerGUI® 2.4 are now available!

Kirk Munro4 Comments

I am pleased to announce that PowerGUI Pro 2.4 and PowerGUI 2.4 have been released to the web and are now available for download!

This release includes the following improvements:

Easy Remote Script Execution (PowerGUI Pro only)

The PowerGUI Pro Script Editor now supports easy remote execution of scripts.  You can now run an entire script or a portion of a script on one or more systems using PowerShell 2.0 remoting.  This feature allows you to either provide a static list of computer names or you can select a remoting configuration that you want to use when running your script remotely.

image

See that View Remoting Script button in the screenshot above?  You can use that button to generate a script that will run your script remotely.  Clicking on that button will open the remoting script in a new document in the Script Editor so that you can then save it separately and then use it on other machines, in a scheduled task, a background job, etc.

The remoting configurations support allows you to use a static list of computer names or a script to dynamically determine the list of target computers.  You can also configure any remoting options that should be used when running the script.  This includes options for configuring the URI address, proxy server credentials, certificates, security context, background job support, throttling, and other more advanced items.

image

Remoting configurations support every remoting option that is directly available in PowerShell 2.0, and some options that are not directly available as well.

Improved MobileShell Experience with Collapsible Command Groups (PowerGUI Pro only)

When you are accessing PowerGUI Pro MobileShell from your mobile device, your commands will now appear inside of collapsible groups.  There will be one group for favorite commands and one group for each module associated to your MobileShell user account.  This new user experience makes it easier to work with a large set of commands from small mobile devices such as an iPhone, Android, BlackBerry, or Windows Phone 7 device.

Add-on Discovery and Installation

In both PowerGUI Pro and PowerGUI, the Script Editor now allows you to search for Add-ons and install them with a single button click.  This eliminates the need to manually download, unblock and load Script Editor Add-ons. With this feature you can search for Add-ons using keywords or phrases like “script signing” or “transcription”, or you can see a list of all Add-ons that are available by performing a search with no keywords.  Just open the Tools menu, and then click on Find Add-ons Online… to search for Add-ons in the Add-on category on PowerGUI.org.

image

Once you see the Add-on you want to install, simply click on it and then click on the Install button and the Add-on will download, install and load automatically in your Script Editor.

Remote session Intellisense, Syntax Highlighting and F1 Help

In an earlier release of PowerGUI Pro and PowerGUI we added support for the Enter-PSSession and Exit-PSSession cmdlets to the Script Editor to allow you to work with remote systems from within remote sessions.  In this release we’ve taken that support further, providing you with Intellisense, Syntax Highlighting and F1 help support while you are working inside of a remote session.  This makes it much easier to work with servers such as Exchange 2010 or SharePoint 2010, where remoting is required.

Automatic Reload of Modules on Runspace Reset

PowerGUI Pro and PowerGUI allow you to automatically reset your runspace every time you start debugging.  This is a feature we have had for a long time, and it allows you to debug from a clean system state.  In 2.4, this support has been enhanced so that modules are automatically reloaded when the runspace is reset in this manner, ensuring that you only have loaded what you want to have loaded.  This also ensures that any module On Remove event handlers are called before modules are reloaded again, and that modules are in a clean state when you start debugging.

Script Editor SDK Enhancements

This release of PowerGUI Pro and PowerGUI includes several enhancements to the Script Editor SDK that allow you to create more advanced Add-ons than you could in the past.  New to this version is an Execute method on the root of the SDK that allows you to invoke PowerShell commands as if you had typed them into the embedded console.  This allows more control over how Add-ons send feedback back to the end user.  Also new to this version, you can now directly access the colors used in the embedded PowerShell console via the SDK, allowing you to apply whatever color theme you want for your day-to-day use of the Script Editor.  Menu item and toolbar capabilities have been enhanced as well, so that you can get or set Checkable, Checked and Enabled properties on commands in the Script Editor, and the corresponding menu items and toolbar buttons will automatically show you the appropriate change in state.

How to Install or Upgrade

If you haven’t tried PowerGUI Pro, now’s a great time to do so.  The new remoting feature is just great, and MobileShell keeps getting better and better every time we release.  If you want to try it out, go to www.powerguipro.com and click on the Try button to try it out for a bit.

To upgrade to the new release, you can either manually check for updates by clicking on Check for Updates from the Help menu, or you can wait until the next day that you start up one of the components and it will detect the update for you automatically.  If you have disabled auto-update or if you are working on a system that does not have online access, you can download the bits for offline install by visiting Quest SupportLink if you are using PowerGUI Pro or the PowerGUI downloads page if you are using the free version of PowerGUI.

Share your feedback!

I’d love to hear what you think of these new releases, so please let me know in the comments on this blog post or in our forums on PowerGUI.org.  This is only the first of many exciting releases we have planned for this year.  If you have features you would like to see added or changed in the product, please share your feedback with us.  It directly influences what we include in our releases, and ultimately makes PowerGUI Pro and PowerGUI better for everyone!

Thanks,

Kirk out.

PowerShell Cheat Sheet for Lync Server 2010

Kirk Munro2 Comments

Curtis Johnstone, Lync Server MVP and author of the Inside OCS and Inside Lync blogs just published a PowerShell cheat sheet for Lync Server 2010.  This cheat sheet contains a lot of information to help you get the most out of your Lync Server management experience by leveraging the Windows PowerShell support that is included with Lync Server 2010.

This cheat sheet includes commands and documentation to help you manage permissions, users, client policies, devices, address books, sites, pools, servers, computers, enterprise voice settings, and certificates more easily using PowerShell.  It also includes a list of gotchas that you may encounter when working with Lync policy scopes and explains how to deal with those gotchas more easily.

You can find this cheat sheet in the PowerGUI.org library, or you can get to it directly via www.insidelync.com/PSCheatSheet.  Download it today and keep it with you, either in your favorite PDF reader or hung in your cubicle – it should come in very handy.

This is our second PowerShell cheat sheet we have made available for free on PowerGUI.org.  Last year we published a SharePoint 2010 PowerShell cheat sheet.  If you have any suggestions on additional content that you would like added to either of these cheat sheets, or if there are other server products or platforms that you would like to see cheat sheets for in the future, please let me know in the comments and I’ll see what I can do.

Kirk out.

VMware vSphere PowerPack beta, now with PowerCLI 4.1 and later support

Kirk Munro11 Comments

If you’ve been following my blog you probably heard that we hit a bit of a stumbling block with our VMware PowerPack with versions 4.1 and 4.1.1 of the PowerCLI.  There are some changes in those versions that break compatibility with previous versions of the PowerCLI, and this prevented our PowerPack from working with either of those two versions.  I had also mentioned on my blog that I anticipated we would provide two separate versions of our PowerPack in the short term, one that works with PowerCLI 4.0 U1 only and another that works with PowerCLI 4.1 and later.  Well I’m happy to let you know that I just finished uploading a beta version of the VMware vSphere PowerPack with PowerCLI 4.1 support to the PowerGUI® website.  This version has been posted in the same document in the PowerPack Library that contains the other version of the VMware PowerPack, so now there are two files to choose from when you visit the VMware vSphere PowerPack download page:

  1. VMware.VIToolkit.powerpack.  This file contains the version of the PowerPack that requires version 4.0 U1 of the PowerCLI and that ships with PowerGUI Pro and PowerGUI 2.3.
  2. VMware.PowerCLI.4.1.powerpack.  This file contains the beta version of the PowerPack that works with PowerCLI 4.1 and later releases.

A number of you have been asking via twitter if we have PowerCLI 4.1 (and PowerCLI 4.1 U1) support, and now we do, in beta form at least.  The functionality between the two versions is identical, with the exception of two minor bug fixes in the beta version that I came across during testing that are not yet fixed in the other version.

If you want to try out the beta version of this PowerPack, here is what you need to do:

If you are using PowerGUI Pro or PowerGUI 2.4 and you have the VMware PowerPack and PowerCLI 4.0 U1 already installed:

  1. Open the PowerGUI Admin Console.
  2. Select File | PowerPack Management.
  3. Browse down to the VMware PowerPack and select it.
  4. Click on the Remove button to remove the VMware PowerPack.
  5. Click on OK to close the PowerPack Management dialog.
  6. Close the PowerGUI Admin Console.
  7. Uninstall PowerCLI 4.0 U1.
  8. Download and install PowerCLI 4.1 U1 (or 4.1 if you prefer).
  9. Download the VMware.PowerCLI.4.1.powerpack that is linked earlier in this blog post.
  10. Open the PowerGUI Admin Console.
  11. Select File | PowerPack Management.
  12. Click on the Import button.
  13. Browse to the location where you put the VMware.PowerCLI.4.1.powerpack file that you downloaded in step 9, select it, and click on Open.
  14. Click on OK to close the PowerPack Management dialog.

If you do not have the VMware PowerPack installed simply follow steps 7 through 14 in the list above.

At this point you should be up and running with the beta version of the VMware PowerPack with PowerCLI 4.1 U1 (or 4.1 if that is what you installed).

Please use the PowerGUI Forums if you have any feedback you want to share or issues you want to report regarding the beta release of this PowerPack.

Enjoy!

Kirk out.

PowerShell MVP for 2011

Kirk Munro5 Comments

Did I ever mention how much I think my kids are great? Smile

Last year I blogged about a very cool Lego model of PowerGUI® that I received from my kids for my birthday.  It turns out that this was mostly the work of my son, and my daughter (who refused to be outdone) decided she wanted to offer me something equally special on her own for Christmas that I could also share on my blog.  She knows how important my MVP award is to me, so on Christmas morning she gave me this great gift:

Microsoft PowerShell MVP - Kirk A Munro

What more could a person ask for?  And isn’t Lego just the coolest toy ever? Smile

When I first saw this it reminded me of the original Microsoft logo from 1983. It’s not quite the same as that logo, but it definitely came to mind when I saw it.

Of course upon receiving this there was a little nervous anticipation as I waited until January 1, 2011 to see if I was re-awarded the PowerShell MVP award again, but sure enough I received the email that morning.  Thanks Microsoft for allowing me to continue my work as a PowerShell MVP for another year!  PowerShell is a truly exciting product to work with, and with all of the innovative solutions in that space (check out PowerGUI Pro, I highly recommend it!), and the strong community that is really second to none, 2011 looks like it will be another very exciting year to continue working with PowerShell!

Kirk out.

PowerCLI 4.1 U1: Current state of affairs

Kirk Munro4 Comments

UPDATE 10-JAN-11: To deal with the issues identified below, I published a beta version of the VMware vSphere PowerPack with PowerCLI 4.1 or later support.  You can read more about the beta and how to install it here.

Luc Dekens suggested that I share my concerns about upgrading to PowerCLI 4.1 U1 here so that the rest of the community could be aware of some of the details behind the issues between upgrading from PowerCLI 4.0 U1 to version 4.1 or 4.1 U1.  Ask and ye shall receive. Smile

Back in July 2010 I shared my concerns about upgrading to version 4.1 of the PowerCLI due to a number of breaking changes introduced in that release.  These changes were far reaching and have caused us challenges as we try to support the VMware community with our VMware PowerPack for PowerGUI®.  A little while later, Scott Herold sat down with members of the PowerCLI team and they agreed to put in temporary support for the old object model as part of their 4.1 U1 release, so going forward this seemed like it would give us a smooth upgrade path for our customers.  PowerCLI 4.1 U1 was released earlier this month, and it was supposed to address these issues while also including great new enhancements for the community.  Unfortunately we were not aware of the release schedule for the PowerCLI, nor were we provided early release versions to work with, so while we were working on our PowerGUI Pro and PowerGUI 2.3 releases which included (among many other things) the VMware PowerPack for the first time, we had no choice but to include a firm requirement in the installer for PowerCLI 4.0 U1.  This is why the VMware PowerPack will not install with PowerGUI Pro or PowerGUI 2.3 if you are using any version of the PowerCLI other than 4.0 U1.  As a result, the inclusion of the VMware PowerPack in PowerGUI has met mixed reviews because many community members expected it to work with PowerCLI 4.1.1 out of the box, however we had no knowledge of that release during our own release cycle so we simply could not build-in support for that release.

Now that PowerGUI Pro and PowerGUI 2.3 are released as well as VMware’s PowerCLI 4.1 U1 though, which is supposed to come with complete support for the old type names, I suspected that I would be able to manually upgrade my PowerCLI to the latest version and that my PowerPack would continue to function the way it did before, possibly having a few minor issues to deal with.  That suspicion has proved incorrect because of a number of problems.  Based on my initial testing, here are the issues that I see in PowerCLI 4.1 U1:

  1. PowerCLI 4.1 U1 still returns the same type hierarchies that were returned in PowerCLI 4.1, which are not compatible with the VMware PowerPack which is based on the 4.0 U1 types.  As indicated on the blog post titled “PowerCLI 4.1: A fork in the road”, these incompatibilities affect many community-driven content that is based on the PowerCLI, including the VMware PowerPack, the VMware Community PowerPack, books, blog posts, shared scripts on PoshCode, the VMware VI Toolkit Extensions module, etc.  I have tested multiple commands (Get-VMHost, Get-VM, Get-Cluster, Get-Datacenter) against multiple labs using PowerCLI 4.1 U1 and none of them show the old type names, so backward compatibility is still broken as far as I can tell.
  2. When you invoke a PowerCLI cmdlet like Get-VM, if you show all of the properties for those VMs you will now see warnings about properties that are to be deprecated in a future release.  The properties still work today, but the warning indicates they are obsolete and therefore they are not guaranteed to work tomorrow.  The trouble is you see these warnings even if you are not directly using those properties.  For example, if you invoke Get-VM and pipe that to Format-List * to see all properties, you’ll see warnings in the output before you see the results.  In this case the warnings are benign (unless there are other warnings mixed in that should get your attention), however it shows a disturbing trend that VMware has taken to changing PowerCLI object data such that scripts that work today are not guaranteed to work tomorrow unless they are updated when the existing properties are deprecated, causing multiple rifts between users are on the current release and those who don’t upgrade right away.  It means you will see multiple ways to do things in scripts over time that have different properties, and when you view those scripts you may or may not be aware of which is current so this is bound to cause some user confusion.  This also makes it difficult for anyone to consider upgrading if you use anything with scripts that are dependent on the PowerCLI (PowerPacks for example), because there is no guarantee with this approach that those will not break when you switch from one version to the next unless you are sure they have upgraded to support new releases as well where object properties may deprecate over time.  Blog content that normally could be published and left as is for a very long time may become out of date more quickly.  Books will have a much more limited lifetime if they don’t use the right properties.  And so on.

Breaking changes in any programming language are considered something to completely avoid unless those changes are absolutely necessary.  On those rare few occasions when they are necessary, there are mechanisms in place that allow you to reduce the impact of those breaking changes (side-by-side versions for example).  PowerShell has a rich Extended Type System that allows for type extensions so that you can evolve objects over time, using alias properties, script properties, code methods, etc. to allow you to continue supporting older versions while you upgrade your technology to new versions.  All of these together should give cmdlet authors enough flexibility that they don’t need to introduce breaking changes haphazardly like this.  Unfortunately I don’t feel that VMware gets this yet, but I continue to try to evangelize this and work with them so that this gets easier going forward.

If you have any questions about any of this, please don’t hesitate to ask.

Thanks,

Kirk out.