andreas.l

klar ist das etwas anderes, vorausgesetzt, der externe Client ist auch Mitglied der Domäne. versuchst du das Outlook Konto von extern manuell einzurichten? Oder ist das ein bereits eingerichtetes Profil, welches intern bereits via Outlook Anywhere funktioniert und du bekommst von extern nur keinen Zugriff auf das Postfach? Port 135 hört sich eher wie reines RPC an. ich würde als nächstes den Port 443 direkt frei schalten, nur zum reinen Test, um den Reverse Proxy und seine Sicherheitsfeatures auszuschließen

hm, ok. Outlook Anywhere (RPC / HTTP) war schon immer spezieller über WAF / Reverse Proxy Leider kenn ich mich mit der Barracuda (welcher TYP? CloudGen?) nicht aus. Geht es denn, wenn du zum Test den Port 443 nicht via Reverse Proxy veröffentlichst, sondern direkt veröffentlichst? Was ich nie verstehen werde, warum man heutzutage immer noch ein Self Sigend Certificate verwendet wenn Services veröffentlicht werden sollen. Speziell Outlook Anywhere war mit self signed certificate immer schon problematisch. Greifen die clients intern auch wirklich via Outlook Anywhere auf den Exchange zu? Welche Outlook Versionen werden genutzt? Evtl. auf MAPI / HTTP switchen?

wenn OWA funktioniert, sollte (sofern nur Port 443 von extern nach intern geöffnet ist) auch Outlook Anywhere funktionieren. Wie wird / ist der Exchange Server nach außen veröffentlicht? Via WAF? wenn ja, welcher Hersteller? Outlook Anywhere auf dem Exchange aktiv und intern funktionsfähig? Wie ist der interne / externe Hostname für Outlook Anywhere eingerichtet? Name auf Zertifikat?

was gibt denn der Befehl: Get-ADObject -Filter * -Properties * | where-object {$_.homeMDB -eq "CN der DB"} | select name aus? Den CN kannst du ja aus dem AD Attribut homeMDB auslesen (evtl. bei einem anderen Benutzer und dann den Namen der DB anpassen) Oder du erstellst nochmals ein Postfach in der DB, um von diesem User dann den CN der homeMDB herauszukopieren. Taucht dann noch ein Objekt auf?

Man muss doch die Arbitration und Discovery Mailbox auch mit umziehen, oder nicht (zumindest habe ich das immer so gemacht)?: Get-Mailbox -Arbitration | New-MoveRequest -TargetDatabase <Target Databasename> Get-Mailbox "*Discovery*" | New-MoveRequest -TargetDatabase <Target Databasename> Danach solltest du normalerweise die Datebank löschen können.

Hab gerade keinen Exchange 2016 zur Hand, daher konnte ich nur auf einem 2013er nachsehen: Du hast das Zertifikat "Microsoft Exchange" nicht mehr im ECP drin? Das wir ja standardmäßig vom Exchange auf den Hostnamen erstellt. Dieses ist bei mir im Backend auf den Port 444 gebunden. Ist das beim 2016er anders? Dachte, das wäre dort gleich geblieben. Bitte korrigieren, wenn das falsch ist. Evtl. kannst du das Zertifikat mit dem Anzeigenamen neu erstellen und dann dieses an den Backend Port binden? der CN ist bei mir der Hostname des Exchange Servers und als SAN (Subject Alternative Names) ist dort noch der FQDN mit drin.

bzw. darum: https://docs.microsoft.com/de-de/exchange/plan-and-deploy/system-requirements oder darum: https://technet.microsoft.com/de-de/library/ff728623(v=exchg.150).aspx Das sind die Requirements für Exchange 2016 und Exchange 2013 auf der entsprechenden MS Seite. Da steht auch ganz klar der Hinweis, dass "Versionen von .NET Framework, welche nicht in der Tabelle aufgeführt werden, in keinem Release von Exchange 2016 unterstützt werden". Das war bei Exchange schon immer so, dass der Support seitens MS für das neueste .NET Framework immer erst mit einem späteren CU kommt (mit .net 4.7 wurde auch eine Version übersprungen, da kurz darauf das .NET Framework 4.7.1 folgte)

danke fürs verifizieren... Ja, da wird (wenn überhaupt) nur noch der MS Support helfen können, da sehr wahrscheinlich Reste des alten Exchange Servers in der AD sind, die nicht deinstalliert worden sind. Da das aber mit O365 in nicht deinstalliert? das löschen selbst ist ja noch viel schlimmer... bzw. eigentlich nicht supported

Laut Microsoft ist es sogar strengstens empfohlen mit AAD einen on-premise Exchange zu betreiben, bzgl. Attributeverwaltung, usw. Ein MS Mitarbeiter hat mir sogar geflüstert, dass ein leerer on-premise Exchange in einer Hybrid Umgebung keine Lizenzkosten verursachen würde. Dies habe ich allerdings noch nicht geprüft / prüfen lassen. Dieser darf dann natürlich keine Postfächer hosten, wie es mit SMTP Auth Versand über den on-premise dann ausschaut, das weiß ich allerdings nicht. Leider habe ich auch noch keine O365 Lösung zu Hybrid umgebaut, kann mir aber durchaus gut vorstellen, dass dieser Schritt nicht mehr gehen wird. Viele Grüße

Super, dann hab ich die letzten Jahre ja alles richtig gemacht Dann warten wir mal auf die Antwort des Thread Erstellers...

Hi Jan, bezieht sich deine Antwort auf meine Antwort? Ich kenne Franks Whitepaper schon fast auswendig, danke dennoch ;-). Ich habe bisher bei so gut wie allen Kunden mithilfe von Split DNS gearbeitet, da sich oft der interne Domainname von der E-Mail Domain unterscheidet. Damit dann nicht alle DNS Einträge der externen Domain intern auch gepflegt werden müssen, habe ich jeweils eine DNS Zone namens "autodiscover.domainname.de" und eine für "exchange.domainname.de" angelegt. In diesen dann jeweils einen neuen Host A-Eintrag erstellt ohne Namen, nur mit IP Adresse. -> nie wieder Autodiscover Probleme gehabt... Und Zugriff der Clients funktioniert extern, wie intern mit derselben URL, sofern diese auf dem Exchange exakt gleich konfiguriert wurden. Grüße Andreas

Hi, Wie wird denn intern Autodiscover gemacht? Mit einem DNS A-Record (autodiscover.externalemaildomain.de), oder einem CNAME? Von extern wird Autodiscover via A-Record (Subdomain), oder CNAME gemacht? Welche Outlook Clients nutzt ihr? Grüße