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

 

Powershell Plus and other editors

I have been a big fan of PowershellPlus, the enhanced shell and scripting tool from Idera.  I had started experiencing issues with the application going into a “Not Responding”  state.  So the new version (3.5) was announced and I thought I would give it a try.  Same interface that drew me to the product with the clear command history, variable displays and the command completion were there.  I started using it and again it was regaining my interest.  Testing done, now lets use it…. Uhoh! I can only suspect this is an issue with PowershellPlus and Quest AD Management tools not working well together but… I was doing a pretty simple query of computers using the Quest get-qadcomputer cmdlet.  Simple output of:

Get-QADComputer -SearchRoot 'somedomain.com/Some OU' -SearchScope 'Subtree' | select Name, ParentContainer

looks as expected.  I prepended to a variable with:

$test = Get-QADComputer -SearchRoot 'somedomain.com/Some OU' -SearchScope 'Subtree' | select Name, ParentContainer

$test.count returns a number in the range I was expecting as it shows 113, so lets look at the output of $test … WTH! it shows 11 items which equated to a specific ParentContainer and the “Not Responding” state surfaced again but not as severe.  Odd, so I test in a standard Powershell CLI and $test.count returns 113 again, and when I check the contents of $test, the screen shows lines of what would be expected of 113 records. 

I will look at this but I have to say my loyalty to this product is done.  On the upside, since I have taken a new position, I have been evangelizing Powershell amongst the Windows SystemAdmins so I have been suggesting PowerGUI and even more the Powershell ISE.  Some of the main features (automatic code-signing, V2 comment based help template, etc…) that I used to favor PowerShellPlus have been showing up in these products.  If you can’t work with the Quest AD cmdlets that’s a deal breaker for me.

I am thinking my blog entries with be adorned with this from here on out….

Toolbox

