jimmyone

Sorry, mir war nicht klar, das ich das Grundprinzip eines SMTP Proxy noch erklären muss. Das hatte ich irgendwie vorausgesetzt. Also vom Grunsatz her sind SMTP-Proxys MTAs, die, ähnlich wie andere Proxy-Server, SMTP-Sitzungen an andere MTAs weiterleiten, ohne dabei den typischen Store-and-Forward-Ansatz eines üblichen MTA zu verwenden. Wenn ein SMTP-Proxy eine Verbindungsanfrage erhält, initiiert er eine weitere SMTP-Sitzung zu seinem Ziel-MTA. Fehler oder Statusinformationen vom Ziel-MTA werden über den Proxy an den sendenden MTA zurückgegeben. Heißt: Ich erreiche bei einem Connect den Exchange on-premise nicht direkt sondern nur über den Proxy und zwischengeschaltete Firewalls. Nach außen sieht es aber so aus, als würde ich diesen direkt erreichen. Für meine Begriffe liegt da irgendwo der Hase im Pfeffer. Ich kann mir sonst nicht erklären, warum ich diese Meldung von außen erhalte, von innen aber nicht.

Aber nur auf diesem einen Connector, sonst nicht. Und auch nicht unmitelbar sondern über den Proxy.

Es ist nur ein Server. Früher waren es mal mehrere, inzwischen liegt das alles auf EXO und die sind zurückgebaut worden. Dazwischen befinden sich ein Proxy und 2 Firewalls. Sowie ein externes Mailgateway. Heißt: Der Exchange ist nicht direkt über das Netz erreichbar, weder für SMTP nocht für https Verbindung, wobei letztere inzwischen auch dicht sind, weil die Postfächer in EXO sind. Der Connector, dessen Port etc. aber sind erreichbar und werden laut den Netzwerkern und das sagt ja auch das Protokoll bis zum Exchange on-prem geroutet. Haelth Checker vom meldet derzeit mal keine Probleme. Zumindest solange nicht, bis es wieder Sicherheitsupdates gibt. Das meine ich ja auch, das dass Netzwerkseitig ist. Ich erhalte derzeit nur als Meldung: Netzwerkseitig keine Probleme oder Fehlconfig. Keine Fehlermeldung im Log des Exchange on-prem ersichtlich. Im Grunde will ich sicherstellen, bevor ich das erneut eskaliere an die Netzwerker, das nicht ich der Depp war, der eine Fehlconfig gebaut hat und man sich am Ende entschuldigen muss. Deshalb dachte ich, geh mal in den Austausch. Manchmal übersieht man ja was.

Zur Zeit knapp 400 GB. Edit: Zusatzinfo: Wartungsmodus ist nicht, auch nicht teilweise aktiv.

Hallo Zusammen, wir haben einen speziellen Connector auf einem Exchange on-prem, der bestimmte Aufgaben übernimmt und als einziger auch von außen über einen Proxy, DMZ, aber nur von bestimmten public IPs angesprochen werden darf. Die Frewall und Netzwerk Jungs haben bereits geprüft und melden, das die Pakete und Anfragen vom Exchange on-prem angenommen werden. Ein entsprechendes Protokoll liegt mir vor. Teste ich das ganze intern oder via VPN meldet sich der Exchange auf dem betreffenden Connector. Rufe ich das nun komplett von außen auf, wie das Szenario gedacht ist, erhalte ich als Meldung: 421 4.3.2 Service not active. Ich hatte vermutet, das der Proxy irgendwas filtert oder die Firewall, aber nichts dergleichen trifft hier zu. Die Konfiguration des Connectors lässt die anfragenden IPs zudem zu, heißt der Scope ist dafür gesetzt. Was übersehe ich denn hier? Hat ggf. jemand eine Idee, die vielleicht weiterhelfen könnte? Vielen Dank und LG

Hallo Zusammen, gibt es Erfahrungen bezgl. dem Einsatz des SPO Migrations-Manager und der betreffenden Agents bezgl. Zuverlässigkeit und Durchführung in der Migration von Fileservern? Zusätzlich wäre interessant (ich weiß nicht ob ich das bei der umfangreichen Doku einfach überlesen habe) ob und wie ggf. NTFS Berechtigungen migriert werden. LG

