Registry Access is not allowed – Logging to the Event Log and SharePoint

Overview

Any custom development that you do should have logging. Log anywhere, somewhere but please make sure that you do it. As a developer you probably think that logging code is a waste of time but try telling that to the poor infrastructure tech who is trying to work out why the entire SharePoint site or collection is down… with no information.

I log to the Event Log, a custom event log at that. We create our own Event Logs based on the functionality that we create and have pretty detailed logs. Frequently we have options for the level of debugging and using the Event Log provides a familiar interface to the users and also you can set retention policies and so forth to make sure that the logs don’t grow out of control. Additionally by not jamming everything in the Application log we keep things a little cleaner.

But alas things do go wrong and this is one example….

Symptom

You are trying to access the registry because you want to write to the application log, or a custom event log (even better).

So testing goes fine locally and then when you deploy you start getting the “Registry Access is not Allowed” error as seen below:

Possible Causes:

This usually occurs when you code is using the Application.EventLog class in someway (maybe writing to it) but the account that is executing the code (the actual user on SharePoint) does not have rights to edit or read the registry.

This is usually because your feature is trying to write to the application event log and the event source has not been created.   Also SharePoint is running under the “Local Service” and the local service account does not have rights to edit the registry.

Solutions:

Create the event source manually using regedit.

This is not really preferred but is one option. It does mean however that if the event source is removed for whatever reason then you are hosed.

1. Start Regedit
2. Go to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventlogApplication
3. Create a new key under application tag. “<Name of the source>”

Add the event source in your code (usually in the FeatureInstalled event of a Feature Receiver)

This is the preferred way since you don’t have to do anything and its all done by code. I put the Event Source in the FeatureInstalled method of a feature, you can also have the code in the FeatureActivated method as well.

public override void FeatureInstalled(SPFeatureReceiverProperties properties)
{
//Create event sources to prevent register permission errors when  activating features
EventLog.CreateEventSource("<Source Name>", "Application");
}

Tip: Don’t remove the Event Source  because if you do then when reading the Event Log you will get a message telling you that Windows doesnt know where the event is from, just leave it there…

But wait there is more!

So when you test this on your development machine and all is good, the event source has been created so there shouldn’t be an issue. It works for your account and a test account. But then another users complains that they are getting still getting the same error..what is going on…

Registry Access and Privileges

Unfortunately writing and even reading from the Registry required priviliges. Most commonly the developer is a local admin in the box that they develop so running this code below will be fine:
private void writeLog(string message, SPFeatureReceiverProperties properties)
{
if(!System.Diagnostics.EventLog.SourceExists(properties.Feature.Properties[Property_EventSource].Value))
System.Diagnostics.EventLog.CreateEventSource(properties.Feature.Properties[Property_EventSource].Value,
properties.Feature.Properties[Property_LogFile].Value);

System.Diagnostics.EventLog log = new System.Diagnostics.EventLog();
log.Source = properties.Feature.Properties[Property_EventSource].Value;

log.WriteEntry(message, EventLogEntryType.Information);
}

But then once again when you deploy there is an issues. The solution is to wrap all code that accesses the registry, this includes the SourceExists() and CreateEventSource() methods in an Elevated Priviledges block so that the code runs under the Web Application Pool account and not the local user, so the above code code be re-written thus:

private void writeLog(string message, SPFeatureReceiverProperties properties)
{
SPSecurity.RunWithElevatedPrivileges(delegate()
{
if(!System.Diagnostics.EventLog.SourceExists(properties.Feature.Properties[Property_EventSource].Value))
System.Diagnostics.EventLog.CreateEventSource(properties.Feature.Properties[Property_EventSource].Value,
properties.Feature.Properties[Property_LogFile].Value);

System.Diagnostics.EventLog log = new System.Diagnostics.EventLog();
log.Source = properties.Feature.Properties[Property_EventSource].Value;

log.WriteEntry(message, EventLogEntryType.Information);
});

}

Of course you have to make sure that the Application Pool account has access to the registry but once it does then its all good.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.