Patch Lady – computers know when they are going to be replaced

There are some fundamental truths in computing.

1. Computers hear when you talk about replacing them and suddenly start doing weird things.
2. When you are doing a migration process, do not install updates.

…so Saturday night at 3 a.m. the server that housed our old (and still active) domain controller went offline.  The time of 3 a.m. is notable as it’s the historical and traditional time that updates are installed in my office.  This server is a virtual machine and was housed along with a few others on an older HyperV server that I’m getting ready to retire.  In a small environment I normally don’t join the HyperV (virtual server) to the domain, but had in this case in order to do a live migration from the old server to the new server.  I was going to leave this one domain controller behind once I migrated off of it on the old server since I was planning to retire it, along with the HyperV.  My guess is that because I had joined it to the domain it inadvertantly caught the update policies from the domain and installed updates that I hadn’t intended and it rebooted.  Note that I can’t prove this, but I just know what I did to the server and how it went offline at 3 a.m on Saturday morning, which is the exact time that updates are normally installed in my office.

Now comes the fun part.  When I went to the office to see why it wasn’t online, it was at a boot  prompt waiting for a bitlocker key for the C drive.

Now here’s the thing, when I built this server five years ago I wasn’t comfortable with bitlockering the boot drive so I didn’t do it.  I bitlockered (drive encryption) the Data drive on D, but NOT the C drive.  And I’m positive I didn’t because I blogged at the time (five years ago) that I wasn’t comfortable with encrypting the boot drive.  I had the print out of the bitlocker key for the D drive, but NOT the C drive as I never bitlockered the C drive.  I went back in fact and found my blog post where I talked about not bitlockering the C drive.

And the bitlocker key wasn’t hooked to a Microsoft account like my Surface devices, nor was it in AzureAD as again, I never entered  it on the C drive.  So the two places that you can go to to see if your bitlocker key is there, I know it wouldn’t BE there.

Needless to say I didn’t have a recovery key when I never gave it one.   Just for grins I tried the recovery key of the D drive (you can see that above) and it said it was incorrect.  Yeah, no kidding!  So while I then got out my backup of that server and started the process of restoring it to the new HyperV server, I decided to also reinstall the host OS knowing that once I got into the server I could then reset up the HyperV server that was safely on the D drive untouched.  It was an exercise to see which method would be faster and rebuilding the boot drive was faster than the restoration process.

So what update might have triggered this?  I honestly don’t know.  I know that when I patched this hyperV server based on 2012 R2 I only installed recommended updates not optional ones.  I never installed a later .net.  Given that I had hooked it to the domain, my guess is, and I can see in my WSUS policies that it had picked up additional patch approvals while on the domain and accidentally installed them.  Shame on me I know better than this and while doing migrations I should have turned the windows update service to disabled.

It’s a reminder to me that encryption is wonderful, until it’s not.  It’s a reminder to ensure you have an alternative way to get to the web because your normal method may be impacted.  It’s a reminder to remember you have backups and to have paper documentation of passwords and information in case you can’t get into the digital copies.  It’s a reminder to download a copy of Windows media and have flash drives and external usb hard drives as supplies ready at a moments notice.

….. and finally, it’s a reminder to not talk about new servers and migration plans while the old server is listening.  Clearly I hurt it’s feelings.