Virtually Jason

One of my customers recently asked me for some help developing a script to search his Active Directory for user accounts that hadn't been used for more than 90 days.  He had already found that the get-aduser "LastLogon" parameter was domain controller specific, meaning that whichever DC is responding to the request will tell you when it last authenticated that user account.  Of course, since you have multiple DCs (you do, right!?), that isn't guaranteed to give you their actual last logon time. So, we put together a script that will get a list of all active AD accounts from a particular OU, then query each DC (filterable to a given site by DC name, if necessary) for each account's last logged in time.  Whichever DC returns the most recent last logged in date is the winner, and that date is stored.  At the end, the script returns a list of all users who haven't logged in to the network in X days (we used 90 days).  The script returns some basic info about the

We came across an unexpected situation recently at a customer site that I wanted to briefly discuss.  Typically, when applying ESXi host updates, you're safe to install whatever patches are available for your current version of ESXi.  The December 2015 patch, ESXi550-201512001, as described in this VMware blog entry , does not fall into that category.  You may have heard about the POODLE exploit; this patch updates the openSSL implementation and disables SSL version 3 in order to block that vulnerability. Blocking vulnerabilities is well and good, but this patch requires many vsphere administrators to modify their normal patching workflow.  If you just apply the available ESXi updates, your ESXi hosts will lose their connection to vCenter and enter an unmanaged state.  The proper way to apply this update is to update vCenter first, then apply updates to the ESXi hosts.  That workflow is well understood, when updating ESXi versions (say, from 5.1 to 5.5 or 5.5 to 6.0)... but as t