Benutzer mit den meisten Antworten
Exchange Migration 2010 > 2016 Rückbau | Warteschlangen – Shadow Redundanz

Frage
-
Hallo zusammen,
wir sind aktuell dabei unsere Exchange Server 2010 (haben nur noch 2 mit der CAS & HT Rolle) zurückzubauen. Jeglicher Mailverkehr ist an den Connectoren auf die Ex2016 Server umgestellt. Auch die Externen E-Mail werden vom Mailproxy an den KEMP Loadmaster zugestellt hinter dem die EX2016 stehen. Es existieren bei den Exchange Server 2010 nur noch die Empfangsconnectors „Default & Client“ wobei beim Default nur die Berechtigungsgruppen „Exchange-Benutzer, Exchange-Server und Vorversionen…“ aktiviert sind. Anonyme Benutzer sind nicht erlaubt und dafür hatten wir vorher eigene EC mit den jeweiligen IP-Adressen und diese EC haben wir gelöscht, da jene nun an den Ex2016 vorliegen. In unserer Umgebung haben wir 2 Sendeconnectoren. Ein SC ist für die EX2016 Umgebung und enthält nur die EX2016 Server und den SC für EX2010 haben wir deaktiviert.
Nun habe ich vorher noch durch die Logs einige System herausgefiltert, welche noch über die Ex2010 Umgebung Mails versendet haben und umstellen lassen. Heute stand das herunterfahren der Exchange Server 2010 an und hier gab es dann eine Auffälligkeit in den Warteschlangen der Ex2016 Servern. In den Warteschlangen gab es nun folgende Einträge.
Nächste Hopdomäne: Ex2010.domain.local
Zustelltyp: Shadow-Redundanz
Status: Bereit
Nachrichtenanzahl: 5
Gehe ich auf eine Ex2010 Warteschlange, so werden da E-Mails angezeigt (meistens Externe) und in den Empfängerinformationen steht der Status „Bereit“ oder „Abgeschlossen“.
Nun habe ich die Server wieder hochgefahren und die Warteschlange hat sich geleert. Im Anschluss deaktivierte ich auf den Ex2010 Servern die Empfangsconnectors „Default & Client“ und es passierte das selbe.
Es trat dann auch die Meldung „Letzter Fehler“ [{LED=};{MSG=};{FQDN=};… bei einigen E-Mails aus diesen Warteschlangen auf.
Was habe ich übersehen bzw. muss ich noch vor der Deinstallation machen?
Ps.: Hier noch unsere Transportconfig
get-TransportConfig AddressBookPolicyRoutingEnabled :False AnonymousSenderToRecipientRatePerHour :1800 ClearCategories :True ConvertDisclaimerWrapperToEml :False DSNConversionMode :UseExchangeDSNs JournalArchivingEnabled :False ExternalDelayDsnEnabled :True ExternalDsnDefaultLanguage : ExternalDsnLanguageDetectionEnabled :True ExternalDsnMaxMessageAttachSize :10 MB (10,485,760bytes) ExternalDsnReportingAuthority : ExternalDsnSendHtml :True ExternalPostmasterAddress : GenerateCopyOfDSNFor :{5.4.8, 5.4.6, 5.4.4, 5.2.4, 5.2.0, 5.1.4} HygieneSuite :Standard InternalDelayDsnEnabled :True InternalDsnDefaultLanguage : InternalDsnLanguageDetectionEnabled :True InternalDsnMaxMessageAttachSize :10 MB (10,485,760 bytes) InternalDsnReportingAuthority : InternalDsnSendHtml :True InternalSMTPServers :{x.x.x.x} JournalingReportNdrTo :<> LegacyJournalingMigrationEnabled :False LegacyArchiveJournalingEnabled :False LegacyArchiveLiveJournalingEnabled :False RedirectUnprovisionedUserMessagesForLegacyArchiveJournaling :False RedirectDLMessagesForLegacyArchiveJournaling :False MaxDumpsterSizePerDatabase :50 MB(52,428,800 bytes) MaxDumpsterTime :7.00:00:00 MaxRetriesForLocalSiteShadow :2 MaxRetriesForRemoteSiteShadow :4 MigrationEnabled :False OpenDomainRoutingEnabled :False RejectMessageOnShadowFailure :False Rfc2231EncodingEnabled : False SafetyNetHoldTime :2.00:00:00 ShadowHeartbeatFrequency :00:02:00 ShadowMessageAutoDiscardInterval :2.00:00:00 ShadowMessagePreferenceSetting :PreferRemote ShadowRedundancyEnabled :True ShadowResubmitTimeSpan :03:00:00 SupervisionTags :{Reject, Allow} TLSReceiveDomainSecureList :{} TLSSendDomainSecureList :{} VerifySecureSubmitEnabled :False VoicemailJournalingEnabled :True HeaderPromotionModeSetting :NoCreate Xexch50Enabled :True
- Bearbeitet Lexxitus Montag, 30. März 2020 16:12
Antworten
-
Ich habe nun alle Warteschlangen auf den beiden Ex2010 neu gestartet und den Systemen 2 Tage Zeit gegeben. Als erstes deinstallierte ich einen Ex2010 (Vorher aus dem Sendeconnector der Ex2010 herausgenommen) und gestern war der letzte dran. Es gab keine Probleme bei der Deinstallation und wir sind nun mit der Exchange Migration fertig.
Ich wünsche allen eine erfolgreiche Migration ohne viel Kopfschmerzen/-zerbrechen ;-)
MfG Paul
- Als Antwort markiert Lexxitus Donnerstag, 2. April 2020 05:32
Alle Antworten
-
Es muss etwas mit den Shadow-Redundanz Einstellungen bei uns zu tun haben. Mir ist auch nicht klar warum der Exchange 2016 an den Exchange 2010 Servern (stehen alle am selben AD-Standort) noch E-Mails (als Redundanz) hinsenden muss und nicht zu seinen anderen Exchange 2016 Servern.
-
Ich habe nun alle Warteschlangen auf den beiden Ex2010 neu gestartet und den Systemen 2 Tage Zeit gegeben. Als erstes deinstallierte ich einen Ex2010 (Vorher aus dem Sendeconnector der Ex2010 herausgenommen) und gestern war der letzte dran. Es gab keine Probleme bei der Deinstallation und wir sind nun mit der Exchange Migration fertig.
Ich wünsche allen eine erfolgreiche Migration ohne viel Kopfschmerzen/-zerbrechen ;-)
MfG Paul
- Als Antwort markiert Lexxitus Donnerstag, 2. April 2020 05:32