Hallo Zusammen, ich befasse mich derzeit mit dem Thema Migration on-prem Exchange nach Exchange Online. Ich betreue das derzeit alleine, deshalb habe ich niemanden, mit dem ich mal Gedanken austauschen kann. Nicht das noch jemand denkt, ich habe hier Lack gesoffen. Keine Ahnung davon und will migrieren, so ist das nicht. Es geht hier nur um Überlgungen zu einem möglichen Szenario. Zur Zeit verwenden wir den Agent Hybridmouds mit AD-Connect und zugehörigen Settings. Meine Frage bezieht sich ganz konkret auf den Mailflow im Hybrid-Szenario. Derzeit zeigen die MX'er auf ein Mailgateway, das vor dem on-prem Exchange in einer DMZ steht. Mailgateway als auch Exchange sollen in dem Szenario migriert werden. Für das Mailgateway gibt es derzeit noch die Problemstellung des blocked Port 25 in Azure ohne Ent. Agreement. Die machen den Port auch nicht frei. Also wandert das GW ggf. nach AWS, weil wir keinen Zusatzdienst für den Mailflow nutzen wollen oder verzichten zukünftig auf das versenden über das Mail GW und regeln nur noch den Empfang. In meinem Szenario wird der MX'er weiterhin auf das Mailgateway zeigen und damit ist kein Flow Problem da. Wie wäre das aber, zum Verständnis, wenn ich das Mailgateway nicht hätte, dann würde der MX'er ja auf den on-prem Exchange zeigen. Der Eintrag müsste aber ja eigentlich zukünftig auf Exchange Online zeigen oder bleibt dieser auf der on-prem Variante solange eingetragen als dieser als Hybrid noch verfügbar ist? Insbesondere wenn nicht unmittelbar alle Postfächer migriert werden oder es Postfächer gibt, die nicht ohne B-Rat oder DS Zustimmung migriert werden dürfen. Auf der anderen Seite muss ich auch auf dem Mailgateway zukünftig entscheiden, wohin ich die Nachricht zustelle. Also müsste doch in der Grundüberlegung ein System das "führende" bleiben, bis ein kompletter Switch auf Exchange Online mit allen Postfächern, Freigaben etc. stattgefunden hat. Könnt ihr da etwas Licht ins Dunkel bringen? Danke vorab.

Vielen Dank, für die Hinweise, für welche Szenarien AADDS geeignet ist. In meinem Fall habe ich dann diese Szenarien so nicht.

Hallo Zusammen, bei einem per VPN an das on-premise angebundene Azure Netzwerk kann eine Azure Windows VM ob Server oder Workstation an das on-premise AD per Join hinzugefügt werden. Nun gibt es aber ja auch noch die Azure AD Domainservices, die ja quasi das Pedant zur on-prem Welt sind. Seht ihr besondere Vor oder Nachteile, warum man Azure AD Domainservices anstelle on-prem nehmen sollte? Jetzt mal ohne Berücksichtigung, das man dadurch mit on-prem wieder stark verzahnt ist und die Ausfallsicherheit wieder stärker auch von on-prem abhängt. Würde mich über einen Meinungsaustausch freuen. LG Jimmyone

Jup. Aber: Mein innerer Monk hatte kurzzeitig Probleme mit dieser Thematik.

Ok, ja dann passt es ja. Ja, genau das meinte ich in meinem Einleitungstext mit ich sehe auch die Änderungen im Filesystem. Ich war nur etwas irritiert. Aber passt dann so für mich. Ganz herzlich bedankt bei allen. :)

Hallo Zusammen, aktualisieren eure Exchange Server 2016 die Buildnumber nach Security Updates im ECP und PS Abfrage auch nicht? Nachweislich sehe ich in der Systemsteuerung die eingespielten Updates durch ihre KB Nummer. Auch die Änderungen im Filesystem. Die Buildnumber bleibt aber im ECP auf der des CU22 (2375.7) für Exchange 2016. Auch über die PS erscheint nicht die Buildnumber des Patches. In der PS nutze ich zur Abfrage: Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion Jetzt interessiert mich: Ist das nur bei mir so oder auch bei euch? LG

Hallo Zusammen, kann jemand das folgende Verhalten bestätigen oder nachstellen? Wir haben eine moderne hybrid Exchange Umgebung. Eine Kennwortänderung des hinterlegten Admins in Exchange Online für den Batchvorgang war notwendig. Über den Hybridassistenten auf der on-premise Seite muss man diesen vergeben, also habe ich den Assistent entsprechend gestartet und dort verändert. Dem Anschein nach wird diese Änderung aber nicht nach Exchange Online für den Endpunkt repliziert. Auch dann nicht wenn ich einen völlig anderen Nutzer eintrage. Das führt bei einem Batch zu dem Fehler, dass keine Verbindung mit dem Appproxy hergestellt werden kann. Sobald ich das Kennwort manuell in Exchange Online anpasse ist der Vorgang wieder erfolgreich durchführbar. Ist das ein Fehlerbild nur bei mir oder für euch auch nachvollziehbar?

Also laut Doku war das System niemals PDC oder sonst wie FSMO Owner. Aus Interesse: Von welchem How-to ist hier die Rede? Ich weiß heute ehrlich gesagt nicht mehr wirklich, wo wir die Lösung damals her hatten. Ich weiß noch, das rum gekrebse mit dem Zeitgeber war irgendwann so nervig, dass wir eine Domänenweite Lösung gesucht haben. Vielleicht basiert diese Lösung sogar auf dem von Dir genannten How to.

Prima, das hat geklappt. Danke NorbertFe. Tatsächlich hätte ich darauf ja auch noch kommen können. Insbesondere weil ich diese Möglichkeit kannte. Was solls, vielen Dank für den Tipp. Ich kann aktuell nicht sagen, ob der fehlerhafte DC mal die PDC Rolle hatte. Auszuschließen ist das allerdings nicht. VG Jimmyone