Exchange 2019 ECP - Seltsames Verhalten

[Christian-K 0]

Wir betreiben einen Exchange 2019 Cluster mit einer DAG und 2 Knoten 
Exchange 2019 CU13 mit letztem Patch.

Zu diesen 2 Knoten habe ich einen weiteren Exchange Server installiert, den noch nicht in die DAG aufgenommen und nur eine lokale Datenbank angelegt.

Alle Service Urls angepasst und auf jedem Server genau gleich ... Clients scheinen sich alle sauber zu connecten.

Nun das Problem, sobald ich den neuen Server 3 herunterfahre geht das ECP auf dem Server 1 und Server 2 nicht mehr, kein 
ServernameFQDN\ECP , kein Localhost\ECP, kein MailCommonName\ECP  ( also der Name der bei allen Servern als Externer Name steht) 

Wenn man sich das Log vom Server 1 ansieht dann kommt dort immer sofort nach dem Aufruf der eigenen ECP Seite eine Weiterleitung zum Server 3,
es scheinen also alle Server immer nur das ECP auf dem Server 3 nutzen zu wollen,
wenn der Online ist geht alles, stoppe ich dort den WWW Dienst endet jeder Aufruf in einem 503 Fehler.

 

Leider kann ich aus dem Log nicht mehr entnehmen und weiß nicht was dieses Verhalten triggern kann.
Hat einer von Euch dazu einen Tip für mich ? 

 

Ich habe mal das ECP Log annonymisiert damit man sieht was passiert, vielleicht kann jemand in die Logs so tief eintauchen und den Grund sehen warum jeder Aufruf an den htttps://Server1/ECP sofort erst einmal an den https://Server3\ECP geleitet wird.

 

HttpProxy_2024051320-1_V3anno.txt

bearbeitet 13. Mai von Christian-K
Rechtschreibfehler

[testperson 1.711]

Hi,

 

auf welche IP Adresse zeigt denn der Hostname der Service URLs? Es klingt so, als würde hier ein Loadbalancer fehlen.

 

Gruß

Jan

[Christian-K 0]

hmm ..  könnte etwas dran sein .. die beiden vorhandenen Exchange also 01 und 02 sind hinter einem Load Balancer der auch die "Common" Adresse bei dem System hält...
Also mail.kundenname.de  ( der Server 3 ist in diesem Load Balancing Konstrukt noch nicht integriert.

 

Es ist trotzdem unlogisch weil ja das Konstrukt gerade bei der Abwesenheit des neuen Servers laufen sollte, ich verstehe nicht an welcher Stelle das Exchange bei Aufruf der

URL auf dem Server 1 auf einmal sagt .. gehe bitte auf Server 3 / ECP .
laut dem Log wird ja jeder Zugriff auf die normale Server1/ECP sofort auf den Server3 umgeleitet ....und dann geht alles nur wenn der Online ist.

Ich nehme den Server 3 heute mal ins Kemp System mit auf .. mal sehen ob dann die Probleme verschwunden sind.

bearbeitet 14. Mai von Christian-K
Rechtschreibfehler

[Nobbyaushb 1.478]

Der neue Exchange hat den SCP gesetzt

Jeff hat mal was dazu gschrieben

Set-AutodiscoverSCP.ps1 script is now on the TechNet Gallery | The EXPTA {blog}

 

[Christian-K 0]

Hallo Norbert,

 

klingt logisch, in dem Artikel ist aber immer nur von SET Befehlen etwas zu sehen.
Kann ich irgendwie im AD / ADSIEDIT oder über einen GET Befehl den Fehler erst mal verifizieren und sehen das der SCP gerade auf dem falschen Wert 
server3.kundenname.de  steht und nicht wie eigentlich richtig auf  common.mail.kundenname.de  ?

 

[NorbertFe 2.065]

Get-clientaccessservices | fl *uri*

 

bearbeitet 14. Mai von NorbertFe

[cj_berlin 1.329]

Moin,

 

vor 9 Minuten schrieb NorbertFe:

Get-clientaccessservices | fl *uri*

 

Service, Einzahl  

Nur mal als Schuss ins Blaue:

• hat der Einzel-Server exakt den gleichen Build wie die DAG-Member?
• auf welchem Server wohnt das Postfach von dem Account, mit welchem Du die ECP-Webseite aufrufst?

[Christian-K 0]

schade .. wäre zu schön gewesen .. ich habe den Befehl auf allen 3 Servern abgesetzt ...

Der SCP ist auf allen Servern schon auf den "common.name.domäne" gesetzt ...  sollte also bei Ausfall des Servers 3 auf jeden Fall gehen .

es bleibt also weiterhin das Mysterium wieso sogar bei Aufruf des localhost\ecp  sofort eine Weiterleitung an den Server3/ecp erfolgt ..


Sieht man hier :   ( Server 3 war zu dem Zeitpunkt gerade down bzw.. IIS Service gestoppt zum simulieren..
Anfrage geht an ECP Server 1 und wird sofort abgebrochen weil Server 3 nicht verfügbar ist .

Es sieht von der Logik so aus als ob die ECP´s auf Server 1 und 2 nicht mehr funktionieren und nur wenn Server 3 Online ist ein ECP kommt.
Ich kann aber bei laufendem Server 3 auch problemlos server1/ecp  oder Server2/ECP aufrufen.
Die Frage ist hier .. bin ich zu dem Zeitpunkt auch auf Server 1 oder 2  ? 

 

2024-05-13T20:29:06.764Z,cece738a-8804-4502-9a35-f15589ec29d5,15,2,1258,34,,Ecp,server1.kundenname.de,/ecp/DDI/DDIService.svc/GetList,,FBA,true,DOMÄNE\Adminnutzer,,Sid~S-1-5-21-444444444-3276941519-1113038830-148023,Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML  like Gecko) Chrome/124.0.0.0 Safari/537.36,192.168.2.17,Server1,503,ConnectFailure,ConnectFailure,POST,Proxy,server3.kundenname.de,15.02.1258.000,IntraForest,WindowsIdentity,,,6,27,,,,1,12,0;,0,2;,2,1;1;,2,4,,0,2038,9,,,,,,,,1003,2,2028,0,,2037,,2038,2038,,?ActivityCorrelationID=4264ea6b-26a0-9628-fe99-1a1a0eb2c804&workflow=GetCount&ua=0&schema=Notification&retryIdx=2&msExchEcpCanary=6Wo7Yam-DESMFmjSgpTTTiBZ4hiIc9wITfZdoGThngL3-4mPg4e_FVEW2oZuKmSbBg2dC8QULYE.,,BeginRequest=2024-05-13T20:29:04.725Z;CorrelationID=<empty>;ProxyState-Run=None;AccountForestGuard_kundenname.de=1;ServerLocatorCall=DM:198efac6-301e-4b12-8498-9f5d7e7c0532~~kundenname.de;FEAuth=BEVersion-1942127850;RoutingEntry=DatabaseGuid:198efac6-301e-4b12-8498-9f5d7e7c0532%40kundenname.de%40kundenname.de Server:server3.kundenname.de+1942127850@638512275467788159;NewConnection=192.168.20.54&0;BeginGetRequestStream=2024-05-13T20:29:05.753Z;OnRequestStreamReady=2024-05-13T20:29:06.755Z;InvalidatingBackEndServerCache=198efac6-301e-4b12-8498-9f5d7e7c0532;ProxyState-Complete=ProxyRequestData;SharedCacheGuard=0;EndRequest=2024-05-13T20:29:06.764Z;I32:ATE.C[DC2.kundenname.de]=3;F:ATE.AL[DC2.kundenname.de]=0;I32:ADS.C[DC2]=2;F:ADS.AL[DC2]=1.2581;I32:ADR.C[DC2]=1;F:ADR.AL[DC2]=0.763,WebExceptionStatus=ConnectFailure;WebException=System.Net.WebException: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden. ---> System.Net.Sockets.SocketException: Es konnte keine Verbindung hergestellt werden  da der Zielcomputer die Verbindung verweigerte 192.168.20.54:444    bei System.Net.Sockets.Socket.InternalEndConnect(IAsyncResult asyncResult)    bei System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)    bei System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure  Socket s4  Socket s6  Socket& socket  IPAddress& address  ConnectSocketState state  IAsyncResult asyncResult  Exception& exception)    --- Ende der internen Ausnahmestapelüberwachung ---    bei System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult  TransportContext& context)    bei System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult)    bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<>c__DisplayClass199_0.<OnRequestStreamReady>b__0();SharedCache=MailboxServerCacheEntryRemovalFailure;SharedCache=AMCacheRemovalFailure;,,|RoutingDB:198efac6-301e-4b12-8498-9f5d7e7c0532,,,CafeV1

