Beschreibung:

Ziel ist es, für die Personal Sites mittels FeatureStapling ein eigenes Feature zu aktivieren, welches die Design-Files in die Style Library sowie die Masterpage in die Masterpage-Gallery von einer Solution aus dem Solutionstore kopiert und anschliessend als aktive Masterpage setzt.
Dies hat in SharePoint 2010 problemlos funktioniert. Nach der Migration zu SharePoint 2013 scheint dies nicht mehr zu funktionieren. Getriggert wird das Staple Feature auf das Personal Site Template.

• Liste der Templates: http://wellytonian.com/2012/07/sharepoint-2013-site-templates-powershell-codes/

Die Feature-ID und die zu setzende Masterpage ist in der WebConfig festgelegt:

<appSettings>
…
<add key=“IOZ.Tools.MyContentSetDesign.FeatureId“ value=“{feature-id};kunde.master“ />
…
</appSettings>

Im FeatureActivated Eventreciever wurde folgende Methode verwendet um den Key auszulesen:

string WebConfigKey = „IOZ.Tools.MyContentSetDesign.FeatureId“;
SPSecurity.RunWithElevatedPrivileges(delegate()
{
string settings = System.Configuration.ConfigurationManager.AppSettings[WebConfigKey];
}

Diese Variante funktionierte in SharePoint 2010 problemlos, in SharePoint 2013 wird die Erstellung entweder durch einen TimerJob oder den Sharepoint Prozess durchgeführt.

Der TimerJob – Prozess hatte aus einem auch für den Microsoft-Support unerfindlichen Grund keinen Zugriff auf die WebConfig.

Lösung

Als Lösung des Problems hat sich die Installation des SharePoint Server 2013 March Public Update ergeben, nach diesem Update konnten wir keine Probleme mit dem Zugriff auf die Konfigurationsdatei feststellen und auch konsistentes Verhalten des Feature Activated Event Receivers bestätigen.

• March Public Update: http://support.microsoft.com/kb/2767999