Sometimes you encounter errors, that seem to stick around forever. I recently noticed on my SharePoint 2010 dev-machine, that the ULS doesn’t seem to be working anymore. For some strange reason the ULS is complete empty. No logmessages whatsoever. Changing the loglevel doesn’t seem to have any impact at all.
Only messages while deploying solutions from Visual Studio 2010 where showing up in the log.
Can you spot the error?
After ignoring this problem for a couple of weeks – who needs logfiles anyway, when you’re doing everyhting the perfect way! – I actually did run into a problem with a custom component and I just couldn’t figure out what’s going wrong. Having SharePoint present me a correlation-id doesn’t help at all if you have no logmessages!
The solution is actually quite simple, and it’s always the same cause when working with SharePoint: permissions! I get the feeling, that 90% of all errors and problems are related to permissions and security. This kinda leads me to thinking, that no two SharePoint installations are the same. When I comes down to security and permission settings all installations differ. Even if it’s just a tiny bit – this is sometimes all it needs to take a system down.
Back to my originial problem, well actually to the solution of my problem. The solution was, to add the account for application pools to the “Performance Log Users” group. So far the accounts where just a member of the “Performance Monitor Users”.
Heaven knows why and how this happened. A quick comparision with another SharePoint installation revealed, that on that machine the application pool account was just a member of the local users group. The account was not a member of any other group (WTF?).
I had the same problem and I found the same solution: insert application pool account in “Performance Log Users” group.
Finally, the account has the following gropus:
– Domain Users
All the problems came when we changed the user account for application pool.
During the test of this solution I found “false positive” or “false negative” results, so be sure, after any change, to close browsers, eventually kill some wp3.exe process, and IISRESET. I tried also to restart the server every time, but I suppose it’s not mandatory.
This solution is necessary for both two logging solutions: using SPDiagnosticsService directly or implementing a Custom Logging Service from SPDiagnosticsServiceBase.
Any other feedback are welcome. Thanks.
Actually I added the WSS_WPG Group to the PerformanceLogUsers. This way I can make sure, that future application pool accounts can also write to the ULS logs.
I’ve applied this solution. However, I had to restart the PC in order to get the logs going. Recycling the application pools, the sites or the IIS Admin Service wasn’t enough.
Thanks for posting the solution.