Hi Leute,
ich habe hier eine Migrationsumgebung von 2013 DAG auf 2016 DAG, aktuell in Koexistenz.
Soweit klappt eigentlich alles, ist ne recht komplexe Umgebung, aber ich hab bereits >400 Mailboxen auf die neuen beiden Server verschoben (Clientconnectivity über Kemp LB ist bereits auf die neuen Server umgestellt).
Jetzt hab ich ein Phänomen, das ist mir neu und ich hatte gehofft, ihr habt ein paar Ansätze, die ich noch nicht gecheckt habe.
Normalerweise kann ein Admin in der ECP ja einen Benutzerwechsel vollziehen und da bspw. die Abwesenheit für einen User aktivieren. Wenn ich das in der ECP auf einem der neuen Server mache, für ein Postfach, das bereits migriert wurde, bekomme ich den netten 403 Fehler: Zugriff verweigert. Mache ich das Selbe für einen User, der sein Postfach noch auf einem der 2013er hat, geht alles wie gewohnt.
Die 2016er laufen noch auf CU22, 23 wird nächste Woche eingespielt.
Was hab ich schon alles gecheckt:
Default Role Assignment Policy: existiert und hat auch die 9 angecheckten Rechte, die meine anderen Exchange Server auch haben.
Die Rolle ist auch jedem Benutzer zugewiesen.
Computerkonto Mitglied in einer beschränkenden Gruppe: Nö, sieht für mich nicht so aus, der ist da, wo er sein soll. gpresult /scope computer /r ergibt auf alt und neu die gleichen Gruppen, da sehe ich keinen Unterschied.
Rechte auf ECP (Backend) sieht für mich identisch auf alt und neu aus.
Die Benutzer können alle in OWA arbeiten und dort auch ihre eigene Abwesenheit setzen.
Alle Benutzer können mit Outlook arbeiten und dort ihre eigene Abwesenheit setzen.
(Damit will ich sagen, ich habe kein Autodiscover Problem).
Alle VirtualDirs sind identisch mit der alten Umgebung (umgestellt wurde per DNS auf mail.firma.de) und laufen sowohl intern als auch extern auf mail.firma.de (das Zertifikat passt auch).
OutlookAnywhere ist identisch auf beiden Umgebungen konfiguriert.
Also: irgendwo ist ein Unterschied zwischen alt und neu - wo?
Ich nehm mittlerweile wirklich alle Hinweise an, die mich irgendwie weiterbringen könnten....
ganz doof nachgefragt... der Admin, den du zum Verwalten nimmst, ist aber auch bereits auf der neuen Zielumgebung?
Gruß,
Ralf
Nachtrag: das Verhalten ist identisch, wenn du über den VS des Kemp gehst und als Gegenprobe auf einen der Real Server der neuen Umgebung?
Hi Ralf,
danke für deinen Input.
Der User, den ich nutze ist dediziert für die Migration angelegt worden und Exchange Admin, sowie mit den notwendigen Rollen im AD ausgestattet, um bspw. die Schemaerweiterung zu machen. Das Konto liegt bereits auf den neuen Servern.
Das Verhalten in der EAC ist gleich, ob ich das mit "localhost" oder mit "mail.firma.de" mache (letzterer geht über die Kemp LB).
Vielleicht noch ergänzend: ich kann auch nicht auf das Konto meiner Testbenutzerin zugreifen, die ebenfalls auf den neuen Servern angelegt wurde. Die wurde nicht aus der alten Umgebung migriert. Wenn ich die auf einen der alten Server zurückschiebe, kann ich auch nicht auf das Konto zugreifen. Das geht nur für die User noch, die originär auf der alten Umgebung erzeugt wurden und dort liegen. Ich find das recht mysteriös.
hi,
ich steh grad auf dem Schlauch, wird aber an mir liegen :)
Normalerweise kann ein Admin in der ECP ja einen Benutzerwechsel vollziehen und da bspw. die Abwesenheit für einen User aktivieren. Wenn ich das in der ECP auf einem der neuen Server mache, für ein Postfach, das bereits migriert wurde, bekomme ich den netten 403 Fehler: Zugriff verweigert. Mache ich das Selbe für einen User, der sein Postfach noch auf einem der 2013er hat, geht alles wie gewohnt.
hast du einen Screenshot (anonymisiert) für mich, damit ich das nachvollziehen kann?
Gruß,
Ralf
Hi Ralf, meld dich auf einem Exchange in der ECP an, als wolltest du den Server administrieren.
Dann klick oben rechts auf den Pfeil neben deinem Benutzernamen (links neben dem Fragezeichen), dann geht ein Menü auf, dort kannst du "Anderer Benutzer" auswählen und dort einen beliebigen Postfachbenutzer. Dann geht ein Extrafenster mit dessen Benutzereinstellungen auf, wo du bspw. eine Abwesenheit schalten kannst, wenn der Benutzer das mal wieder vergessen hat.
Hier mal ein Testuser, den ich am alten DAG angelegt habe und der mit meinem Exchangeadmin am neuen DAG mit https://localhost.... geöffnet werden kann.
Und hier das Gleiche für meine Testuserin, die am neuen DAG angelegt wurde und dann auf den alten DAG verschoben wurde (es ist egal, ob die an alt oder neu liegt).
Noch eine Zusatzinfo, das hatte ich noch nicht erwähnt: das gleiche Problem haben Adminuser, die in der Firma bereits existiert haben, bevor ich dort die Migration begonnen habe. Die haben das in der Vergangenheit immer gemacht, wenn sie das jetzt für ein Postfach versuchen, das auf den neuen DAG verschoben wurde, bekommen sie auch den 403 Fehler.
Daher gehe ich nicht davon aus, dass es an meinem Admin hängt, wenn es irgendwo ein Problem gibt.
ach da willst du hin... jau.
Hmm, da muss ich leider (für dich) sagen, dass es in meiner Umgebung auch mit EX2019 ohne Probleme funktioniert.
Ganz doofe Idee noch. Schaust du mal, ob auf den betroffenen Userns ggf. die Vererbung unterbrochen ist?
Waren die vielleicht mal alle Mitglieder adm. Gruppen, solls ja geben :)
Gruß
ggf auch ein Problem mit Exchange Trusted Subsystem..
https://docs.microsoft.com/en-us/exchange/troubleshoot/client-connectivity/error-occur-ems-eac-owa
@monthy Nope.
Vererbung ist an.
Und das 2. auch nope: der Computer ist kein Mitglied in einer beschränkenden Gruppe. Das hatte ich bereits gecheckt. Dann müsste es auch gehen, wenn ich ein Konto zurück auf den alten DAG schiebe. Dummerweise geht das aber auch nicht.
Und ich hab kein generelles Problem mit der EAC, die geht ganz normal und wie immer. Auch OWA geht für alle User ganz normal, egal ob sie am alten oder am neuen DAG beheimatet sind.
Ok, jetzt wird es komplett verrückt. Ich hab grade mal den Anton Meise in eine MBXDB auf dem neuen DAG geschoben. Kann weiterhin auf die Benutzereinstellungen zugreifen O_o
Nochmal Testbenutzer in der selben OU erstellt, wo auch der Anton drin ist, aber auf einer MaiboxDB auf dem neuen DAG. OWA geht, Benutzerwechsel in der EAC nicht. 403.
Ich flipp hier noch komplett aus.
Ok, jetzt wird es komplett verrückt. Ich hab grade mal den Anton Meise in eine MBXDB auf dem neuen DAG geschoben. Kann weiterhin auf die Benutzereinstellungen zugreifen O_o
Nach 3h immer noch. Ist also nicht einer noch nicht stattgefunden habenden Replikation geschuldet.
Ich fasse mal grade zusammen:
User alter DAG nach neuer DAG mit Migration Batch migiert: geht nicht
User alter DAG nach neuer DAG mit PS (new-moverequest) migriert: geht, aber nicht für die ALTEN Benutzer, die es schon gab, sondern nur für einen einzigen Account, den ich heute angelegt habe
User Postfach am alten DAG erstellt, liegt noch am alten DAG: geht
User Postfach am neuen DAG erstellt: geht nicht
User Postfach am neuen DAG erstellt, per PS auf alten DAG migriert: geht nicht
Braucht irgendjemand eine Glaskugel? Ich mittlerweile schon. @Frank Zöchling: hast du noch Termine frei die nächsten Tage? :D
hattest du /preparead + /preparealldomains bei der Installation der Exchange 2016 Server gemacht?
Ansonsten bin ich überfragt, sieht sehr speziell aus.
Hast du dir mal einen neuen adm. Benutzer gebaut, den du in die Organization-Management Verwaltungsgruppe gepackt hast? Einfach um auszuschliessen, dass es nur an deinem Adminuser liegt.
Gruß,
Ralf
noch ne Idee... da du ja ne DAG hast, hast du ja auch mind. 2 Knoten.
hast du mal geschaut, ob das Problem "mitwandert"? Sprich, ob selbes Fehlerbild vorhanden ist, wenn die Datenbank des betroffenen Benutzers auf DAG Member 1 oder 2 gehostet wird?
Gruß,
Ralf
Hi Ralf,
es gibt nur ein AD, allerdings mit Standorten. Die neuen Server stehen an einem RZ Standort, dort haben sie auch einen DC (von insgesamt 4). Die Replikationstopologie passt, soweit ich das beurteilen kann.
Ich habe 5 Mailbox Datenbanken, davon liegen 1,3 und 5 auf Knoten 1 und 2 und 4 auf Knoten 2. Die Replikation läuft sauber, der DAG auch. Ausfallszenarien sind sämtlich getestet.
Es spielt aus meiner Sicht keine Rolle, auf welchem Knoten der User liegt. Alte, migrierte User gehen alle nicht, egal auf welcher Datenbank sie ihr Postfach haben. Mein gestern angelegter Testuser, den ich mit dem alten DAG in einer Datenbank am alten DAG angelegt habe, liegt jetzt in der MBXDB5 auf Knoten 1. Meine Testuserin, die ich auch gestern am neuen DAG angelegt habe, liegt in MBXDB1 auf Knoten 1. User 1 geht, User 2 nicht.
Ich bin kurz davor, ins Wasser zu gehen. Ich hab grade mal versucht den gestern angelegten User an Host1 zu öffnen: 403.
Der selbe User an Host2: geht.
Bei den anderen scheint es aber egal zu sein, ob ich das an Host1 oder 2 versuche.
Versuch jeweils mit https:/localhost....
Versuch mit https://mail.firma.de.... geht auf beiden nicht, wobei ich keine Ahnung ab, wo mich der LB da hinschickt, im dümmsten Fall bin ich 2 Mal am selben Knoten.
Meint ihr ich sollte mal testweise den Standort auflösen und das Netz einem anderen Standort zuordnen?
Könnte auch den DC testweise nochmal rausnehmen. Ich denke nur, dass ich die Knoten dann einmal durchbooten muss, die haben ja momentan den DC im RZ als originating DC...