10
Exchange 2007 - Externer Login nicht mehr möglich - (neuer DC, alter DC entfernt)
Hallo in die Gemeinde,
kurze Vorgeschichte, letzte Woche einen Windows 2012 R2 (erster 2012er) als DC am Hauptstandort installiert. Nachdem alles lief, am Wochenende den zu ersetzenden runtergestuft und ausgeschaltet im AD und DNS auch nicht mehr als DC bzw GC und DNS gelistet. Gestern ist mir dann aufgefallen, dass mein Outlook (2013) über Anywhere immer wieder eine Passwortabfrage bringt und diese auch nicht annimmt/speichert. Wenn ich mit VPN verbunden bin, dann kommt ab und an eine Passwortabfrage, jedoch kann ich Outlook nutzen, was ohne VPN nicht möglich ist.
Da nun die ersten Mac Nutzer kommen (Outlook 2011) besteht das Problem wohl auch über den EWS. Das was interessant ist, wenn ich den https://autodiscover.domain.tld/autodiscover/autodiscover.xml im Browser eingeben (funktioniert nur mit Eintrag in der host Datei) lässt er mich mit meinem Benutzer mich nicht anmelden. Jedoch wenn ich den Admin eingebe, funktioniert es. Wir hatte vor nicht allzu langer Zeit schon mal ein Problem nur mit Mac's, dies war jedoch auf einen Unterschiedlichen Patchstand zurückzuführen und das man die Server (DC und Mailserver) 2x neu Starten musste.
Mailserver (Exchange 2007 auf einem 2008 R2) wurde auch schon neu gestartet und ein /flushdns gemacht. Ich schau gleich noch die Logs an ggf. IIS Einstellungen?
Hat jemand einen Tipp? Ist der alte DC ggf. noch an einer Stelle drin wo ich ihn händisch abändern muss?
Danke schon mal und viele Grüße,
Ribiku
Nachtrag:
- wenn ich mich intern über https://namedesserver/autodiscover/autodiscover.xml über meinen Benutzer anmelde funktioniert es.
- OWA von extern funktioniert auch
kurze Vorgeschichte, letzte Woche einen Windows 2012 R2 (erster 2012er) als DC am Hauptstandort installiert. Nachdem alles lief, am Wochenende den zu ersetzenden runtergestuft und ausgeschaltet im AD und DNS auch nicht mehr als DC bzw GC und DNS gelistet. Gestern ist mir dann aufgefallen, dass mein Outlook (2013) über Anywhere immer wieder eine Passwortabfrage bringt und diese auch nicht annimmt/speichert. Wenn ich mit VPN verbunden bin, dann kommt ab und an eine Passwortabfrage, jedoch kann ich Outlook nutzen, was ohne VPN nicht möglich ist.
Da nun die ersten Mac Nutzer kommen (Outlook 2011) besteht das Problem wohl auch über den EWS. Das was interessant ist, wenn ich den https://autodiscover.domain.tld/autodiscover/autodiscover.xml im Browser eingeben (funktioniert nur mit Eintrag in der host Datei) lässt er mich mit meinem Benutzer mich nicht anmelden. Jedoch wenn ich den Admin eingebe, funktioniert es. Wir hatte vor nicht allzu langer Zeit schon mal ein Problem nur mit Mac's, dies war jedoch auf einen Unterschiedlichen Patchstand zurückzuführen und das man die Server (DC und Mailserver) 2x neu Starten musste.
Mailserver (Exchange 2007 auf einem 2008 R2) wurde auch schon neu gestartet und ein /flushdns gemacht. Ich schau gleich noch die Logs an ggf. IIS Einstellungen?
Hat jemand einen Tipp? Ist der alte DC ggf. noch an einer Stelle drin wo ich ihn händisch abändern muss?
Danke schon mal und viele Grüße,
Ribiku
Nachtrag:
- wenn ich mich intern über https://namedesserver/autodiscover/autodiscover.xml über meinen Benutzer anmelde funktioniert es.
- OWA von extern funktioniert auch
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 284053
Url: https://administrator.de/contentid/284053
Printed on: April 27, 2024 at 03:04 o'clock
10 Comments
Latest comment
Hallo,
also autodiscover muss auch ohne Hosteintrag in der etc/hosts laufen.
Wenn nicht ist Autodiscover falsch konfiguriert und es gibt Probleme.
War der exchange vor der Installation des 2012R2 auf aktuelles Patchlevel gebracht worden?
Es ist denkbar das der Exchange evrtl in seinen Netzeinstellungen den falschen DC als DNS Server drin hat.
Es kann sein das noch Einträge im DNS auf den alten DC verweisen, das muss sauber gemacht werden.
Normalerweise sollte die Eingabe des FQDN vom Exchange zu FQDN/owa führen.
Ich tippe mal auf unter anderem unsauberes DNS.
Gruß
Chonta
also autodiscover muss auch ohne Hosteintrag in der etc/hosts laufen.
Wenn nicht ist Autodiscover falsch konfiguriert und es gibt Probleme.
War der exchange vor der Installation des 2012R2 auf aktuelles Patchlevel gebracht worden?
Es ist denkbar das der Exchange evrtl in seinen Netzeinstellungen den falschen DC als DNS Server drin hat.
Es kann sein das noch Einträge im DNS auf den alten DC verweisen, das muss sauber gemacht werden.
Normalerweise sollte die Eingabe des FQDN vom Exchange zu FQDN/owa führen.
Ich tippe mal auf unter anderem unsauberes DNS.
Gruß
Chonta
Hallo Chonta,
der Autodiscover läuft nur bei 2 Leuten, es ist auch kein Zertifikat, bzw. das Zertifikat des "OWA" mit einem anderen FQDN am laufen. Probleme gab es mit der Lösung noch nie, außer das er beim Start eine Zertifikatswarnung bringt.
Die DNS Einstellungen sind überall angepasst worden und auch eine /flushdns.
Das Läuft bei uns über ein Portal.
DNS würde ich ausschließen, zumindest was die Einstellungen angeht. habe nichts gefunden, was "komisch" ist.
Als Fehler im IIS Log kommt ein 401 bei den Nutzern, in dem Event Log vom Exchange kommt ein Benutzer unbekannt.
Danke Dir und viele Grüße
Ribiku
Nachtrag:
- Interessant war auch, dass sich einige User über ein Mac Outlook anmelden konnten und andere nicht. Ich schätze, dass der neue 2012 R2 etwas einbringt was dann den Fehler bringt.
der Autodiscover läuft nur bei 2 Leuten, es ist auch kein Zertifikat, bzw. das Zertifikat des "OWA" mit einem anderen FQDN am laufen. Probleme gab es mit der Lösung noch nie, außer das er beim Start eine Zertifikatswarnung bringt.
Die DNS Einstellungen sind überall angepasst worden und auch eine /flushdns.
Das Läuft bei uns über ein Portal.
DNS würde ich ausschließen, zumindest was die Einstellungen angeht. habe nichts gefunden, was "komisch" ist.
Als Fehler im IIS Log kommt ein 401 bei den Nutzern, in dem Event Log vom Exchange kommt ein Benutzer unbekannt.
Danke Dir und viele Grüße
Ribiku
Nachtrag:
- Interessant war auch, dass sich einige User über ein Mac Outlook anmelden konnten und andere nicht. Ich schätze, dass der neue 2012 R2 etwas einbringt was dann den Fehler bringt.
Die Aktuelle Lösung sieht so aus:
alten DC wieder die Domänen Dienste installiert, neuen DC aus und alles läuft erstmal wieder.
Wie Chonta geschrieben hat, werde ich jetzt mal noch schauen, bezüglich Patchstand, normales Windows Update lief immer durch. Schau jetzt noch den Exchange direkt an.
Viele Grüße,
Ribiku
alten DC wieder die Domänen Dienste installiert, neuen DC aus und alles läuft erstmal wieder.
Wie Chonta geschrieben hat, werde ich jetzt mal noch schauen, bezüglich Patchstand, normales Windows Update lief immer durch. Schau jetzt noch den Exchange direkt an.
Viele Grüße,
Ribiku
Die Letzten 2 uR16 und uR17 sind noch nicht installiert. Werde ich am WE mal nachholen. Scheint laut RN aber nicht unbedingt das Problem zu lösen.
Grüße,
Ribiku
Grüße,
Ribiku
Hallo,
Das macht nicht viel sinn....
Wenn mit dem alten alles läuft, dann hat etwas im DNS oder mit der Autentifizierung nicht hin. Auf dem 2012R2 hätte man mal ntlm2 erlauben können um zu sehen ob es dann geht.
401 kann durchaus bedeuten, das eine Autentifizierungsmethode verwendet wird die nicht vom DC akzeptiert wird.
Und alles geht über autodiscover, vor allem outlook.
Wie die Clients die Verbindung aufbauen bei denen es geht und bei denen es nicht geht hilft evtl der Hai.
Gruß
Chonta
alten DC wieder die Domänen Dienste installiert, neuen DC aus und alles läuft erstmal wieder.
Der alte war doch schon aus der Domäne raus? Und jetzt extra wieder riengenommen, repizieren lassen und dan den neune DC aus gemacht?Das macht nicht viel sinn....
Wenn mit dem alten alles läuft, dann hat etwas im DNS oder mit der Autentifizierung nicht hin. Auf dem 2012R2 hätte man mal ntlm2 erlauben können um zu sehen ob es dann geht.
401 kann durchaus bedeuten, das eine Autentifizierungsmethode verwendet wird die nicht vom DC akzeptiert wird.
Und alles geht über autodiscover, vor allem outlook.
Wie die Clients die Verbindung aufbauen bei denen es geht und bei denen es nicht geht hilft evtl der Hai.
Gruß
Chonta
Hallo nochmal,
der alte war nicht mehr DC also demote und dann alle Rollen (AD und DNS) deinstalliert. Er war dann nur noch ein "normaler" Server in der Domäne. Im DNS war er als GC weg aus den Standorten hab ich ihn auch entfernt. Dann kamen die Fehler die über Wochenende leider nicht aufgefallen sind. Ich hatte dann noch mehrere Versuche unternommen Updates am Client Einstellung geschaut. Leider hat nichts geholfen. Dann habe ich die Rollen auf dem alten DC wieder installiert (AD (GC) DNS) und den anderen abgestellt. Dann funktionierten wieder alle Clients. Ich schätz mal, dass die Clients die liefen, sich an einem der anderen DC mit GC angemeldet hatten? Wobei mir nicht bekannt ist, wie Exchange das handhabt.
Das was Du da erwähnst, hört sich jedoch eher nach der Lösung an. Ich schau mal was ich zu Authentifizierungsmethode bzw. ntlm2 erlauben so finde. Hast Du ggf noch weitere Tipps in diese Richtung. Bzw. einen Vorschlag wie ich das dann testen kann. Ich hatte leider keine Möglichkeit gefunden, dem Exchange einen Server für die Authentifizierung mitzuteilen.
Danke Dir schon mal, denke in diese Richtung wird das Problem gehen.
Grüße,
Ribiku
PS: der Sinn war einfach der, dass viele Leute in USA um 16:00 Uhr Ihren PC anmachen und wir dann keine schnelle Lösung gehabt haben. Daher war die Lösung die beiden Rollen wieder zu installieren die schnellere. Vor allem, da die Geschäftsführung Mac's hat.
der alte war nicht mehr DC also demote und dann alle Rollen (AD und DNS) deinstalliert. Er war dann nur noch ein "normaler" Server in der Domäne. Im DNS war er als GC weg aus den Standorten hab ich ihn auch entfernt. Dann kamen die Fehler die über Wochenende leider nicht aufgefallen sind. Ich hatte dann noch mehrere Versuche unternommen Updates am Client Einstellung geschaut. Leider hat nichts geholfen. Dann habe ich die Rollen auf dem alten DC wieder installiert (AD (GC) DNS) und den anderen abgestellt. Dann funktionierten wieder alle Clients. Ich schätz mal, dass die Clients die liefen, sich an einem der anderen DC mit GC angemeldet hatten? Wobei mir nicht bekannt ist, wie Exchange das handhabt.
Das was Du da erwähnst, hört sich jedoch eher nach der Lösung an. Ich schau mal was ich zu Authentifizierungsmethode bzw. ntlm2 erlauben so finde. Hast Du ggf noch weitere Tipps in diese Richtung. Bzw. einen Vorschlag wie ich das dann testen kann. Ich hatte leider keine Möglichkeit gefunden, dem Exchange einen Server für die Authentifizierung mitzuteilen.
Danke Dir schon mal, denke in diese Richtung wird das Problem gehen.
Grüße,
Ribiku
PS: der Sinn war einfach der, dass viele Leute in USA um 16:00 Uhr Ihren PC anmachen und wir dann keine schnelle Lösung gehabt haben. Daher war die Lösung die beiden Rollen wieder zu installieren die schnellere. Vor allem, da die Geschäftsführung Mac's hat.
Hallo,
Vorraussetzung alle wagen GC.
Evtl. unterstützen die Clients bei denen es geht auch einfach nur die geforderten Sicherheitsstandards (alle gleicher Patchstand?)
Und wie gesagt wenn Du bei irgendweclhen Rechnern mit der /etc/hosts arbeiten musst, dann ist was im DNS nicht sauber.
Gruß
Chonta
keine Möglichkeit gefunden, dem Exchange einen Server für die Authentifizierung mitzuteilen.
Das macht man auch nicht, wenn das DNS richtig funktioniert machen die das von selber.dass die Clients die liefen, sich an einem der anderen DC mit GC angemeldet hatten?
Wieviele DC hast Du denn? Sinn ist es das alle DC bis auf einen ausfallen und abfackeln können und trotzdem alles weiter läuft.Vorraussetzung alle wagen GC.
Evtl. unterstützen die Clients bei denen es geht auch einfach nur die geforderten Sicherheitsstandards (alle gleicher Patchstand?)
ntlm2 erlauben so finde.
Per GPO für den DC freischalten das der das animmt und auch sendet.Und wie gesagt wenn Du bei irgendweclhen Rechnern mit der /etc/hosts arbeiten musst, dann ist was im DNS nicht sauber.
Gruß
Chonta
Zitat von @Chonta:
Hallo,
Ist mir bekannt, ich hoffte einfach auf eine Möglichkeit diesen für einen gewissen Zeitraum fest mitzugeben. Um ungestört an einer Lösung arbeiten zu können.Hallo,
keine Möglichkeit gefunden, dem Exchange einen Server für die Authentifizierung mitzuteilen.
Das macht man auch nicht, wenn das DNS richtig funktioniert machen die das von selber.dass die Clients die liefen, sich an einem der anderen DC mit GC angemeldet hatten?
Wieviele DC hast Du denn? Sinn ist es das alle DC bis auf einen ausfallen und abfackeln können und trotzdem alles weiter läuft.Vorraussetzung alle wagen GC.
Evtl. unterstützen die Clients bei denen es geht auch einfach nur die geforderten Sicherheitsstandards (alle gleicher Patchstand?)
ntlm2 erlauben so finde.
Per GPO für den DC freischalten das der das animmt und auch sendet.Und wie gesagt wenn Du bei irgendweclhen Rechnern mit der /etc/hosts arbeiten musst, dann ist was im DNS nicht sauber.
Das hat nichts mit zu tun ob das sauber ist, dass nutzen wir nicht "offiziell", einzig ich und jemand anderes aus der IT nutzen das. Wie schon geschrieben gibt es keinen externen Zeiger von autodiscover.server.tld auf unsere IP noch gibt es ein Zertifikat.Die einzigen die intern und extern das Problem hatten, waren Mac's mit Office 2011. Dieser verbindet sich über den Exchange über den IIS über den Ordner EWS. Hat also nichts mit funktionierendem autodiscover samt anywhere, activesync, owa etc. zu tun. Nochmal es funktionierten alle Clients (Android, iPhone, Outlook auf Windows von 2007-2013 (Nachtrag: intern) und manche Mac Clients mit Outlook 2011) intern wie extern. Nur eben gewisse Mac's mit Outlook 2011 alle selbes OS und Outlook Patchstand. Wie ich oben auch schon geschrieben hatte, konnte ich selbst ja nicht auf den Ordner mit dem Autodiscover Zugriff nehmen. Zugriff nach 3 mal anmelden war verwehrt. Jetzt kann ich mich wieder normal anmelden. Das hat daher nichts mit dem DNS zu tun, sonst hätten alle Clients das Problem bzw. nur intern. Ich habe die Vermutung, dass der neue Server die Nutzer über den IIS nicht akzeptiert. Aber eben nur die Ordner Autodiscover bzw. EWS. auf den OWA bin ich zumindest ohne Probleme gekommen.
Ggf. steh ich auch auf dem Schlauch was Du speziell mit DNS Fehler/Problem meinst. Sehe aber aktuell dort auch keinen Ansatz den ich verfolgen könnte, da alles sauber aussieht und auch nur ein BS davon betroffen ist.
Danke Dir nochmals und viele Grüße,
Ribiku
Hallo,
wenn einige Clients normal gehen und andere nicht, dann muss es ja was am Client sein, "verstekcte Einstellungen" andere Konfiguration etc.
Und dann muss man die Clients untersuchen. Z.B. Wireshark mitschneiden beim Verbindungsaufbau.
Was für Ordner auf dem IIS gibt ist dem DC egal.
Wenn Du eine Lösung findest bin ich auf jedenfall an Ursache und der Lösung interessiert
Gruß
Chonta
wenn einige Clients normal gehen und andere nicht, dann muss es ja was am Client sein, "verstekcte Einstellungen" andere Konfiguration etc.
Und dann muss man die Clients untersuchen. Z.B. Wireshark mitschneiden beim Verbindungsaufbau.
Was für Ordner auf dem IIS gibt ist dem DC egal.
Wenn Du eine Lösung findest bin ich auf jedenfall an Ursache und der Lösung interessiert
Gruß
Chonta
Hallo nochmal,
ich werde berichten ;) Problem ist einfach auch das an den Systemen hier schon zu viele dran waren und keiner weiss was der andere mal gemacht hat. Denke das hier das Problem unter anderem her kommt.
Meine Idee dahinter ist aktuell (auf die Du ja auch schon hingewiesen hast) das es an der Authentifizierung scheitert. Jetzt ist es so, dass im Netz recht viel Probleme beschrieben sind die das Symptom zeigen wie ich es auch habe. Einmal war es ein Update einmal war es dies einmal das...
Aktuell könnte ich es mir so erklären, dass ein Teil funktioniert, weil der Exchange zwei DC mit GC an seinem Standort hat. Im Fall wo der Fehler kommt ist es ein DC der auch die FSMO Rollen inne hat und ein der neue 2012 R2. Ggf. melden sich manche am alten an und alles passt weil der ein Einstellung hat die der neue noch nicht hat und bei denen wo es nicht geht, meldet er sich bei dem neuen an. Das wäre aktuell meine Erklärung. Ich werde jedoch leider erst am WE wieder testen können.
Viele Grüße,
Ribiku
ich werde berichten ;) Problem ist einfach auch das an den Systemen hier schon zu viele dran waren und keiner weiss was der andere mal gemacht hat. Denke das hier das Problem unter anderem her kommt.
Meine Idee dahinter ist aktuell (auf die Du ja auch schon hingewiesen hast) das es an der Authentifizierung scheitert. Jetzt ist es so, dass im Netz recht viel Probleme beschrieben sind die das Symptom zeigen wie ich es auch habe. Einmal war es ein Update einmal war es dies einmal das...
Aktuell könnte ich es mir so erklären, dass ein Teil funktioniert, weil der Exchange zwei DC mit GC an seinem Standort hat. Im Fall wo der Fehler kommt ist es ein DC der auch die FSMO Rollen inne hat und ein der neue 2012 R2. Ggf. melden sich manche am alten an und alles passt weil der ein Einstellung hat die der neue noch nicht hat und bei denen wo es nicht geht, meldet er sich bei dem neuen an. Das wäre aktuell meine Erklärung. Ich werde jedoch leider erst am WE wieder testen können.
Viele Grüße,
Ribiku