Support Tip: Microsoft Windows Azure Pack Usage data stops being collected
Published Feb 16 2019 01:50 AM 233 Views
First published on TECHNET on May 27, 2015

~ Brian McDermott | Escalation Engineer

If you use Microsoft Windows Azure Pack and WAP Usage used to work but has now mysteriously stopped working then this post is for you. If it has never been working then you need to first set it up and configure it correctly, and you need to read this instead. However, if it still isn’t working after you have done all of that, read on for some tips on how to get it going again.

Be aware that while WAP Usage may not be working for the reason I list below, this is not the only possible reason. I promise more articles will follow covering some of those other reasons but I have to start somewhere.

What needs to be working for WAP Usage to work

1. Virtual Machine Manager.
2. The VMM to Operations Manager connection.
3. Operations Manager.
4. The OperationsManager DB to OperationsManagerDW DB synchronization workflows.
5. The OperationsManagerDW data aggregation workflows.
6. Service Provider Foundation (SPF).
8. The Usage service.
9. The UsageDB.

If WAP usage has stopped working then it has stopped working somewhere in the middle of this, somewhere at the edges, or somewhere in the detail between the bits I have listed.

This article will only cover one very particular way it can stop, and I will follow up additional blogs on the others.

VM display names and SQL DB tables

When designing your application, one of the things you need to think about is how your application will store its data. A very popular way to do this is to use a SQL database as your store. In fact, it is so popular that the Usage service uses no fewer than seven databases, and once you include the end-user billing systems, it is often many more. If you are using a SQL DB then when you are creating your tables you need to specify for each column how big the entries are going to be.

When it comes to WAP Usage we defined the maximum size of certain property tables to be 64 characters, as that is the maximum size of a VM name when you are creating it from VMM (which is what WAP does). When you are creating VMs this way, it cannot be any longer. Unfortunately, as the data is arriving in the Usage DB via the OperationsManagerDW DB, it is possible that some VMs who have their data in the OperationsManagerDW have been created outside of WAP and are managed outside of WAP, and the VM names have been changed to contain more than 64 characters outside of WAP.

It should be noted that the VM display name is not the same thing as the computer name of the VM, but is rather how VMM displays the name of the VM in its console.

When VM names contain more than 64 characters

So what happens when a VM display name is changed to contain more than 64 characters? Put simply, WAP Usage breaks.

The data will have been gathered into the OperationsManager DB and the OperationsManagerDW DB, and it will have been correctly aggregated, however when the SPF service attempts to pull this data into the SPF Usage tables it will fail.

If you enable SPF debug logging then you will find entries logged similar to this:

<Event xmlns=" ">


<Provider Name="Microsoft-ServiceProviderFoundation" Guid="{1111d4e2-0e8e-1b8b-af11-faa11ad42a01}" />

< EventID>11</EventID>

< Version>0</Version>

< Level>2</Level>

< Task>65523</Task>

< Opcode>0</Opcode>

< Keywords>0x0</Keywords>

<TimeCreated SystemTime="2015-04-27T14:53:47.925530600Z" />

< EventRecordID>14718</EventRecordID>

<Correlation />

<Execution ProcessID="2592" ThreadID="3056" ProcessorID="4" KernelTime="39" UserTime="3359" />


< Computer></Computer>

<Security UserID="S-1-5-21-123456789-123456789-123456789-1234567" />



<Data Name="component">7</Data>

<Data Name="context">{ABCDEF12-3456-7890-ABCD-EF1234567890}</Data>

<Data Name="elapsedMilliseconds">0</Data>

<Data Name="activityName">WebAuthentication Call</Data>

<Data Name="activityId">{ABCDEF12-3456-7890-ABCD-EF1234567890}</Data>

<Data Name="parentActivityName">none</Data>

<Data Name="parentActivityId">{00000000-0000-0000-0000-000000000000}</Data>

<Data Name="message"> The SPF Usage Metering Retriever encountered an error while attempting to retrieve usage data.  All SCSPFDB database changes have been rolled back.  Failure information: The given value of type String from the data source cannot be converted to type nvarchar of the specified target column.. </Data>



How to tell if this is the problem

Run the following SQL against the Operations Manager DB:

USE OperationsManager
select  displayname, len(displayname) as [No. of Chars] from basemanagedentity
where  FullName LIKE 'Microsoft.SystemCenter.VirtualMachineManager.2012.VirtualMachine:%'
and len(displayname) > 64

This will list the names of all VMs that have been given a display name that can break the Usage service.

Please note that if none are listed then this isn’t your problem.

The fix

The easiest way to fix this is to rename the listed VM names so that they are less than or equal to 64 characters, using the console where it was changed in the first place (Hyper-V or VMM). Once done, wait for the data flow to move through and Usage will commence once again.

As I mentioned above, it is possible there are other causes of a breakage in the WAP usage service and I will be adding to this post with some more in the very near future. If this isn’t your problem then keep watching.

Brian McDermott | Escalation Engineer | Microsoft GBS Management and Security Division

Get the latest System Center news on Facebook and Twitter :

System Center All Up:

Configuration Manager Support Team blog:
Data Protection Manager Team blog:
Orchestrator Support Team blog:
Operations Manager Team blog:
Service Manager Team blog:
Virtual Machine Manager Team blog:

Microsoft Intune:
WSUS Support Team blog:
The RMS blog:
App-V Team blog:
MED-V Team blog:
Server App-V Team blog:
The Surface Team blog:
The Application Proxy blog:

The Forefront Endpoint Protection blog :
The Forefront Identity Manager blog :
The Forefront TMG blog:
The Forefront UAG blog:

Version history
Last update:
‎Mar 11 2019 10:22 AM
Updated by: