Azure VMware Solution

What Does the Phrase “Migrations Are Not in a Silo” Mean?

Marty NickisonLeave a comment

Imagine this…


You have joined a team that will migrate an entire (one) VMware vSphere instance to Azure with the Azure VMware Solution. It has been six months, but a lot of progress has been made with the team (including you, of course).

You have:

  1. Created a scope of all servers included and cross-referenced those servers to applications each supports
  2. Designated Azure Infrastructure tenet admins and created co-contributor access accounts in Azure AD to support this project
  3. Created a special owner group in Azure AD called “Security Oversight Azure” and included everyone who is a current member of the “SECOps Private Share 1” group
  4. Created a Windows 10 VM ‘jump box’ and ensured all team members could access it
  5. Worked with the IT Network Engineering Team to construct a valid design for access to the new private cloud for the AVS (Azure VMware Solution) vSphere instance
  6. Had Microsoft start a new AVS Private Cloud instance in the company production Azure tenet
  7. Coordinated with the Network Engineering Team to have Express Route devices and configurations set up from the physical datacenter where the hosts are located (in this instance, let’s say the datacenter is located in Ohio, United States) to the Azure datacenter where you are going to have AVS ‘stood up’ in (in this instance, let’s say the target AVS’s primary location is Virginia, United States)
  8. Used the information provided by the Network Engineering Team to configure the AVS instance in Microsoft Azure
  9. Downloaded and installed the HCX appliance in your local vSphere instance with the proper configurations
  10. Performed a test migration using HCX on some legacy “not in use/scheduled to be decommissioned” virtual machine guests in the vSphere at the Ohio datacenter. The guests contained a mixture of operating systems — including Microsoft Windows 2019 DataCenter and Oracle Linux 8.x.

CONGRATULATIONS! IT WORKED!!!

Now, you are tasked with assisting the team in moving more servers. In compliance with the schedules of the application portfolio sub-team, you are going to migrate five more servers next weekend. In this instance, these servers (guests) are:

1. OHDCFileServGP1 File Server in Ohio Datacenter for non-executives 1

2. OHDCFileServGP2 File Server in Ohio Datacenter for non-executives 2

3. OHDCFileServGP3 File Server in Ohio Datacenter for non-executives 3

4. OHDCFileServGP4 File Server in Ohio Datacenter for non-executives 4

5. OHDCFileServEX1 File Server in Ohio Datacenter for C-Suite executives 1

As a proactive migration professional, you make sure all the servers above are currently listed in vSphere as running, and you can currently log into them.

WAIT! PROBLEM! OHDCFILEServEX1 is now titled “OHDCFILEServEX1(LEGACY_DELETE03272025)”…

WHAT IS THIS?!

Well, you start asking your team members about this via group chat in Microsoft Teams. Furthermore, you provide pictures of what you see (THANK YOU, SNIPPING TOOL). The team was not aware of this, so they use the team liaison to reach out to the onsite System Engineering team.

YOU GET AN ANSWER:
Change Management Record CR010272008 was completed 33 days ago. The fileserver was moved to Azure Storage and placed in a blob storage container with multi-factor authentication. Apparently, an executive’s account was compromised, and swift and decisive action was taken to assure the future security of all executive data.

Why was the team not aware of this emergency change, and WHO IS RESPONSIBLE FOR UPDATING THE TEAM ON SUCH WORK?!

Questions are asked, and in the future, team members are designated to join the Change Management weekly approval call to keep aware of the changes coming for anything that might impact the project plan.

Now — Here’s how that whole story fits into the question:

What does the phrase “migrations are not in a silo” mean?

In the illustration above (as with many special projects in general), the team was focused on the objective at hand — migration to Azure VMware Solution. They spent time and resources to make sure they were continually moving towards that goal. In this respect, the team was doing what they should have done.

However, Information Technology is a continually changing entity in corporations.

While the team is working hard to accomplish the goal(s) at hand, other information technology projects and initiatives are being accomplished in real-time. Any IT project team needs to keep an eye on other projects that can potentially impact the project at hand. Failure to do so can potentially bring CATASTROPHIC results to the project, for instance:

  1. Task accomplishment delays
  2. Significant increase in cost waste for the project
  3. Required redesign of the project plan
  4. COMPLETE INVALIDATION OF THE PROJECT — Basically, making the project irrelevant

Essentially, you have to keep an eye on other projects that are going on while you work on your own project(s). MIGRATIONS ARE NOT IN A SILO — other projects and changes can affect the migration in multiple ways.

What Is Meant by “The Migration Is Not Done Once All the Servers Are Migrated”?

Marty NickisonLeave a comment

Congratulations!

You have migrated the last of the servers from the datacenter into Azure VMware Solution’s Azure Private Cloud. You can see all of the migrated VMware guests listed on the new vSphere instance with three ‘virtual’ hosts load-balancing the full load of all servers that have been migrated (for now, let’s say you migrated a total of ten virtual machines). The servers are all running without operational issues in the AVS vSphere. Furthermore, you don’t see any alerts in the details tabs.

CONGRATULATIONS! YOU ARE NOT DONE!

WHAT?
WHAT GIVES?!

For anyone who plans to move into cloud migration engineering or architecture, please keep the following phase locked into your memory: “THE MIGRATION IS NOT DONE, JUST BECAUSE ALL THE SERVERS ARE MIGRATED.”

…let me explain.

Yes, getting the physical servers migrated is a major accomplishment! You should feel like a load has been lifted off of your back. However, do not be tempted to think you’ve completed your migration work just because the servers are up and running in the new environment.

Here’s the key: the migration is done when the clients are operational in the new environment.

The difference is the presence of post-migration workloads. Once the servers and related infrastructure are migrated and tested while working, you have to ensure the clients can get to the new location and that the testing results align with pre-migration results.

Specifically, the migration is done when the clients are working the way they used to before migration into the new environment with few changes to the overall work approach and execution.

Remember, we are migration engineers and architects who work to serve the clients’ needs (company, customers, etc.). IT’S ONLY WHEN THE END-USERS ARE WORKING ‘NORMALLY’ IN THE NEW ENVIRONMENT THAT WE CAN START TO CONSIDER THE CLOSURE OF THE PROJECT WITH SUCCESS.

…NEVER forget the above.

What Is Meant by “Patch Management” When Discussing Migrations?

Marty NickisonLeave a comment

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:

  1. Microsoft Intune (how Microsoft pushes updates for all their software; this includes Windows and Dynamics)
  2. 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!