Configuring RBAC for MobileShell in PowerGUI Pro 3.0

Yesterday we released the public beta of PowerGUI® Pro 3.0, which comes with all sorts of cool new features for PowerGUI users.  My favorite feature is definitely the new management interface for MobileShell.  With this interface, you can perform systems management from your handheld device very easily.  Here’s what that might look like from your webkit-enabled web browser:
Since this is only a beta release, it doesn’t necessarily have everything fully polished just yet.  One thing that we didn’t get to include in the beta release was a management console allowing you to associate PowerPacks with AD users and groups as well as instructions describing how you set up MobileShell to use this new interface with the beta.  The PowerPack that will be used to do that will come later.  In the meantime, this post will give you the necessary instructions to get started.

Step 1: Install the MobileShell Server

First, you need to find a system with IIS 7 or later installed.  Once you have a system where you will install the MobileShell server, you can run the PowerGUI ProMobileShell installer that was included in the beta package.  During that installation, make sure you indicate you will use https for your web site, because the new MobileShell user experience requires https in order for it to function properly. With the MobileShell server installation complete, you have a few configuration tasks that you need to perform to set up PowerPacks

Step 2: Add MobileShell Users to the PowerGUI MobileShell Users Local Group

Any user who will access MobileShell needs to be a member of the PowerGUI MobileShell Users local group.  The local group is created automatically by the MobileShell Server installer, so all you need to do is make sure you put the appropriate user accounts in to that local group so that they will have access to MobileShell.  Note that it may take several minutes before MobileShell checks the group again to see if there are new users in the group, so you may need to wait before newly added users can log in to MobileShell.

Step 3: Associate PowerPacks with AD Users and Groups

With your MobileShell users configured, you can now associate PowerPacks with different AD users and groups.  When a user logs on to MobileShell, they are presented with any PowerPacks that are associated with their user account or with any groups in which their user account is a member. MobileShell PowerPack configuration is done via a simple xml file.  The file does not exist by default, so you need to create it.  Invoke the following PowerShell script on your MobileShell server to create and open the configuration xml file:

