LogToOperations Not Logging to ULS Log?

Oct 10, 2010 at 10:57 AM

When I call LogToOperations, I'm only getting an entry in the Windows Event Log and not the ULS log ... contrary to the documentation.  The documentation states that calling "LogToOperations" will write to BOTH the Event log and the the ULS log.  In looking at the SPG source code briefly, it doesn't appear that any LogToOperations methods will lead to the creating of a ULS log entry.  Can someone please confirm whether or not LogToOperations should also log to the ULS?  Thanks.


Oct 10, 2010 at 3:35 PM

Hi Steve,

That behavior is implemented by the SharePoint logging logic below SPG.  Are you sure your filter levels for the ULS for that category aren't preventing it from being logged?


Oct 12, 2010 at 12:24 AM

Hi Chris.  Yes, did look at the filter levels.  I can see my new area and categories and even set them all to verbose, but still nothing showing up in the ULS log.  I didn't realize that the underlying SharePoint logging logic handled the writing to the ULS log when also writing to the event log, so I'll continue investigating to ensure I'm doing things right ...


Oct 12, 2010 at 6:38 AM

Here's the scenario I'm working with and some additional information. 

I have two features that I'm deploying.  One is a farm level feature containing core stuff like setting up the diagnostics areas, etc.  I activate this feature in Central Admin (Manage Farm Features).  When I activate this core farm feature, I create test log entries: a call to "LogToOperations" and a call to "TraceToDeveloper".  Both calls succeed and I see log entries in both the event log and the ULS log.  So, now I know that my categories are recognized and my diagnostic filtering is configured correctly.

The other feature is a site collection level feature.  Activation of this feature is done using an administrator account.  The site collection where the feature is deployed is running under a web app pool account different from the central admin pool account.  When I activate this feature, there is an exception.  When I log the exception using "LogToOperations" I only receive the entry in the Windows event log.  "TraceToDeveloper" writes nothings.  Neither method writes to the ULS log and neither method throws an exception.  There is no other log information I can find in the event log or ULS log that would indicate why ULS entries are not written.  I'm thinking it must have something to do with security based on execution taking place under a different pool account?


Oct 12, 2010 at 9:06 AM

Ok, more information/research.  I think I've pinned it down to a permissions issue with the pool account that attempts to write to ULS. 

I launched PowerShell using the central admin account (let's call it 'spadmin') and executed a script that used the SPG SharePointLogger class to call "TraceToDeveloper".  Worked.  I then launched PowerShell as my content web app pool account (let's call it 'spapp') and executed the same script.  Nothing; no entry in ULS log and no exception thrown.  I then made the 'spapp' account a member of different groups.  Giving it god-like Enterprise Admin group membership worked.  Looking at the 'spadmin' (central admin) account group memberships I noticed a couple of groups not assigned to 'spapp': WSS_ADMIN_WPG, WSS_RESTRICTED_WPG_V4, and "Performance Log Users".  Making 'spapp' (the content wep app pool account) a member of the "Performance Log Users" did the trick! 

So, it would appear that all SharePoint accounts that need to log to the ULS log need to be a member of "Performance Log Users".  Is that well known and is something I simply missed when configuring my web app pool account?  Should, or does, SharePoint automatically make registered managed accounts a member of the "Performance Log Users" group?  I did a quick online search for this but didn't come up with any documentation that explicitly mentions this group membership requirement; I could easily have missed something.  Any insight you could add would be appreciated.


Oct 12, 2010 at 9:14 PM

Thanks for the feedback Steve.  I'm checking with the product team on getting this documented when setting up a managed account.