I really wanted to title this blog “Lessons Learned: A rookie mistake?” However, I am actually eating Reese’s peanut butter cups right now. Just don’t tell the wife or the doctor because I am supposed to be eating better.
Anyway, I was really curious to see the new Operations Manager management pack for Azure Stack. How was the experience importing and configuring it, the alerts we get, and how are the views, etc. So off to my lab I went. My current lab is actually being redeployed with the newest and greatest versions of System Center. I currently am running Operations Manager 1801? I will have to admit, I have been working with cloud solutions for a year now and haven’t had much time with the System Center products and I am not fully up to speed with versions, etc. Hence why my lab is being rebuilt and I can refresh my skill sets with System Center again.
So I have a pretty fresh installation of SCOM 1801 (2016 build 1801) and I have a multi-node Azure Stack running build 1803 with 1804 actually being updated. Now, I am only using the Azure Stack Management Pack at this time. Which means I am not monitoring the tenant workloads, and I am not monitoring the physical infrastructure at a hardware layer as of yet. I am going to be adding that here soon. Also, don’t tell the SCOM guys but I am going to see how Nagios monitors Azure Stack infrastructure as well. However, the SCOM guys shouldn’ worry too much, I am a bit bias when it comes to monitoring tools and I tend to lean to SCOM or Log Analytics before I will adopt anything else. :)
So first things first, I actually downloaded the Azure Stack Management Pack Guide first. That doesn’t mean I read it first like any good SCOM Admin should! :) This time, I did find myself reading the guide as I was importing the management pack.
I didn’t download the Management pack and install, I just imported it from the catalog. The most recent version at this time was 18.104.22.168. The import went very smooth and painless.
So from the Administration Workspace in the SCOM console, you should see under Management packs there is a Microsoft Azure Stack option. This was there before the Management pack was imported. I am curious and might reach out to the team again to find out why and if you could still add a deployment even without the MP being imported just to grab the data and have it for future uses? Hmm… interesting thought? Anyway, they made this pretty painless and simple, at least I thought so. I really like the fact that it will create the SPN for you.
So, from the Administration Workspace, select Microsoft Azure Stack. On the Microsoft Azure Stack Overview window, click on the Add deployment link below Configured deployments.
For your Endpoint URL, enter the admin management ARM Endpoint in full. In most cases for a multi-node solution, it would be https://adminmanagement followed by your region and then your FQDN.
For the Region field, add your current region where your current stamp is configured.
At this point, I selected Service Principal for Authentication Mode.
We are using Azure Active Directory for our Identity. I went ahead and selected AAD – Use auto-created SPN. If the account you are using is an owner or a contributor role this should work for you.
If you select AAD – Enter SPN Manually you will need to have created this SPN in your AAD already and enter the information in on the next screen after clicking next. For those who will allow the SPN to be auto create then you will not need to enter that information.
It will ask you for your the account and password.
Doing the configuring of the SPN…. please stand by…
The Service Principle name has been created and the information is provided to you. Make sure you copy the super secret key and put in a very secure location (not on notepad file on the server’s desktop.)
Select a server pool I place mine in the All Management Servers Resouce Pool.
Please stand by while it adds the deployment… hold please!
Just like that, as easy as making pancakes you are done. The deployment wizard is successful!!!!
Now on the Microsoft Azure Stack Overview window you should see your newly configured deployment.
If you go to your Azure subscription under Enterprise Applications you will see your newly created SPN there as well.
So that, in a nutshell, is how to configure the Management Pack to pull data from your Azure Stack. Now we can go to the Monitoring Workspace and view all the new data that will be populating all the views.
First thing first!!! As I mentioned I almost called the blog Lessons Learned: A Rookie Mistake! When I first opened the Monitoring Workspace and started to click on all the Azure Stack views and dashboards I kept seeing an error being reported on every view and dashboard. I contacted Microsoft and put in a question on the Azure Stack forums. I do have to say the response back from Microsoft was pretty fast. The product team knew exactly what the issue was and the fix was pretty darn simple. I closed the SCOM console and reopened it. Yep, rookie SCOM admin mistake right there! So if you see the following error after you import the management packs and create a deployment then all you need to do is close out the SCOM console and open it again and the problem goes away.
Now on to the views.
The Views, Alerts, State, Dashboards!
So, I need to call out something before going forward. The snapshots I have included I almost didn’t want to include. I currently have a node down that didn’t come back up after starting the 1804 update. I didn’t want to show that I had some issues currently with my first Stack. However, things happen and as I thought about this I came to the conclusion that this is a perfect example of how the management pack works and the alerts you will see within the management pack. Now, the update issues we had are not related directly to the update process. Our 3rd node did not power on like it should have during the update process. Once we get that 3rd node fixed we can resume the updates from the point it failed and will have a healthy updated Stack soon.
This is a quick snapshot of the management pack and its views.
This is the Active Alerts view that shows all my current critical and warning alerts. As you can see right now I have a few critical alerts all based on the updates that failed. These should go away once we get node 3 replaced or repaired.
I think this is my favorite view, the Infrastructure Dashboard view. From here you will be able to see all your deployments “clouds”, all the regions under that cloud, and all the infrastructure roles for each. Now, currently, Azure Stack only supports a single cloud, single regions, single stamp. This will change at one point when they release support for multi-regions, etc.
What you can’t see in the screenshot below is the health of each infrastructure VM under each Role. If you click on a role that has dedicated VM’s in the bottom right window you will see each VM and the health of that instance.
I didn’t go into the available task for each view. Some are interesting and I may need to play around to see if we have permissions enough to run those task. For instance, under the infrastructure dashboard, when you click on an infrastructure role, and then click on one of the role instances, you have several tasks: Force Infrastructure Role Instance Refresh, Restart Infrastructure Role Instance, Shutdown Infrastructure ROle Instance, and so on. I want to know if you need elevated permissions to shut down or restart these instances? I guess I could wild west it and try on my stack?
Overall this management pack was very easy to import and configure. The information is very well laid out. The team that put this together did a very good job. I do want to know if without the Management pack itself imported can you configure a deployment still and collect data for various other uses?
I would like to thank Thomas Roettinger and his team with their assistance.
I really want to see what I can grab from Dell EMC’s tools next. I know our operations team will really want to see all around health of the entire stack at one point. However, this management pack is our first step and overall is a very good way to monitor your Azure Stack integrated systems health. I have not tried it on the ASDK yet but maybe one day will get around to doing so. I also have plans on playing with the integration with Log Analytics as well. I love work and love working with this technology!