• hat der Einzel-Server exakt den gleichen Build wie die DAG-Member?
  
  ja das ist auf allen Servern EX19 CU13 mit letztem Security Patch ..
   
• auf welchem Server wohnt das Postfach von dem Account, mit welchem Du die ECP-Webseite aufrufst?
  
  das muss ich prüfen aber auf jeden Fall auf Server 1 oder 2 ...  ( Server 3 ist noch nicht in der DAG und hat nur Single DB ) 

[NorbertFe 2.065]

Wenn der eh Mitglied der DAG werden soll, warum konfigurierst du dann erst rum außerhalb der DAG? Hätte man doch von Anfang an gleich in die DAG reinnehmen können, dann gäbs doch gar kein Problem, oder überseh ich was?

[Christian-K 0]

Du hast natürlich Recht, ich wollte den Server einfach nur erst mal als normalen Member im Exchange Verbund haben auf dem der Mail Flow und der 
Client Access läuft bevor ich den in den DAG nehme und auch Mailboxen draufpacke.

Ich dachte die DAG Funktionalität ist nur für den Ausgleich und das Synchronisieren von Mailboxen und Mailbox Databases zuständig.

 

Jetzt kann ich den Server noch jederzeit herunterfahren und testen, wenn er dann in der DAG ist müsste man sauber mit Wartungsmodus usw. arbeiten.
Irgendwie fühle ich mich ja bestätigt. Ich habe ein nicht erklärbares Verhalten des gesamten Systems nach der Installation des 3. Servers und würde gerne erst mal dieses
Problem beheben und zu einem Punkt kommen an dem ich die ECP aufrufen kann, egal welcher Server gerade offline ist.

 

[NorbertFe 2.065]

vor 1 Minute schrieb Christian-K:

Ich dachte die DAG Funktionalität ist nur für den Ausgleich und das Synchronisieren von Mailbox Databases zuständig.

Naja da das alles multirole Server sind… erübrigt sich diese Denke. ;)

vor 2 Minuten schrieb Christian-K:

Jetzt kann ich den Server noch jederzeit herunterfahren und testen,

Sieht man ja, wie toll das geht. ;)

vor 2 Minuten schrieb Christian-K:

wenn er dann in der DAG ist müsste man sauber mit Wartungsmodus usw. arbeiten

Warum? Ich kann da auch einfach einen Server runterfahren. Nicht schön, aber auch kein wirkliches Problem. ;) und nur weil ein Server in der dag ist, muss er noch lange keine Datenbankkopien haben.