Virtually Jason

Sometimes, we write scripts that we want to schedule.  For example, I recently put together a small script that checks an environment for Snapshots that are older than 7 days and then emails the sys admins a report if it finds any.  Alan Renouf put together a quick guide on how to run PowerShell scripts with Windows Task Scheduler back in 2009, but I ran into a hiccup while trying to use that procedure the other day. Alan suggests two possible methods for accomplishing this task.  One involves editing your scripts to add the required PS Snapins and the other involves launching the PowerShell session from a pre-configured Console File.  I decided that I’d had enough of messing around with Add-PSSnapin, so I decided to experiment with the PowerShell Console option.  The example syntax that he provides is basically: Powershell.exe –PSConsoleFile myConsole.psc1 & myScript.ps1 Which didn’t exactly work for me.  When I executed this at a command line, it started PowerShell and

How often do we, as system admins, find ourselves with a strange error that might be due to network connectivity?  Pretty often, in my experience.  While Ping is a great tool for validating basic routing, we live in a world of firewalls – be they physically on the network, virtually on the network, or software installed on the server.  When diagnosing network connectivity issues, Ping is not good enough, as that only tests the ICMP network flow.  You can’t ping a specific port in Windows, so if you’re looking to test something like HTTPS (TCP 443), with Ping you’re out of luck.  Fortunately, there are many other tools available. My favorite tool is PortQry  (that link will work as long as Microsoft graces us with a consistent URL… so until tomorrow, probably).  PortQry was originally a SysInternals tool (developed for Windows 2000!) and is still one of the best.  You’ll have to download it, but it’s a simple executable that you can invoke from the command line to do some really pr

One of my customers was upgrading their Unidesk environment to 2.6 and we ran into a problem.  It proved to be an incredibly specific problem and not at all tied to Unidesk (just tied to the way they push this particular upgrade), but the troubleshooting process was very interesting and so I think it's worth putting this knowledge out there. As part of the upgrade, the Unidesk Management Appliance needs to install an OVF of itself (which is an uncommon but not unprecedented behavior for virtual appliances).  That is the step that was failing.  The most common source of that failure is a firewall; if port 443 is blocked between the Management Appliance and the ESXi host, that deployment will fail.  We went round and round with the network team, checking firewalls and couldn’t find any records of ports being blocked, but we couldn’t communicate with the ESXi hosts (although we could communicate with the vCenter server just fine). Eventually, we did a TCPDump on the ESXi hos