none
SP2010 Profildaten in ContentDB / UserProfileService - Woher kommen sie wirklich? RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen!

    Wir haben hier folgendes Szenario. Migration einer Sharepoint-Farm von 2007 nach 2010 per Database Attach. Außerdem Umstellung der User von NTLM-Authentifizierung auf Claims-based via ADFS. Sagen wir, wir haben einen AD-User CRAP\HeMueller und folgende Site Collections:

    https://mywebsite/ und https://mywebsite/sites/2ndSite

    CRAP\HeMueller war vor der Migration nur auf der 2ndSite explizit berechtigt und hat hier offenbar auch innerhalb der ContentDB in der Tabelle UserInfo einige Profilinformationen gespeichert. Außerdem hat er aber ein vollständiges Benutzerprofil im SSP. In der Root-Site-Collection war CRAP\HeMueller nur über eine (AD-)Gruppenmitgliedschaft berechtigt.

    Jetzt kommt die Migration. Per PowerShell Move-SPUser wird der User CRAP\HeMueller nun in das Claims-Format konvertiert, also das Konto heißt nunmehr: i:05.t|adfs provider|heinz.mueller@crap.com (Das mail-Attribut ist fortan unser Identifying claim).

    Jetzt kommt es: Ruft Heinz Müller nun über den ADFS Authentication Provider die Website https://mywebsite/sites/2ndSite auf, dann steht rechts oben sein normaler DisplayName (oder PreferredName?), wie vorher auch, in diesem Falle "Müller, Heinz". Klickt er dann auf "Meine Einstellungen" steht dort bei Konto auch korrekt "i:05.t|adfs provider|heinz.mueller@crap.com" und bei Name "Müller, Heinz" eingetragen, zudem einige weitere Informationen wie Telefonnummer, E-Mail-Adresse usw. Erstmal ok...

    Klickt der gleiche User nun auf eine andere SiteCollection in einer anderen Datenbank, sprich hier https://mywebsite/, steht rechts oben plötzlich "CRAP\HeMueller" und wenn er dann auf "Meine Einstellungen" geht, steht dort unter Konto korrekt "i:05.t|adfs provider|heinz.mueller@crap.com", aber unter Name eben "CRAP\HeMueller". Die weiteren Infos außer E-Mail fehlen...

    Soweit schon mal komisch, zumal wir ja einen UserProfileService eingerichtet haben, der eigentlich ja SiteCollection- und gar WebApp-übergreifend die Profilinformationen bereitstellen soll. Dort finde ich für den Eintrag "i:05.t|adfs provider|heinz.mueller@crap.com" auch ein vollständiges Profil.

    Wieso jetzt also das unterschiedliche Erscheinungsbild in den Site Collections? Wie kann ich das geradeziehen und wie komme ich heile aus der Nummer raus? Dabei ist natürlich zu bedenken, dass es sich hier nicht um einen User handelt, sondern um ein paar Tausend, die nach der Umstellung ein ähnliches Verhalten zu erwarten hätten. Vielen Dank für jede Hilfe!

    Freitag, 20. Januar 2012 11:34
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hi Michael,

    der SharePoint Profilsync arbeitet in 3 Schritten:

    AD -> User Profile Application (via FIM) -> Content DB (via Full/Quick Profile Sync Timer Job)

    Das Problem scheint beim Sync zwischen der UPA und der Content DB zu sein.

    stsadm -o sync -listolddatabases 1 sollte dir auch zeigen, ob, und fals nicht, welche Content DBs nicht mit dem UPA synchronisiert wurden. Falls die betroffene CDB angezeigt wird, mit deleteolddatabases 1 die Verbindung zurücksetzen.

    Was du auf einen Testsystem erstmal ausprobieren könntest wäre die vorhandene Verbindung zwischen dem UPA und Content DB egal vom o.g. Ergebniss neu aufzubauen. Das geht über stsadm -o sync deleteolddatabases 0 und dann den o.g. Timer Job ausführen. Wird ein wenig länger dauern, dalle Profil Daten wieder synchronisiert werden müssen.

    Mehr Infos (diese treffen auch auf SP2010 zu):

    http://support.microsoft.com/kb/2388988

    http://blogs.technet.com/b/nishants/archive/2010/08/23/troubleshooting-user-profile-sync-issues-in-office-sharepoint-server-2007.aspx

    Gruß,
    Andrei


    • Bearbeitet Andrei Talmaciu Dienstag, 31. Januar 2012 16:08 Full und nicht Quick Profile Sync
    Dienstag, 31. Januar 2012 14:33
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Andrei,

    den Zusammenhang zwischen User Profile Service und den Profildaten innerhalb der Content-Datenbanken habe ich mittlerweile eindringlichst verstanden, weil ich mich seit Tagen mit fast nichts anderem beschäftige. Zu dieser Thematik ist mittlerweile auch ein Case bei Microsoft am Laufen und man findet viele Sites im Netz, die sich genau mit diesem Phänomen beschäftigen.

    stsadm -o sync -listolddatabases 1 liefert zurück, dass die Datenbanken durchaus aktuell synchronisiert werden, daher bringt auch ein erneuter Sync über den entsprechenden Timer Job nichts. Das Thema war bei uns sogar noch etwas verzwickter. Wir mussten eine neue User Profile Service Application anlegen, da vorher die Datenbanken eben doch nicht gesynct wurden. Jetzt wie gesagt werden die Datenbanken angeblich wieder sychronisiert, tatsächlich aber nicht alle dort enthaltenen Userprofile. In manchen Datenbanken der Farm bzw. der gleichen WebApp schon, in anderen wiederum nicht.

    Hier sind zum Beispiel solche Dinge beschrieben: http://www.paulgrimley.com/2011/08/user-profile-information-not-correct-in.html

    Empfohlen wird dort z. B. eine frische Content-Datenbank anzulegen und die enthaltenen Site Collections in diese zu verschieben. Eine Möglichkeit, die ich noch nicht ausprobiert habe, aber sicher ein denkbares Szenario wäre. Viel schärfer bin ich aber auf die Beantwortung der Frage, wieso einzelne Profile einfach nicht aktualisiert werden.

     

     

    Ich kopiere mal einige Kommentare hier hinein, die auch genau das Verhalten in meiner Farm zu beobachten ist.

    I had this problem and it seemed nothing would fix it. I called Microsoft, mentioned all the deleteolddatabases, synctiming, ignoreisactive, etc etc etc that I ran. Here's our 2 second fix.

    Add the user explicitly into a different site in the site collection again or add them back into the site again. Verify their settings update (which in our case it did) and then remove the explicit add. Since we were using groups and not explicit users to control permissions, it appears the WSS profile wouldn't update. The manual explicit add forced a recheck it seems.

    That was it! Still doesn't explain the bug, but it got us there!

    (...) 

    Giving the user explicit permissions to a site worked for us as well.

    (...) 

    None of the suggestions seems to work in our environment including Matt's suggestion. (…)

    Nun, wie gesagt, das entspricht meinem Verhalten, aber ist natürlich letztlich keine Lösung. Hier bin ich wirklich gespannt, was der Microsoft Support Engineer mir präsentieren kann. Ich kann ja schlecht einige tausend User explizit berechtigen, dann einen Profilsync anstoßen und die explizite Berechtigung wieder entfernen.

    Vielleicht fällt dir oder einem anderen User noch etwas dazu ein.

    Grüße
    Michael


    Edit: Im Übrigen exisitiert dieses Verhalten absolut analog in unserer Sharepoint 2007-Farm (die wir im Begriff sind zu migrieren). Dort werden ebenfalls zwar die User Profile Service bzw. SSP-Profildaten aktualisiert, der Sync-Job zu den Content-Datenbanken funktioniert aber nicht wie er soll, gleiches Symptom wie hier in der 2010er-Umgebung.
    • Bearbeitet michael.olb Dienstag, 31. Januar 2012 14:54
    Dienstag, 31. Januar 2012 14:51
    |
  • Question
    Anmelden
    0
    Anmelden

    wir hatten mal ein ähnliches Problem: Ein Benutzer der nie direkt in SP Berechtigt wurde/Daten vereibert hatte(Publishing Umgebung), hat den Nachnamen geändert. UPA hat die Änderung aus AD mitbekommen, in der Content DB blieb weiterhin der alte.

    Microsoft standardverhalten ist, dass wenn ein Benutzer nicht direkt in SP berechtigt wird/Daten vereibertet, dieser als inaktiver Benutzer gekennzeichnet wird. Inaktive Bentuzer sind standarmäßig von Full/Quick Profile Sync ausgeschloßen...

    Zum Glück wurde ein stsadm Befehl entwickelt der auch den Sync von "inaktiven" Benutzer erlaubt:

    http://blogs.msdn.com/b/ronalg/archive/2010/02/22/stsadm-sync-ignoreisactive-flag.aspx

    Der Vorgang war:

    1. stsadm -o sync -ignoreisactive 1 ausführen
    2. stsadm -o sync -deleteolddatabases 0 um die Referenzen zurückzusetzen
    3. Timer Job laufen lassen.

    Nachdem wurden alle "inaktiven" Benutzerprofile synchronisiert und der Name aktualisiert.

    Falls es nicht funktionieren sollte, wäre ein Blick im ULS Log der nächste Schritt, nicht das der Profile Timer Job an etwas anderem scheitert.

    Hoffe das hilft.

    Gruß,
    Andrei


    Dienstag, 31. Januar 2012 15:39
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Andrei,

    danke für dein weiteres Engagement, aber auch das haben wir bei einigen Datenbanken schon erfolglos versucht. Der nächste Schritt ist jetzt tatsächlich die Analyse von Verbose-Level ULS-Logs, diese liegen gerade beim MS-Support. Ich bin da wirklich sehr gespannt. Meine Vermutung, unabhängig ob jetzt Sharepoint 2010 oder 2007, weil das Verhalten wie gesagt analog zu beobachten ist, ist die, dass durch das Verschieben von Site Collections in andere Content-Datenbanken, die Verknüpfung zum SSP bzw. zur Service Application "verloren gegangen" oder "Schaden genommen" hat. Auf diesen Trichter bin ich gekommen, als ich mir mal die Technet-Infos zu stsadm -o preparetomove durchgelesen habe. Gleiches könnte aus meiner Sicht passieren, wenn die Content-Datenbanken migriert werden, was erklärt, dass auch in der 2010er-Umgebung ein Problem vorliegt. Oder sehe ich das so falsch?

    Ich bin mir gerade nicht sicher, ob das mit dem Verschieben der Websitesammlung in eine andere Content-DB gerade die Websitesammlung betrifft, anhand der ich gerade exemplarisch das Problem im 2007er-Umfeld feststelle, möglich ist das aber. Wir haben diese Operationen immer mit dem Batch Site Manager aus dem Sharepoint Administration Toolkit von Microsoft gemacht. Da sollte man eigentlich davon ausgehen, dass diese Fehler dort nicht auftreten sollten.

    Letztlich könnte es unter Umständen vielleicht noch daran liegen, dass die 2007er Farm auf einem sehr alten CU-Stand ist. Vielleicht gibt es hier ja tatsächlich einige Bugfixes in neuen Cumulative Updates. Letztlich wird mir aber diese Fragen der Support beantworten können. Heute Nachmittag soll es neue Informationen geben. Ich halte euch auf dem Laufenden, aber vielleicht gibt es ja auch noch weitere Überlegungen hier im Forum, die mir nutzen könnten!?

    Grüße
    Michael

    Mittwoch, 1. Februar 2012 09:42
    |