Archiv der Kategorie: SharePoint

SPC 2014: Upgrade, Migration und Performance

Montagnachmittag hatte ich noch zwei Sessions besucht. Zunächst den Vortrag zu Upgrade und Migration auf SharePoint 2013 und Office 365 von Dan Holme. Er ist weniger auf die technischen Feinheiten, als auf die Business-Entscheidungen dahinter eingegangen. Sehr richtig fand ich die Aussage: “Soll ich auf SharePoint 2013 bzw. In die Cloud migrieren? – Nein!”. Denn im Gründe muss eine Änderung einen Business Value haben und darf kein Selbstzweck haben. Eine weitere Empfehlung von ihm: möglichst früh die neuen Produkte parallel einführen und für die Zwecke nutzen, die dort besser gehen. Im Grunde genommen bei SharePoint 2013 eben alle Workloads.

Dies hat natürlich zur Folge, dass man zwei Umgebungen betreuen muss, daher muss man sich die Frage stellen, ob eine Migration der alten Inhalte dann nicht doch einen Business Value hat.

Eine weitere Absage erteilte er der weit verbreiteten Mär, dass man bei neuen Produkten besser bis Service Pack 1 warten sollte. Mal davon abgesehen, dass diese Wartezeit bei SharePoint 2013 nun vorüber ist, werden die neuen Releases bereits bei Microsoft mit Millionen von Benutzern getestet, im Rahmen von Office 365. wir haben es also mit’m feiner völlig anderen Test zu tun, der die Bugfreiheit enorm erhöht.

Beim zweiten Vortrag von Ryan Campbell ging es um Advanced Performance Analysis. Er stellte anhand eines Kundenszenarios mit einer sehr großen SharePoint Farm dar, mit welchen Mitteln er beim Kunden Flaschenhälse entdeckt hatte.

Hierzu sammelte er 400GB Rohdaten von IiS Logs, Performance Countern, TraceRoutes, ULS Logs und so weiter und analysierte diese per SQL Server, Power BI und Excel, um Grafiken zu erstellen

Das Resultat der Untersuchung ergab folgende Action Items:

• Abschalten vergessener Überwachungsfunktionen
• Erhöhen der Dateianzahl der TempDB
• RAM-Erweiterung
• Setzen von MAXDOP im SQL Server auf 1
• Erhöhen der Netzwerkbandbreite bei einigen Verbindungen

Im Endeffekt also genau die Punkte, die sich bereits in den Empfehlungen des TechNet finden.

SPC 2014: KeyNote

Auch diesmal berichte ich wieder von der SharePoint Conference aus Las Vegas. Ein paar Berichte werden sicher erst nach und nach kommen, ich versuche das aber möglichst aktuell zu halten.

Die SharePoint Conference 2014 begann natürlich wie immer mit einer Keynote, die von Jared Spataro eröffnet wurde. Nach den üblichen Worten kam dann auch gleich Ex-Präsident Bill Clinton zu Wort, der vor allem über den Nutzen von Technologie beim Aufbau fairer Gesellschaftsstrukturen referierte mit Beispielen aus dem humanitären, öffentlichen und unternehmerischen Bereich.

Nach diesen Worten ging es dann mehr zur Technik. Jared Spataro wies darauf, dass die momentan aktuellen Themen wie Cloud, Social, Mobile und Big Data meist eher im privaten Bereich genutzt werden, als in den Unternehmen. Gerade Social Collaboration ist dort meist noch nicht richtig angekommen.

Auch mehrere offizielle Ankündigungen waren sehr interessant: es wird eine separate Lizenz für OneDrive for Business geben, die 25GB Speicher auf einer Office 365 Personal Site bereitstellen soll. Seit Service Pack 1 für SharePoint 2013 lässt sich diese auch direkt OnPremise einbinden.

Weitere Änderungen wir des bei Office 365 geben: bis zu 1TB Größe Site Collections und grenzenloser Tenant-Speicher wird Einzug halten, ein neues Videoportal und Office Graph zum Auffinden relevanter Informationen werden implementiert.

Aber auch OnPremise gibt es Neuigkeiten: 2015 wird es neue OnPremise-Releases von Office, SharePoint und Exchange geben.

Interessant war dann auch die Demo von Julia White zur künftigen Yammer-Integration in Office 365, Office Online und in das Design von Office 365.

Microsoft veröffentlicht Service Pack 1 für Office 2013, SharePoint 2013 und Exchange 2013

Wie im “Office Update Blog” nachzulesen ist, hat Microsoft das Service Pack 1 für die genannten Produkte veröffentlicht. Das Update für Office 2013 steht bereits über WSUS und Microsoft Update zur Verfügung.

Nach der Installation des Service Pack 1 auf SharePoint 2013 sind in der Zentraladministration direkt neue Optionen aufgetaucht, die sich sehr interessant anhören und die ich mir in der nächsten Zeit genauer anschauen werde:

Abfragen von großen Datenmengen in SharePoint

Da ich vor Kurzem wieder mal zu einem Kunden gerufen, der in seiner SharePoint-Umgebung sehr große Performance-Probleme hatte mit einer Eigenentwicklung, möchte ich die “Lessons Learned” an dieser Stelle nieder schreiben, da ich immer wieder erleben muss, dass Entwickler in Ihrer kleinen Entwicklungsumgebung vor sich hin “coden”, den späteren Produktiveinsatz und deren Datenmengen und –Strukturen aber völlig links liegen lassen.

Ausgangslage

Die produktive Umgebung läuft derzeit auf SharePoint 2007. Innerhalb einer WebApplication existieren derzeit 130.000 Site Collections verteilt auf 100 Datenbanken. Die gesamte Datenmenge umfasst etwa 1,4TB in den Datenbanken plus eine große Datenmenge in einem angeschlossenen Archivsystem.

Die Applikation selbst besteht aus einer Vielzahl von Komponenten, die ich hier nicht alle beschreiben kann. Wichtig sind immer die Startseite der Site Collection und die Startseiten der Sub-Sites. Hier werden in verschiedenen WebParts Übersichten über die Sub-Sites, über alle in der Site Collection vorhandenen Dokumente und bestimmte Dokumente aufgelistet.

Und genau hier versteckte sich auch das Problem. Große Site Collections können durchaus mehrere GB groß werden und ein paar Hundert Dokumente beinhalten. Und unter anderem auf solchen benötigt die Startseite zum Rendern meist mehrere Sekunden bis sogar zu einer Minute. Für die Akzeptanz des Gesamtsystems ist dies natürlich tödlich.

Für meine Tests und Verbesserungen hatte ich eine größere Site Collection mit 5GB Inhalt in 74 Sub-Sites und ein paar Hundert Dokumenten genommen.

Hinweis: Die folgenden Messungen sind nicht repräsentativ, da das Entwicklungssystem nicht sonderlich performant war. Allerdings spricht das Delta zur Verbesserung eine sehr deutliche Sprache und kann durchaus als Information für eigene Entwicklungen herangezogen werden.

Problem(e)

Viele hatten sich das System bereits angeschaut und die meisten haben es auf die Infrastruktur geschoben: “Der SQL Server ist dafür nicht ausgelegt”, “Sie brauchen mehr SharePoint Server” und “Das Storage darunter passt nicht” wurden geäußert.

Das Problem versteckte sich jedoch (wie meistens) ganz woanders: Es war die Art und Weise wie der Entwickler die benötigten Daten abgefragt hatte und wie die Gesamtstruktur der Sites aufgebaut war.

Beispiel 1: Iteratives Abfragen aller Web-Objekte

Ein WebPart ging durch alle Sub-Sites durch und suchte dort ein Element in einer speziellen versteckten Liste:

 

Durch die Instanziierung von allen SPWeb-Objekten bei jedem Aufruf ging jede Menge Zeit verloren und das WebPart benötigte bereits etwa 700-800ms. Dabei hatte der Entwickler bereits die Grundlagen für eine schnelle Abfrage gelegt, indem die Liste und das Element einen eigenen Content Type verwendeten. Dies ermöglichte eine sehr einfache Verbesserung durch die Verwendung eines SiteDataQuery:

Diese Änderung führte zu zwei Vorteilen:

  1. Die Ausführungszeit reduzierte sich auf 100ms
  2. Der Code ist sehr viel einfacher. Da GetSiteData() bereits eine DataTable produziert, musste diese für das anzeigende Grid nicht erst erzeugt werden.

Doch hier war noch nicht das Ende erreicht. Da die Informationen in den Listen sehr statisch sind, kann das Ergebnis ideal zwischengespeichert werden. Hierzu bietet SharePoint bereits den Object Cache an. Wenn bereits ein SiteDataQuery verwendet wird, ist die Nutzung des Object Cache sehr einfach realisierbar:

Hierdurch erhöhte sich die Ausführungszeit beim Erzeugen des Cache zwar auf etwa 130ms, jedoch konnten fortfolgende Requests innerhalb von 10ms bedient werden.

Beispiel 2: Iteratives Abfragen aller Web-Objekte

Auch das zweite Beispiel ist sehr ähnlich. Der erste Code-Teil iteriert durch die SPWeb-Objekte:

In der aufgerufenen Methode werden die Dokumente jedoch diesmal mittels eines CAML-Query abgefragt, allerdings auch wieder einzelne für jede Dokumentbibliothek:

Wie man erkennen kann, werden nach dem Erzeugen des Ergebnisses durch das CAML-Query wieder Elemente verworfen, die bestimmten Bedingungen nicht genügen. Idealerweise sollten diese in das CAML-Query aufgenommen werden, allerdings hat CAML auch gewissen Beschränkungen, die nicht alle Varianten von Bedingungen erlauben.

Folgender Code hat jedoch auch hier für eine Verbesserung der Laufzeit von 2.500ms auf etwa 10ms nach dem Cachen und 1.300ms zum Cachen gesorgt:

Beispiel 3: Verwendung von Contains statt separater Spalten

Die schwierigsten Performance-Probleme bei der Datenabfrage generell ergeben sich, wenn Strings nicht komplett vergleichbar sind, sondern nur Teilbereiche der Strings für Bedingungen herhalten müssen. Hier lässt sich auch nicht sehr viel optimieren, jede Art der Abfrage ist hier egal ob in SharePoint oder in anderen Systemen langsam. Um dies zu optimieren, müssend die Datenstrukturen verändert werden. Hinzu kommt in diesem Beispiel, dass die Kategorisierung von Dokumenten in SharePoint über Ordner vorgenommen wurde:

Das WebPart hat folgende Aufgabe: Es sucht Dokumente in der aktuellen Website, die in Ordner stehen, die im Namen “(sensible Daten)” stehen haben:

Hier wird rekursiv jeder Ordner auf oberster Ebene in jeder Dokumentbibliothek geprüft, ob der String “(sensible Daten)” im Titel vorkommt. Wenn er dazu noch Dokumente enthält wird er einer Liste hinzugefügt, die später für das WebPart gerendert wird. Dies führt zu einer Ausführungszeit von 500ms.

Auch hier habe ich versucht über ein CAML-Query das Ergebnis zu verbessern, allerdings ist die Verwendung der CAML-Methode “<Contains>” auch nicht sehr viel schneller. Folgender Code konnte eine Reduktion der Ausführungszeit von gerade einmal 150ms auf 350ms erreichen:

Man könnte hier auch wieder durch Verwendung des Object Cache das Ergebnis wahrscheinlich deutlich verbessern, sinnvoller wäre jedoch eine Anpassung der Datenstrukturen, z.B. durch Auslagerung des Flags “Sensible Daten” auf den Content Type des Dokuments, um diese mittels “<Eq>”-Methode per CAML zu finden. Doch diese Anpassung kann sehr viele Querverbindungen innerhalb der Gesamtlösung haben und ist damit mit sehr intensiven Tests verbunden. Zudem müssen alle Bestandsdaten modifiziert werden.

Fazit

In den vorigen Kapiteln habe ich ein paar Beispiele erläutert, wie viele Entwickler auf schnelle Art und Weise versuchen ein Problem zu lösen und den offensichtlichsten, aber damit nicht den schnellsten Weg gehen. Weitere Infos zu SPSiteDataQuery und CrossListQueryCache finden sich in einem interessanten Blog-Artikel von Vardhaman Deshpande: http://www.vrdmn.com/2012/11/querying-list-items-from-large-number.html.

In einem späteren Artikel werde ich versuchen auf Gründe für dieses Vorgehen eines Entwicklers und mögliche Lösungsansätze einzugehen.

