So, we’ve got lots of PowerShell tools we wrote in v2 that we are slowly getting around to updating to the new features in v3.  But the thing is, we still can’t be certain where these scripts will be run, and by whom.  So we’ve put together a little “version detector” to help run the correct version of the command and give the best performance possible, whenever possible.  And as a result, you — the reader — can apply this type of thing to any script that might be run in a mixed environment.

This example below features the new -Directory flag in the PowerShell v3 Get-ChildItem, though you could just as easily replace that line in each section with any other CMDlet that behaves differently between versions.  Just modify this section, and wrap it around your CMDlet with the updated v3 capability…

$hostVersionInfo = (get-host).Version.Major
if ( $hostVersionInfo -eq "2" )
{
  # For PowerShell v2
  write "We appear to be using PS version $hostVersionInfo... That's okay, but this script processes faster with PS v3!"
  write ""
  $containers = Get-ChildItem -path $MoLoPath\$CurrentParent -recurse | ? {$_.psIscontainer -eq $true}
}
elseif ( $hostVersionInfo -eq "3" )
{
  # For PowerShell v3
  write "We appear to be using PS version $hostVersionInfo... Good!"
  write ""
  $containers = Get-ChildItem -Directory -path $MoLoPath -recurse
}
else
{ 
  write-host "Unknown/unapproved version of PowerShell. Exiting!"
  exit
}

Normally, I’d explain some of the functionality in the script; but it’s fairly simple, well-commented, and in general pretty descriptive.  It just detects which version of PowerShell you’re running, and runs one of the two version of the CMDlet.  So you should be able to figure it out quickly even if you’re new to this stuff. 

Of course, if you have a question (or have a better way of getting it done), feel free to comment. 

So that’s it, I hope it helps!

Last week Matt and I were working on a “Go-Live” event — where every moment is part of a timed, scripted series of steps — and one of Matt’s critical remote workstations crashed.  Matt had to move on to other tasks while waiting for the machine to come back up, but in that waning moment we wondered to each other… “In all the PowerShell scripts and tools we’ve written, how is it that we never wrote a ‘Host Up’ notification script?”

Well, we can’t let that stand.  So we began to devise the scripts in our heads, and later that evening I scratched it down so that we’d have it next time. 

