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 :
LoginName : i:0#.w|blue-net\user2
Email : user2@domain
DisplayName : user2
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
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.
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 :(
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?
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.
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.