$programDataPath = [Environment]::GetFolderPath('CommonApplicationData')
$powerGUIDataPath = 'Quest Software\PowerGUI Pro'
$folder = Join-Path -Path $programDataPath -ChildPath $powerGUIDataPath
if (-not (Test-Path -LiteralPath $folder)) {
    New-Item -ItemType Directory -Path $folder | Out-Null
$configPath = Join-Path -Path $folder -ChildPath 'MobileShellConfig.xml'
$configuration = @"
<?xml version="1.0" encoding="utf-8"?>
    <User SID="S-1-5-21-123456789-0123456789-0123456789-01234">
        <Module Path="$folder\ActiveDirectory.powerpack" Type="PowerPack" />
        <Module Path="$folder\Export Actions.powerpack" Type="PowerPack" />
        <Module Path="$folder\HTMLReporting.powerpack" Type="PowerPack" />
        <Module Path="$folder\Local.powerpack" Type="PowerPack" />
        <Module Path="$folder\Network.powerpack" Type="PowerPack" />
        <Module Path="$folder\VMware.VIToolkit.powerpack" Type="PowerPack" />
  <!-- <Groups>
    <Group SID="S-1-5-21-123456789-0123456789-0123456789-43210">
        <Module Path="$folder\Network.powerpack" Type="PowerPack" />
        <Module Path="$folder\VMware.VIToolkit.powerpack" Type="PowerPack" />
  </Groups> -->
$configuration | Out-File -FilePath $configPath -Encoding UTF8
notepad $configPath

Once you have the configuration file open, you will see the layout that is used to associate AD user or group SIDs with PowerPacks.  Copy all of the core PowerPacks that you have in the PowerPacks subfolder of your PowerGUI Pro installation folder that you want to use via the MobileShell UI into the same path where this file was created (the value of the $folder variable in the script above contains this path).  Then modify this file to contain only the PowerPacks you copied over, update the first User SID for your user account, and this will finish off the initial configuration of PowerPacks for MobileShell.  If you want to add additional users, you can copy and paste the User node in the XML document and then modify the SID for the users you add.  Retrieving a SID should be an easy task of course: simply use Get-QADUser from the Quest AD cmdlets! Smile

Note: With this beta release there is a bug in the Groups support in this configuration document, so simply associate PowerPacks to users for now.  Thanks!

Step 4: Open the New MobileShell User Interface

The new MobileShell User Interface we have in the beta is accessed by opening your webkit-enabled web browser and pointing it to the following website:


This web address allows you to try out the new systems management features that you can get from the PowerPacks you just associated with your user account.  Once you log in you should be all set to start using your PowerPacks!

A Note About MobileShell Support for PowerPacks

Note that if you try to use this new user interface with a PowerPack other than the ones that currently are included in the beta, by default the nodes and actions in those PowerPacks will not be visible in the MobileShell UI.  This must be explicitly turned on in PowerPacks that you want to access this way.  The reason behind this is because there may be some script that displays a Windows Forms or WPF-based UI on the system where they are run.  When you are remotely managing your environment via your MobileShell Server, you don’t want any UI to be displayed on the server because that would freeze your web client interface.  For this reason, nodes and actions must be explicitly configured to work with the new MobileShell UI.  I will write a separate post later about how you can do that really easily.  In the meantime, please try MobileShell with the core PowerPacks and see what you think! Hopefully this will help get you up and running with the new MobileShell UI in your test environment.  If you have any questions about this process, please let me know.


Kirk out.

Try the PowerGUI Pro® 3.0 Beta today!

Today marks another exciting milestone for PowerGUI, as we release a public beta of PowerGUI Pro 3.0 to the web.  We’ve been working very hard on this release, and it includes a lot of new and improved features.   The highlights of this release are shown below.

MobileShell Now Supports PowerPack Rendering

A lot of our customers have been requesting this feature for a while (myself included!).  With PowerGUI Pro 3.0, you can now expose PowerPacks to MobileShell users!  An xml document is used to provide role-based access control (RBAC) to PowerGUI PowerPacks.  You simply associate PowerPack files with Active Directory users or groups, and when a user logs in they will see the PowerPacks that are configured for them!  Here’s a screenshot showing the top level of MobileShell, where you can see the PowerPacks that have been exposed to this user:


Just like in the Admin Console, you can browse through nodes and see child nodes:


Once you invoke a node that returns data, you can see the records showing up in the MobileShell PowerPack Rendering UI:


Clicking on any of these child nodes allows you to see more object detail if any is available as well as any actions that are available for the object:


This gives you full PowerPack support on your handheld device!  Devices supported include all iOS devices (iPhone, iPad), Android and BlackBerry 6.0 and later devices.  You can also use the Google Chrome or Apple Safari web browsers from your desktop.  If you don’t have a webkit-enabled web browser on your device or laptop, or if you want to invoke an ad-hoc command from your mobile device, you can still use the other MobileShell user experiences that we released in previous versions of PowerGUI Pro – they are still supported in PowerGUI Pro 3.0.

New Interactive Welcome Page in Script Editor and Admin Console

We have updated our Welcome Page that we have had all along in the Admin Console and we’ve made it available in the Script Editor as well.  This page now allows you to keep track of the latest PowerPacks or Add-ons on, monitor your favorite RSS feeds, see a featured video from the PowerShell and PowerGUI channel on YouTube, or read the latest tip of the day.


Create Executable Files from Scripts

Many customers have asked us for the ability to create executable files from scripts.  This is very useful, especially if you want to send someone the functionality you design in a script so that they can execute it without any difficulty.  PowerGUI Pro 3.0 includes this functionality, allowing you to build executable files that may be optionally password protected if they contain sensitive information.  You can also include any additional files that a script is dependent on as part of the package.  The only requirements for these executables are for PowerShell 2.0 itself to be installed and for the script requirements to be satisfied (if there are any).


Improved Version Control Integration

PowerGUI Pro has included Version Control support since its first release.  In PowerGUI Pro 3.0, we have improved this integration by providing a new Get Files from Version Control menu item in the Version Control menu to allow you to retrieve files from version control.  We have also simplified the check-in process so that you can disable the display of the check-in description dialog if it is not required by the version control provider.  This allows for a more streamlined check-in experience when working with Team Foundation Server.

Reset Runspace on Demand

As you create and modify scripts in the Script Editor, you are often changing the state of the PowerShell session, loading or unloading modules or snapins, or adding, removing or modifying functions or variables.  When this happens, it is a recommended practice to re-run your script from a clean state to make sure that something isn’t working simply because of the current state of your system.  Getting to a clean state in the PowerGUI Script Editor just got easier in PowerGUI Pro 3.0.  Now all you need to do is select Reset Runspace from the Debug menu and your functions, aliases and variables will be cleaned up and all of your modules and snapins will be unloaded and reloaded.


Go to Definition Support for Functions

As you work with PowerShell, the number of files containing commands you use can grow.  This commonly happens as users create multiple modules they manage or use modules they download from other sources.  In cases where you work with functions from different sources, you may want to go to a definition for a function to see how it is implemented.  In PowerGUI Pro 3.0, you can right-click on a function name in the Script Editor and go to the definition of that function by selecting Go to Definition from the context menu.

Find PowerPacks Online with Click-Once Install

You can now search for PowerPacks on the website right from within the PowerGUI Administrative Console.  Searching is done using keyword matches, and if you want to see all PowerPacks simply perform a search without entering any keywords.  Once you have found the PowerPack you want, select it and click on the Install button to download, unblock, install and import the PowerPack automatically.


Authoring Mode for the Administrative Console

If you know PowerShell, you may want all the capabilities that are available in the Administrative Console to be available to you so that you can customize it to meet your needs.  This allows you to create a tailored management experience for yourself or other users in your organization.  If you provide the Administrative Console with PowerPacks to other users in your organization, they may not know PowerShell, in which case you really don’t want them to change the configuration of the PowerPacks you give them.  The PowerGUI Administrative Console now has Authoring Mode for users who want to be able to modify PowerPacks, and basic (read-only) mode for users who shouldn’t be modifying PowerPacks.  Simply set the system up with the appropriate shortcut for the user who uses the Administrative Console and you won’t have to worry about them accidentally changing something anymore.

And that’s not all!

We also have a lot of other improvements in the product as well that were added as part of the PowerGUI Pro 3.0 release.  Here’s a list of a few more notable changes:

  • Improved Action functionality in the Administrative Console;
  • Automatic loading of required modules or snapins when a PowerPack is loaded;
  • Automatic variables for $PGHome, $PGUICulture, $PGVersionTable and $PGSE;
  • Multi-line command support for the embedded PowerShell Console; and
  • For Add-on authors, $PGSE is now defined by default and name lookups of UI elements is now case-insensitive
    There are other fixes as well, but this short list gives you an idea of some of the other things that are included in this release.  Each of these improvements were suggested by various members of our community, so please keep the feedback coming, we’re really listening!

This sounds great!  Where can I get the beta?

You can download the public beta of PowerGUI Pro 3.0 right now by clicking on the Download button on the PowerGUI Pro 3.0 Public Beta page on  That page also describes what the beta package contains as well.  PowerGUI Pro can be installed side-by-side with PowerGUI freeware, so if you are a freeware user and want to try this out, you can install the beta without disrupting anything you do with the freeware product.

Provide your feedback on the PowerGUI forums!

We will be running this beta for a short period while we work on finishing up this release.  Your feedback is very important during this beta cycle, so please give the beta release a try and share your feedback by posting messages on the PowerGUI forums.  The sooner we get your feedback, the sooner we can respond to it.  I’m really looking forward to hearing what you like, what you don’t like, and what else you would like to see in this and future releases, so please share your thoughts with us.

That about wraps it up for this post, so if you made it here, thank you for reading this far and please, give PowerGUI Pro 3.0 Beta a try to see what you think about it!

Happy testing!

Kirk out.

PowerGUI 2.2 public beta is now available!

Today we released a public beta of our upcoming PowerGUI 2.2 release.  This beta includes a very significant change to our debugger as well as compatibility support with version 1.4 of the Quest AD cmdlets.  Here are a few of the improvements that come with the new debugger:

  • Native support for the PowerShell 2.0 debugger, including command-line management of breakpoints using Disable-PSBreakpoint, Enable-PSBreakpoint, Get-PSBreakpoint, Remove-PSBreakpoint and Set-PSBreakpoint;
  • Advanced breakpoint support such as command and variable breakpoints through the PSBreakpoint cmdlets;
  • $MyInvocation support in scripts that you are debugging (this has been an issue we have wanted to fix for a long time)
  • Start-Job and Invoke-Command support in scripts that you are debugging (this was another issue that had to be worked around that is fixed by the new debugger);

This is the first public beta that we have had in a while, so I want to make sure everyone interested knows how the beta works.  It’s a pretty straightforward process, as follows:

  1. If you are interested in trying out the beta, go to the beta download page and follow the instructions to download and install the beta.  If you are using PowerGUI 2.1.1, it will automatically be upgraded when you install the beta.
  2. Use the beta just like you would use the previous version of PowerGUI.
  3. If you run into any issues, please notify us on the PowerGUI 2.2 public beta forum.

That’s pretty much it.  I should also note that auto-update from the beta version of PowerGUI 2.2 to the RTM version of PowerGUI 2.2 will be supported.

We’re looking forward to your feedback, so please download the beta and let us know what you think!

Kirk out.

Share this post: