Azure Migrate and Understanding Dependencies

Sarah Lean -

A while back I wrote a blog post entitled Getting Hands on with Azure Migrate, which covered off how you can deploy Azure Migrate within your environment to evaluate how ready your servers are for a move to Azure.

The information Azure Migrate gives you on it's own is fantastic and can really set you on a great course to making informed decisions about migrating from an on-premises data center to the Cloud. If you couple it with Operations Management Suite(OMS), it becomes an even more powerful tool.

OMS is a monitoring solution that was developed by Microsoft with the cloud in mind.  It can monitor both cloud and on premise environments with the use of agents.  And it doesn't just monitor the Azure environment, it can help you manage multiple cloud environments.   Some of the things that it can help you monitor are:

  • Active Directory configuration
  • Active Directory replication
  • Anti-malware installation
  • Azure Automation
  • Security and auditing
  • SQL configuration and performance
  • The status of Windows Updates
  • Performance and Log information
  • Dependencies
  • Office 365 tenant information

When we are use it in conjunction with Azure Migrate we are particularly interested in it's ability to log performance information and it's ability to capture how servers interact with each other.

OMS and Azure Migrate

When you spin up a Azure Migrate project within Azure you will see that a Log Analytics workspace is also spun up for you, running on the free tier. You can run these two products separately, however, having them deployed together gives you a but more information than having them run separately would.

When combined together you can view the dependency information within the Azure Migrate blade.

How do you get it to collect this information?

In order to get OMS to capture this information you need to install two pieces of software on your servers. The first one is the Operations Management Suite Agent and the second one is the Operations Management Suite Dependency Agent. The OMS Agent collects rich real time data from your server, while the OMS Dependency Agent collects information relating to how the server interacts with other servers/services.

Within OMS there are things called Solutions, if you are familiar with System Center Operations Manager, Solutions are similar to Management Packs. One of the Solutions available to is called "Service Map".

Service Map

The Service Map Solution discovers the application components on Windows and Linux systems and maps the communication between services. It helps you to view and discover how interconnected your servers are with each other. You'll see connections, running processes, and TCP connected ports. And all you need to do is install the Operations Management Suite Dependency Agent and enable the Solution within OMS.

What does it look like?

Above is a picture of what Service Map has found within the small lab environment I am running at home. I have three servers running:

  • WinServer01: A Windows Server 2012 R2 box
  • SQLServer02: A Windows Server 2008 box with SQL Server 2008 installed
  • Webfrontend: A Ubuntu server with Apache installed

From the picture above you can see that client machines are connected into my servers, this is Remote Desktop (RDP) sessions or in the Linux case an SSH session.

The Windows and Ubuntu servers are talking to the SQL server and interacting with the SQL instance that is installed.

The servers are also interacting with several services either internally to the network or external on ports 80, 443 and 9443.

In the example below, I've focussed my attention on SQLServer02 and can see there is a process called "Rundll32" on WinServer01 that is connecting to the SQL Server component on SQLServer02. If I drill down into that Rundll32 process Service Map helps to show me the user user, working directory (the directory where the process is running from) and the command line that was ran to get that process to run.

Within a production environment the level of detail that you can obtain is very comprehensive. It can help to plug the gaps where your internal documentation fails.

Why do you want to collect this information?

Collecting information about your environment is one of the first steps you need to take before a migration. You need to understand what servers you have, what operating systems they run, how they communicate with each other and the outside world, what resources they need. Getting a good insight can help setup your migration for success. If you start to migrate without understanding what operating systems are supported on the Azure platform you could run in to issues which could be very costly from a business point of view.

As always if you’d like to reach out and speak to me about any of the above please get in touch via Twitter @TechieLass