wznutzer

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.

Vielen Dank für Deine Mühe am Wochenende. Seit April 2022 gibt es eine kostenlose Exchange 2019 Lizenz und ich kann "nur" die Management-Rolle von Ex2019 installieren. Das dann kein IIS installiert wird, geht das nur per Powershell, wäre OK, aber geht es tatsächlich ohne lokal etwas zu installieren? Es gibt zwar zwei Postfächer, aber das EXO Postfach wird nicht verwendet und könnte gelöscht werden. Evtl. so, nachdem die Lizenz entfernt wurde. Set-User xyz@abc.de -PermanentlyClearPreviousMailboxInfo Die Daten von Sharepoint (Teams, OneDrive) sollten so erhalten bleiben. Bei OneNote und ToDo bin ich mir nicht sicher. Weißt Du da was? Ist ToDo nicht der Aufgabenersatz bei EXO? Wenn ToDo oder OneNote weg wäre, gibt es keinen Weg zurück für mich, als das mit 3rd Party zu machen. Das Attribut MsExchMailboxGuid ist doch die Verbindung zwischen dem AD und Exchange. Das kann ich doch lokal nicht entfernen, oder? Deswegen nur beim Sync. Das Attribut sagt EXO, dass es ein lokales Postfach gibt, deswegen legt EXO keines an, nachdem eine Lizenz zugewiesen wurde. In EXO heißt es dann: Das lokale Postfach dieses Benutzers wurde noch nicht zu ‎Exchange Online‎ migriert. Das ‎Exchange Online‎-Postfach ist erst nach Abschluss der Migration verfügbar. Damit ich das richtig verstehe. 1) Mit 3rd Party migrieren Ab hier könnten dann alle User mit EXO arbeiten. Ich bin aber nicht in der Lage die Postfächer zu verwalten weil die nachfolgenden Schritte noch nicht gemacht sind. 2) Dann alle lokalen Mailboxen wie folgt deaktivieren: Disable-Mailbox-identity <xyz@abc.de> 3) Den HCW durchführen?? Mit welchen Einstellungen? 4) Remote-Mailbox für jeden User aktivieren?? Enable-Remote-Mailbox <xyz@abc.de> -RemoteRoutingAddress <xyz@abc.mail.onmicrosoft.com> 5) Jetzt ist aber doch die Mailbox noch immer im AD unbekannt, oder nicht? Im Attribut MsExchMailboxGuid steht doch noch immer die Guid vom alten Postfach. Ich könnte dann versuchen die Guid der nun deaktivierten lokalen Mailbox der Remotemailbox zuzuweisen, aber ist das den der richtige Weg und supportet. Edit: Denkfehler, hier müsste wahrscheinlich die Guid vom Online-Postfach eingetragen werden. Set-RemoteMailbox <xyz@abc.de> - ExchangeGuid <Guid vom Online-Postfach> Oder ich habe Dich nicht verstanden was Du mit "Cloudpostfächer matchen" meinst. Vielen Dank Nach der Migration mit 3rd Party habe ich theoretisch diesen Fall der hier beschrieben ist. https://www.msxfaq.de/cloud/identity/doppelpostfach_mit_exo.htm Aber muss ich wirklich Exchange Hybrid konfigurieren. Das würde man doch nach einer Migration ohne 3rd Party zurückbauen. Edit: Warum ich zur Verwaltung zwingend den HCW ausführen muss, ist mir nicht klar. Es gibt ja keinen Hybridbetrieb und somit auch nichts was zwischen EXO und lokal abgeglichen werden muss (Mail-Routing z. B. zwischen lokaler und Online-Mailbox). Alle User sind lokal oder nach der Migration online.

