SCOM: Connect management groups between on-prem and Azure
During a recent project I explored the benefits on hosting a 2 legged SCOM environment for both on-prem and cloud services. Although this is possible with just one management group and site to site VPN to the cloud they opted for a 2 management group approach to keep a certain sort of divider between the on-prem and the cloud.
In this blog post (who knows it could become a series) I’ll show you how to connect the management groups to each other so they can exchange alerts and use 1 console but benefit from presence of a management group on both platforms.
In this scenario I’m going to use connected management groups. As explained here http://technet.microsoft.com/en-us/library/hh230698.aspx
Connecting management groups in SCOM 2012 gives you a couple of benefits. The biggest one in my opinion is the fact you can have multiple management groups with different settings but use 1 console to get all the alerts. The customer wanted the ability to monitor their clients on different thresholds than their own systems. The own systems were mainly situated on site although the other systems were at the clients site or in the cloud.
The management group which will have the consolidated view is called the local management group. In my example it is VLAB which is on prem. The other management groups are called “connected management groups” in this case VCLOUD.
They relate to each other in a hierarchical fashion, with connected groups in the bottom tier and the local group in the top tier. The connected groups are in a peer-to-peer relationship with each other. Each connected group has no visibility or interaction with the other connected groups; the visibility is strictly from the local group into the connected group.
So in this scenario it’s a good idea to connect these management groups to see all data in 1 console for both on-prem and client based. In VCLOUD it’s not possible to see the alerts of VLAB but the other way around it’s possible.
So what do we need to do to obtain this (even without different AD domains and firewalls in between).
First of all prep the VCLOUD in Azure:
Create endpoints on Azure machine
In order to be able to resolve the Azure management group from the on prem we need to make sure that connection is possible to the VCLOUD management server. This is done through port 5723 and 5724.
Open the Azure management portal:
My server is called vcloud-ms1
Open the endpoints and add 5723 and 5724 to the endpoints. This in fact opens the firewall of azure to your machines. All communication will happen over these 2 ports.
Click add and fill in the endpoints as shown below.
Next find the following
- The Public Virtual IP address (VIP) and take a note. In my case it’s 23.101.73.xxx
- The DNS name: in my case vcloud-ms1.cloudapp.net
Prepare the onsite management server
Now that the management server of our VCLOUD management group is configured we need to configure the management server in our VLAB environment to become the local management group which will receive the alerts.
First we need to make sure that the onsite server can resolve AND reach the server in VCLOUD management group.
This can be done by changing the hosts file on the VLAB management server.
Go to c:\windows\system32\drivers\etc\ and open the hosts file:
Note: I’ve deleted the last 3 digits of all the IP addresses above you need to fill in the full IP address as documented in the Windows Azure console.
Let’s check whether this works now from the VLAB management server. Doing THE route check: ping the hostname:
hmmm not working. Did we configure something incorrect? Check, double check. NO.
Well this makes perfect sense because: PING IS DISABLED towards Azure machines. Therefore you will get a Request timed out all the time you test no matter what you configure!
Connecting the management groups
Now that we have both ends configured it’s time to see whether we can connect the management groups. Remember: initiate the connection from the local management group (the one who needs to see all alerts and is on top of the hierarchy)
So let’s connect to the management server in VLAB:
Open the Administration pane and select Connected Management Groups and click
Right click and choose Add Management Group
Fill in all the data requested:
- Management Group Name: The name of the VCLOUD management group
- Management Server: The name of the management server in VCLOUD (make sure to use the exact name as filled in in the host file)
- Account: Because the account we use as SDK service resides in the VLAB AD and is not known in the VCLOUD we need to use the VCLOUD credentials
Note: You need to initiate this from the management server where you have changed the host file so make sure there’s a console on there
You will get the message below because it’s not possible to validate the account in the local AD:
Just click next and normally you should be connected at this point:
Success!
So now all we have to do is configure what we want to show on the local management group.
I’ll explain this further in the next blog in this series.