Our server's been up and running for a while with a couple thousand users. I go to check the Usage report for the site that I know is the most popular and it's empty. 0's across the board.

I've been through the usual troubleshooting steps:

  1. I made sure the Usage and Health Data Collection was configured
  2. I verified that the WSS_Admin_WPG and WSS_WPG groups both had full access to the Log File Location
  3. I made sure both the Microsoft SharePoint Foundation Usage Data Import and Microsoft SharePoint Foundation Usage Data Processing timer jobs were enabled and able to run successfully.
  4. I checked the WSS_Logging database's permissions, the web service webapplication account and the farm account both have ownership rights over it.
  5. I checked the contents of the WSS_Logging database, the request tables are populated with information.
  6. I validated that there are receivers configured per this blog post: http://geekswithblogs.net/bjackett/archive/2013/08/26/powershell-script-to-workaround-no-data-in-sharepoint-2013-usage.aspx
  7. I tried configuring an SQL account to do this, but it doesn't look like it sticks on the configuration page.

Another note, the Search Usage data is working fine...it's just the standard site usage reports that are empty.

How can I get this pulling data?

  • did you wait for 24 hours for result? – Waqas Sarwar MVP Dec 22 '14 at 19:12
  • yup, after every change. – Snowburnt Dec 22 '14 at 20:39
  • I even forced the processing service to run...it only took about 30 seconds. – Snowburnt Dec 22 '14 at 20:48

Can you please confirm following?

Usage File Creation (typically found C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS\RequestUsage)

In the logging folder, we need to find a folder called RequestUsage. In this folder, if healthy and working correctly, we will see a *.tmp file and periodically a *.usage file being generated. If there is no file being created in here then the site is not listening for page requests.

If there is no file in here being generated make sure the site has some traffic to it, so browse the site, and check the folder periodically.

RequestUsage folder

The Microsoft SharePoint Foundation Usage Data Import timer job looks in this folder and takes *.usage file and imports the data to the Event Store.

and also this: he Event Store (typically found at C:\Program Files\Microsoft Office Servers\15.0\Data\Office Server)

The Event Store can be a chore to find, because the folder before it consists of a name with a GUID in it. If you look at your server’s shares, you’ll see it in there. In some cases, you can navigate directly from there to folder, but in other cases you cannot and will have to find it manually. Usually, I run a search for this folder by searching the computer for Analytics or EventStore. In the picture below you can see the “Analytics_(GUID)” share.

The Event Store Analytics_(GUID)

Once you find the event store, we want to make sure that it is creating folders with data in them. The folders are names based on their date. Inside the folders, you should find some .log files.

Event Store .log files

Not everything that gets passed from the RequestUsage folder gets put into the Event Store data files. Some of the information does get filtered out.

  • 1
    Should the EventStore be on all the SharePoint servers or just the central admin? – Snowburnt Dec 23 '14 at 16:31
  • So I've determined that the importer job deletes the files in the RequestUsage folder, but I'm not sure where that goes. The EventStore only has 3 folders in it, the most recent is from last week. I have verified the proper groups have access to the folder – Snowburnt Dec 23 '14 at 21:14
  • I dont see any files being created in the Event Store is there a way that we can start doing that? – user39979 Feb 25 '15 at 21:48
  • Did you verify the steps in checklist mentioned in question? – 404 Feb 25 '15 at 22:01
up vote 2 down vote accepted

In the end I deleted the Health and usage service application in "manage service applications" section in Central Admin.

I then re-enabled it by going to monitoring -> Configure usage and Health Data Collection and then checking the Enable usage data collection and enable health data collection check boxes and validating the other information.

The next day I had results.

When in doubt...kick it.

  • Do you crawl default zone or the intranet zone in the Content Sources? – Kannan Oct 9 '15 at 4:23

In my case, Search Service application was the culprit. More precisely, timer jobs that should have existed didn't.

So, verify that you have the following timer jobs:
1) Analytics Event Store Retention
2) Analytics Timer Job for Search Service Application
3) Crawl Log Cleanup for Search Application Search Service Application.
4) Health Statistics Updating
5) Indexing Schedule Manager on (Multiple)
6) Prepare query suggestions
7) Query Classification Dictionary Update for Search Application
8) Query Logging
9) Rebalance crawl store partitions
10) Search Custom Dictionaries Update
11) Search Health Monitoring - Trace Events
12) Software Quality Metrics reporting for Search
13) Spelling Customizations Upgrade
14) Spelling Dictionary Update
15) Usage Analytics Timer Job for Search Application

(This list is courtesy of https://social.technet.microsoft.com/Forums/en-US/397871a0-847e-41f6-a55f-9096f55c9630/missing-default-timer-jobs-can-we-get-them-back?forum=sharepointsearch)

In my case, 8 timer jobs were missing, but the 2 important ones that were missing:
1) Usage Analytics Timer Job for Search Application
2) Analytics Timer Job for Search Service Application

The symptom that gave this away that the Search Analytics Reporting database has a table named "SearchReportsData" that was empty in my non-working environment and populated in the environment that was OK.

Please note that directly querying SharePoint databases remains unsupported, so execute your query on a backup/replica of the database.

If you are missing one or more of those timer jobs then: 1) Delete the Search service application (keeping databases)
2) Delete the crawl, links and Analytics reporting databases
3) Rebuild the Search Service application using Restore-SPEnterpriseSearchServiceApplication
4) Create the Proxy using PowerShell
5) Verify that the timer jobs exist

This way, you are not going to lose any configuration. However, you may lose some Analytics data, but assuming it never worked, then you should be safe.

You could also opt to recreate the search service application from Scratch if you are not worried about any search customizations such as query rules or custom managed property or custom mappings, content sources, schedules, etc.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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