SharePoint-Einstellungen bzgl Active Directory

C.Kaiser Als Antwort am 31 Jan. 2011 15:18

zu 1:
Das hier sollte dir weiterhelfen:
http://technet.microsoft.com/de-de/library/cc263460(office.12).aspx

zu 2:
Was heisst lange? Eventuell wirds durch die o.g. Einstellungen besser

Allgemein:
Sharepoint durchsucht immer alle Domains, mit denen die Domäne, in der der Sharepoint Server steht, einen Trust besitzt. Zusätzlich greift Sharepoint noch auf die User zurück, die unter "Alle Websitebenutzer" gespeichert sind. D.h. selbst wenn kein Trust zwischen der alten und der neuen Domäne besteht, der Sharepoint sich aber noch User aus der alten Domäne "gechached" hat, werden diese in den PeoplePickern angezeigt -> manuelles rauslöschen nötig.

Nachtschelm Als Antwort am 31 Jan. 2011 15:59

Hallo Christian,
vielen Dank für Deine schnelle Antwort.
Den STSADM-Befehl probiere ich aus, sobald ich von unserer IT die forest- und die domain-eigenschaft bekomme. Danach gibt#s selbstverständlich Feedback.

Lange bedeutet fast eine ganze Minute. Wenn ich beispielsweise einer Person eine Aufgabe zuordnen möchte und nicht den exakten Domönennamen (DOMAIN\username) eingebe, sondern z.B. nur den Nachnamen und dann den Button "Namen überprüfen" klicke, dauert es fast eine geschlagenen Minute, bis ein Ergebnis kommt. Und das pro Suchvorgang. Tippe ich beispielsweise 5 Nachnamen ein, muss ich 5x eine knappe Minute Wartezeit in Kauf nehmen. Das ist natürlich völlig inakzeptabel.

C.Kaiser Als Antwort am 31 Jan. 2011 16:15

ja wir hatten dieses Phänomen in einer ähnlichen Konstellation mal (DMZ mit Trust in interne Domäne). Dort hat es auch sehr lang gedauert. Wir konnten das Problem aber nicht zeitnah lösen und haben dann die Fehlersuche eingestellt und nur die Accounts aus der DMZ durchsuchen lassen. Dann gings wieder schnell.

Wie gesagt, stell mal en PeoplePicker um und schau obs dann besser ist. habt ihr schon den stsadm -migrateuser Befehl durchlaufen lassen?

Nachtschelm Als Antwort am 31 Jan. 2011 17:48

Hallo Christian,
so wie es scheint, hat der STSADM-Befehl keine Verbesserung bewirkt. Es werden immer noch Treffer aus beiden Domänen angezeigt, was wohl daran liegt, dass es eine Vetrauensstellung gibt. "Stsadm -migrateuser" haben wir nicht laufen lassen. Was tut das?

Nebenbei: Ich kriege ums Verrecken den "Benutzerprofil-Synchronisierungsdienst" nicht gestartet, was wohl daran liegt, dass der FIMService streikt. Könnte das was mit der langen Antwortzeit zu tun haben?

Nachtschelm Als Antwort am 8 Feb. 2011 09:09

Hallo Forum,
ich habe nur die Einschränkung auf eine Domäne hinbekommen. Hier die Befehlszeile, falls jmd auch danach sucht:

stsadm -o setproperty -pn peoplepicker-distributionlistdomains -pv FQDN

Dennoch habe ich das Problem, dass der People Picker extrem langsam ist, wenn man zB nur den Nachnamen und nicht den Loginnamen angibt.

Woran kann das liegen? Es sei nochmal gesagt, dass ich auch den Benutzerprofil-Synchronisierungsdienst nicht zum laufen bekomme, falls es damit was zu tun haben könnte.

C.Kaiser Als Antwort am 8 Feb. 2011 09:19

Zum Thema Benutzerprofildienst -> Event ID 6398?:
Wenn ja -> Gib mal dem Farm Account lokale Admin und "Logon as a Service"-Rechte und starte danach den Timer Dienst neu. Danach versuche den Profil Dienst nochmal zu starten.

Wenn nein: Was für Fehler bekommst du?

Was ist, wenn ihr den Trust testweise entfernt? Läuft die Namensauflösung in z.B. Dateifreigaben zügiger? Wie habt ihr denn überhaupt migriert? Mit SID-History, ohne SID-History?

MigrateUser Befehl: Setzt im Sharepoint alle Loginnamen aus der alten Domäne auf die neue Domäne inkl. MySites. Kann Recht lange dauern, weil er alle Webseiten durchläuft und die Accounts entsprechend ändert.

P.S.: Hier noch ein Link was man alles mit dem People Pciker anstellen kann:
http://blogs.msdn.com/b/joelo/archive/2007/01/18/multi-forest-cross-forest-people-picker-peoplepicker-searchadcustomquery.aspx

Außerdem hier die Frage: Besteht ein Two-Way-, One Way-Trust?

P.P.S.: http://www.wildwires.com/blog/10-10-27/Slow_People_Picker.aspx

Nachtschelm Als Antwort am 8 Feb. 2011 16:12

Hallo Christian,
danke für die schnelle Antwort. Zu Deinen Fragen (Fehlermeldung bzgl Profil-Sync kommt am Schluss):

Ich habe schon mit der IT bei uns im Haus gesprochen. Da anscheinend noch ein oder zwei wichtige Syteme am alten AD hängen, sei es derzeit nicht möglich, den Trust zu entfernen. Warum genau, weiß ich nicht.

