Wednesday, January 21, 2015

Azure Operational Insights: Differences Between Direct Connection & SCOM Connection


Update 01-21-2015
I got some good feedback from Microsoft about this posting. As it turns out the process AdvisorAssessment.exe runs on MMA with Direct Connection to AOI as well. It’s used for SQL Assessment and new assessments to be added in the future. This thread on the Azure Feedback Forum tells more about it. Needles to say I’ve updated this posting accordingly. A BIG thanks to Microsoft for their feedback since it keeps this blog on topic and correct as well.

Since I am testing AOI and the Microsoft Management Agent I’ve two different kind of setups running in my lab:

  1. Windows Servers running the MMA and connected directly to AOI (AKA Direct Connection);
  2. Windows Servers running the MMA, reporting to SCOM which is connected to AOI (previously known as Advisor).

And as it turns out, there is a difference in what the MMA does. But of course you’re saying. In the first setup there is no on-premise SCOM MG involved, so the MMA only runs AOI based workloads, compared to the MMA which is connected to the on-premise MG. In the latter case the MMA runs the workloads of that MG as well.

Guess what? You’re totally right. However, there is more happening besides the obvious. I noticed that the MMA which is connected directly to AOI doesn’t run any Advisor workloads compared to the MMA which reports to an on-premise SCOM MG which is connected to AOI, previously known as Advisor. The latter does run Advisor workloads.

There is much to tell, so let’s continue!

Direct Connection
As stated before in this setup the MMA connects only with AOI. The first sign the Advisor component of the MMA is dead silent is a total clean installation folder of it, meaning only the basics are there, noting more. This folder is found in the location where the MMA is installed: ~:\Program Files\Microsoft Monitoring Agent\Agent\Advisor.

This is what a basic installation looks like:
image
Just two folders and four DLL files. Just to get it running. However ONE crucial folder is missing, like a car ready to run but with it’s engine turned off, which is the folder AgentData. That folder is THE telltale sign Advisor has entered a running state, meaning it’s collecting data and – when all is well – sending it to the cloud.

However, on EVERY Windows Server having a Direct Connection with AOI, this folder is lacking, telling me Advisor is switched off.

MMA connected to on-prem MG and MG connected to AOI (previously known as Advisor)
On Windows Servers connected like this with their MMA I see that the folder ~:\Program Files\Microsoft Monitoring Agent\Agent\Advisor\AgentData is in place and running! Not only because this folder is present but also because it’s doing what’s supposed to do, more about that later.

image

Okay, so the folder AgentData is present. So this tells me Advisor is running? Well, not exactly. Yes, Advisor is or was running. But how to know whether Advisor is running right at this moment? This is a challenge since the Advisor workload doesn’t run 24/7 but on timed intervals.

When it does you’ll find the process AdvisorAssessment.exe (found in a subfolder with an increment folder up to 4 digits normally of the folder C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Resources) in a running state. This file is present on ANY Windows Server running the MMA. So you’ll find this file on MMA with a Direct Connection as well. This executable is used (for now) for the SQL Assessment functionality offered by AOI and will be used for other assessment capabilities, added to AOI in the future.

But how to see whether Advisor has been running lately? That’s easy! Just check it’s mailbox! Seriously. Go to the folder ~:\Program Files\Microsoft Monitoring Agent\Agent\Advisor\AgentData\AdvisorMonitorV2\Mailbox and there you’ll find a basic mailbox setup:
image

And yes, the folder ~\Sent Items will show you when the latest upload has taken place:
image

As you can see is Advisor sticking to it’s schedule: It sends the collected data two times per day on the exact time, once at 3:57 AM and once at 9:57 PM, exactly 12 hours later. So the data upload happens twice per 24 hours. Good to know!

Every single CAB file contains a bunch of XML files where every single XML file contains the collected information uploaded to AOI.

So far so good. But HOW does the MMA which has only a Direct Connection to AOI know NOT to run Advisor? Let’s go back to the Windows Server with a MMA connected to AOI only.

MMA with Direct Connection
As we know MMA uses MPs to carry out it’s monitoring tasks and workload. And with MPs one can configure the MMA to do all kinds of different tasks. So the first line of investigation I ran was looking at the MPs present on such a Windows Server.

All MPs received and processed by the MMA are to be found in the folder
~:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Management Packs. So I looked there for something standing out. And yes! Soon I was rewarded with the MP Microsoft.IntelligencePacks.DirectAgentOverrides.20.xml. Mind you, the number 20 in red will differ per system.

This MP won’t be found on Windows Servers running the MMA reporting to an on-premise SCOM MG which is connected to AOI.

When opening this MP in IE for instance you’ll find a bunch of Overrides which DISABLES the Advisor component:
image
So there we have it. Now we know HOW the Advisor component is disabled on MMA with Direct Connections.

But WHY? Please read on…

Recap
Advisor isn’t about monitoring at all. It’s all about ASSESSMENT of the configuration like Windows Server OS, Hyper-V, SQL, Exchange and SharePoint to name a few.

Even though Advisor served it’s purpose it’s soon going to be legacy and it’s functionality folded into AOI. As AOI is in preview (beta) it’s under heavy construction as we speak. Many things will be modified and added along the way, for instance assessment capabilities.

How that’s going to play out I don’t know. But for now we’re in a transition phase where Microsoft has decided to disable Advisor for Direct Connected MMA’s and enable it for on-premise SCOM MGs connected to Advisor.

And this makes perfect sense. When looking in the SCOM 2012 R2 Console under AdministrationSystem Center Advisor > Advisor Connection, one EXPECTS the Advisor service and functionality, ready to be enabled:
image
It would be pretty dumb when you sign up for Advisor you wouldn’t get that service. So Microsoft delivers that functionality through AOI.

However, when you have your MMA’s connecting directly to AOI, you want MONITORING alongside assessment capabilities, present in Intelligence Packs like the ones highlighted in yellow:
image

So even on a MMA connected directly with AOI, there is already Advisor functionality, thus assessments, to be found and running! And this is only the start of it all.

Intelligence Packs are added almost on a weekly basis. Just keep an eye on your AOI piece of it all and be amazed!

But how about the systems which were using SCA?
Systems which used SCA before AOI became available are already smoothly migrated to AOI with preserving the Advisor connectivity and functionality. With the added bonus of monitoring Smile.

No comments: