Ich hatte letzthin einen Fall, wo ein Kunde von einer SharePoint (2013) Standard-Lizenz auf eine Enterprise-Lizenz wechseln wollte, da er neu einige der Enterprise-Features benötigte (z.B. für die Anzeige von Visio-Dateien).
Die Umstellung auf der Test-Farm funktionierte ohne Probleme. „Enable Enterprise Features“ in der „Central Administration“ gewählt, auf „Enterprise“ gewechselt und den Key eingegeben, nach einigen Sekunden Wartezeit kam die Erfolgsmeldung.
Doch als ich die selben Schritte auf der produktiven Farm durchführte, ging auf einmal nichts mehr. Die Websites waren nicht mehr verfügbar. Einige SharePoint-Services (z.B. der Timer-Service oder der Service für die Administration) waren gestoppt. Zur Sicherheit bootete ich die Server neu (es gab ja ein Wartungsfenster) und die Webseiten liefen wieder, allerdings war die Lizenz noch immer auf „Standard“.
Dann habe ich einen erneuten Versuch unternommen und es funktionierte leider wieder nicht. Zumindest brachte die Central Administration nun eine Fehlermeldung und sagte mir, dass ich in den Logs nachschauen sollte für mehr Details – auch stürzten die Webseiten nicht mehr ab.
In den ULS-Logs (zumindest auf dem Application Server) fand ich keine nützlichen Hinweise bezüglich der Fehlerursache. Ein Blick in den „Event Viewer“ zeigte mir einen Eintrag mit Source „SharePoint 2010 Products Configuration Wizard“ (auf einem „SharePoint 2013“-Server 🙂 ) mit der Mitteilung, dass der Wizard mit Erfolg durchgelaufen ist.
Da die Produktion aus 3 SharePoint-Servern bestand (1x App, 2x Web Frontend), ging ich via RDP auch auf die beiden WFE und öffnete auch dort den Event Viewer, auf dem ersten WFE gab es auch einen erfolgreichen „Product Configuration Wizard“-Eintrag, jedoch auf dem zweiten WFE gab es einen Fehler-Eintrag, mit folgendem Text:
„Failed to register SharePoint services.
An exception of type Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException was thrown. Additional Information: An update conflict has occurred, and you must re-try this action. The object SearchAdminWebService was updated by Domain\AccountXy, in the PSCONFIG (9444) process on machine SERVER01. View the tracing log for more information about the conflict.
…“
Gemäss Fehlermeldung ist also ein Konflikt aufgetreten, es scheint so, als hätte ein Prozess auf dem einen SharePoint-Server den Prozess auf diesen Server gestört, da beide Prozesse etwas mit dem Objekt „SearchAdminWebService“ ändern wollten.
Die Suche im Internet lieferte zu diesem Problem leider nicht viele Lösungsvorschläge, jedoch ein Eintrag war vielversprechend. Ein Benutzer hatte eine Ähnliche Fehlermeldung (zumindest auch mit der Rückmeldung bezüglich „SPUpdatedConcurrencyException„) und er konnte das Problem lösen, in dem er die SharePoint-Timer-Services auf den SharePoint-Servern stoppte und dann (im Erfolgsfall) nach und nach aktivierte, so wurde verhindert, dass sich die Prozesse gegenseitig störten.
Ich habe also auf den beiden WFE-Servern den SharePoint-Timer-Service gestoppt. Dann habe ich auf dem App-Server den Lizenz-Key erneut eingegeben und auf OK geklickt. Sobald im Event-Viewer des App-Servers (Source: „SharePoint 2010 Products Configuration Wizard“) der Eintrag mit der Erfolgsmeldung für den „Product Configuration Wizard“ kam, habe ich auf dem ersten WFE-Server den Timerjob gestartet, als auch dort die Erfolgsmeldung kam, habe ich auf dem zweiten WFE den Timerjob gestartet und nach etwas Wartezeit kam dann auch dort die Erfolgsmeldung im „Event Viewer“.
Nach dem Zurückwechseln auf den App-Server wurde mir dort die Meldung präsentiert, dass die Lizenz erfolgreich eingespielt wurde und die CA fragte mich, ob ich auf den bestehenden Site-Collections das Enterprise-Feature aktivieren wollte – was ich verneinte.
Das Timing-Problem konnte also durch das serielle Starten der Timer-Jobs umgangen werden.