andreas.l

vor 6 Minuten schrieb NorbertFe:

Das ist kein Selfsigned Certificate sondern ein Zertifikat einer eigenen internen CA. das ist ein Unterschied. Für Exchange würde ich sowas aber heutzutage auch nur noch maximal in internen Umgebungen nutzen und auf keinen Fall bei welchen die von extern erreichbar sind.

 

klar ist das etwas anderes, vorausgesetzt, der externe Client ist auch Mitglied der Domäne.

vor 40 Minuten schrieb mr.sarge:

ja, alle über Outlook 2013. Bzgl. Self Signed Certificate muss ich dir recht geben, das gehört umgestellt und würde sicher einige Probleme vermeiden.

 

Vielleicht würde ich auf den Fehler kommen wenn ich wüsste warum und woher Port 135 beim Zugriffsversuch benutzt wird

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)

vor 3 Minuten schrieb Nobbyaushb:

Wenn der letzte On-Prem nach der Migartion entfernt wurde, bekommst du nur wieder einen mit dem O365 Support in das Netz.

Offiziell geht es meines Wissens gar nicht.

Wer hat das denn warum gemacht?

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

vor 1 Minute schrieb memphis1:

Deinstalliert wurde er nicht, sondern nur per ADSI Editor gelöscht...

 

Aber gut zu wissen, dann werde ich mal den Support anfragen ob dies Möglich ist

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...

vor 23 Minuten schrieb testperson:

Hi,

 

wenn intern = innerhalb der Domäne bedeutet, dann mittels SCP (Service Connection Point) aus dem Active Directory. Clients die nicht in der Domäne sind bzw. von extern nutzen DNS. Ein Umfangreiches Whitepaper findest du z.B. hier: https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-autodiscover/

 

Gruß

Jan

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