Diagnostic Area not Appearing on Diagnostic Logging Page

Sep 13, 2010 at 6:40 PM

I've created an area with several categories. I believe these are correct as I write to ULS via LogToOperations and all works as expected.

However, I don't see the Diagnostics Area in Central Administration. The documentation suggests that I should. So...

Should I see the area in Central Administration?

If yes, what should I do to make it visible?

Thanks for your work on these tools!

--Doug

Sep 14, 2010 at 2:54 PM

Could it be that you must call DiagnosticsService.Register()?

--Doug


Coordinator
Sep 14, 2010 at 5:53 PM

In general you should call DiagnosticsService.Register, although if the logging is showing up in ULS then it was called under the covers for you by SharePoint - as you stated above, the categories/areas won't show up in central admin until the logger is resgistered.  This takes a higher permission level than is available from a content web, so I'm surprised an exception wasn't thrown, unless your logging is occurring in Central Admin logic, where you do have sufficient permissions (or if you logged from a command line/powershell script, etc - outside of a content web).

Don't forget you also need to register the event sources with the event log for each area.  The documentation on MSDN covers how to do that.

Please let me know if you are still seeing an issue.

Chris

Sep 14, 2010 at 6:58 PM

Thanks! Funny you should mention registering the event sources. My call to the DiagnosticsAreaEventSource.EnsureAreasRegisteredAsEventSource method results in the error shown below. It seems that my farm account doesn't have access to the Security log and my provisioning timer job is failing. I can manually provide permission but i wonder why this happens when i don't need the Security log?

I am doing this in a timer job as my assumption is that i must ensure these areas on each server in the farm.

Thanks Chris,
--Doug

ExceptionType: 'SecurityException'   ExceptionMessage: 'The source was not found, but some or all event logs could not be searched.  Inaccessible logs: Security.'   StackTrace: '   at System.Diagnostics.EventLog.FindSourceRegistration(String source, String machineName, Boolean readOnly)       at System.Diagnostics.EventLog.SourceExists(String source, String machineName)       at Microsoft.Practices.SharePoint.Common.Logging.DiagnosticsAreaEventSource.RegisterAreas(DiagnosticsAreaCollection areas)       at Microsoft.Practices.SharePoint.Common.Logging.DiagnosticsAreaEventSource.EnsureConfiguredAreasRegistered()       at MyService.ApplicationCode.ProvisioningTimerJob.RegisterEventSources()       at MyService.ApplicationCode.Provisioning... a55085d8-8f54-468e-87fe-cf69ad92b293
09/14/2010 14:46:03.58* OWSTIMER.EXE (0x0780)                    0x05AC My Service             Installation                   1203 High     ...TimerJob.Execute(Guid targetInstanceId)'   Source: 'System'   TargetSite: 'Microsoft.Win32.RegistryKey FindSourceRegistration(System.String, System.String, Boolean)'

Sep 14, 2010 at 7:48 PM

Actually, I'm not sure this is a permissions issue. I added the timer job service account to the local machine and domain admins groups just to test and I got the same error.

Coordinator
Sep 17, 2010 at 1:42 PM

Hi Doug,

I think you are likely running the timer under the network service account which has insufficient permissions.  The Farm account must be configured with an account that has permission to write to the registry for the timer job to work.  Can you check this?

Chris

Sep 17, 2010 at 2:34 PM

Hi Chris,
Nope. It's running under a domain account. As is the norm it started life as a basic domain user account and all additional configuration came from psconfig. On Server 2008 R2 the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Security has more restrictive permissions than the rest as it denies Read to authenticated users.

I'm OK with running a script to register the event sources under a different account, but the doc's are ambiguous as to whether this an expected requirement. I say this because while they clearly say it must be done, the operation is not included in the sample feature receiver code.

See: "The SharePoint Logger provides a convenience method to help register event sources. The static DiagnosticsAreaEventSource.EnsureAreasRegisteredAsEventSource method iterates through all the diagnostic areas in configuration settings, checks to see whether each diagnostic area is already registered as an event source, and registers a new event source if required. You can call this method from your PowerShell script or your timer job, as required." http://msdn.microsoft.com/en-us/library/ff798507.aspx

--Doug

Coordinator
Sep 17, 2010 at 3:28 PM

Hi Doug,

Is the issue that you don't want to run your farm account at a higher permission level for the timer jobs? You can do this from a timer job, I have done it before - if the account has sufficient permissions.  I intend to blog about this and post the code, I just didn't get to it yet.   When I first created the timer job, I did not change the farm account, and I received this error.  We did test this operation in a farm as well as standalone with the timer job.

We didn't not include the code ior registering events in the feature receiver since the code must run on every WFE, and therefore using a feature receiver won't typically be sufficient in a farm.  I would have liked to ship the timer code, but we didn't have time to get it in.  What do you think is ambigous about the docs - that its unclear it must be done, or because we don't really show a code snippet on how to do it?

Thanks,

Chris

 

Sep 17, 2010 at 4:50 PM

Hi Chris,

Ambiguous because I was just trying to read between the lines. Knowing that there is some additional security configuration required and that this is expected behavior makes it clear.

The registry keys in question allow administrators access, so it should work to add the farm account to the local administrators groups on the machines in question. That said, I'll probably have the customer register the event sources with a script for two reasons.

1. It's fewer steps. (login, run this script)
2. I don't want to give the farm account this level of access to accomodate one situation.

I think modifying permissions on the individual registry keys, while workable, has more cons than pros.

Based on this I don't get event logging in my provisioning time jobs (this is for a custom service application), but that work is done by a SharePoint savvy admin anyway so ULS only at that point is fine.

I really appreciate the clarification, I think you folks did a great job on this. If you need help next time around I'd be happy to pitch in!

--Doug