SharePoint Foundation 2013 SP1 Bits..Diagnostic Data Provider Timer Jobs Enabled

I don’t know if this was a one-off thing, but I figured I’d share just in case. It’s even possible someone turned these jobs on without notifying anyone..though nobody has fessed up yet! If I run through another SPF13 install soon I’ll be sure to update the post.

I have confirmed that all copies of SharePoint Server 2013 do NOT enable the Data Diagnostic Timer Jobs by default. I have also confirmed that a RTM SharePoint Foundation 2013 install has the same behavior. Recently I ran through a SharePoint Foundation SP1 install (ISO pulled from VLSC)..and after a few weeks noticed the Usage Logging database was growing out of control! Looking over the timer jobs I saw that all diagnostic data provider timer jobs were turned on:


That explains it..These jobs are normally disabled as they aggregate a lot of different information/logs from SharePoint and puts it into one central location/database. We usually either turn these on for “health checks” or when troubleshooting issues and want a complete snapshot of the farm. Turned them off..Trimmed up the usage data using this method:

Note: The link above cleared up only about 10GB of data..leaving me still with a gigantic Usage Logging database. Apparently there isn’t any way I could find (without SQL queries) to clear the Diagnostic Data out of the DB. It did trim some items – Page Requests, Feature Usage, etc. You could either wait for the retention period to kick in..or if the data isn’t important you can create a new Usage database and delete the old one using the Set-SPUsageApplication PowerShell cmdlet explained here:

SharePoint 2013 Foundation – Creating the Search Service with PowerShell and Removing those Pesky GUIDs

I found this awesome PowerShell script on Gary LaPointe’s blog and decided to give it a try. This essentially mimics the SharePoint Configuration Wizard, but it gives you the power to use PowerShell! Below are is my experience with this script and how I went about removing the GUIDs from the database names.

Note: This bases the DB Server off of the default DB Server specified in Central Admin (Can be change using PowerShell Later) and it results in databases with GUIDs at the end, but we’ll remove those later :). Obviously change the Managed Account and App Pool names to fit your environment.

This will result in a default topology, but there are GUIDs..yuck! If GUIDs are unacceptable there is a method of renaming Search Service Databases on I went ahead and tried this out.

1. Run the following commands to suspend the search service

2. Now Go into SQL Server Management Studio and set each Search DB to Read-Only Mode (Accept the message to close existing connections). Right Click Database | Properties | Options. Set Read-Only to True

3. Perform a copy-only backup of each Search Database

4. Detach all of the old databases

5. Restore each database backup (Change Restore to File Names so there are no GUIDS in the MDF and LDF files)

6. Right Click Each Database and Rename (Had a pain with Admin DB. I ended up detaching and reattaching with new name)

7. Restore the old databases (Delete MDF and LDF Files first! May need to close out SQL Mgmt Studio).

8. Use PowerShell to point the Search Service Application at the renamed databases

9. Delete the old Databases with GUIDs

Check it out!


Edit: As Tuppence pointed out below there is now a way to set this up from the get-go. Check out this link: