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: ,,,


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



      Checks for install status of KB978207.


      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.  


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




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



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


$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




.csharpcode, .csharpcode pre
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
background-color: #f4f4f4;
width: 100%;
margin: 0em;
.csharpcode .lnum { color: #606060; }