Recently a client asked to that all Site Collections that are created are automatically connected to the main corporate portal using the Portal Site Connection Setting (Site Actions -> Site Settings -> Portal Site Connection)

Portal Connection Settings

To do this in code is very simple as shown below which is actually triggered when a Feature gets activated:


public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
using (SPSite site = properties.Feature.Parent as SPSite)
{
PortalLog.LogString("Activating feature for: " + site.PortalName + " at URL: " +   site.PortalUrl);

site.PortalUrl = "http://corporate.portal.com";
site.PortalName = "Corporate Portal";
}
}

And thats it you can now you can set this in code and maybe do what we did and attach it to various site templates.

When doing any sort of Feature Stapling you usually want to associate the feature to an out of the box SharePoint site template.

So here is a listing of the out of the box site templates that I find really useful:

GLOBAL#0 = Global template
STS#0 = Team Site
STS#1 = Blank Site
STS#2 = Document Workspace
CMSPUBLISHING#0 = Publishing Site
BLANKINTERNET#0 = Publishing Site
BLANKINTERNET#1 = Press Releases Site
BLANKINTERNET#2 = Publishing Site with Workflow
MPS#0 = Basic Meeting Workspace
MPS#1 = Blank Meeting Workspace
MPS#2 = Decision Meeting Workspace
MPS#3 = Social Meeting Workspace
MPS#4 = Multipage Meeting Workspace
CENTRALADMIN#0 = Central Admin Site
WIKI#0 = Wiki Site
BLOG#0 = Blog
BDR#0 = Document Center
OFFILE#0 = Records Center
OFFILE#1 = Records Center
OSRV#0 = Shared Services Administration Site
SPS#0 = SharePoint Portal Server Site
SPSPERS#0 = SharePoint Portal Server Personal Space
SPSMSITE#0 = Personalization Site
SPSTOC#0 = Contents area Template
SPSTOPIC#0 = Topic area template
SPSNEWS#0 = News Site
SPSNHOME#0 = News Site
SPSSITES#0 = Site Directory
SPSCOMMU#0 = Community area template
SPSREPORTCENTER#0 = Report Center
SPSPORTAL#0 = Collaboration Portal
SRCHCEN#0 = Search Center with Tabs
PROFILES#0 = Profiles
BLANKINTERNETCONTAINER#0 = Publishing Portal
SPSMSITEHOST#0 = My Site Host
SRCHCENTERLITE#0 = Search Center
SRCHCENTERLITE#1 = Search Center
SPSBWEB#0 = SharePoint Portal Server BucketWeb Template

Another great example and a good tutorial is here

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.