Microsoft stellt InfoPath ein

Laut einem Beitrag im Office Team Blog wird es keine weitere Version von InfoPath nach Office 2013 mehr geben. Zwar wird InfoPath 2013 bis zum Jahr 2023 supported, allerdings nicht mehr weiter entwickelt.

InfoPath wird gern in von SharePoint zur einfachen Erzeugung von Formularen mit Logik und einfachen Oberflächen genutzt (um z.B. Prozesse und Workflows anzustoßen) oder auch zur Anpassung von Listenformularen.

Schon lange wurde über die Zukunft von InfoPath spekuliert, da in den letzten Versionen sehr wenige Neuerungen integriert wurden und viele Mängel nie richtig behoben wurden.

Eine Antwort zur zukünftigen einfachen Erstellung und Anpassung von Formularen in SharePoint gibt der Artikel jedoch nicht. Microsoft arbeitet offensichtlich an einer neuen Technologie, die im Laufe des Jahres vorgestellt werden soll. Auf der SharePoint Conference in Las Vegas im März soll es dazu einen Ausblick geben.

Was bleibt? Microsoft empfiehlt trotzdem derzeit weiter InfoPath zu nutzen. Wahrscheinlich wird die neue Technologie erst mit der nächsten Version von SharePoint Einzug halten. Mit K2 Forms oder Nintex Forms existieren jedenfalls im Dritthersteller-Markt auch potentielle Alternativen.

Aufgabenverwaltung in SharePoint Server 2013

Bis SharePoint 2010 waren Aufgaben in SharePoint, die bestimmten Mitarbeitern zugewiesen wurden für selbige nur über eine E-Mail-Benachrichtigung sichtbar. Jede Aufgabenliste stand für sich alleine und alles zusammen zu fassen bedeutete zusätzlichen Implementationsaufwand, z.B. indem die Suche für das tabellenartige Darstellen der Aufgaben herangezogen wurde:

Jeder Benutzer konnte zusätzlich noch jede einzelne Aufgabenliste in sein Outlook synchronisieren lassen, um einen Gesamtüberblick zu erhalten.

SharePoint 2013

Mit SharePoint Server 2013 ändert sich dies nun. Auf dem MySite Host gibt es hierzu eine zentrale Tasks-Übersicht, die über die Suche alle zugewiesenen Aufgaben in der gesamten Farm für den aktuellen Benutzer zusammengefasst darstellt:

Aufgaben können nun auch mehreren Benutzern gleichzeitig zugewiesen werden. Über diese Ansicht kann ich die Aufgaben in einem Zeitstrahl abbilden lassen, direkt bearbeiten oder einen einfachen Klick direkt als Abgeschlossen kennzeichnen. Die Seite aktualisiert dann die entsprechende Aufgabe in der Quellliste. Auch können dort direkt persönliche Aufgaben erstellt werden, die dann in der Personal Site in einer Aufgabenliste gespeichert werden.

Die Aufgabenübersicht wird standardmäßig maximal alle 5 Minuten aktualisiert, sobald der Benutzer sie aufruft.

Für diese Funktionalität verantwortlich sind die Work Management Service Application in Verbindung mit User Profile Service Application und Search Service Application. Die Einrichtung wird z.B. hier erklärt: http://www.brainlitter.com/2013/01/09/provisioning-the-work-management-service-application/. Allerdings muss man zusätzlich beachten, dass der Application Pool Account der Services auch Zugriff auf die WebApplications benötigt. Dies kann mit einem PowerShell-Skript erreicht werden:

foreach ($wa in Get-SPWebApplication) {
    $wa.GrantAccessToProcessIdentity("Username")
    $wa.Update()
    }

Exchange 2013

Erweitert wird diese Funktionalität dann durch eine Zusammenarbeit mit Exchange 2013: Hier können alle Tasks aus dem Benutzerpostfach nach SharePoint synchronisiert werden und alle gefundenen Tasks aus SharePoint auf dem umgekehrten Weg mit dem Postfach synchronisiert werden.

Somit erhält der Benutzer auch im Outlook einen Komplettüberblick aller anstehenden Aufgaben und kann sie dort auch bearbeiten. In Outlook neu erstellte Aufgaben landen jedoch immer in der Personal Tasks Liste in der Personal Site des Benutzers.

