VM Usage not updated in Azure Pack

One of our customers was building a billing solution for their Azure Pack environment. We just finished the implementation of the fabric and the configuration of Azure Pack. We started testing and all worked fine. We also configured the integration between SCOM and VMM for usage and configured usage in Azure Pack.

After a couple of weeks we started to implement UR5 for System Center and Azure Pack and all looked good… Until, After a while a developer came to me and said, are you using a VM with 0 cores and 0 GB’s ram and it’s up the whole hour? I said no, that machine is deleted for a couple of days. Then the panic started. What happened? How can it be the usage is off from VMM?

I had it once before that VM’s are not updated correctly in SCOM and quickly took a look at the Virtual Machine dashboard in SCOM. And yup, there were still VM’s that were deleted a while ago. Then I connected back to VMM and did a refresh of the Operation Manager Connector. A Completed w/ Info appeared. The error message:

050315_1440_temp1.png

When I tried to run that command VMM PoSh didn’t know the cmdlet. I know that VMM keeps all management pack updates in its installation directory so I logged on to the VMM server and went to the installation directory of VMM. There is a folder called ManagementPacks. I noticed that the date modified was related to the RU 5 installation release date:

050315_1440_temp2.png

I copied all files over to my desktop and did an import in SCOM:

050315_1440_temp3.png

After the import I did another refresh on the Operations Manager Connector in VMM:

050315_1440_temp4.png

After a while the connection was restored and couple of hours later the VM’s are updated in Azure Pack Usage table.

050315_1440_temp5.png

We still face an issue where some properties from the usage remains empty. We are investigating if it has something to do with the UR 5 update or something else. The fields are empty since the update of the SCOM management packs and the reconnect we did as instructed above.

eventId: 172681
externalRecordId: 169544
resourceId: VM Utilization
startTime: 2015-04-09T19:00:00
endTime: 2015-04-09T20:00:00
providerName: systemcenter
serviceType: VirtualMachine
subscriptionId: 548f0d00-3ddb-4c50-8ed3-1c0cf8c8563d

Properties:
vmName: TestVM001
vmmServer: VMM
meteredService: VM Utilization
VMId: 8955d115-d060-4c99-bdaa-28134697eb29
subscriber: email

Resources:
memoryAllocatedMin:
memoryAllocatedSum:
memoryAllocatedMedian:
memoryAllocatedAverage:
memoryAllocatedMax:

memoryConsumedMin:
memoryConsumedSum:
memoryConsumedMedian:
memoryConsumedAverage:
memoryConsumedMax:

crossDiskSizeAllocatedMin:
crossDiskSizeAllocatedSum:
crossDiskSizeAllocatedMedian:
crossDiskSizeAllocatedAverage:
crossDiskSizeAllocatedMax:

CPUAllocationCountMin: 4
CPUAllocationCountSum: 4
CPUAllocationCountMedian: 4
CPUAllocationCountAverage: 4
CPUAllocationCountMax: 4

runtimeSecondsMin: 900
runtimeSecondsAverage: 900
runtimeSecondsSum: 3600
runtimeSecondsMedian: 900
runtimeSecondsMax: 900‏

I’ll keep you posted on this…

UPDATE:
We addressed this issue at Microsoft and they have come up with some workarounds. In our case it had to do with the fact that some how the  run as accounts and run as profiles where messed up and missing. Find detailed instruction on how to fix this here.