SharePointCommunity
Die deutschsprachige Community für SharePoint, Microsoft 365, Teams, Yammer und mit Azure

Sponsored by

Willkommen im Forum Archiv.
Einträge sind hier nicht mehr möglich, aber der Bestand von 12 Jahren SharePoint-Wissen ist hier recherchierbar.




AD-Gruppenauflösung funktioniert auf neuen SP-Servern nicht

Geprüfte Antwort Dieser Beitrag hat 6 Antworten

Ohne Rang
4 Beiträge
Astortel erstellt 25 Juni 2020 14:26
SchlechtSchlechtIn OrdnungIn OrdnungDurchschnittDurchschnittGutGutSehr gutSehr gut

Hallo zusammen,

 

(erst mal ein bisschen Vorgeplänkel, da das Thema sich nicht so einfach erklären lässt)...

 

ich (viele Jahre Erfahrung mit Win-Servern und generell mit vielen verschiedenen MS-Applikationen), wurde damit beauftragt, unsere letzten Windows Server 2008R2-Server mit Sharepoint 2013 auf eine noch supportete Plattform zu bringen. Da SP2013 laut MS max. auf 2012R2 läuft, war die Wahl recht einfach.

Vorerfahrung mit Sharepoint habe ich nicht wirklich, nur sporadisch, wenn mal irgendwas gebrannt hat, hab ich versucht, das Problem zu lösen.

Im Testsystem lief der Umzug (2. Server zur Farm hinzufügen, nach und nach die verschiedensten Diensts und Komponenten umziehen, alten Server aus Farm schmeissen) relativ reibungslos.

Nun, beim Produktivsystem gibt es ein Problem, dass Gruppennamen auf den neuen 2012R2-Servern im Sharepoint nicht aufgelöst werden können (wir haben ein Ticketsystem im Sharepoint, welches Mails an Gruppen schickt).

 

Farm:

2x WinSRV 2008R2

2x WinSRV 2012R2

Sharepoint 2013 Enterprise SP1. Der SP-Patchstand ist leider ziemlich alt (nach einer CU-Installation liefen irgendwelche ANpassungen nicht mehr und seitdem hat sich niemand mehr rangetraut...)

Alle Webseiten stehen auf Claims

normale AD-queries funktionieren auf den neuen Servern (get-aduser, get-adgroup etc) ganz normal  

 

Endlich zum konkreten Problem: Für die Auflösung der AD-Gruppen wird quasi das gemacht (die ID 856 habe ich mir vorher rausgepickt)

 

$web = Get-SPWeb https://URL

$user = $web.SiteUsers.GetByID(856)

$account = $user.LoginName

$reachedMaxCount = 0

[Microsoft.SharePoint.Utilities.SPUtility]::GetPrincipalsInGroup($web, $account, 9999, [ref] $reachedMaxCount)

 

 

Auf den alten (2008R2) Servern kommt dabei wie erwartet folgendes Ergebnis bei raus (gekürzt und anonymisiert):

 

PrincipalType     : User

LoginName         : i:0#.w|blue-net\user1

IsSharePointGroup : False

PrincipalId       : -1

Email             : user1@domain

SIPAddress        :

Mobile            :

DisplayName       : user1

Department        :

JobTitle          :


PrincipalType     : User

LoginName         : i:0#.w|blue-net\user2

IsSharePointGroup : False

PrincipalId       : -1

Email             : user2@domain

SIPAddress        :

Mobile            :

DisplayName       : user2

Department        :

JobTitle          :


Wenn ich das Gleiche auf den neuen Server (2012R2) ausführe, erhalte ich einfach nichts zurück. Keinen Fehler o.Ä., im ULS-Log findet man auch nichts.

 

Hat jemand einen Ansatz, wie/wo ich weitersuchen könnte?

 

Gruß, Nico

Alle Antworten

Ohne Rang
19231 Beiträge
Andi Fandrich Als Antwort am 26 Juni 2020 08:53
SchlechtSchlechtIn OrdnungIn OrdnungDurchschnittDurchschnittGutGutSehr gutSehr gut

Wie wird denn das PS ausgeführt, also in welchem Kontext? Läuft das vielleicht unter einem lokalen Account, der ganz einfach keinen Zugriff aufs AD hat? Ansonsten würde ich sagen, das hat rein gar nichts mit SharePoint zu tun, sondern liegt an irgendwelchen Restriktionen beim Server 2012.

PS: noch ein Wort zu dem alten Patchlevel: ich würde auch empfehlen dort zu bleiben. Die CUs haben schon sehr viele Probleme verursacht und MS empfiehlt selbst, sie nur zu installieren, wenn man von einem der behobenen Probleme betroffen ist.

Viele Grüße
Andi		 af @ evocom de
Blog
Ohne Rang
4 Beiträge
Astortel Als Antwort am 26 Juni 2020 09:52
SchlechtSchlechtIn OrdnungIn OrdnungDurchschnittDurchschnittGutGutSehr gutSehr gut

Vielen Dank für die Antwort, Andi!

 

Der User mit dem ich getestet habe, ist ein AD-Account, welcher sowohl lokaler Admin auf den Servern ist und auch entsprechende Berechtigungen in der SP-Farm hat.

Aber ich habe zum Testen das gleiche jetzt nochmal mit dem Farm-Admin-Account ausgeführt > leider kein anderes Ergebnis.

 

Was mich wurmt: Im Testsystem habe ich quasi das gleiche gemacht. Allerdings ist dort nicht aufgefallen, ob es auch nicht funktioniert hat, als noch ein 2008R2 in der Farm war. Zumindest inzwischen (2008R2-Server wurde vor ein paar Wochen aus der Farm genommen) funktioniert es dort ohne Probleme.

Allerdings ist mir das Risiko zu hoch, die alten Server aus der Live-Umgebung zu nehmen, ohne vorher zu wissen, ob dieser Mischbetrieb evtl. das Problem verursacht :(

 

Gruß, Nico

Ohne Rang
19231 Beiträge
Andi Fandrich Als Antwort am 26 Juni 2020 12:12
SchlechtSchlechtIn OrdnungIn OrdnungDurchschnittDurchschnittGutGutSehr gutSehr gut

Wie schon gesagt, glaube ich nicht so richtig, daß SharePoint hier etwas damit zu tun hat, sondern an andere Faktoren. Welche Unterschiede gibt es denn noch? Steht vielleicht eines der Systeme in der DMZ mit einem readonly-DC und das andere nicht?

Viele Grüße
Andi		 af @ evocom de
Blog
Ohne Rang
4 Beiträge
Astortel Als Antwort am 30 Juni 2020 11:11
SchlechtSchlechtIn OrdnungIn OrdnungDurchschnittDurchschnittGutGutSehr gutSehr gut

So, kurzes Update, da ich etwas neues rausgefunden habe:

Sobald ich eine Webseite auf den neuen Server "umziehe", funktioniert dafür der PeoplePicker nicht mehr. Fehler "Sorry, we're having trouble reaching the server" erscheint nach 1-2 Sekunden.

Alle benötigten Domaincontroller können erreicht werden und die ersten Lösungvorschläge von z.B. https://www.sharepointdiary.com/2016/07/sharepoint-2013-people-picker-sorry-were-having-trouble-reaching-the-server.html habe ich bereits kontrolliert/getestet.

 

Ohne Rang
19231 Beiträge
Andi Fandrich Als Antwort am 30 Juni 2020 14:03
SchlechtSchlechtIn OrdnungIn OrdnungDurchschnittDurchschnittGutGutSehr gutSehr gut

Schau Dir mal im IIS den Account an, unter dem die Website läuft. Das muß auf jeden Fall ein Domänenaccount sein und kein lokales Konto, weil sonst die Rechte für den PeoplePicker fehlen. Dahinter steckt ja eine AD-Abfrage.

Viele Grüße
Andi		 af @ evocom de
Blog
Ohne Rang
4 Beiträge
Astortel Als Antwort am 3 Juli 2020 12:02
SchlechtSchlechtIn OrdnungIn OrdnungDurchschnittDurchschnittGutGutSehr gutSehr gut

Ich habe den Fehler inzwischen gefunden und gelöst.

Da wir einen DomainTrust zu einer anderen Domain haben, wurde irgendwann in der Vergangenheit u.a. "stsadm -o setapppassword -password ..." auf den alten Servern ausgeführt.

Da das Passwort leider nicht dokumentiert wurde und ich Angst hatte, dass irgendwas nach Neusetzen des PWs auf allen Servern nicht mehr funktioniert, habe ich mir die entsprechenden Regkeys (in HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\Secure) rausgesucht und auf die neuen Server übertragen.

Nach finalem iisreset lüppt es endlich :)

 

CC BY-NC-ND - Michael Greth
Powered by Evocom Productivity