Fixing the Usage and Health Data Collection Service Application Proxy

Unfortunately I’ve found a problem with our development build, or rather, with SharePoint 2010. You may notice that the Usage and Health Data Collection Proxy is Stopped after deploying it in your environment. This is not just a matter of starting the service like it is with some Service Applications. In this case the SA proxy itself appears to be stopped. It appears that this is a known problem when provisioning this Service Application via the GUI. In fact, ours was created automatically as part of the Search Service Application creation process. At any rate, it doesn’t work in its current state in our environments, so it won’t actually collect any data.

To fix this just requires a couple of lines of PowerShell, courtesy of this article (to which I’ve added some clarification here).

If you go to the Manage Service Applications link you’ll see the problem:

Open the SharePoint 2010 Management Shell and Run as Administrator.

Update, 10 January 2011
Tom suggested an improvement in the comments here, which I agree is better!

$sap = Get-SPServiceApplicationProxy | where-object {$_.TypeName -eq “Usage and Health Data Collection Proxy”}

Original approach

Run Get-SPServiceApplicationProxy to enumerate the IDs of all the Service Application Proxies in your farm.

(note: you will probably have more Service Application Proxies than these)

Copy the ID for the WSS_UsageApplication.

Run the following two lines of PowerShell.

$UP = Get-SPServiceApplicationProxy | where {$_.ID -eq "<PASTE COPIED ID HERE>"}

If you refresh the Manage Service Application page the proxy should be started now.

Once that has been configured, the usage data will not appear immediately in all of the usage reports because the timer jobs to collect the data will not have run yet. The granularity of the data collection and processing is pretty fine if you want to reconfigure them for your needs, but keep in mind that none of the Web Analytics reports will appear for at least 24 hours after this fix is in place. They do not allow reporting on the current day. If you try to configure a Custom Date Range to include today’s date you will get the following message:

I’ll try to track this issue as updates come out.

Join the conversation


  1. An even simpler and quick method is to run the following commands, you don’t need to get the ID with this;

    $sap = Get-SPServiceApplicationProxy | where-object {$_.TypeName -eq “Usage and Health Data Collection Proxy”}

  2. You can automate the GUID for the proxy as follows if you only have one proxy.
    $sap = Get-SPServiceApplicationProxy | where-object {$_.TypeName -eq “Usage and Health Data Collection Proxy”}
    $ua = Get-SPServiceApplicationProxy | where-object{$_.TypeName -ilike “Usage and Health*”}
    $UP = Get-SPServiceApplicationProxy | where {$_.ID -eq $ua.Id}

      1. The last line uses a var instead of having to copy and paste in the ID. Just run the lines together, no need to copy and paste GUIDS. A lot faster, just copy and paste the code and watch it run.

  3. I think I left off $UP.Provision() at the end too.

    Anyways, I used your code, but just got the GUId as a var and used that var’s ID later so I didnt have to copy/paste.

    Worked for me.

  4. For me, the service proxy did not say it was started on the applications page, but via powershell its status said ‘online.” I hope that means it will eventually update on the UI.

  5. THANK YOU! This worked as designed and specified. Thank you for being so detailed and specific. It made for execution of the proxy fast and simple! Thank you!

Leave a comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.