Going going gone…

Well not really going, just in the process of moving this blog to wordpress.  While I miss Windows Live Spaces, I tried this google product and as with the others I just find it underwhelming.

http://jkavpowershell.wordpress.com/

Been Awhile

Wow, I have not posted here in some time.  With contracting and then starting a new job I have to admit my Powershell focus has been sporadic.  It is interesting that an employer can hire you in part for powershell but then don’t want you to focus on writing or perfecting scripts.

I am posting today based on the Scripting Guy’s recent post.  One of the things I have found interesting is to see Windows Admins who aren’t interested in scripting.  Then I show them how to run a simple wmi query from the Powershell prompt.

Then the next step is show them how to create a profile (colorful text still seems to get attention ) and then provide normal daily activities that can be accomplished via a function within their profile.

Of course there is still the work of converting vbscript coders to Powershell.  Admittedly there still seem to be things vbscript is better at but showing vbscript diehards some of the advantages Powershell provides is fun.

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"
SearchRoot = 'some.domain.com/OURoot/SubOU'
SearchScope = "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.

I 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.

It’s for automation

Okay, a recent interview I was asked a question and upon further thought I should have 1) answered differently 2) rant about it.  The question was basically “with all of this powershell related answers you see things and figure out how to automate it?”

The simple answer is yes.  However, with Powershell the answer is not that simple.  Just referring at the Windows platform here. 

Yes, Powershell has provided a much more powerful environment for scripting, tasks that would be considered automation.  “If you repeat it, script it” is a great slogan I have seen and it’s very true.  I have used bat files, kixtart, and then vbscript to assemble commands that I will use on a scheduled basis or just a tool to have for recurring tasks to address administration or resolve problems.  Porting many of these routines to Powershell most certainly falls into the automation category.

What I believe is lost is just the power of the command line interface Powershell offers.  Using a current situation, I can query a remote machine for specific values.  I can call upon LDAP and WMI and can tweak my attempts.  Yes, I could open compmgmt.msc to check what I am looking for but I find a shell environment is easier to work in personally.  Using the data retrieved I can now perform steps necessary to resolve the issue, again all in the powershell command line interface.  I test my changes and find that the steps taken do in fact resolve the issue.  Now Automation does come in, with the steps now verified I can save them to a script for later use.

Another example is when I have been asked to make broad changes.  Yes I could open my script editor of choice and write some code, but this is an impromptu request and I probably won’t be repeating the action.  Being very generic; someone wants all accounts that end in X (in this case the naming convention would indicate that they are contractors) added to a group, using Powershell and the Quest AD cmdlets this can be down in a one-liner querying for all users matching criteria and piping that to the cmdlet to add group members.  Yes there are other ways to perform the same operation, whether it be GUI or another console, but we are talking about Powershell and the assumption its for automation only.

Just my two cents.

Just my two cents.

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 = @{
SizeLimit = 0
SearchRoot = "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.

 

Be More Specific

Nothing revolutionary here and I probably should have planned accordingly but… I was provided with a list of computers to delete, as long as they are not online.  It’s a pretty simple script and since its been a sporadic request I have not really formalized it.  I use the start-transcipt and stop-transcript to record the output, and was going through the anomalies (computer objects with sub-objects, etc..).  Hmmmm why didn’t this computer get deleted???

Well based on the name, a get-qadobject returns several objects.  The computer name met the naming convention but was not complete.  An example would be if your computers are named in a fashion similar to computerXXX and a computer is named computer, when you perform:

get-qadcomputer computer

This will return the object you were looking for but will also return all of the computerXXX named objects.  The fix is simple, and this is not a bug in my opinion, just a caveat that is easily accounted for.  When performing the get-qadcomputer use the Name parameter to return the specific object…

get-qadcomputer -Name computer