Die systemseitige Einrichtung dieser Synchronisation ist nicht ganz einfach, ein TechNet-Artikel führt aber sehr gut hier durch: http://technet.microsoft.com/en-us/library/jj554516.aspx.

Um die Funktion aber danach für einen Benutzer zu aktivieren muss dieser in der Taskübersicht diese selbst aktivieren:

Der Timer Job “Work Management Synchronize with Exchange” synchronisiert dann für alle eingerichteten Benutzer alle paar Minuten die Aufgaben zwischen beiden Welten und man erhält entsprechend die Ansicht in Outlook

und die korrespondierende Ansicht in der MySite

Aktuelle Patch-Übersicht zu SharePoint 2013

Da es inzwischen einige Patches für SharePoint und die darum liegenden Produkte gibt, möchte ich an dieser Stelle einmal alle zusammen fassen, die bisher erschienen sind und welche auf welchen Systemen installieren werden sollen.

SharePoint 2013

Für SharePoint 2013 gibt es inzwischen bereits zwei Updates:

March 2013 Public Update

Hier handelt es sich um ein Public Update, dass auf allen Systemen installiert werden muss, da es für alle zukünftigen Updates ein Prerequisite darstellt. Sie sollten dieses Update also sehr bald evaluieren und installieren:

Die Installation ist jedoch nicht ganz so einfach, in meinem letzten Blogbeitrag habe ich den Link hinterlegt, den Sie beachten sollten, wenn Sie eine Search Service Application in Betrieb haben.

April 2013 Cumulative Update

Dieses CU behebt einige Problem in SharePoint. Lesen Sie sich die Release Notes genau durch und installieren Sie dieses Update nur, wenn ein Fehler davon bei Ihnen auftritt. CUs sind nicht intensiv getestet und können dadurch Nebenwirkungen haben:

  • SharePoint Foundation & Server 2013: KB2751999

Das Foundation-Update beinhaltet auch das entsprechende Update KB2727025 für den SharePoint Server.

Für Nutzer der InfoPath Forms Services dürfte auch KB2752020 interessant sein. Hier wurde ein Fehler behoben, bei dem nach einem Upgrade von SharePoint 2010 auf SharePoint 2013 in InfoPath enthaltene Datenverbindungen auf SharePoint-Listen nicht mehr funktionierten.

Office Web Apps Server 2013

Für den Office Web Apps Server sind auch die entsprechenden Updates veröffentlicht worden:

March 2013 Public Update

April 2013 Cumulative Update

Workflow Manager

Wer SharePoint Server 2013 einsetzt und den Workflow Manager installiert und konfiguriert hat, sollte nach dem Einspielen des March 2013 PU in SharePoint auch das Cumulative Update 1 für den Workflow Manager installieren:

  • Cumulative Update 1 für Service Bus 1.0: KB2799752
  • Cumulative Update 1 für Workflow Manager 1.0: KB2799754

Wichtig zu beachten ist, dass beide Updates auf den Workflow Manager Servern installiert werden müssen. Das zweite Update muss jedoch auch auf allen SharePoint Servern installiert werden, da auch der Workflow Manager Client davon betroffen ist.

Nach dem Update muss zudem der im Workflow Services Application Proxy eine Deployment Group angelegt werden, da dies eine der neuen Funktionen im CU WM und PU SharePoint ist:

$WmsSap = Get-SPWorkflowServiceApplicationProxy

$WmsSap.RegisterWorkflowLifecycleManagementEnvironment()

SharePoint 2013: März Public Update verfügbar

Diese Woche wurde ein Public Update für SharePoint 2013 veröffentlicht. Im Gegensatz zu Cumulative Updates stellen diese wichtige Bugfixes bereit und sind diesmal auch eine Voraussetzung für alle weiteren Service Packs und Cumulative Updates. Zudem enthält dieses PU auch die Bugfixes aus dem Februar CU.

Die Updates und zugehörige Release Notes finden sich unter folgenden Links:

Vorsicht ist jedoch geboten, wenn Sie eine Search Service Application in Betrieb haben. Hierzu hat das SharePoint Team eine Anleitung veröffentlicht, wie das Update hier zu installieren ist und was vorher und nachher getan werden sollte: http://blogs.technet.com/b/tothesharepoint/archive/2013/03/13/how-to-install-update-packages-on-a-sharepoint-farm-where-search-component-and-high-availability-search-topologies-are-enabled.aspx

Office 365 Lizenzen: Aufgepasst!

Wer sich für Office 365 interessiert und erste Erfahrungen damit sammeln möchte, hat zunächst einmal die Qual der Wahl: Welche Lizenz soll er wählen?

Wie in den Screenshots zu sehen, gibt es drei kostenlose Testaccounts und genau hier fängt das Problem an. Bestimmte Lizenztypen lassen sich später nicht mischen oder umstellen und das ist auf dieser Auswahl nicht mehr klar ersichtlich. Je nachdem, welche Lizenz Sie für Ihren Testaccount verwenden, kann der Account nachher nicht mit den tatsächlich benötigten Lizenzen ausgestattet werden, sondern es muss ein neuer Account erstellt werden:

  • Office 365 Small Business Premium: Hier sind später nur noch Small Business-Lizenzen möglich, also normal (links neben Premium) und Small Business Premium. Eine Mischung z.B. mit dem auf derselben Seite dargestellten Exchange Online ist nicht möglich!
  • Office 365 Midsize Business: Diese Lizenz ist neu und reiht sich in die Small Business-Problematik ein. Hier lassen sich nur Midsize Business Lizenzen hinzufügen
  • Office 365 Enterprise (Plan E3): Dieser Typ ist der flexibelste, da sich hier alle Enterprise-Lizenzen und Einzeldienstlizenzen (z.B. Exchange Online aus Bild 1) mischen lassen. In Summe kann es sein, dass dieser Plan etwas teurer ist, dafür kann man beliebig mischen und z.B. auch eine Active Directory Synchronisation und Single Sign On einrichten.

Grundsätzlich ist es natürlich kein Problem, einen neuen Account zu erstellen. Allerdings müssen hier zwei Dinge beachtet werden:

Vanity Domain: Sollten Sie dem Testaccount eine eigene Domäne hinzugefügt haben und damit Mail getestet haben, sollten Sie vor Eröffnung eines neuen Accounts (bzw. vor Ablauf der Testperiode) sicherstellen, dass Sie die Domain wieder entfernt haben. Tun Sie dies nicht innerhalb des Zeitraums, in dem Sie auf die Adminoberfläche des ersten Accounts noch Zugriff haben, können Sie die Domain nur noch mit Hilfe des Supports aus dem deaktivierten Account lösen und wieder verwenden.

SharePoint Domain: Beim Anlegen eines Accounts werden die beiden Domänen [meinName].onmicrosoft.com und [meinName].sharepoint.com registriert. Erstere dient zunächst zum Anmelden an dem Account und für E-Mail, kann aber durch eine eigene Domäne ersetzt werden. Die Zweite lässt sich aber hinterher nicht mehr ändern! Sie dient als Adresse für die öffentliche SharePoint Website und alle SharePoint TeamSites. Und letztere lassen sich nicht von dieser Domäne lösen. D.h. die Adresse [meinName].sharepoint.com wird immer für interne SharePoint-Sites verwendet!

Wenn Sie also Ihren Wunschnamen für die spätere Verwendung beim ersten Testaccount verwendet haben und doch andere Lizenzen benötigen, werden Sie diese Domäne erst mal nicht mehr registrieren können. Laut Support werden die Test-Domains nach 90 Tagen nach Ablauf des Testzeitraums wieder freigegeben, aber verkürzen können Sie diese Zeit nicht. Da heißt es also: Warten…

In der Lizenzübersicht stellt sich das übrigens etwas übersichtlicher und klarer dar:

Fehler beim Starten des User Profile Service Sync in SharePoint 2013

Heute habe ich mal wieder eine SharePoint 2010-Infrastruktur auf SharePoint 2013 umgestellt. Hierbei sollten natürlich auch alle Profilinformationen migriert werden. Dafür muss man die drei Datenbanken des User Profile Service (Profile Database, Social Database und Sync Database) auf die neue Farm kopieren und hiermit dann eine User Profile Service Application erstellen.

Das ganze Vorgehen beschreibt der Artikel Upgrade Service Applications to SharePoint 2013 sehr gut im Detail:

  1. Sichern des FIM Encryption Keys von der alten Farm (nicht im Artikel beschrieben!)
  2. Sichern der drei Datenbanken
  3. Wiederherstellen der Datenbanken auf dem neuen SQL Server
  4. Anpassen von Berechtigungen
  5. Erstellen der User Profile Service Application mit den bestehenden Datenbanken per PowerShell
  6. Starten des User Profile Synchronisation Service
  7. Importieren des Encryption Keys in SharePoint 2013

Seltsamerweise funktionierte der Schritt 6 in meinem Fall nicht. Der FIM Service versuchte mehrmals die Sync-Datenbank zu aktualisieren, scheiterte dabei aber mit folgendem Fehler im Event Log und brach danach ab:

The server encountered an unexpected error and stopped.

 

“BAIL: MMS(6828): storeimp.cpp(306): 0x80230453 (Setup has determined that the schema version of the database being restored is newer than the current setup binaries.)

ERR: MMS(6828): server.cpp(373): Failed to connect to the database UserSyncDB on [DatabaseServer]

BAIL: MMS(6828): server.cpp(374): 0x80230453 (Setup has determined that the schema version of the database being restored is newer than the current setup binaries.)

BAIL: MMS(6828): server.cpp(3860): 0x80230453 (Setup has determined that the schema version of the database being restored is newer than the current setup binaries.)

BAIL: MMS(6828): service.cpp(1539): 0x80230453 (Setup has determined that the schema version of the database being restored is newer than the current setup binaries.)

ERR: MMS(6828): service.cpp(988): Error creating com objects. Error code: -2145188781. This is retry number 0.

BAIL: MMS(6828): clrhost.cpp(224): 0x80131022

BAIL: MMS(6828): scriptmanagerimpl.cpp(7670): 0x80131022

BAIL: MMS(6828): server.cpp(251): 0x80131022

BAIL: MMS(6828): server.cpp(3860): 0x80131022

BAIL: MMS(6828): service.cpp(1539): 0x80131022

ERR: MMS(6828): service.cpp(988): Error creating com objects. Error code: -2146234334. This is retry number 1.

BAIL: MMS(6828): clrhost.cpp(224): 0x80131022

BAIL: MMS(6828): scriptmanagerimpl.cpp(7670): 0x80131022

BAIL: MMS(6828): server.cpp(251): 0x80131022

BAIL: MMS(6828): server.cpp(3860): 0x80131022

BAIL: MMS(6828): service.cpp(1539): 0x80131022

ERR: MMS(6828): service.cpp(988): Error creating com objects. Error code: -2146234334. This is retry number 2.

BAIL: MMS(6828): clrhost.cpp(224): 0x80131022

BAIL: MMS(6828): scriptmanagerimpl.cpp(7670): 0x80131022

BAIL: MMS(6828): server.cpp(251): 0x80131022

BAIL: MMS(6828): server.cpp(3860): 0x80131022

BAIL: MMS(6828): service.cpp(1539): 0x80131022

ERR: MMS(6828): service.cpp(988): Error creating com objects. Error code: -2146234334. This is retry number 3.

BAIL: MMS(6828): service.cpp(1002): 0x80131022

Forefront Identity Manager 4.0.2450.47″

 

Nach vielem erfolglosem Experimentieren und Neuerstellen der User Profile Service Application habe ich mir die Sync-Datenbank genauer angeschaut und mit anderen verglichen und schließlich den Profiler angeworfen. Eine der wenigen Abfragen des FIM an diese Datenbank ging an die Tabelle “mms_server_configuration” und das dortige Feld “fixed_schema_version_number”. Im Backup von der SharePoint 2010 Farm war in diesem Feld die Zahl “321” eingetragen, in anderen SharePoint 2010- und auch SharePoint 2013-Farmen stand hier jedoch nur 314.

Lösung des Problems: Einfach den Eintrag auf 314 geändert, Dienst wieder gestartet und siehe da: Er startet einwandfrei. Natürlich sollte man dies nur nach einem Backup machen und sonstige Änderungen tunlichst unterlassen!

Wie in die 2010-Datenbank der Wert 321 rein kam, ist mir bislang ein Rätsel.