Recently a client came to me, wanting to upgrade their aging network server. It handled Exchange (email), MS SQL (database), file/print services, and Active Directory (network administration), so the upgrade process wasn’t as straightforward as if it had been performing fewer functions. These are all mission-critical elements to my client, requiring as little downtime as possible. With aging network hardware and internet speeds, this became quite a long process, requiring many weekend and evening labor hours. This is the story of saving a failing server.

Migrating from on-site Exchange to Office 365 is pretty much a no-brainer at this point. Microsoft has made moving to the cloud so inexpensive compared to hosting the service yourself that the return on investment comes very quickly. Over the three-day holiday weekend, their network was saturated with email migration, sending more than 10 years’ worth of email over a screaming 3.0mbps circuit.

I was very pleased at how easy it was to add a Server 2016 machine into the existing SBS 2011 network – install the Active Directory role and give it credentials. Provided that your existing domain is at the 2003 level or above, it’ll do all the configuration itself and boom, instant second domain controller. The replication of organizational units and group policies went very quickly, and I was pleased to be able to start managing the domain on the much faster new server.

The client’s core business application was supported by a third-party vendor, who really dragged their feet with the idea of migrating their existing database to the new 2016 SQL database I had set up. Unfortunately while the client and vendor were negotiating some manner of payment plan the old server became nearly unresponsively slow, and the client asked me to do whatever I could to migrate off of the existing box.

With few options remaining, I dove into the idea of a physical-to-virtual migration, running the existing server as a software image inside the new server. This wouldn’t make the code better, but I could disable all newly-unused services (such as Exchange) and dedicate even more RAM to the database itself. With any luck that will help speed up the business application and let the company get back to work.

Right now I’m in the middle of using Microsoft’s disk2vhd application to make a dedicated “old server” image that can be run inside Hyper-V on the new Server 2016 machine. Obviously the best solution would have been for the vendor to migrate their application into a native Server 2016 VM, but per my client’s desires I wanted to make sure we were moving off of the existing server as quickly as possible.

With any luck I’ll be able to post an update about my progress using disk2vhd soon, detailing more of the process (and potential hang-ups) I came across when trying to save an old server.