Written by [Update: Here is the SPF UR11, that has the fix:
https://support.microsoft.com/en-us/kb/3184834 which updates SPF to 7.2.2386.0 and has been verified to keep Usage operational]
We received a signal from one of our service provider customers in the Netherlands, that they were unable to get Azure Pack to see any usage records.
If you have ever configured Usage, you probably recall that the Azure Pack Usage Collector service runs every 3 minutes for every resource provider to collect usage data from the OperationsManagerDW database. However, the WAP Usage Collector actually depends on Service Provider Foundation (SPF) to connect to the database and run an SQL query against the OperationsManagerDW database.
The WAP usage framework is quite a complex chain of interacting components with several different actors: VMM, SCOM, SPF, WAP and usage consumers such as Cloud Cruiser. It takes a very good understanding of the interaction of these components to troubleshoot WAP Usage and several great blogs have been published to troubleshoot Usage. If you take a look at the Usage section of my Azure Pack Wiki, you’ll quickly find them.
In this case, two WAP specialists at the service provider, had already gone through all the troubleshooting steps and were quite confident their configuration was correct. So that’s where I joined the party, and to tripple check, I again went through an analysis of the Usage configuration. For analysis of a WAP Usage problem, I always use the slide below, which I prepared for a talk to the Houston System Center User Group, several years ago. It helps you understand the order in which you can analyze a WAP Usage problem.
So I started checking if VMM agents were able to collect performance data (1), if the integration between VMM and SCOM was operational (2), if performance data was moved from the SCOM Operational Database to the SCOM DataWarehouse database (3), if SPF could connect to SCOM (4), if there was any usage data in the SPF usage table (5), if there was usage data for all existing resource providers (6), if the WAP Usage Collector was querying SPF for usage data every 3 minutes (7), if usage data was transferred from temporary SPF usage table to WAP Usage Database (8), if for instance Cloud Cruiser was able to connect to the Usage Service API and receive json file from WAP (9) and that data properly ended up in the Cloud Cruiser database (10).
All-in-all quite a complex chain, but if you understand this chain, it is obvious where to start.
I quickly concluded that VMM to SCOM was configured correctly and produced the correct results. The problem had to be in SPF and after I checked that the SPF was correctly configured to know how to connect to SCOM, I had to conclude I was dealing with a bug in SPF UR10.
There are two scenario’s that you can run into this issue:
- You install a fresh copy of SPF and directly upgrade to UR10 and then configure Usage
- You have already installed SPF with UR9, upgrade to UR10 and then configure Usage
I assume that if you already had a working Usage configuration and then upgrade to UR10, you should have no problems.
In this case there was a third possible culprit: SCOM 2016. As part of the WSSC 2016 TAP, the service provider had received approval from Microsoft to upgrade SCOM 2012 R2 to SCOM 2016 TP5. Because WAP Usage had not been configured up to then, this should not cause any problems … but it did. It was easy to blame an unsupported combination of WAP 2013 and SCOM 2016 for breaking Usage … but it didn’t. Read More »
