So, this post is more about personal loyalties than Powershell itself.  The recent changes with PowerGUI have me contemplating changing my default editor.  I have found PowerGUI to be great, but part of the greatness was the Product Manager.   The product is great, especially the editor.  I did buy the pro version and quite frankly in my environment it didn’t give me anything I could use but it seemed right to support the product as I as endorsing it to everyone I worked with.

At this point I am considering going back to PowershellPlus but after I played with the most recent beta I miss the original version.  I still use Sapien for when I have to work with vbscript code but I find it way too bloated when comparing it PowerGUI.  When it’s all said and done I think I will be deciding between the ISE and the free PowerGUI.


Passing on the power of Powershell

I was recently asked to help a fellow systems administrator in one of our divisions with a request.  The request was simple enough with Powershell and when I provided the information the recipient shared the attempts they had made.  When I saw the example it was the familiar blue background of a powershell console and the syntax showed they were familiar with the Quest AD cmdlets….. 

I noticed they tried to run the same command several times just changing the SearchRoot.  So, working on the request I offered a one-liner they could use to replace it, simplifying it to list through the OU’s instead of specifying each one in another command line and formatting the output to make it easier to use.

So I offered the following syntax as a possible solution for their request (Report the count of objects in a set of sub-OUs).

get-qadobject -Type OrganizationalUnit -Searchroot 'some.domain.com/OURoot/SubOU' -SearchScope OneLevel | `
% {$_.CanonicalName + ": " + (get-qadobject -SearchRoot $_.CanonicalName -SizeLimit 0).count }

The one-liner  produced the results they looked for and I was able to explain the line continuation with the backtick (`) and the alias for ForEach (%).  The obvious next question was how do I save this to a script.  So I have an admin hungry for some information on Powershell so I had to create an easy to read script. I had to include something I recently mentioned (thanks to Karl Mitschke) to add a new twist and make the code a little easier to read.

$QADObject = @{
Type = "OrganizationalUnit"
= 'some.domain.com/OURoot/SubOU'
= "OneLevel"
# Create array of OU's to measure
$checkous = Get-QADObject @QADObject
# Process a count for each returned OU
ForEach ($ou in $checkous){
# Generate output in report format
$ou.CanonicalName + ": " +(get-qadobject -SearchRoot $ou.CanonicalName -SizeLimit 0).count

Of course I also had to ask what they were using for an editor and suggested that, since they were obviously familiar with the Quest AD cmdlets, they try PowerGUI.


Evaluating–PowerGUI MobileShell

I bit the bullet and bought Quest’s PowerGUI Pro.  While I have made the full transition from PowershellPlus Pro, I really didn’t see value in upgrading from the already strong PowerGUI product.  I really only use the editor and the “pay for” version doesn’t really seem to offer more than you can get from the download. 

I couldn’t just leave it at that.  One of the components that comes with the Pro package is mobile shell.  I installed the MobileShell component on a laptop and answered a few questions or responded to the warnings, and in 25 minutes I was able to test it and have to say I was impressed.  The first warning is logical as it warns you that this product was really intended for a server running IIS and it mentions verbiage about installing on Windows 7 for evaluation.  It provides three options for SSL and again this is just a test so unsecured http was selected.  The option to provide other users access to the mobile shell was pretty straight forward as well.  Installation complete, time to test.

mobileshell-evalI was able to get to the shell interface from my desktop computer.  Performance was as I would expect in such a test case.  I was impressed with the interface and then kicked the tires and I can see how this would be very useful.  Keep in mind this is from a computer, not necessarily the “mobile” but I can still think of some use cases.  As the image shows, it loads the default profile on the hosting machine and any commands I run were in fact being run on the host.

I was reluctant to test a mobile device due to the ability to connect to the wireless network in the current environment where I work.  Since my phone is a personal device I would have to connect to the wireless network designated for guest and I have experienced connectivity issues in the past when using a personal laptop onsite.  Not to mention, accessing my personal email would then be interrupted.  Oh well this will be just a quick test.  I connected to the guest wireless network, opened the web browser on my WP7 device and connected to the url.  Connected… very nice.

The interface is broken into three tabbed windows for Favorites, Run Script and Results.  Again I can not verify this should even work, so when I received errors when running scripts or executing one of the “Favorites” never seemed to complete and show results could be a factor of several things (WP7 browser issue, guest access rules, etc).  Just having that connectivity and knowing the shell does work, just being able to see the interface was a win.


With the success I saw in a short testing period here, I will now try a similar test on my home network with a few mobile devices.

Making lines of code easier to read

When helping to spread the Powershell bug, one of the questions I get often is “how can I keep the line length manageable?”.  The easiest answer is to break the line into smaller segments and span multiple lines with the back tick (`).  Using Powershell Snapins like Quest Active Roles ADManagement or vmware PowerCLI the cmdlets come with a multitude of parameters.  The parameter set makes interacting much more flexible and using a quick example you can perform commands with a simple purpose of returning information and because of the parameters you can  avoid lengthy where-object clauses.  For example;

get-qaduser | where {$_.FirstName -eq ‘John’ -and $_.LastName -contains ‘Kava*’}
can be simplified to:
get-qaduser -FirstName ‘John’ -LastName ‘Kava*’

Pretty simple, but when you start adding even more parameters (e.g SizeLimit, SearchRoot, etc…) for a more targeted request the command line can get very lengthy.  So how do we clean that up?  I came across the answer by accident.  When looking at PowerGUI editor enhancements I came across one that revealed the answer.  The answer is to create Splatted Hash Tables to formulate the parameter set.  Using the example above and adding two parameters the new method would look like:

$qaduser = @{
= 0
= “dc=somedomain,dc=corp”
LastName = ‘Kava*’
FirstName = ‘John’

get-qaduser @qaduser

As you can see all of the parameters are stored in a hast table and then passed to the cmdlet.  As long as the keys match up to the parameters we have boiled down a lengthy string to a concise and easy to read piece of code.

The PowerGUI Script Editor add-on can be found here.  This allows you to take a long piece of code (cmdlet with multiple parameters for example) and press Ctrl+L and it will assemble the splatted hash table and change the command line.  I have found a parameter like “-SizeLimit 0” does not work so well, but easy enough to correct after the add-on does the bulk of the work.