vWorkspace PowerPack: A great example of the power and flexibility you get from PowerShell and PowerGUI®
Last week, the Quest vWorkspace guys showed their prowess once again when they released the first version of the vWorkspace PowerPack for PowerGUI® Pro and PowerGUI®. I love this PowerPack because it really demonstrates how PowerGUI is so complementary to PowerShell. To see what I mean, take a look at the following screenshot:
This screenshot shows two major improvements to the vWorkspace management experience by demonstrating how you can use the vWorkspace PowerPack to perform management tasks across all farms, and by demonstrating how you can use the vWorkspace PowerPack to perform management tasks across all locations in a single farm or across all locations in all farms. In the native vWorkspace management user interface, you can only work with one farm at a time, and you can only work with one location at a time.
Scaling management tasks out in a product like this can take a long time when you need to build the capabilities into a native management user interface, and these days in many cases PowerShell is provided as the vehicle to satisfy larger scale automation and management needs. PowerShell is great and it definitely fits the bill for these medium to large enterprise needs, however it does not provide a user interface to facilitate those management scenarios. This is where the administrative console in PowerGUI Pro and PowerGUI really shines, because it allows you to build out rich PowerPacks with enterprise-ready solutions with very low cost and effort.
I spoke directly with Adam Driscoll (author of PowerGUI VSX, member of the vWorkspace team, and one of two developers who created the vWorkspace PowerPack) about this, and it took them less than one week to put this PowerPack together. That’s less than one week for two developers to create a rich, functional management user interface that not only provides many of the management capabilities that come with the vWorkspace management console, but that also adds additional enterprise capabilities that the vWorkspace management console does not provide natively. Aside from the multi-farm management and multi-location management features I mentioned earlier, it also allows administrators to upgrade the vWorkspace VM tools on the VMs you select, and it simplifies how administrators search for provisioning objects like templates, sysprep customizations, parent VHDs, and so on. And by building these capabilities into a PowerPack, vWorkspace administrators can perform custom filtering and sorting of the data in the grid, generate rich HTML reports for that data, export the data to an external file for use in other programs, and view the PowerShell scripts that are doing all of the work, all because those features come with the PowerGUI administrative console automatically. That’s an amazing feat for one weeks worth of effort!
The really sweet part of all of this is that it gets even better very soon. If you’ve been following my blog recently you’ve seen that we have released two betas of PowerGUI Pro 3.0 in the last little while which comes with many great features worth highlighting, however for now I only want to mention one: MobileShell. In PowerGUI Pro 3.0, you can provide administrators with a custom mobile management solution, defined using PowerPacks and tailored for their needs using role-based access control (RBAC). That means that once we release PowerGUI Pro 3.0 (which should happen very soon), the vWorkspace guys will be able to publish an update to their PowerPack that enables mobile management support so that vWorkspace administrators can have a mobile management solution for very little cost! All they will need once the vWorkspace PowerPack is updated to support this mobile management scenario is a license of PowerGUI Pro 3.0 for each administrator who wants to manage their vWorkspace environment from their webkit-enabled mobile device. Considering that it also allows those administrators to create executable files from PowerShell scripts, work with integrated version control in a best-in-class script editor, manage systems remotely using easy PowerShell remoting capabilities, find functions they are working with using go to definition support for functions, and more, the PowerGUI Pro price of $199/user is a pretty good value.
If you are at all interested in VDI, you should give vWorkspace a look because it’s an awesome solution that keeps getting better all the time. If you use vWorkspace already I encourage you to take a look at the PowerShell capabilities that this team is providing, particularly in the PowerPack, because a ton of additional value is being provided here that is worth checking out. You can find the installation instructions for the PowerPack on the vWorkspace PowerPack page on PowerGUI.org.
That’s it for this post. If you have any questions or feedback, please don’t hesitate to reply in the comments below.
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:
- 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.
- 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:
- Open the PowerGUI Admin Console.
- Select File | PowerPack Management.
- Browse down to the VMware PowerPack and select it.
- Click on the Remove button to remove the VMware PowerPack.
- Click on OK to close the PowerPack Management dialog.
- Close the PowerGUI Admin Console.
- Uninstall PowerCLI 4.0 U1.
- Download and install PowerCLI 4.1 U1 (or 4.1 if you prefer).
- Download the VMware.PowerCLI.4.1.powerpack that is linked earlier in this blog post.
- Open the PowerGUI Admin Console.
- Select File | PowerPack Management.
- Click on the Import button.
- 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.
- 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.
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.
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:
- 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.
- 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.
Today I am happy to announce that PowerGUI Pro and PowerGUI 2.3 are now available. This is a really exciting release for all PowerGUI users because there are a lot of cool new features in this release.
For PowerGUI Pro customers, we’ve spent quite a bit of time on MobileShell and made the following enhancements:
- More mobile device support!
MobileShell now supports iPhone 3G, 3GS, and 4G, iPad, BlackBerry OS 5.0 and 6.0, Android OS 2.1 and 2.2, and even Windows Phone 7 OS devices!
- Improved user experience for MobileShell on smartphones!
Since smartphones have limited real estate for apps, we have redesigned MobileShell to better fit your smartphone device. Now when you log in you will see your favourite scripts first, front and center, and optionally you can go to another tab if you want to do some ad hoc scripting. If you are using an iPhone and prefer the old UI, you can specifically use that UI but the new UI is highly recommended for smartphone devices. Larger devices such as desktop browsers and the iPad still use the old UI since they have more real estate to work with.
- Improved favourite script management for MobileShell admins!
Now admins can preconfigure the default favourites that are assigned to users when they first log on to MobileShell. This makes it easier for you to set up the default commands you want available for your team once and then when they log in for the first time they will get assigned those commands automatically.
- Role-based assignment of MobileShell commands!
Admins can now associate modules with Active Directory users and groups so that when a user logs on to MobileShell, all public commands in any module associated with their user account or with a group they are a member of are automatically made available to them as favourites. This allows you to manage your MobileShell commands in modules using the PowerGUI Script Editor, and whenever you publish a new version your MobileShell users will automatically have the commands from that version available on their handheld device when they log on!
We didn’t forget the freeware community either! This release also includes the following features for both PowerGUI Pro and PowerGUI (freeware):
- Virtualization support in PowerGUI!
With version 2.3, the VMware PowerPack is now available as a core PowerPack included in the PowerGUI Admin Console. This PowerPack is a fantastic way to manage your virtualization infrastructure. If you want an example of how this might make a difference for you, have a quick look at this blog post.
- HTML Reporting support in PowerGUI!
We have had an Advanced Reporting PowerPack available for download from PowerGUI.org for a while now. That PowerPack has recently been renamed the HTML Reporting PowerPack, and it now comes with PowerGUI. This PowerPack allows you to generate HTML reports with features such as indenting, grouping, collapsible sections, and support for list or tabular format for any data you have in front of you in the PowerGUI Admin Console grid. Just click on the “Create report…” action, configure the report you want to generate, and it will handle the rest for you!
- Enter-PSSession and Exit-PSSession support!
You asked, we answered. Now you can use Enter-PSSession and Exit-PSSession from within the PowerGUI Script Editor to manage remote machines as if you were working on them locally.
- Greatly improved snippet support!
This one is a personal favourite of mine. Snippets are a great way to create a lot of useful PowerShell functionality really quickly. You just insert the snippet you want, fill in the input fields, and you’re done! We have had this for a while, and now we have added more features to this support including:
a) Support for user defined snippets! If you have snippets you want to use in PowerGUI, you no longer have to have admin access to put them in the snippets subdirectory under the PowerGUI installation folder. Instead, you can put them into your Documents\WindowsPowerShell\snippets folder and they will automatically be picked up by the PowerGUI Script Editor. Even better still, if you have a snippet that comes with PowerGUI that you want to override, you simply use the same relative path in the snippets folder in your profile and your snippet will be used in place of the one that comes with PowerGUI!
b) Support for snippets in modules! If you import a module, and if that module has a snippets subfolder, then PowerGUI will recognize those snippets and they will be available in the Script Editor automatically. This allows module authors to include snippets as part of their offering so that users can learn how to use the module commands much more easily! If you author a module and share it with others, I strongly encourage that you add snippets to that module. Your module users will thank you for it!
c) Support for using snippets from any path on your system! PowerGUI now uses a PGSnippetPath environment variable to decide where to look for snippets, allowing you to reference snippets from any path you include as part of that environment variable!
Can you tell I love the snippet features?
Of course we also included some bug fixes as usual. One worth highlighting is that the PowerGUI Script Editor can now be used to debug files that are in a path containing paired square brackets. We have had several customers let us know that they use these types of paths and that our new debugger wouldn’t stop on breakpoints for them, and this issue is now fixed.
This is a totally awesome release, and I’m really happy that I can finally share it with you! If you are already a PowerGUI Pro or PowerGUI user, you’ll probably notice the auto-update notify you of the new release when you start it up very soon. If you don’t want to wait though, you can always force PowerGUI to check for updates using the “Check for Updates” menu item in the help menu, or you can update it manually by downloading it from Quest SupportLink if you use PowerGUI Pro or from the PowerGUI.org download page if you use the freeware version.
I will be recording screencasts for some of these specific features very soon so that you can see how they work first hand, but don’t hesitate to try them out in the meantime and ask questions if you have any. Also please share any feedback you have for this release, I’d love to hear what you think of it and what you would like to see in future releases!
As always, thanks for your continued support, PowerGUI would not be what it is if we didn’t have such a great community!
In 10 days on November 15, the 2010 PowerGUI Challenge comes to a close. The PowerGUI Challenge is a contest that gives you a chance to win some money while having fun with PowerShell and PowerGUI. The rules are pretty simple: create a PowerPack or an Add-on for PowerGUI and post it in the contest folder for a chance to win one of the prizes. The best part is that it is possible to create a contest entry in 10 minutes once you do a little research and watch a few videos. That’s only 1 minute a day for the next 10 days, or a fun 10 minute break from doing something else that you really don’t want to be doing. If you want to learn more, here is what you need to do:
1. Review the contest details on the contest page (http://www.powergui.org/contest.jspa). That should answer a lot of the up front questions you might have and it will highlight a few useful resources (but I’m going to highlight some of the most important ones here as well).
2. Take a moment and watch this screencast that demonstrates how easy it can be to create a really useful Add-on for the PowerGUI Script Editor:
3. Now that you know what an Add-on is and how easy it can be to create one, take a few more minutes and watch this screen cast that demonstrates how easy it can be to create a really useful PowerPack for the PowerGUI Admin Console:
4. Create your Add-ons and PowerPacks and post them to the contest folder once you have them working. The earlier you post your entries, the more time you will have to collect valuable feedback so that you can polish them up before the contest ends on November 15th, and the more you participate the more chances you have to win (some of the prizes are based on level of participation, others are based on best PowerPack or Add-on).
What a great way to spend time having fun with PowerShell and PowerGUI on those dull, Fall days!
Good luck with your entries, and don’t hesitate to ask questions to myself or any of the other judges!
Ladies and gentlemen, start your engines! The 3rd annual PowerGUI® Challenge is about to begin!
That’s right, this year Quest Software is sponsoring yet another PowerShell contest that gives you a chance to win some money by having fun with PowerShell and PowerGUI. I’m totally excited about the contest this year, because there are more prizes, more categories, more judges, and more possibilities with what you can do than ever before! If any of your entries make it into the top 10 in the two main categories (PowerPacks and Add-ons), they will be put in front of our incredible panel of celebrity judges for review and suggestions. Judges this year include Jeffrey Snover, Hemant Mahawar, Don Jones, Jeffery Hicks, Shay Levy, Brandon Shell, Aleksandar Nikolic, and Marco Shaw. If you’ve read even a little bit about PowerShell on the web, I’m sure a few of those names ring a bell. Dmitry and I will review the entries and offer our own feedback as well.
Sound interesting? Here’s what you should do:
- Head on over to the PowerGUI Challenge contest page and read all of the details about the contest, paying close attention to the tips and the resources that are listed there to help you out.
- If you’re not familiar with them already, take a look at the kinds of things you can do with PowerPacks and Add-ons by visiting the PowerPack Library and the Add-ons Library and trying some of them out (and make sure you install the Authoring Toolkit Add-on if you plan on creating Add-ons yourself – it’s a real time-saver).
- Enter the contest! The only way to make sure you don’t win anything is by not trying at all, and this is a really fun way to discover some of the cool things that you can do with PowerShell beyond regular scripting.
The contest runs from October 15 to November 15, so you have a lot of time to get yourself warmed up before the official start date, and then you can start adding your entries and getting community feedback. Don’t wait, start learning more about what you can do by experimenting now!
In the meantime, I’ll be providing additional resources to help you out that I’ll announce on my blog as well, so keep your eyes open for more useful contest resources.
As always, don’t hesitate to ask questions if you have any. As Alan Renouf (one of our winners in last year’s contest) knows, I’m more than happy to provide feedback and answer questions.
Last week I had the pleasure of participating in a webinar with Randy Franklin Smith of Ultimate Windows Security fame where we demonstrated and discussed the Windows Security PowerPack that was recently published in the PowerPack Library. Randy’s a great guy to present with and this webinar was a lot of fun. Judging by the amount of questions and positive feedback we’ve received, it seemed to generate a lot of interest as well.
A recording of the webinar is now available, so if you missed catching it live you can go here and watch it at your leisure. You won’t be able to ask questions during the presentation of course, but that’s what the comments on this blog and the PowerGUI Forums are for. :)
|Share this post:|
This Sunday at midnight PST marks the closing of our second annual PowerPack Challenge contest. The rules of this contest are very simple: create a new PowerPack or modify one of your existing PowerPacks and submit it to the contest folder in the PowerPack Library for a chance to win some cool prizes. Now you might be thinking: "Sunday, but that’s just three days away…I don’t have time to put together an entry between now and Sunday. Besides, I want my weekend to myself!" Well, you’re in luck my friend because you don’t need three days…you only need 10 minutes (well, 10 minutes after you watch a screencast showing what you can do with PowerShell, the PowerGUI Admin Console, and 10 minutes of your time). That’s not even going to take up your whole lunch hour on Friday, and if you plan to go out for lunch you could make your PowerPack during your afternoon break instead!
Here’s all you need to do:
1. Bookmark the PowerPack section of the wiki. I published a big update to our wiki earlier this week and it should be able to answer a lot of questions you might have. Don’t read the whole thing right now though, that might take too long and what you really want to do right now is explained in the next step.
2. Watch this screencast (also shown below on YouTube) that shows how I created a cool Windows Server Roles and Features PowerPack from scratch earlier today and published it to the PowerPack Library in only 10 minutes. The PowerPack even has dynamic nodes generated from 4 script nodes, which used to be quite a lot of work but thanks to the AdminConsole module they are much, much easier now. In fact, if you pay close attention to the screencast, you’ll see that all of the functionality in the PowerPack itself is done with only 7 lines of PowerShell script plus one basic node and two basic actions — that’s pretty amazing. The entire screencast is longer than 10 minutes because I needed to explain a few things before and after the demonstration, but the creation and publishing of the PowerPack itself is done in only 10 minutes during the screencast.
Good luck with your PowerPacks!
|Share this post:|
Last week Microsoft made the announcement that Windows Server 2008 R2 reached RTM. Among the many cool new features provided with that release (Hello? PowerShell v2? Need I say more?), Microsoft has now added a recycle bin feature to Active Directory. The management interface provided by Microsoft for this feature is the command line, or more specifically, PowerShell. That’s great if you’re like me and you love to manage your infrastructure using PowerShell, but what if you prefer a GUI? Fortunately there is a solution for you too.
As Jackson Shaw suggested on his blog about a week ago, PowerGUI provides an admin console that allows you to create your own management UI that is layered on top of PowerShell. This admin console can be extended with PowerPacks, which are essentially add-ins that provide additional user interface elements in PowerGUI that invoke PowerShell script when clicked. All you need to do is add the user interface elements you want and then provide the scripts to power those elements, managing the Active Directory Recycle Bin objects or anything else you need to manage. Or alternatively you can check to see if someone on the PowerGUI Community like myself has already created a PowerPack with the functionality you are looking for.
In the case of the Active Directory Recycle Bin, you’re in luck. I just finished creating the first release of a new PowerPack that is designed to allow you to manage any objects in your recycle bin. You can find the Active Directory Recycle Bin PowerPack by following the hyperlink here or by going directly to http://www.powergui.org and browsing into the Active Directory subcategory in the PowerPack Library. This PowerPack includes the following features:
- View the contents of the recycle bin, including hierarchies
- Restore individual items in the recycle bin (recursively or not) to their original location
- Restore individual items in the recycle bin (recursively or not) to a specified location
- Permanently delete objects in the recycle bin (recursively or not)
- Empty the contents of the recycle bin
- Modify the number of days that the recycle bin is configured to retain objects and the number of days that objects are to be kept in a tombstone state before permanent deletion
If you would like to see a demo of the Active Directory Recycle Bin PowerPack, watch this screencast:
This is the initial release of this PowerPack and it contains a good amount of new functionality. If you are experimenting with the Active Directory Recycle Bin feature, please take a look at this PowerPack and provide any feedback you have so that we can continue to provide improvements that are valuable to you and others in future releases.
Thanks for listening!
|Share this post:|