$MyRemoteHost = "8.8.8.8"
$MyFlag = "False"
while ($MyFlag -eq "False")
{
  $MyResult = ping -n 1 $MyRemoteHost |findstr /C:"Reply "
  if ($MyResult -ne $null)
  {
    #write "$MyRemoteHost is up!"
    #Or do something cool here...
    $LoadStatement = [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
    $MyInput = [System.Windows.Forms.MessageBox]::Show("$MyRemoteHost is up.  Do you want to EXIT?","Yuuup!","YesNo","Warning")
    if ($MyInput -eq "YES")
    {
      break
    }
  }
  Start-Sleep 5
}

…why?  Just because we can.

Upon seeing the email, I immediately thought of my wife, who had done some charity-focused walks in the past, and forwarded the email.  She loved the idea, and immediately joined in. 

Fast-forward to a sunny,  wonderful Saturday May 4th at the Detroit Zoo where 3000 of our closest friends came out to help raise more than $345,000, and had a great time doing it.  And Sarah’s little Coretek team even raised over $500 in the process — not bad! 

And once we arrived on the morning of the walk, the kids and I could not resist either, and jumped in with Sarah’s family, making it a two-family team.  Sarah’s son was an excellent zoo tour guide!  We had great time all the way through.  Here’s a pic of some of our team crossing the finish line…

It ended all-too fast, and wrapped up with a nice celebration ceremony and lunch.  Afterward, we made our way back through the zoo afterward just to see some more sights at a little more of a leisurely pace.

All in all: great enthusiasm, a great zoo, great company, great food, and of course, a great cause. 

Thanks to Sarah for putting it together, and thanks to many of you reading this for donating.

See you there next year!

No matter what your opinion of “Earth Day” itself, I think it’s a great idea to utilize this day in a way that fits your motivations.  As I’ve mentioned before, I don’t think it matters as much *why* you do good things, as it does that you just *do*.  So in my busy life, I think it’s great to have these sorts of reminders to make at least a tiny donation (like the eyeglasses, phones, etc.), especially when the stuff doesn’t even matter to you any more.  Even recycling old computer junk with organizations like this can be considered a “donation” when you think about all the componentry and raw material that will be scavenged from the old computer hardware and returned to usefulness in new products; so much better than filling up a land fill!

 This year, while my part was fairly small (my mother’s old PC and monitor, 2 of my wife’s old laptops, 2 desktops I got off eBay fro Dev/Testing, and 2 Intel clone servers that served me well), I took a moment to reflect on a couple things:

1. Even though these are all *working* computers and parts, all of the computing power — combined — is still just a fraction of just ONE of my Virtual Machine hosts that replaced them
2. It’s a tiny piece of “mess” in my basement that can’t and won’t be re-made; these types of computer components are just not seen as much anymore (and certainly will not be seen in my home anymore) as smartphones, tablets, and other modern devices (and cloud services) have pretty much replaced the need for these things

So that’s all the good news…  The bad news is that my basement still has a ton more of this old hardware.

But I hope Earth Day 2013 helped you in some way, too.

There, that’s my tribute to Dana Carvey as “Grumpy Old Man”.  Google it, kids.

Anyway, I’ve got an absolute ton of old PowerShell scriptlets that I have lying about that I regularly cannibalize or resuscitate back into production.  And since we are in that squishy transitional period between PowerShell v2 and v3, I don’t always bother to check them for compatibility with v3 or update features in the script to take advantage of new capabilities.  But I hit on one v3 improvement the other day that solved a problem has bugged me so much for so long that I wanted to shout from the mountaintops about it!  And since I live in mostly-mountainless Michigan, the blog is the best I can do…

Really it’s such a little thing.  But it’s so overdue.

In the past, if you wanted to recursively inspect a folder structure on a remote server — for instance while fishing for explicit NTFS permissions on folders — you were forced to inspect all folders *and* files, no matter if you only wanted folders.  Basically, you had to ask for everything (all children folders and files, recursively), then parse the result to extract the folders (check psIsContainer) from the listing.  Here’s an example of this, similar to what you might see all around the internet:

# For PowerShell v2
$containers = Get-ChildItem -path $TopPath\$CurrentParent -recurse | ? {$_.psIscontainer -eq $true}

 Of course, this could be incredibly wasteful in processing, network bandwidth, time, etc…   All this time I’ve always wished there was a way in my loops to just ask for ONLY the folders, to save all of that waste.  Thankfully, this has arrived with v3.  Behold:

# For PowerShell v3
$containers = Get-ChildItem -Directory -path $TopPath\$CurrentParent -recurse

 This has significantly sped up some of my analysis scripts that I run in a large enterprise, cutting as much as half a day off of some of my execution times (I did mention it was large).  So really what this means is that I have to start spending more spare time looking through the v2/v3 differences…  But I won’t have any spare time until I implement more v3 changes…  Quite a conundrum… 

First, by default, the Remote Desktop Connection Manager gives you a thumbnail view of all of your workstations when you click on any “group” of servers from the left server pane list.  I always thought this was a “gimmick” and never thought twice about using it for anything because the dimensions of the thumbnail views of the remote desktops were just way too small to be useful.

But after reviewing the program’s options I found that you can modify the size of the thumbnails (Tools > Options > Client Area > Thumbnail Size)!

But that isn’t all!

The thumbnails are actual “live” clickable Remote Desktop sessions; so if you set the pixel size of the thumbnails to 25%, 30% or 40% of your screen size, you can fit 4-12 active server connections into one very productive window (obviously depending on your monitor size and screen resolution!).  This screen cap should give you a good idea of what I mean:

I hope you find this tip as useful as I did!  Enjoy!

Though Wise Package Studio has been discontinued by Symantec, it’s still quite popular in many packaging environments.  The main tool used for creating and editing Windows Installer projects in Wise Package Studio is the “Windows Installer Editor”, which was previously available alone as “Wise for Windows Installer” (wfwi.exe). 

Most of the packaging work will be done in the “Installation Expert” view, which is a slightly more “user friendly” or “cleaner” project editor.  After creating my new project, I’ll add a couple files to it.  The files I added are Process Explorer (procexp.exe) from “SysInternals” and it’s help file (procexp.chm).  Process Explorer is one of several extremely useful utilities available (free!) in the Sysinternals Suite. 

Next, I’ll add an “Advertised” desktop shortcut to “procexp.exe” from the “Shortcuts” page.  By default, when you add a shortcut to point to a file in your installation the “Advertised” check box is marked. 

Note that “Complete” is listed in the “Current Feature” drop down list.  By default, Wise starts with a feature named “Complete” and puts all files, registry keys, shortcuts, etc. under the “Complete” feature, but we need a “hidden” parent feature.  So, from the Features page “Add” a new feature.  Give it a name, select “<None>” from the Parent drop down list, “Hidden” from the Display drop down, and check the “Required Feature” check box; the rest of the defaults can be left.  After adding the hidden parent feature, I go into the “Complete” feature to select the hidden feature from its “Parent” drop down list. 

Finally, I add an HKCU registry key to the new hidden feature.  Notice now that I’ve added a new feature, I can select it from the “Current Feature” drop down list from all the pages in Installation Expert. 

After the project is compiled, the .MSI can be run on any system “per machine” with the “ALLUSERS” value set to ’1′.  When a new user logs onto the machine and clicks on the advertised shortcut, the HKCU key will be installed by the windows installer repair. 

 Next time, I’ll take a look at implementing self repair using InstallShield.  I hope you found this tutorial enlightening, instructive, and maybe even a little fun.  Well..uh..instructive and enlightening should be good enough! 

But first, if you haven’t launched the pre-loaded Active-Directory PowerShell Module, then let’s do that now:

Import-Module ActiveDirectory

Here’s a first blush at how we can list all AD-based computers, grabbing only the interesting properties we need, formatting the output to a list, and redirecting the results to file (I’ve seen some things like this while ‘Googling):

Get-AdComputer -Filter * -Properties IPv4Address,OperatingSystem,OperatingSystemServicePack | Format-List Name, IPv4Address, OperatingSystem* > OutputServerList.txt

Now, let’s dig deeper, and perhaps refine the command a bit.  First, the filter is a wildcard, and retrieves all computers.  That might be fine in a small environment with few computers; but we’re really only after Servers here, and we might be working in a larger environment.  So, we will change the filter to use an LDAPFilter and get a bit more granular like this:

-LDAPFilter "(OperatingSystem=*Server*)"

Next, I think the results will actually look better if we output them to a CSV, so we’ll drop the redirect and list formatting, and replace it with a pipe like this:

| Export-Csv ExportCsvServerList.csv

Now a warning about the CSV export…  Unfortunately, Microsoft chose to include a “restricted” symbol (little r in a circle) in the Server 2008 (non-R2) name, like this:

Windows Server® 2008 Standard

…and, the CSV export operates only with the ASCII set by default.  Sheesh.  So, we use the UTF8 flag to make sure the wacky “restricted” mark is rendered correctly, like this:

| Export-Csv -Encoding UTF8 ExportCsvServerList.csv

So with all that, we end up with a command looking like this:

Get-AdComputer -LDAPFilter "(OperatingSystem=*Server*)" -Properties IPv4Address,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion | Export-Csv -Encoding UTF8 ExportCsvServerList.csv

And since it’s a spreadsheet you can further filter/format/manipulate the results how you see fit.

One more thing that causes confusion sometimes: 

Be aware that even though we are calling ActiveDirectory for these servers and their correlating properties, there’s one of these items that don’t come from there: the IP Address.  As you are likely aware, the IP address of a computer object is not stored in the directory; so what is actually happening is that the Get-AdComputer module is retrieving the FQDN of the computer, and doing a DNS query to resolve it to the address for you. 

Now, this can be good or bad, depending on your situation; for instance, it might slow down your 8000+ server export… or might also help alleviate the burden on your AD server as you make the query (while it delays the processing a tad to retrieve the name).  Also, you’d better be able to rely on your DNS to return valid values, or the results might be confusing/misleading! 

I hope that helps…  Thanks for reading, and by all means if you have additional tips, be sure to comment!

There are situations, however, when an application requires registry keys or some data files installed in the user’s profile prior to the applications first launch.  One common post-installation method used for installing user data is called “Active Setup”; a full explanation of how to implement this method is beyond the scope of this post… and besides… there’s already been a blog post on this topic! 

A major drawback of the Active Setup method is that any user logged on to the system when the silent installation occurred must log out of their profile and log back in.  The reason is because the mechanism which initiates Active Setup compares a Local Machine registry keys to one in the User’s profile when the user logs on.  A more convenient and functional method (and slicker, I must say) to install data to the user profile in the user context is by initiating a Windows Installer repair. 

By design, Windows Installer initiates “self repair” or “self healing” when an entry point to the installed application is launched.  Typically, the entry point is an “Advertised” shortcut.  When the user clicks on the shortcut, Windows Installer will perform an integrity check to verify all the “key paths” of the installed application are present; if not present, the Windows Installer repair will install any missing component(s) and their key path.  The key path of a component is typically a file or shortcut. 

One  method for installing Current User registry keys post install is to add a top level “Hidden Feature” (note: the feature doesn’t really have to be hidden, but we do this to ensure that whoever runs the install doesn’t have the option not to install it) to the install which contains all the HKCU keys.  Mark the feature as “required” and make it the “Parent” feature to all other features in your MSI.  Move all HKCU keys to the same component in the required feature.  Finally, add an “advertised” to your application to facilitate the repair.  After the application is installed (in the system context), when a user click on the advertised shortcut a self repair will occur to install the components with the missing key paths… IF the key path doesn’t exist.

Ya see…this blog post was partly inspired by a setup I encountered on a customer location which attempted to use this method for installing the required HKCU registry keys.  When I tested the application, it was not behaving as expected.  I looked into the .MSI that installed it and found that everything had been laid out according to the prescribed method detailed above… except… the component key path holding the HKCU keys was actually an HKLM registry key which already existed on my system!  Thus, the self repair would never “kick off”.  When attempting to initiate a controlled Windows Installer repair, you must ensure the component key path is truly unique, or the repair won’t happen. 

I hope you enjoyed this little insight into Windows Installer and find this method to install user data helpful.  This was just a high level overview; next week, I’ll follow up with a more detailed post on how to implement this functionality. 

Take, for example, the situation of having a naming convention for group objects in AD that dictates a single-letter suffix of either a “C” (to indicate a group of computer objects) or a “U” (for a group of user objects).  In this case, a group might be named something like, “Detroit Application Data U”, or “Chicago Printers Floor2 C”.  And with intentions such as these — and human beings being what they are — it’s inevitable that some users will end up in computer groups, and vice versa.

So how to we check for this messiness?  With PowerShell, of course…

We create a script that will accept an array of our AD OUs (or group-specific OUs if you’re lucky), loop through them, grab all the groups and the memberships, and do a validation to make sure the members are of the correct class (note that I could fill up pages of the lines of code for this, depending on your specifics; so I’ll just stick with the main conceptual points).  Let’s dive into the code snippets!

First, add your OUs into an array, and other variables.  Of course, you might not be able to just scrape a level with PowerShell and grab all your OUs…  Oh, but you *do* have a perfectly-regulated AD hierarchy, don’t you?  Whether it’s perfect or not, AD structure goes a long way here; and my examples show how convenient it is if you have all your groups in a standard ou=GROUPS structure or some predictable way.

$OUs = @("Detroit", "Chicago", "Los Angeles")
$MyDomain = "dc=MyDomain,dc=org"

Then you start to loop and grab all the groups in an OU:

foreach ($OU in $OUs)
{
  #... skipped a few more lines of code here...
  # Here we get the list of our groups for the loop
  $OuGroupNames = Get-ADObject -Filter {(ObjectClass -eq "group") -and ((name -like "* U") -or (name -like "* C"))} -SearchBase "ou=Groups,ou=$OU,$MyDomain"

And, now that you have the groups, you can start to evaluate each group like this:

  foreach ($OuGroup in $OuGroupNames)
  {
    #...skip more code.. What are we skipping here? Oh, validations, error-checking, and stuff...
    # we need the group name and DN
    $OuGroupName = $OuGroup.Name
    $OuGroupDn = $OuGroup.DistinguishedName

Now, we can truly check the object membership type!

    # If it is a user group...
    if ($OuGroupName -like "* U")
    {
      $MemberList = Get-ADGroupMember -Identity "$OuGroupName"
      # ...it had better be a user...
      if ($Member.ObjectClass -like "computer")
      {
        #...or we kick out an error to the report!

And so on.  Of course, you’d do the converse of the snippet above for a user-type object in a “C” group.  By the way, this can lead to all kinds of other error detection too; in fact, the main reason I couldn’t show all my code is that I ended up adding checks for empty groups, groups with members from external OUs, and so on.  Because basically, once you have the group attributes and its membership list in hand, you may as well do some validation while you’re there…

So have fun with it, and see where it leads you…  And make sure to drop me a line if you need any help putting the whole thing together.