次の方法で共有


SharePoint 2010 ULS (Diagnostic ) logs not working, 0KB is size.

Recently I was working on a test farm and ran across an issue where the ULS log where not being written to.

There are several blogs out there on this issue, however I did not see any that mentioned checking the WSSTRACESESSION14 trace session.   

First open up SharePoint PowerShell (as administrator) and run the following command: Get-SPLogLevel this will list the current logging level.  If everything is set to NONE then at some point logging was disabled. Simply go back into Central Admin --> Monitoring --> Configure diagnostic monitoring then set the appropriate logging level.  Note: This page will list the location of the folder where your logs are writing to, check to ensure you are not low on disk space,

Next let's check what account is running the windows service "SharePoint 2010 Tracing",normally this is "Local Service" and should not be changed.  The "Local Service" , WSS_ADMIN_WPG, WSS_WPG, and WSS_RESTRICED_WPG_V4 accounts should have the following permissions (WSS_ADMIN_WPG should also include delete) on the folder that contains your logs:

If you have to change permissions you will want to recycle the "SharePoint 2010 Tracing" service. Once you have verified the permissions are correct, then we will want to check the Event Trace Sessions. 

The Event Trace Sessions are located inside of Performance Monitor.

Once you open up Performance Monitor, click to expand Data Collector Sets, then click on Event Trace Sessions.  On the Right you will see WSSTRACESESSION14 (you will also see WSSUASGESESSION14 which is used for the usage logs)

Right click on WSSTRACESESESSON14 then click on Properties.

You will now see the Provider for this Event Trace Session. 

Click on Security (either the tab up top or the button to the right) and review the permissions.  WSS_ADMIN_WPG, WSS_WPG, and WSS_RESTRICED_WPG_V4  should be listed and should have TRACE_LOG_EVENT permission.

If these are missing they will need to be added.  I found that there is a trick to adding permissions. If you simply add then and click Apply and then Click OK the permissions will not stay.  So I add all the IDs that need permissions and grant them the appropriate permission, then I flip back to Performance Monitor and right click on WSSTRACESESSION14 then click stop.  I quickly toggle back to the Security setting screen and then click Apply and then click OK.  Now toggle back to Performance monitor and right click WSSTRACESESSION14 session and click start. If you now verify your permissions you should see the IDs added along with the permissions.

If you look at the blogs out on the internet you will see several that suggest adding the "Account" that is nor logging to “Performance Log Users”.  This will fix the issue but if you review the permissions for “Performance Log Users” you will see that you are granting more permissions to the "account" then if you follow the above instructions. Also for SharePoint 2013 the permissions for WSS_ADMIN_WPG will have a lot more rights then what it has in SharePoint 2010 and more than “Performance Log Users” so you may not grant all the correct permissions if you are running SharePoint 2013.

Note: There should be a registry entry at HKLM\SYTEM\CURRENTCONTROLSET\WMI\SECURITY that corresponds to the Provider number listed above, if this registry is missing then most likely you have the "default" Event Trace session permissions and so the WSS_ADMIN_WPG, WSS_WPG, and WSS_RESTRICED_WPG_V4 probably do not have permissions.