Guten Tag, es wurde leider etwas länger. Gegeben ist Exchange 2016 und ein bestehender Office Tenant. Alle User sind bereits im Tenant vorhanden und die Apps (Teams, OneDrive, OneNote usw.) werden aktiv genutzt. Die User werden per ADConnect mit SSO synchronisiert. Nun soll der lokale Exchange weg und nur noch Exchange-Online genutzt werden. Es soll keine Hybrid-Umgebung eingerichtet werden. Die User haben derzeit zwei voneinander unabhängige Postfächer. Nun gibt es aber ein paar sich widersprechende Dinge: Ist AD-Connect aktiv braucht es einen lokalen Exchange . Cut-Over Migration ist nicht möglich, weil diese keine bestehenden User mag. User zu löschen ist nicht möglich, wegen der bereits bestehenden Daten (Teams, Sharepoint usw.) Aufgrund einer Empfehlung eines Dienstleisters habe ich mir die Migration mit einem Drittanbieter-Tool angesehen. Funktioniert perfekt. Aber doch gibt es ein paar Ungereimtheiten. Wenige User die erst durch AD-Connect angelegt wurden, haben trotz Lizenz keine Mailbox und warten auf die Microsoft eigene Migration. Das lässt sich durch setzen des Attributs MsExchMailboxGuid auf NULL im Regelwerk von AD-Connect beheben. Dann bekommt nach Zuweisung einer Lizenz der User ein Postfach und die Daten können migriert werden. Aber so hat der lokale Exchange ja keine Kenntnis der Mailbox in Exchange-Online und kann somit auch nicht zur Verwaltung verwendet werden . Nun ergeben sich zwei Fragen: 1) Wie schaffe ich es, dass ich einen lokalen Exchange habe den ich zur Verwaltung von Exchange-Online verwenden kann? Der alte Exchange müsste ja zuvor deinstalliert werden oder dieser muss zur Verwaltung umfunktioniert werden. 2) Ich setze das alles zurück und verwende die Microsoft-Migration. Aber kann die Hybrid-Migration in bestehende Postfächer migrieren? In der Doku finde ich da nichts. Und welche Migrationsart wäre da wohl am geeignetsten? Minimal Hybrid mit Modern Hybrid Technology. Mit Modern Hybrid Technologie wären keine eingehenden Verbindungen nötig. Evtl. könnt Ihr mich etwas in die richtige Richtung schieben. Danke

Ich lerne gerne: Starting test: SystemLog * The System Event log test Fehler. Ereignis-ID: 0x0000272C Ich vermute ich kann das ignorieren. Der Fehler wird immer im Ereignislog protokolliert wenn ich dcdiag ausführe. EventID 10028. Es ist so oft im Log wie ich dcdiag ausführe. Auffällig ist, dass nicht alle Fehler des Eventlog ausgegeben werden, sondern nur die in einem bestimmten Zeitfenster (60 Minuten) vor dem Aufruf von dcdiag. Wenn ich eine Stunde lang dcdiag nicht ausführe steht da: Found no errors in "System" Event log in the last 60 minutes. Somit generiert dcdiag selber einen Fehler der dann bei einem nachfolgenden Aufruf protokolliert wird .

ja Nach: ** Sichere ausgehende Kanäle wurden nicht getestet, da "/testdomain:" nicht eingegeben wurde. Ich verwende dcdiag /c /v /e /q

Hallo zusammen, wenn ich dcdiag ausführe erscheint folgende Meldung: DCOM konnte mit keinem der konfigurierten Protokolle mit dem Computer "IP-Adresse der Firewall" kommunizieren; angefordert von PID 474 (C:\Windows\System32\dcdiag.exe). Erklären kann ich mir das nicht. Wisst Ihr etwas darüber? Danke und Grüße

Guten Abend, weil es hier angesprochen wurde, ja ich versuche schon ein Schutzkonzept (Tier 0 usw.) umzusetzen. Den Restore habe ich mir nicht aus der Sicht, dass ein Update den AADC kaputt macht vorgestellt. Ich denke, dann habt ihr das schon erlebt. Mein Restore-Konzept wäre gewesen, neuer DC, replizieren lassen, alter raus aus der Domäne und AADC lt. meiner Doku neu installieren. Aber das will ich natürlich nicht jeden Monat machen, weil es ein Update von AADC gibt. Wenn es da ein erhöhtes Risiko gibt, habe ich darauf keine Lust und ich lasse das. Meine Motivation war einfach, wegen so einem kleinen Programm nicht eine weitere VM haben zu müssen auf die ich aufpassen muss. Ab Herbst hätte ich auf einem Host eine Datacenter-Lizenz. Da würde die separate VM noch nicht einmal etwas kosten. Vielen Dank für euren Input.

Guten Abend, lt. Doku ist es problemlos möglich AADConnect auf einem Domänencontroller zu installieren, aber ist das eine gute Idee? Lt. Microsoft muss der Server ohnehin so "beschützt" werden wie alle Member in Tier 0. Es muss ein SQL-Server installiert werden, da ist jetzt eher so mittelgut auf einem DC, aber ist es so schlimm? Bei Problemen mit AADConnect müsste ich vielleicht mal den Server starten, dann ist auch der DC weg, aber ich habe ja sowieso mehrere. Der DC ist nicht mehr identisch zu den anderen, wäre aber auch egal. Ein DC ist ja schnell installiert und hinzugefügt. In einer sehr großen Umgebung ist das vielleicht etwas anderes, aber bei < 200 User will mir kein trifftiger Grund einfallen das nicht zu tun. Evtl. irre ich mich, aber deswegen frage ich. Danke und Grüße

Inzwischen ca. 130 User. Jede Menge Einstellungen, Gerätschaften und vergebene Rechte und leider erst seit ca. 5 Jahren vollständig dokumentiert. Davor . Ja, Upgrade. Habe ich bei faq-o-matic glatt übersehen. Danke. Aber ich habe verstanden. Es gibt keinen technischen Grund das unbedingt machen zu müssen. Vielen Dank