I want to capture usage logging in a single server SharePoint 2016 in order to know which pages are being accessed and by which user. Nothing more and nothing less.

I went into Configure usage and health data collection under Central Administration and configured it a follows:

  • Enable usage data collection: Enabled
  • Events to log: Page requests
  • Enable health data collection: originally disabled, but now selected

I wonder if enable health data collection should be selected? What is the implication of not having this selected? Would I still have the event(s) I selected (i.e. page requests) logged into the database?

If I click on log collection schedule and I then click on the jobs and choose to "run now", the job does not run. There is nothing in the job history to indicate that the job was run or not. All 3 jobs are enabled. View health reports gives me nothing. Also there are no errors or warnings reported at all.

What am I doing wrong?

EDIT1: I noticed that the "Usage and Health Data Collection Proxy" was stopped, so I managed to start it by following the instructions here (why was this stopped? bug?). Regardless I still can't seem to make those jobs run.

EDIT2: Upon further investigation, we found out the following error in the SharePoint ULS logs:

Job definition Microsoft.SharePoint.Administration.SPUsageImportJobDefinition, id aee32ef7-5eee-4a06-a40f-a46d9aade916 has no online instance for service Microsoft.SharePoint.Administration.SPUsageService, id ee820682-3a34-4d36-a05e-79135ee82a22, ignoring

The following screenshots confirm that the error is pertinent: Result of Get-SPUsageService Result of Get-SPUsageServiceApplication

  • This problem has been finally resolved by Microsoft support -- and I think I have stumbled upon a hornet's nest. They were all over the place, providing conflicting and erroneous information at first. They are supposed to provide me a full report on how they fixed the issue, so I will share it here as soon as I get it.
    – pmdci
    Commented Feb 14, 2017 at 10:09

2 Answers 2



Capture usage logging in a single server SharePoint 2016 in order to know which pages are being accessed and by which user

Microsoft SharePoint Foundation Usage Data Import job doesn't run Imports usage log files into the event store.


SPUsageService Provisioning issue We found that there was a mismatch in the ID of the timer job

Resolution Summary:

The following commands had to be executed in a SharePoint PowerShell session (admin mode):

$instance = Get-SPUsageService

I will post a full description of the problem later on. I simply don't have the time or the energy at the moment!

NOTE: I would like to restate that search is NOT required for these jobs to run. Whoever says it is, has no idea of what they are talking about. Amazingly, some people at Microsoft itself does not understand their own product. I had to waste about 2 days with their support engineers to prove them that search isn't required. Yes, like many others here I do know we need the search service for the out of the box reports to work, but this has NOTHING to do with these timer jobs failing. Plus the search service is irrelevant if you create your own reports from the populated database -- which is my case, which I made crystal clear from the start.

  • 2
    Thank you for pointing me in the right direction. Had the exact same issue. Event store was not populating any folders. However, my problem was slightly different. I had instances deployed, but if you would look into the Instances Properties, they were disabled. So I had to enabled them by running $instance.Instances | For-Each { $_.Provision(); $_.Update() }
    – Ben Lime
    Commented Aug 11, 2017 at 6:18
  • FYI... no "Dash" in For-Each... the command should be $instance.Instances | ForEach { $_.Provision(); $_.Update() } Commented Mar 25, 2019 at 20:37

Thanks for such a clear explanation of the problem and resolution, pmdci! I had something very similar - I have a 4 server SharePoint 2016 farm running on SQL 2017 AlwaysOn, and per Microsoft's recommendation, the usage DB was not included in an availability group. I had a failover event, so SQL2 became primary, and I frankly forgot to do anything about the Usage service DB (we're just starting to use it).

The transaction logs on the Usage DB filled the log drive on the #1 server because our maintenance jobs were only running on the primary (#2), and after much gnashing of teeth, we decided to remove and rebuild the Usage service, placing the DB on SQL2.

Two months after doing that, the E: drives on my SharePoint servers were filling up, and it was because the Usage DB log location was growing. The timer job is supposed to clear the .usage files after it sweeps the data inside those files into the database, but that wasn't happening.

After finding your post, I found that the four instances of my SPUsage service (one for each server in my farm) were all disabled. Re-enabling them kicked things into gear, and the .usage files were deleted and swept the data into the DB, as expected.

The one variation I had was that I couldn't execute the looping script that Ben Lime posted from a single server because I would receive an error saying the instance couldn't be provisioned because it was on another server.
$instance.Instances | ForEach { $.Provision(); $.Update() }

I had to identify which service instance was homed on which server, and then provision the instance from each server. Not sure if that's something weird affecting only me, or if it is a global thing, hence this post to let folks know.

Enumerate all instances to see which one was on which server:

$instance = Get-SPUsageService

$instance.Instances | Format-List id,server

enter image description here

Login to each server and run (replace the GUID with the GUID matching the instance that lives on that server from the previous step):

$instance = Get-SPUsageService

$serverinstance = $instance.instances | where id -like 'bdac140f-dc51-40f3-b6c2-b4d0585b5b34'



Check to make sure all are online:

$instance = Get-SPUsageService


enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.