HCX – Marty Nickison II

Congratulations!

You have successfully migrated (in this instance) 10 Windows 2016 DataCenter servers. Each runs part of the Supply Chain ecosystem. They are all VMWare Virtual Servers, each with 8 GB of vRam, 2 vCPUs, and a 200 GB Hard Disk.

You migrated the systems to a private cloud instance in the Microsoft Azure subscription using AVS (Azure VMware Solution). This utilized the HCX appliance installed in the common vSphere instance that hosted these guests.

Additionally, an Edge Router was successfully installed at the company’s datacenter. The Edge router was configured with an Express Route set up to transfer migration traffic ALONE. Finally, the Edge Routers at both the local and Microsoft datacenters were set up with Microsoft Enterprise Edge for Express Route Global Reach.

You are now able to log into the newly-created vSphere instance. You see three hosts in this vSphere, and each VMware virtual guest is listed under the hosts.

In the next meeting, you demonstrate this success on a network laptop connected to the room projector. You feel that you have climbed Mount Everest! You are ready to get the ‘GREAT JOB’ and plan the celebration…

…it’s at this time that the CyberSecurity professional on the project asks you, “So, how are we going to keep these new environments patched?”

YIKES!!!

In a fit of panic, you try to review what you remember of the project planning sessions. Was this even discussed? You start looking in the Microsoft Sharepoint repository with all the company contracts for IT — you want to see if that was included in the scope of work — NOPE !!

Ok, so what does this mean for the project?

In an attempt to keep things simple, “patch management” refers to the overall system/process that will successfully ensure all involved hardware and software updates and patches are installed regularly with as little manual intervention as possible.

This presents some challenging questions. How will the following be updated in a timely manner?

⦁ Windows operating systems
⦁ VMWare vSphere operating
⦁ VMWare ESXi on the hosts
⦁ Microsoft Dynamics supply chain (the supply chain base software)

Many answers CAN work, but each solution needs to be presented concerning success rate, cost, budgeting, and testing — POTENTIAL SOLUTIONS can include:

Microsoft Intune (how Microsoft pushes updates for all their software; this includes Windows and Dynamics)
Microsoft AVS (they maintain updates for their hosts ESXi and vSphere instances)

A discussion of options and their plus/delta needs to happen for the next steps to proceed properly.

To conclude, “patch management” refers to the overall system/process that will successfully ensure all involved hardware and software updates and patches are installed.

DISREGARD THIS, AND HACKING RISK INCREASES TREMENDOUSLY!

Let’s assume we plan to move two applications from the local datacenter into a Microsoft Azure subscription. We will call the applications “LiftAndShift” and “NewBuild.” For the purpose of simplicity, let’s assume each application is hosted on one server: “LiftAndShift1” and “NewBuild1”.

First, we create a space for these servers and applications to live on.

Since they share data and talk to each other via shared folders on each server, we decided to create a single tenet that will ‘house’ both servers above.

Next, we meet with the application portfolio team, stakeholders, and power users.

This meeting happens so that we can agree on a sequence of events for moving these two applications. This agreement is CRITICAL as both servers need each other, and we must minimize the risk of downtime while this migration takes place. Furthermore, we must test as many things as we can as we go through this process.

We decide to use the Azure Migrate Tool to move “LiftAndShift1” first. This server is currently a virtual machine hosted on a VMware EXSi cluster of hosts running ESXi 6.5 Update 3 (build 13932383). We then download the Azure Migrate Tool from the Microsoft Azure tenet we created.

Next, it is installed as an appliance (*.ova file) into vSphere. Finally, it is configured with an Admin-level account for both SQL on-prem and the Windows Active Directory (SPECIFICALLY USED JUST FOR THIS PURPOSE — AS DIRECTED BY LEADERSHIP, NAMELY THE CISO).

A cutover weekend plan is established.

The prior weekend, we ran an assessment for “LiftAndShift1” using that functionality in the Azure Migrate section of the Microsoft Azure portal. Since this application is very ‘lean’ (small), the VMware virtual server on which the application ‘sits’ is also quite small.

The Azure Migrate Tool successfully completes the initial assessment and recommends two drives and a B2s target to migrate this virtual server directly into the Azure Tenet.

The cutover of “LiftAndShift1” is a success, and the afterward testing completes with no major concerns.

In compliance with the plan created above, the “NewBuild1” server will not be migrated. Instead, we will move the server via a ‘new build’ process.

Now we commence with a ‘new build’ migration.

What does this mean? Simply stated, a ‘new build’ migration is when you first create a new server in the cloud with more than enough resources to run the application, data, etc.

Next, you install the most current version of the software the server will run on. There is one pre-requisite, though; you need to engage the vendor to assure you have access to the most current software. You’ll also need to get the support contracts and proper license structures for it.

Finally, you set up another cutover weekend where all the data is copied to the new location, and the new server is configured to work with the new data copy. It then needs to be tested by the power users to assure functionality.

So, when the expression ‘new build’ is used in the context of cloud migration (e.g., migrating a server to Microsoft Azure), it refers to creating a new server so house data will be updated and then copied to that new server. The base server (operating system, etc.) will NOT BE MIGRATED using tools like Azure Migrate Tool and the HCX appliances.