Benachrichtigungen
Alles löschen

Transportdienst muss andauernd neu gestartet werden

9 Beiträge
4 Benutzer
0 Likes
186 Ansichten
(@nothobranchius)
Active Member
Beigetreten: Vor 2 Monaten
Beiträge: 5
Themenstarter  

Hallo,

vielen Dank für die gelungene Webseite zu dem Thema Exchange so wie der Pflege der ganzen Struktur. Super, das es zur heutigen Gierzeit noch Menschen gibt, die anderen helfen wollen und nicht mal eine Gebühr kassieren. Auch ein Lob an alle Teilnehmer des Forums, die mit Ihren Tipps und der Bereitschaft, sich überhaupt die Probleme anderer durchzulesen dieses Forum sehr wertvoll machen. Das ist kein Gesülze, sondern wirklich ernst gemeint.

Nun zu meinem eigentlichen Problem,

ich musste unseren Exchange2019 komplett neu im recoverymodus mit CU11 installieren. Habe auch einen neuen Server 2019 dafür verwendet. Die Datenbank hat sich gut anbinden lassen und alles läuft eigentlich top. Aber nur eigentlich, denn ich habe das Phänomen, dass der Server Nachrichten annimmt diese auch sofort in die Postfächer packt aber nach mal 30 Minuten, mal 1 Stunde mal 2 Stunden landen die angenommenen Mails alle in der Warteschlange und ich muss den Microsoft Exchange Transport Dienst neu starten damit sie in die Postfächer weitergeleitet werden. Hat jemand einen Tipp für mich? Ich benutze im übrigen ein Lets encrypt ssl Zertifikat und erhalte daher immer ein event, dass das TLS Zertifikat bald abläuft da es ja harcoded auf 90 Tage Warnzeit festgelegt ist, daran kann es doch wohl nicht liegen? Ich wollte heute Abend CU12 drüber bügeln und hoffe eigentlich, dass es sich dann erledigt, aber vielleicht ist das Problem ja doch bekannt.

Gruß

Frank


Zitat
NorbertFe
(@norbertfe)
Prominent Member
Beigetreten: Vor 2 Jahren
Beiträge: 836
 

CU 12 plus letztes Security Update (plus notwendige /PrepareAllDomains) ist sicher eine gute Idee. Hast du denn sonst irgendwelche Meldungen im Eventlog die mit dem Transportservice in Verbindung stehen? Kann es evtl. Backpressure sein?


AntwortZitat
(@geloeschter-benutzer)
Reputable Member
Beigetreten: Vor 2 Wochen
Beiträge: 262
 

Hi,

zuerst CU12 installieren und dann beobachten, ob der Fehler noch auftritt. Wenn ja, dann würde ich mir die Transportlogs als LiveLog mittels bspw. Baretail anschauen. So solltest du ggfs. sehen, was unmittelbar vor der Dienstbeendung passiert.

Anmerkung zur CU Installation an sich: aus einer adm. CMD starten und vorher RealtimeScan vom Virenscanner für den Installationszeitraum deaktivieren.

Gruß,
Ralf


AntwortZitat
(@nothobranchius)
Active Member
Beigetreten: Vor 2 Monaten
Beiträge: 5
Themenstarter  

Hallo und danke für die schnellen Antworten,

ne backpressure kann es bei 3 Mails in der Queue eigentlich nicht sein.

Ich werde erstmal das CU 12 installieren, habe es gestern nicht gemacht, da ich über Probleme mit den Zertifikaten bei CU12 gelesen habe. Muss mich also erst richtig einlesen.

Werde aber den Beitrag aktuell halten.

Danke

Frank


AntwortZitat
NorbertFe
(@norbertfe)
Prominent Member
Beigetreten: Vor 2 Jahren
Beiträge: 836
 
Veröffentlicht von: @nothobranchius

ne backpressure kann es bei 3 Mails in der Queue eigentlich nicht sein.

Wieso nicht? Backpressure sorgt dafür, dass der Kram in der Queue bleibt und zwar aufgrund von Platzmangel. ;)


AntwortZitat
Frank Zöchling
(@franky)
Honorable Member Admin
Beigetreten: Vor 12 Jahren
Beiträge: 510
 

Hi,

Oft hilft es auch die Transport Database neu zu erstellen:

https://www.frankysweb.de/exchange-2016-dag-warteschlange-wird-zu-gross-mail-que/

Beste Grüße,

Frank


AntwortZitat
(@nothobranchius)
Active Member
Beigetreten: Vor 2 Monaten
Beiträge: 5
Themenstarter  

Hallo,

ich habe die Queue gerade mal gelöscht und neu anlegen lassen. Mal sehn ob es was bringt, bin noch in der Vorbereitung der CU12 Installation.

Bin für jeden Tipp dankbar.

Gruß

Frank


AntwortZitat
(@nothobranchius)
Active Member
Beigetreten: Vor 2 Monaten
Beiträge: 5
Themenstarter  

Hallo,

leider hat das Neuanlegen der Queue keine Besserung und auch keine Verschlechterung gebracht.

Ich hab gerade versucht CU12 zu installieren. Dies endete bei Schritt 17 mit einer langen Fehlermeldung aus der ich im Kern entnommen habe, dass die Datenbank nicht angebunden werden konnte weil "Die angegebenen Anmeldeinformationen für 'NT-AUTORITÄT\SYSTEM' sind ungültig"

Ich habe dann versucht mit eseutil /mh "Mailbox Database DB2019.edb" die Datenbank zu prüfen, das geht läuft aber direkt in den Fehler -1811 File not found, auch wenn ich den ganzen Pfad angebe.

Habe dann mit Eseutil /r E00 /d “c:\DB2019\DB2019.edb” einen Softrepair ausgeführt, der zwar erfolgreich durchgelaufen ist, aber den Fehler 1811 nicht beseitigt hat.

Ich probiere daher gerade lustig umher, was wohl mit der Datenbank los ist, die ich ja im recoverymodus angebunden habe.

Gruß

Frank


AntwortZitat
(@nothobranchius)
Active Member
Beigetreten: Vor 2 Monaten
Beiträge: 5
Themenstarter  

Hallo,

habe mein Problem gelöst bekommen. CU12 war leider auch nicht die Lösung. Ich habe einen virtualisierten DC im Netz mit DNS und diesen immer als Nameserver für den Exchange genutzt. Da es so sporadische Probleme waren, habe ich einen zusätzlichen physikalischen DC mit DNS installiert und diesen beim Exchangeserver als Nameserver eingetragen. Nun läuft es schon 12 Stunden durch, das war in den letzten Tagen nicht denkbar, höchstens 1,5 Stunden, ich denke es wird jetzt weiter durchlaufen.

Nochmal Danke für die Tipps.

Gruß

Frank


AntwortZitat
Teilen: