wznutzer

Hier wird das erklärt: https://learn.microsoft.com/en-us/exchange/mail-flow/accepted-domains/accepted-domains?view=exchserver-2019 Wenn ich dich richtig verstehe willst du einfach beliebig viele Adressen für den Empfang haben. Wie hier beschrieben machst Du das über "shared" Postfächer oder einfache SMTP-Adressen bei den User. "Shared" Postfächer können auch senden, dann müssen diese aber lizenziert werden. Falls Dein Problem das Senden der ganzen Email ist, also deine Überwachung, kannst du ja das zentral von einem Account aus machen, der ja nicht unbedingt bei O365 liegen muss. Da SMTP Auth bei Microsoft in Ungnade gefallen ist, willst Du das evtl. sowieso außerhalb O365 senden. Grüße

OK danke, verstanden.

Auch das kann ich nachvollziehen, genau wie wenn man alles auf einzelne Server packt. Was würde dagegen sprechen zum Broker und RDWeb noch die Lizenzen zu packen? Ich will es nur verstehen? Grüße und Danke

Ja, zur Veröffentlichung. Es ist zwar noch ein Reverse-Proxy vor dem Gateway, aber das will ich beibehalten. Dass man das Gateway und WebAccess auf eine VM packt und sonst nichts, kann ich nachvollziehen. Aber warum ich den Broker zwar auf einen DC packen kann aber nicht zusammen mit dem Lizenz-Server auf eine VM, verstehe ich nicht .

Die Motivation ist, wie Du Dir denken kannst, einmal die Lizenzen für das OS zu sparen und keine zusätzlichen VMs zu haben die kaum etwas zu tun haben. Würdest Du das so machen, weil du mit anderen Szenarion schlechte Erfahrungen hast oder als Prophylaxe um Probleme zu vermeiden. Mein jetziger Gateway hat kaum etwas zu tun und WebAccess wird wahrscheinlich nur verwendet um die RDP-Datei für die Farm runterzuladen. Aber klar, wenn es sein muss, muss es sein.

Guten Tag zusammen, ich plane gerade eine RDS-Farm: ca. 100 User, 3 Session-Hosts. HA ist nicht notwendig. Wir haben folgende Rollen: RDS Connection Broker RDS Gateway 3x RDS Session Host RDS WebAccess RDS Lizenz-Server Microsoft schreibt dazu: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-roles?source=recommendations RDS Connection Broker kann auf einen DC. (Würde mir jetzt nicht so gefallen) RDS Gateway und RDS WebbAccess kann kombiniert werden. RDS Lizenz-Server kann auf einem File-Server installiert werden. Ich finde bei MS leider nicht was tatsächlich zusammen supportet wird und was gar nicht zusammen geht. Wäre es z. B. denkbar und gut alle Rollen (RDS Con. Broker, Gateway, WebAcess und Lizenz) außer die Session Hosts auf einen Server zu installieren? In meinem Szenarion wäre das: 1 x Server mit RDS Con. Broker, Gateway, WebAcess und Lizenz 3 x Server -> Session Host Derzeit sind alle User auf einem Server mit allen Rollen (W2K12R2). Nur das Gateway ist separat. Vielen Dank für eure Meinungen.

OK => https://docs.microsoft.com/de-de/powershell/module/exchange/set-sendconnector?view=exchange-ps Merker für mich: Man sollte sich dann wohl nicht auf die in der UI angebotenen Optionen verlassen.

Man muss da noch was ergänzen: Der Haken TLS im Empfangsconnector erlaubt "nur" TLS, erzwingt es aber nicht. Man kann trotzdem unverschlüsselt intern Mails versenden. Ohne separat angelegten Sendeconnector funktioniert auch der Versand von intern zu intern nicht bei Minimalhybid und Modern Topology. Man braucht einen Sendeconnector beim lokalen Exchange der z. B. als Smarthost nach firma.mail.protection.oulook.com routet. Dann braucht es in O365 auch einen Empfangsconnector. An vielen Stellen im Internet ist zu lesen, dass O365 "nur" noch Verbindungen mit TLS 1.2 annimmt. Das ist falsch. Richtig ist, dass verschlüsselte Verbindungen "nur" noch mit TLS 1.2 angenommen werden. Unverschlüsselt geht noch immer, steht auch hier (erster Hinweis): https://docs.microsoft.com/de-de/microsoft-365/compliance/prepare-tls-1.2-in-office-365?view=o365-worldwide Im Sendeconnector kann man nichts mit TLS einstellen. Wenn man aber das Logging aktiviert, kann man sehen, dass der Exchange STARTTLS verwendet. >> TLS protocol SP_PROT_TLS1_2_CLIENT negotiation succeeded using bulk encryption. Grüße

Damit das funktioniert hat, mussten ein paar Dinge gemacht werden. Nichts konnte ausgelassen werden. Alles ist notwendig. Evtl. hilft es auch jemandem anderen. Sophos blockiert standardmäßig Autodiscover extern. Die URLs von hier https://support.sophos.com/support/s/article/KB-000038173?language=en_US helfen nicht. Man muss autodiscover.firma.com und autodiscover.firma.mail.onmicrosoft.com in die Exceptions aufnehmen. Es ist unklar warum Sophos das blockiert. ExcludeHttpRedirect auf 0 (war 1), ExcludeLastKnownGoodURL auf 1, ExcludeExplicitO365Endpoint auf 0. Unklar wo die Keys, außer ExcludeExplicitO365Endpoint, herkommen. Wurden nicht absichtlich gesetzt. HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover gab es einen Unterschlüssel RedirectServers mit zwei Einträgen. Diesen löschen, wird beim Start von Outlook dann mit 6 anderen Einträgen neu generiert. Mit den zwei vorhandenen Schlüssel funktioniert es nicht. Split-DNS für Autodiscover entfernen. Die Profile bleiben auch so erhalten und die OST wird nicht neu generiert. MFA muss für die Zeit der Profiländerung deaktiviert werden. MFA funktioniert nur mit Office365 nicht mit 2016 Zusammen mit SSO muss der Nutzer dann nichts machen, außer Outlook starten. In manchen Profilen bleibt der Microsoft Anmeldedialog (OAuth?) auf und der Vorgang bleibt stehen. Dann muss darin auf „anderen Usernamen“ geklickt werden und die Email-Adresse eingegeben werden. Dann nämlich will sich Outlook mit dem @firma.local zu O365 verbinden. Windows 10/11 mit Office 365 macht keinerlei Probleme, das funktioniert einfach, auch wenn die Sophos Autodiscover blockiert. Windows 10 mit Office 2016 braucht die gleichen Streicheleinheiten. Die Registry-Keys für TLS 1.2 waren auf dem Exchange (W2K12R2) für den HCW nötig. Aber auf einem RDP Host nicht, bzw. ändern nichts. Schaden aber auch nicht, so wie es scheint. Grüße

Hilft leider nicht. Die Registry-Keys für TLS 1.2 habe ich gesetzt. Die wollte auf dem Exchange auch der HCW haben: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v2.0.50727] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v2.0.50727] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 Es scheint ein Office 2016 mit Windows 2012 R2 Problem zu sein . Wenn ich das Autodiscover.xml direkt aufrufe, erscheit zuerst eine Passwortabfrage und dann das xml mit Error 600 <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> <Response> <Error Time="11:21:20.2318216" Id="1596708203"> <ErrorCode>600</ErrorCode> <Message>Ungültige Anforderung</Message> <DebugData/> </Error> </Response> </Autodiscover> Intern zeigt Autodiscover noch immer per Split-DNS auf den lokalen Exchange.

Guten Morgen, woran könnte es liegen, dass manche Clients (W2K12R2 RDP-Hosts mit Office 2016) sich nicht per Autodiscover zu Exchange-Online verbinden? Postfach ist migriert Batch ist abgeschlossen Outlook neu gestartet Der Client verbindet sich weiterhin mit dem lokalen Exchange. Folgender Key war bisher gesetzt, wurde jetzt aber entfernt. HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\16.0\outlook\autodiscover DWORD: ExcludeExplicitO365Endpoint Folgender Key soll man lt MS setzen, bringt aber auch nichts. https://docs.microsoft.com/en-US/outlook/troubleshoot/profiles-and-accounts/cannot-connect-web-service-not-working-migrated-to-office-365 HKEY_CURRENT_USER\Software\Microsoft\Office\<x.0>\Outlook\Autodiscover DWORD: ExcludeLastKnownGoodUrl Im lokalen DNS zeigt autodiscover.domain.de noch auf den lokalen Exchange. Aber manche Clients (vorwiegend W10 mit O365) machen den redirect. Habt Ihr einen Tipp? Grüße

Weil ich gerade im Sendeconnector nichts mit "TLS erzwingen" anklicken kann, war ich mir da nicht sicher ob das vom Empfangsconnector durchgereicht wird. Ich habe gar keine Hybrid-Connektoren . Da wurde vom HCW nichts angelegt. => Minimal-Hybrid mit Modern Topology. Evtl. liegt das aber daran, dass der lokale Exchange nicht direkt empfängt oder sendet. Der Exchange empfängt von einem Archivsystem und sendet dahin. Also ich hatte schon immer die akzeptierte Standarddomain auf "internes Relay" stehen und der einzige Sendeconnector sendet alles vom Adressraum "*" an einen Smarthost (Archivsystem). An den Smarthost natürlich nur was nicht der "eigenen Domain" entspricht.

So werde ich das probieren. Um alle Knoten im Kopf wegzuhaben, brauche ich immer ein vollständiges Bild im Kopf warum und wie alles miteinander funktioniert. Danke für die Tipps.

Ja, ein lokaler Exchange ist vorhanden, derzeit noch 2016 aber wird wahrscheinlich künftig ein 2019 werden. Ich klicke manchmal lieber als alles per Powershell zu machen. ==> Verwaltung von ExO. Beim jetzigen Exchange als lokales Relay habe ich noch einen Knoten im Kopf. Es gibt lokal keine Postfächer mehr und am liebsten würde ich auch die DB weghaben. Die liegt ja nur noch nutzlos rum. Das steht aber noch an. Liege ich so richtig: 1) Ich benötige zuerst bei den akzeptierten Domänen eine Domäne die ich dann als Absender verwende und auf "internes Relay" stelle. 2) Beim Empfangsconnector hake ich TLS und anonyme Benutzer an und gebe die Bereiche und den Port an. Somit sollte die Verbindung Client zu Relay verschlüsselt sein. 3) Der Sendeconnector sendet dann für den Adressraum "*" direkt an den MX oder über einen Smarthost an smtp.office365.com. Beim Smarthost kann ich "Standardauthentifizierung erst nach dem Start von TLS" anhaken, aber beim Senden an den MX nicht. Wenn ich den Authentifizierten Versand über den Smarthost mache, benötige ich einen User mit aktiviertem SMTP und den dann gültigen Limits wie 30 Nachrichten pro Minute. Wenn ich an den MX sende, kann ich TLS nicht anhaken. Irgendwas habe ich noch nicht verstanden .

Guten Tag, was ist "best practice" wenn lokale Anwendungen Emails versenden sollen? Gegeben ist Exchange mit Hybrid-Bereitstellung. Microsoft sieht 3 Möglichkeiten vor: https://docs.microsoft.com/de-de/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365 oder auch hier (etwas ergänzt) https://www.msxfaq.de/cloud/exchangeonline/multifunktionsgeraet_mit_exo.htm Am sympathischsten ist mir das mit dem Relay in Office 365. Alles funktioniert prima und die Limits von 30 Nachrichten pro Minute oder das Hantieren mit "send as" wie beim SMTP-Versand entfällt. Allerdings finde ich keine Möglichkeit verschlüsselte Verbindungen (TLS) zu erzwingen. Wenn der Client es macht dann geht es, ansosten nicht. Geht es irgendwie TLS zu erzwingen? Die Verbindung ist ja auf die feste IP beschränkt. Das bedeutet man muss im Netzwerk dafür sorgen, dass niemand Unsinn macht. Also z. B. die Verbindung über Port 25 nur von bestimmten Clients aus zulassen. Am besten würde mir die Kombination von O365 SMTP Relay gefallen das aber eine Authentifizierung erfordert. Gibt es das? Vielen Dank

Prima, Danke...

Wir reden, glaube ich, ziemlich gekonnt aneinander vorbei . Es wird nicht angezeigt, weil ich dem Exchange ja nicht gesagt habe, dass ich ExO verwende. Dann mache ich New-Remotemailbox. Ansonsten klicke ich oder halt auch New-Remotemailbox. So jedenfalls habe ich das verstanden.

Z. B. Neues Microsoft 365 Postfach, bei den Postfächer.

Ja (CodeTwo). Es funktioniert sehr gut, hat aber einige gravierende Nachteile. Die sogenannte Dealtamigration (wiederholte Migrationsläufe) kann nur neue Elemente übertragen, Änderungen nicht. Wenn z. B. im Quellpostfach ein bestehender Termin geändert wird, eine Email als gelesen markiert, eine Email gelöscht, wird das alles nicht übertragen. Aber für einmal rüber (wenn schon etwas da ist) und dann nie wieder taugt es. Ich habe mich entschieden Minimal Hybrid mit Modern Topology einzurichten und alle im Ziel löschbaren Postfächer zu übertragen. Das sind nach einer kleinen internen Umfrage 80%. Der Rest bekommt die Inhalte per 3rd Party einmalig übertragen. Das passt für mich gut und 80% können das Outlookprofil behalten. Falls jemand die gleichen Entscheidungen treffen muss: https://docs.microsoft.com/de-de/exchange/hybrid-configuration-wizard-options Zum Schluss noch eine Info die ich sonst nirgendwo erwähnt finde. Ohne Hybrid-Bereitstellung kann zwar der lokale Exchange bzw. die Powershell zur Verwaltung verwendet werden, es fehlen aber ein paar Punkte in der UI, bei einem Exchange 2016 jedenfalls.

Genau über diese Ungewissheit denke ich nach: "Was steht so alles im Postfach, was nicht offensichtlich ist". Einen ähnlichen Ansatz habe ich deswegen verfolgt. Nur hätte ich den Mailflow erst am Ende umgestellt. Lt. Tests benötige ich 5 Tage bis alle Mailboxen migriert sind (Drosselung bereits durch MS aufgehoben). Im Grunde aber schon so. Mit Variationen, wie über Nacht erst mal die letzten 60 Tage migrieren, Mailflow umstellen und dann im Betrieb den Rest nachholen. Soweit ich weiß matcht ADConnect über die ImmutableID, was ja eigentlich das Attribut ms-DS-ConsistencyGuid aus dem lokalen AD ist, automatisch, wenn ich ADConnect neu aktiviere. Warum ich dann aber noch Exchange Hybrid konfigurieren soll ist mir nicht klar. Danke und Grüße

Doku vom Microsoft erwarte ich auch von denen . Der Rest ist nett und auch sehr nützlich, aber die Bringschuld liegt bei Microsoft. ToDo ist z. B. weg. Das ist ohne EXO seit einiger Zeit, mit einem Geschäftskonto jedenfalls, nicht mehr nutzbar. Edit: Mir ist natürlich klar, dass das zuvor exportiert und wieder importiert werden kann.

Ich beschwere mich nicht, ich stelle fest. Vielleicht mache ich das , sobald ich eine Doku finde was alles in einem Postfach gespeichert ist und verloren geht, wenn ich mein Doppelpostfach lösche. Oder ich teste das halt selber.

Nichts. Da aber alle Dokumente, Blogs usw. davon ausgehen sind anderen Szenarien etwas mühsamer umzusetzen, weil nicht Standard.

Ich frage mich ob ich im ADSync die Exchange Hybridbereitstellung aktivieren muss wenn ich lokal nur verwalte. Die Attribute die zurückgeschrieben werden: https://docs.microsoft.com/de-de/azure/active-directory/hybrid/reference-connect-sync-attributes-synchronized?WT.mc_id=M365-MVP-6771 Das Attribut proxyAddresses würde z. B. zurückgeschrieben, aber ich kann das in EXO doch sowieso nicht ändern. Wenn ich mir die Attribute anschaue wird es egal sein ob ich das aktiviere oder nicht. In der Doku wird es bei der Verwaltung nicht erwähnt. Aber in der Microsoft-Welt scheint es nur Hybridbereitstellungen zu geben.

Das sollte nicht nötig sein. Ist nur dazu da, wenn man mal wieder zurückmigrieren will. Nach viel Lektüre sollte keine Hybridbereitstellung notwendig sein, wenn lokal nur verwaltet werden soll. Die Verwaltung setzt nur Attribute im AD die dann per AD-Sync übertragen werden. Auch New-Remotemailbox macht nichts online. Hybrid ist nur für den Mischbetrieb notwendig.