Domänenumstellung: Der SharePoint -Server war zu dem Zeitpunkt noch nicht live und von daher auch nicht mit Usern und Content befüllt. Deswegen haben wir einfach die Dienstkonten des SharePoint, die aus der alten Domäne stammten, durch entsprechende aus der neuen Domäne ersetzt. User wurden keine umgezogen. Daher auch kein MigrateUser Befehl.

Die Content-Migration von MOSS 2007 auf SharePoint 2010 haben wir -zugegebernermaßen- quick and dirty durchgezogen.
SharePoint ist bei uns im Unternehmen noch eine junge Technologie, daher ist die Umgebung und der Inhalt recht überschaubar. Mit dem Umstieg von MOSS 2007 auf SharePoint 2010 sollte auch eine neue Struktur eingeführt werden. Da einige Strukturen und Listen aus der 2007er-Umgebung auch in der 2010er-Umgebung 1:1 übernommen werden müssen, haben wir eine Kopie der Content-Datenbank vom MOSS 2007 in eine eigene SiteCollection im SharePoint 2010 gehängt. Nach der automatischen Konvertierung und des visuellen Upgrades haben wir die entsprechenden Parts per Export/Import in die Ziel-SiteCollection übernommen.

Nun zum Benutzerprofildienst: Mittlerweile habe ich es geschafft, dass der Benutzerprofil-Synchronisierungsdienst gestartet ist. Ich musste dem Farm Account Berechtigung für die lokale Aktivierung der Komponente Forefront Identity Management Synchronisation Service. Allerdings habe ich nun das Problem, dass ich in der ZA zwar sagen, dass ich eine Synchronisation starten möchte, defacto passiert aber nichts. Stattdessen tauchen folgende Meldungen im Ereignislog auf:

Ich werde allerdings nicht schlau daraus. Kannst Du mir da helfen?

Tom Scheuermann Als Antwort am 8 Feb. 2011 20:15

Hi Nachtschelm,

Du erwähnst den Benutzerprofil-Synchronisierungsdienst, ich vermute also es geht um SharePoint 2010 ?

Hier gibt es bekannte Probleme die lösbar sind:

http://www.harbar.net/articles/sp2010ups.aspx

Musst Du u.U. mehrmals lesen ....

Mit dieser Anleitung bin ich bisher immer gut gefahren. Du solltest auf jeden Fall so verfahren und nicht das Farm-Konto als lokaler Admin eintragen sonst nervt Dich der Health-Analyzer und Deine Konfiguration entspricht nicht den Vorgaben des Herstellers. Ist allerdings - zugegeben - schon ein ziemlich heftiges Prozedere.

Wenn der Dienst zum Laufen gekommen ist kannst Du eine Synchronisierungsverbindung einrichten und dort explizit den gewünschten Domänencontroller angeben (und ggf. die gewünschten OU's auswählen).

Und wenn Du schon rangehst solltest Du das Eventlog des SP Servers auch mal auf DCOM-Fehlermeldungen prüfen, evtl. fehlt das Recht "Lokale Aktivierung" für Deinen Farmaccount für bestimmte Objekte (z.B. dem IIS Wamreg Service").....

Hope that helps -> viel Erfolg ...

Greets

Tom

Nachtschelm Als Antwort am 9 Feb. 2011 11:29

Hallo Tom,

vielen Dank für Deine Antwort. Die Anleitung scheint zwar lang aber durchaus wertvoll zu sein. Ich werde diese bei Gelegenheit durchexerzieren und entsprechend Feedback geben.

chnollu Als Antwort am 28 Jan. 2014 11:38

Hallo zusammen.

Ich  habe evtl ein ähnliches Problem. Wir haben eine SharePoint-Farm 2013 welche einer Domäne angeschlossen ist die sehr neu ist und in einer Übergangsphase noch einen Trust mit der "alten" Domäne hat. Im Moment kommt es immer wieder vor, dass User die auf Listen/Seiten oder was auch immer Berechtig sind trotzdem nicht auf die Seite kommen. Einen Tag später funktioniert es aber wieder... Leider konnten wir noch nicht einschränken, wann es funktioniert und wann nicht!. Kann dies auch mit dem Trust zusammenhängen? Gibts andere Ideen, ich bin zur Zeit etwas Ratlos....??

Andi Fandrich Als Antwort am 28 Jan. 2014 11:59

Durch den Trust sollten grundsätzlich Benutzer aus beiden Domänen Zugriff bekommen. Ich sehe zwei mögliche Probleme:

Zum einen könnten es simple DNS-Probleme sein und dadurch eine Domäne bzw. deren Domaincontroller nicht gefunden werden.

Das andere Problem tritt auf, wenn Benutzer nicht direkt, sondern über AD-Gruppen berechtigt werden (was der bessere Weg ist). Wenn Ihr jetzt dauernd an den Gruppenmitgliedschaften ändert, dann muß sich ein Benutzer an seinem Rechner neu anmelden (nicht nur an SharePoint!), damit diese Änderungen wirksam werden.

chnollu Als Antwort am 28 Jan. 2014 12:03

Das Problem taucht auch auf wenn die User direkt mit Namen berechtigt sind...

Wie kann ich denn herausfinden ob es am erreichen der Domaincontoller liegt? Und wie kann es sein das User A gestern Zugriff hatte und heute im selben Büro mit dem selben Rechner plötzlich keinen mehr?

Andi Fandrich Als Antwort am 28 Jan. 2014 12:06

Der SharePoint-Server braucht Zugriff auf die Domaincontroller, um das übergebene Usertoken zu validieren. Durch DNS-Probleme kann es sein, daß er den DC mal findet und mal nicht. Ich kenne soclhe Probleme vor allem in Zusammenhang mit IPv6, das sich seit ein paar Windows-Generationen nicht mehr wirklich abschalten läßt.