Powershell – Self-Destruct Button…

2017-07-27T00:01:03+00:00 May 29th, 2013|Uncategorized|

While it usually is the case that the owner or creator of a tool or device would like to keep the item he or she has created safe and sound, occasionally one might create a one-time-use tool that is designed to service its purpose for only a brief time, and then be eliminated — in case further use of the tool is harmful to the purpose for which it was originally invented.  Imagine a wrecking ball for instance; while extremely useful during demolition phase, you don’t want it lying about swinging the big iron ball near your new glass windows when construction is nearly completed, do you?

In these cases, I am reminded of Dr. Heinz Doofenshmirtz, the famous inventor.  For those that know me, it will likely come as no surprise that I’m a big fan of the Doctor’s prolific and voluminous work.  One interesting (and perhaps little-known) facet of his work is that each of his inventions holds an essential – but often overlooked – element of self-mitigation.  It has been said that this feature was sometimes erroneously invoked before the completion of its ascribed task, but — and possibly due to the nature of the feature — scant evidence of this is available.  Nonetheless, he was diligent in making sure that the feature was always available, so none of his tools could cause harm beyond its intended usage.

So it is in this vein — and in honor (and in the spirit) of Dr. Doofenshmirtz — that today I’ve written what might perhaps be one of the more intriguing and perhaps jocular scripts yet:  A PowerShell Self-Destruct Button. 

This is a script that prompts you whether or not it should self-destruct; and then if so, promptly deletes itself.  Enjoy:

 

$CurrentScriptFullPathName = $MyInvocation.MyCommand.Definition
$CurrentScriptName = $MyInvocation.MyCommand.Name
clear
write ""
write "Self-Destruct option: "
$SelfDestructChoice = Read-Host "Do you wish for this script ($CurrentScriptName) to destroy itself upon completion? (Enter Yes or No)"
if ("$SelfDestructChoice" -eq "No")
{
  write ""
  write "Okay, this script will not Self-Destruct."
  write "Keeping: $CurrentScriptFullPathName"
  write ""
}
elseif ("$SelfDestructChoice" -eq "Yes")
{
  write ""
  write "You pushed the Self-Destruct button! This script will now attempt to delete itself..." 
  #write ""
  write "Deleting: $CurrentScriptFullPathName"
  Remove-Item $CurrentScriptFullPathName
  Start-Sleep 3
  write ""
  write "Validating removal...  Is $CurrentScriptName still present?"
  Start-Sleep 3
  Test-Path $CurrentScriptFullPathName
  write ""
  Start-Sleep 3
}
else
{
  write ""
  write "Invalid OverRide choice: "$SelfDestructChoice" is not valid.  Must be Yes or No. Exiting!"
  write ""
  exit
}
write "Complete! Exiting..."
Start-Sleep 3

To walk through this script a bit:  During processing, it first gathers up PathName and ScriptName variable values to help it understand where it is and what it might delete (you don’t want to delete the wrong file!).  Then, it asks you the deadly-serious question of whether or not it should be deleted upon completion.  If not, exit.  If so, self-destruct/delete (and validate).  All that, and a few formatting items to make it all nice.

There you go!  You can copy the text into a file, run it, and amaze your friends.  Maybe amaze the entire Tri-State Area!

🙂

 

Powershell – Check for PS version and act accordingly…

2013-05-22T22:29:39+00:00 May 22nd, 2013|Uncategorized|

In recent posts, we’ve been outlining some important day-to-day differences in PowerShell CMDlets and features between v2 and v3.  And right now I’m working with a customer that is in the midst of transitioning between XP and Win7, and between Server 2003 and 2008/2012, where these differences really start to matter performance-wise. 

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!

🙂

 

 

Powershell – Interactive Ping Test…

2013-05-15T22:39:09+00:00 May 15th, 2013|Uncategorized|

Here’s a fun, goofy little PowerShell script for you. 

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.

😉

 

 

Sarah, The Team, and the “Walk For Wishes”…

2017-07-27T00:01:03+00:00 May 8th, 2013|Uncategorized|

It all started simply enough — fellow Coreteker Sarah Roland sent out an email mentioning that she was starting out a Coretek walking team for the “Walk For Wishes” event, and asked for anyone to join or support her in her effort.  The Southeast Michigan Walk for Wishes 2013 event was to be held at the Detroit Zoo, in support of the Make-A-Wish Michigan foundation

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…

walkForWishesFinish

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!

🙂