I was reading some articles from windowsitpro.com specifically on Powershell editors.  I had been a Sapien PrimalCode/PrimalScript user before Powershell.  Then I started using PowershellPlus.  The editor was great but the icing on the cake was the interactive console. 
Lately however I have gone back to PowerGUI Script editor (I don't use the PowerGUI part, just the editor) and now I am using the Powershell ISE.  The primary reason for going back was not monetary as I have already paid for  PowershellPro Plus and PrimalScript 2009.  Since upgrading to version 3.1 x64 of PowershellPro Plus it has just been too unstable (best word I could think of) to continue with.  After executing a script or while in the console and it tries to perform word completion both the console and script editor go into "Not Responding" state and sometimes that can last until I finally kill the application.  The Idera folks have been responsive so I am not swearing off PowershellPro Plus, but I have also learned that the ISE that comes with Powershell is actually a pretty good and customizable editor.

New Gig

So I have been working at this new gig for over two weeks now.   Personal note, my hesitation about being a contractor were valid for sure.  So  a  few odd things as I started this new spot, Windows 7 on the desktop which in previous shops making the move to Windows 7 is probably a year away at least.  In terms of Powershell, it  would seem no one is using it and the one person I have  encountered  that does scripting, he shuns powershell and instead uses ASP and vbscript.  I have started applying and showing how not just for scripting, Powershell could make some of their processes much easier.  I will post more when I have some free time...

Always Learning

Okay, this one is more about the great community of powershell users. I took a task upon myself after realizing user’s admin accounts were not part of the password synchronization process. The task was a good way to show the group how Powershell could be used. Being a huge fan of one-liners I sent some informative emails showing how easy it was to list user accounts and vital information such as whether it is disabled or the password expired. Its really not about that though. Based on the results it seemed logical to create a script to perform an audit, to include notification to users that their password would expire.

So, onto the point of this posting. I started working on the script, tested the logic for identifying password expiration now it was time to work on formatting the email message(s). I could have made it a simple one line email but considering the recipients I wanted it to be a little more informational.

II have experimented with Here-Strings but never really used them so here was a chance to put it to use…. Doh! its not working, research the problem a little and the problem was, in following proper indentation the string completion meant the whitespace, aka blank spaces, aka tabs, aka indentation was considered the first characters on the line. Wondering if maybe I was missing something I posted to the powershellcommunity.org. I have always been impressed with how quick and in-depth people work to help others on this site. Almost instantly it was confirmed that there was no workaround with here-strings but also a ton of recommendations for alternatives. Then some feedback in terms of sure indentation is great but for the sake of performance and compliance its no crime to break the format to use a true Powershell function versus going through more complicated methods… I hesitated and as you see in the full code listing below I tried two methods and stuck with breaking the “pretty” formatting of the code to use the Here-String. So as the following code shows $usrmsg breaks the indentation, it provides a concise way to build a body of text. I would also like to point out, using a Here-String also made it easier to pass to the function that actually sends the email. A here-string starts with @” and ends with “@, so below you can see it begin with $usrmg=@” so the string will be stored in a variable named $usrmg. Very simple combination of text lines with dynamic data (i.e. $msgdate will actually be the date when the script is executed) assembled and stored to be passed on, the result will be used as the body of the email message.

Done…. not so fast. With Powershell Version 2 sending an email is easy since they included a cmdlet for just that. Code was done, test worked but the actual send-mail message structure was just one very long line. I was using Bing to search for more help with a send-mail message parameter and came across a great blog posting by the group who developed Powershell. Again, very impressed that they not only wrote the language but do a great job of encouraging its use with some great examples and explanations. In reading they address the specific topic of send-mailmessage getting unwieldy and I just had to use it. Basically it stores all of the parameters in a hash table. The resulting code looks cleaner, easier to debug and an added benefit was I could code it out with two values for the email address the email would go to, so one it was ready to go all I need to do is remove the line that had To = my email address and then remove the comment (#) for the entry that used the dynamic value of the user’s email address for notification.

function usrnotification {

    param(

    [string]$varname ,

    [string]$usremail ,

    [string]$vartil 

    )

    Process {

    $msgdate=(get-date).tostring()

#    $msgbody=[System.String]::Format("{0}`r{1}`r{2}",

#    "Message generated: $msgdate from $env:COMPUTERNAME on $msgdate ",

#    "The password for your Windows Admin account $usersam is set to expire in $vartil days  ",

#    "Please verify and change your password."

#    )

# NOTE: Indentation ceased for message text creation

$usrmsgtxt=@"

Message generated: $msgdate from $env:COMPUTERNAME on $msgdate .

The password for your Windows Admin account $usersam is set to expire in $vartil days.  

Please verify and change your password.

"@ # End of message text assembly

    $bodytxt =  $usrmsg | out-string

$usrmsg = @{

        Subject = "Windows Admin Account Password Expiration"

        From = "sender@sendingdomain.com"

        # To = $usremail

        To = "recipient@todomain.com"

        smtpserver = "servername.yourdomain.com"

        Body = $bodytxt

    } # End of mailmessage parameters

    send-mailmessage @usrmsg

No revolutionary code, just a great experience with a great tool and even greater collection of people energized and collaborating for the good of the community.

Home Drive Mapping

So, this one is quick and was primarily meant to be a quick example when presenting on the Quest AD cmdlets.  The practical piece is to deal with something we experience when working remotely.  Typical scenario, user logs in locally to their laptop and then connect to the corporate network via VPN.  The home drive is not mapped because when the desktop state is loaded the VPN connection has not yet been made.  So the script showed how to add a little function to their powershell profile so they could simply run the function to make their connection.

function map-homedrive {

# simple function to map the drive based on your user info

$nw = New-Object -ComObject Wscript.Network

$nw.MapNetworkDrive((Get-QADUser $env:USERNAME).HomeDrive, (Get-QADUser$env:USERNAME).HomeDirectory)

}

The script simply  determines the current user name ($env:USERNAME), then reads the configured values for the corresponding Active directory object for the drive letter (Get-QADUser $env:USERNAME).HomeDrive and then the path (Get-QADUser $env:USERNAME).HomeDirectory , combining those two values to perform the drive mapping.  

Editing

Just thought I would post a quick note on my experience with the Powershell ISE.  In the past I have stated my preference for Powershell Plus as my Powershell script editor.  I am still a huge fan (well other than the new version seems to have an issue) of the product and in truth it is much more than a script editor. 

I also enjoy the PowerGUI editor but in general I do not use the PowerGUI suite, but when working on a script on a machine that isn’t my workstation, it was easy to install PowerGUI and have access to a decent editor.

With Powershell V2, the ISE was introduced.  I had used it briefly when giving an internal demonstration of Powershell to my colleagues.  I also must admit that I tried to customize it using the ISE specific profile but failed miserably and had given up on it.

A recent project had me developing a script on a server and considering latency it was just easier to RDP into the server and interact with the console.  With the ISE, I had access to an editor and a powershell command line interface without installing PowerGUI or any other software.  I am very impressed with the ISE for developing and debugging scripts.

That said, I still think Powershell Plus is a great tool set.  Any script editor that includes syntax highlighting is helpful and there are some other niceties such as automatically certificate signing scripts, snippets and code completion.  Where I still use Powershell Plus the most is the actual shell.  Whether working on a script or just simple day to day sell usage, I have found Iuse get-help much less since within the shell I can type a cmdlet or function and it knows about most if not all the parameters and includes links to help documents or searches.

Okay I have to get back to completing this script.

 

Technorati Tags: Software,Editor,CLI,ISE

Exploring

Yes, there are some duplicates from my other blog.  Sorry about that but I am experimenting with moving my blog.  The Go Daddy admin tools are just too tedious and with the constant wordpress updates, it just seems like time to explore an alternative.

First annoyance here is displaying code.  Since this is primarily powershell code oriented, that is a big gotcha so I will be experimenting to see if I can work around it.

Version 2 vs CTP3 – Test-connection

Interesting little discovery.  Working an a new Windows2008 R2 Server I started working with the test-connection cmdlet.  After testing some code I was ready to reduce some lines of code in some production scripts.  I quickly found out that test-connection <machine name> –quiet doesn’t work.  This would have helped because in current scripts there is an elaborate use of ping and reading the results which with Powershell V2 can be replaced with:

if (test-connection <machine name or ip> -quiet){ 

    # Some code here } 

Else {"Can not contact target machine"}

Well I will have to put this in the snippet library and put it into action when the full version 2 is available for XP.

Scripting On the Fly

Okay so this code is not the elegant sort of code you see on other sites, it is truly a SysAdmin writing functional code while performing Admin functions (hence why the output is handle on the command line and not inside of the script). 

The patch released this past week to address the critical security vulnerability in Internet Explorer prompted action.  On a Friday evening the call went out to get all servers patched this weekend.  Having gone through this before I also knew someone will be asking for a report of what servers have been patched.  In the past I would have written something in vbscript. 

First step was to verify the WMI portion, to include the segment that would indicate the patch had been installed.  Going back one step, there had been a similar critical patch and was never able to get the Powershell code (V1) to work and ended up going with vbscript.  After verifying the WMI with some test cases, I passed on how to use Powershell to check a server to include offering my colleagues a WMIC alternative.

This code was tweaked several times, as the weekend progressed.  The final step was to provide more feedback.  At first it would just report, could not connect, installed and not installed.  I knew people would raise the eyebrows with that information.  I knew that things such as test-connection failing could be for several reasons and leaving it at “could not connect” would make the report suspect.  Also, the WMI query returning no data could mean the patch wasn’t installed but it could be because of other reasons such as Access Denied or RPC issues.

So the process was, patch a server while the code was running, keep checking the output looking for anomalies.  Then with some extra time I started looking at how I could include the current error data to the output instead of the generalized result I was presenting at first.

Below is the code, caution any of you Powershell purists because it might not be pretty but seems to work. :-)

#requires -Version 2

<#

.SYNOPSIS

      Checks for install status of KB978207.

.DESCRIPTION

      Uses a source file of server names, makes sure the server can be connected to,

      then uses WMI to query the QFE information.  Looks for the instance in the QFE

      where HotFixID matches 978207.  

.EXAMPLE

      c:\temp\run.ps1 | out-file c:\temp\audwstats.txt

.LINK

      http://www.microsoft.com/technet/security/bulletin/ms10-002.mspx

#>

function chk-updt {

$curError=$Error.count    # establish current index of the error variable

$qfedat = gwmi win32_quickfixengineering -computer $server  |  where {$_.hotfixid -like "*978207*"}

      #if no data is returned the qfedat variable will be null

      if ($qfedat -eq $Null){

      # Since no data was returned check to see if that was because of an error, if so report the 

      # returned error message

          if ($Error.count -gt $curError){$server + ": " + $Error[0].Exception.Message}

          # No error generated by WMI query so consider the patch not installed

          else {"Patch not installed on " + $server}

       } # Finished processing Null $qfedat

      # An instance was returned therefore the patch has been installed 

      else {$qfedat.HotFixID + " Installed on " + $server}

}  # end chk-updt

# Format report header

get-date

"-----------------------------------------------------------------------"

$ErrorActionPreference="SilentlyContinue"       # Keep the screen chatter done and continue after error

$noconnect=0

$servers = gc c:\temp\full.txt                              # Define array of server names from text file

foreach ($server in $servers) {

      # verify the server can be connected, if it can call the chk-updt function

      if (Test-Connection $server -Count 1){chk-updt}

      # if the server can not be connected, report the specific reason for failure

      else { $server + ": " + $error[0].Exception.Message

          $noconnect=$noconnect +1 }

}

"-----------------------------------------------------------------------"

"Servers Checked:  " + $servers.count 

"Servers not reachable: " + $noconnect

get-date

 

One-Liners

As I mentioned in the previous post I have not written any formal scripts in some time.  I have focused on one-liners recently.  What is a one-liner you ask?  Powershell offers a great deal of tools that can be called up and used right from the Powershell command line. 

I think this is were Windows SysAdmins need to catch on to Powershell.  Scripts are great, especially for repetitive or large tasks but sometimes that is too cumbersome when you need to tackle a quick task or return information quickly. 

How does this apply?  We were recently asked to verify the specific version of Windows installed on a list of machines.  Yes, I had written a vbscript a few years ago to do that but wanted to approach it with Powershell.  Being lazy, I knew WMI would return the information so looking at my existing script I started with a simple wmi query: gwmi win32_operatingsystem, which returns several useful fields of data such as Build Number and Version.  For our use they wanted the publicly known name which I knew from previous of WMI was the Caption field so I was able to expand the one-liner to gwmi win32_operatingsystem | select caption so now I am accessing the same collection of information but now I am selecting just a specific field which is the Publicly known name of the operating system.

caption
-------
Microsoft Windows 7 Ultimate

So, you are sitting there and saying “I can just right click on the computer object and check properties”, but what if you wanted to check a remote computer, now you have to access that computer, with the one-liner I simply add the –computername parameter, as long as I have the necessary credentials I can return the same information from that computer.

Pretty easy right?  Pretty low key example though.  Now consider the ability to do the same type of operations with things like Active Directory and Exchange.  I have found it interesting that while on a conference call in the past, a request for information would be requested and the standard answer was a script, now in many cases a quick one-liner produces the basic information ASAP.  This is so much fun when someone estimates data and you can counter with the actual data, makes planning much more precise.