SharePoint 2013 Usage reports are empty

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.