This one is a challenging one. With more and more customers extending their current OpsMgr experience with Microsoft Operations Management Suite (OMS) new scenarios emerge. In my last article I tried to get into the OPMS data flow and how to control it before it leaves our datacenters (Taking control of your #MSOMS data flow), today I try to tackle the need of monitoring the data flow and potentially much more. And, surprise, since OMS doesn’t do monitoring (yet) I’m going to leverage our good old friend OpsMgr.
I understand that this is somewhat a change of perspective, we are all struggling on how to monitor Opsmg with OMS (this can be a good topic for another article), but let’s consider what we’re facing today in the field:
- Leveraging OMS means, at the very basic, the need of some sort of control that data is really being sent to the cloud
- OMS doesn’t have monitoring builtin (yet). No notifications, no one stop list of active alerts and so on
- Glancing now and then the OMS portal is not an option when the support people have already too much consoles
- There’s a huge investment in OpsMgr, notifications, consoles, alerts management. In many cases OpsMgr is the one stop console for monitoring
- The current OMS (Operation Insights) management pack has a light monitoring coverage for agents connected through OpsMgr, but not for directly connected agents (I discussed a few scenarios where we definitely want directly connected agents in my previous article)
- There are cases where we need to manage and monitor several OMS workspaces
In OpsMgr terms the solution is a new management pack that implements the core of that we need:
- Monitor the ability to connect to a OMS workspace
- Monitor agent data presence on OMS
- Manage multiple tenants, subscriptions and workspaces
This was basically not possible until the release of the search API for OMS, now that we have it the management pack is ready and we’re leveraging it in our production OpsMgr managed monitoring service.
Management pack capabilities and caveats
So what this community based MP does:
- It discovers your Azure AD tenants, the authority used to authenticate to OMS, starting from a preconfigured configuration file
- It discovers all the Azure subscriptions for those tenants
- It discovers all the OMS workspaces for every Azure subscriptions
- It monitors the reachability of every OMS workspace
- It monitors the last data point collected for every OMS connected system and alerts accordingly a preset threshold
The discovering schedule (once a day to every 4 hours) and the monitoring scheduling (once every hour) are loose enough so that they don’t burden the service. The only caveat is that today I choose to discover every single managed system, this scale well if the systems are in the few hundreds, not if in the thousands. I took this decision ‘cause I wanted to have an inventory and an health model for every managed system. If you’re in the thousands of systems and still want to monitor the overall status a simple addition can achieve the same result without discovering every single system.
Management pack configuration
The management pack needs a little configuration OpsMgr side to be able to monitor OMS workspaces.
First of all it defines a resource pool “QND OMS Monitoring Pool”, it’s a good idea to set the pool in manual discovery and add just the management servers you want to use for OMS communication. The management servers need to have internet connectivity, at this stage I didn’t take into consideration proxying requirements.
Secondly you need to create a configuration file that lists all the Azure Active Directory tenants you want to discover. Bu default the file must be created in C:\QND on every pool member and must be named AADTenants.xml. These are the default, you can even set the file on a common share and override the discovery to point to that share. The file format must adhere to the following:
<Tenant Name=’QND1.onmicrosoft.com’ DisplayName=’QND1 Tenant’/>
<Tenant Name=’QND2.onmicrosoft.com’ DisplayName=’QND2 Tenant’ />
This discovery is very light weighted and runs frequently (every hour) to keep the MP responsive to any mod you make.
Thirdly you need to associate the proper access credentials to the tenants. The credentials need at least user access to the OMS workspaces to be monitored. The credentials must be of type “Basic Authentication”
Remember to distribute the credentials to the pool
Finally you need to associate the credentials to the runas profile created by the MP “QND – OMS Azure AD connection” and in turn to the proper tenant (if you have more than one tenant). To make the association simple, every time the MP discovers a tenant it also creates a group you can use as the target of your runas account. The group will be named after the DisplayName property in the AADTenants.xml file.
That’s it, after all the discoveries had had a chance to run you’ll get your console properly populated
How to get it
As usual this is a community MP, contributions and idea are welcome.
… and on GitHub you can find a Squaredup overview dashboard
This posting is provided “AS IS” with no warranties, and confers no rights.