Moin,
wir haben vor kurzem von IBM Notes auf Microsoft Exchange 2019 migriert, ich arbeite mich gerade ein in die große Welt "Exchange 2019".
Kurz zur Infrastruktur: Wir haben zwei Exchange-Server onprem 2019 mit einem IPless DAG. Davor haben wir als Loadbalancer ein Netscaler.
Mir ist aufgefallen das wir in unseren IISLogs sehr viele 401 Fehlermeldung haben mit dem "Code" "2148074254". Dieser Code schließt wohl auf Autodiscover Fehler hinaus?
Diese 401 Meldungen mit dem Code haben wir ca 80.000x innerhalb von einer Stunde bei ca. 1000 Mitarbeiter, das kann ja nicht richtig sein..
Fehlermeldung = "2022-06-29 06:59:59 EX-IP POST /mapi/emsmdb/ MailboxId=ID@domäne&CorrelationID=<empty>;&cafeReqId=ff9cd463-2915-49a2-a0ab-33fa7e0a4172; 443 - NetscalerIP Microsoft+Office/16.0+(Windows+NT+6.3;+Microsoft+Outlook+16.0.5254;+Pro) - 401 1 2148074254 2 IP Adresse Terminalserver"
Autodiscover an sich funktioniert auch ohne Probleme bei uns.
Ich habe zu diesem Fehler ein wenig gegoogelt und herausgefunden das man mal "Authentication loopback check" deaktivieren soll.
Das habe ich entsprechend auf den Exchange-Server in der regedit unter "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa" gemacht und ein reboot durchgeführt, leider ohne Erfolg.
Habt ihr eine Idee wie wir diesen Fehler beheben können?
LG
Habt ihr bei dem virt. Service für die Exchange Umgebung auf dem Netscaler ein SSL Offload oder verteilt ihr nur die Anfragen auf die Dag Member?
Gegenprobe wäre, wenn es die Performance erlaubt, den DNS Alias für die Clientzugriffe mal statisch auf einen Host zu lenken oder DNS Round Robin für einen Tag zu nutzen, so dass der Netscaler raus ist. Wenn es dann mit den Einträgen wesentlich weniger ist, wäre zumindest erstmal der Punkt klar, wo gesucht werden muss.
Gruß,
Ralf
Hi,
die 401er Fehler sagen ja erst einmal nur "Unauthorized" aus. Dies tritt auf, wenn der Client noch nicht authentifiziert ist. Der nächste Request müsste dann sauber durchgehen, da sich dann der Client authentifiziert. Dies könnte auch auf fehlende Persistenz der Session hindeuten. Kann es sein, dass der Netscaler dort RoundRobin macht und nicht eine Session immer zum gleichen Server leitet?
Beste Grüße,
Frank
Moin ihr beiden,
Vielen Dank für eure Antworten.
@Monthy
Leider aktuell so einfach nicht bei uns möglich. Wir machen aber ein SSL Proxy direkt auf die Exchange-Server.
Persistenz haben wir aufjedenfall aktiv, die Session wird auch entsprechend zum gleichen Server geleitet.
Ich habe es leider noch nicht hinbekommen per Powershell herauszufinden welche Timeouts auf unseren Exchange-Server für "SMTP / OWA / ACTIVESYNC / OAB / EWS / AUTODISCOVER / POWERSHELL / MAPI / ECP " konfiguriert sind.
Wie kriege ich das am besten raus ? Habt ihr da ein Tipp für mich?
LG Tim
zu den Default Timeouts kann ich leider nichts sagen, da ich diese noch nicht benötigt habe. Der LB überwacht ja den Dienststatus und prüft, ob die relevanten virt. Services verfügbar sind, indem er regelmässig die konfigurierten VS URL's aufruft und so den Dienststatus prüfen kann. Wenn kein 200 OK zurückkommt, dann wird der relevante Service auf dem Knoten auf Error gesetzt und Anfragen werden gegen einen anderen Realserver geleitet.
Zum Ursprungsproblem. Hab ihr bei Euch Kerberos Konstrained Delegation (KDC) eingerichtet?
Weiterhin habt ihr in den ->Intranet Sites<- die relevanten URLs zum LB + zu den Realservern als trusted hinterlegt? (oder ein Wildcard Eintrag für die AD/DNS Domäne ansich.)
Gruß,
Ralf
@Monthy
KDC= Haben wir aktuell nicht eingerichtet.
Ja, die URLs haben wir entsprechend zum LB und Realserver als trusted hinterlegt.
Was uns aufgefallen ist das wir 4 verschiedene IPs beim Backend beim Worker Process sehen. Ist das so i.O ?
Eine IPV6 Adresse( Wir haben eigentlich IPV6 deaktiviert auf unseren EX-Server), eine IPV4 vom DAGNetz des EX-Server,
eine IPV4 vom ClientNetz und eine öffentliche IPV4 Adresse(169.254.2.172)... Finde ich persönlich irgendwie merkwürdig.
Aktuell ist bei uns eingestellt IPV6 vor IPV4, also default. Was sagt ihr dazu kann das u.a auch daran liegen, also an der Einstellung IPV6vorIPV4?
Was für mich auch interessant wäre: Was passiert wenn man den IIS listener auf nur eine IP stellt? Kann das Exchange?
Aktuell hört er nämlich auf alles, also auch loopbacks und ipv6 etc.
LG Tim
die 169.... klingt wie Replication DagNetwork. Das kannst und solltest du anpassen auf einen Netzbereich bei euch.
Wir nehmen da ein separates VLAN und dort sind nur die EX Hosts drin. Bei der Gelegenheit kannst du dann noch konfigurieren, über welche Netze die DAG replizieren soll/darf. Standardmässig "sollte" das nicht über das MapiDag Network sein.
Aktuell ist bei uns eingestellt IPV6 vor IPV4, also default. Was sagt ihr dazu kann das u.a auch daran liegen, also an der Einstellung IPV6vorIPV4?
Was für mich auch interessant wäre: Was passiert wenn man den IIS listener auf nur eine IP stellt? Kann das Exchange?
Aktuell hört er nämlich auf alles, also auch loopbacks und ipv6 etc.
ich muss sagen, dass ich IPv6 nie deaktiviere und auch an IIS Einstellungen nichts ändere. Die Anfragen kommen alle über den Loadbalancer rein und werden passend auf die Realserver verteilt und von diesen beantwortet.
das Einzige, was du auf den Servern kontrollieren kannst ist die Prio der Networkprovider
und aus leidvoller Erfahrung die Deaktivierung aller NIC's auf dem Server, die nicht in Benutzung sind.
Gruß,
Ralf
@monthy
ah alles klar, werden wir entsprechend machen.
IPV6 mussten wir leider deaktivieren, weil warum auch immer, wir dadurch erhebliche Probleme beim aufsetzen der Exchange-Server hatten... Sobald wir IPV6 deaktiviert haben ging alles problemlos.
Danke für den Tipp mit den NetworkProvider, das habe ich entsprechend gemacht. Ebenfalls habe ich noch auf den Exchange-Server beim DAG-Netzwerkadapter, bei IPV4, die LMHosts Abfrage deaktiviert.
Leider aber noch keine Verbesserung...
LG Tim