NorbertFe

Hab grad keinen Exchange mit Kemp und IMAP in Reichweite. Kannst du mal die Konfig vom Kemp posten?

Wie auch bei L4? ;)

Anpassung Outlook Provider sowie, wenn in Benutzung, imap und Pop Konfiguration. Troubleshooting wird dann meist auch ein wenig umfangreicher.

Und unabhängig von Nils‘ Argumenten, sollte man wissen, dass wildcard Zertifikate auf einem exchange etwas mehr Konfiguration erfordern (können). Ich würde die 70€ einfach bezahlen und mir ein dediziertes Zertifikat für den exchange kaufen.

Kennen wir uns? ;) Kann ich dir nicht sagen, weil ich nicht weiß, wie eure DNS Konfiguration vor und nach dem Neustart aussehen sollte. ;)

Naja, wenn das per Telnet passiert und sonst nicht, würde ich an der Stelle keine Änderung vornehmen. Aber ansonsten get-transportagent gibt schonmal info darüber, was alles aktiviert ist und dann könnte man auch ggf. deaktivieren.

Da hast du imho jetzt einfach Pech. Deswegen migriert man als erstes den Client Access auf Outlook anywhere und erst dann nach 2016. dann stimmen nämlich Namen usw. im Profil schon. Ich denke, wirklich raus kommst du aus der Nummer jetzt nicht mehr.

Tja man deinstallieren den alten Exchange eben auch erst nachdem ein Großteil der Profile sich aktualisiert haben. Wenn’s mit neuen Profilen funktioniert, ist das ja schonmal gut. Hattest du exchange 2010 schon nur mit Outlook anywhere konfiguriert, dann gäbs jetzt auch kein Problem. ;) einen gewissen Schwund gibts bei sowas aber eigentlich immer. Aber 60 von 60 is etwas viel. ;) Outlook 2010 ist sicher auch nicht der idealste Client. Hat Outlook ein aktuelles Patch Level?

Klar geht das. ;) gibts sogar als Template. https://support.kemptechnologies.com/hc/en-us/articles/207896256-Microsoft-Exchange-2016?mobile_site=true#MadCap_TOC_17_2

Ich meine, dass ich das mal umgebaut habe. Ist aber noch zu win2000 zeiten gewesen. ;) wär zumindest einen Versuch wert.

Man könnte schauen, ob man mit subinacl evtl. Weiterkommt, wenn die Namen ersetzt werden.

Kemp als L4 oer L7? Ich würde an deiner Stelle erstmal mit L4 beginnen.

Gar nicht afaik.

Das ist nicht SMTPS sondern SMTP TLS ;) (ja mag unbedeutend sein, aber ist wichtig). Die stehen ja auch nicht im Eventlog sondern im IMAP Log. Und die liegen irgendwo auf der Platte rum und müssen afair auch explizit aktiviert werden: https://docs.microsoft.com/de-de/exchange/configure-protocol-logging-for-pop3-and-imap4-exchange-2013-help

Ja, aber wenn da schon DC und Exchange läuft, wäre das keine gute Konfiguration und definitiv keine Empfehlung (von mir und von MS ;)) Nein, nur für eine VM, weil dein Host ja schon Exchange und DC macht. Die zwei VM Instanzen darfst du nur nutzen, wenn der Host nichts ausser Hyper-V macht.

Naja erstmal Probleme beseitigen, als sie zu lösen. ;) für den Rest müßte man jetzt wissen was du da gebaut hast. Wenn das exe Dateien sind, musst du Erkennungsregeln usw. natürlich alle selbst bauen und logischerweise auch die installationsparameter mal inspizieren. Stimmt, aber siehe andere Antwort.

Hi, nur kurz der Hinweis, dass es VLC auch als msi gibt. ;) Bye Norbert

:) Das ist aber nicht nur bei Exchange ein Problem. ;)

Naja es gibt nur sehr wenige Szenarien, denen ich bisher begegnet bin, wo das nicht sowieso auf dem selben Server terminierte. Und bei denen funktionierte es dann meist sowieso nicht. ;)

War in Anfangszeiten von Exchange 2007/2010 durchaus eine übliche Umgehungslösung. ;) Da haben Zertifikate aber auch noch deutlich über 200€ gekostet.

Ja kann man machen, ist halt egal. ;)

Wozu denn? erst zu autodiscover schicken, wenn du dann sowieso zu outlook.... willst? Die Autodiscover Domain gibts nur, weil man einem NICHT-Domain Mitglied ja den SCP nicht vorgeben kann. ;)

Korrekt. Und zwar NICHT mittels RPC Client Access Array. Das vergißt du einfach, weil das wie der Name sagt für RPC/MAPI ist und Exchange 2016 spricht nunmal nur noch https. Deswegen wäre es "fatal", da jetzt eine Hürde einzubauen, die man bisher ja gar nicht hatte. Du brauchst einen Namen bspw: outlook.deineexternedomain.tld Der Name ist im "internen" DNS als A-Record eingetragen und zeigt auf die IP deines Exchange 2010 Servers. Mehr erstmal nicht! Der Name wird im "externen" DNS als A-Record eingetragen und zeigt auf die IP deiner Firewall/Reverseproxys Üblicherweise gibts den externen Namen ja schon, also schonmal die halbe MIete. Zertifikat für extern und intern muß natürlich alle notwendigen Namen beinhalten. Angenommen dein Exchange hat keinen Reverse Proxy, brauchst du also ein Zertifikat im Exchange, was autodiscover.deineexternedomain.tld sowi outlook.deineexternedomain.tld beinhaltet. Solltest du bereits einen anderen Namen verwenden, dann den ggf. auch noch. Im Exchange 2010 konfigurierst du jetzt _alle_ virtuellen Verzeichnisse auf outlook.deineexternedomain.tld und sorgst dafür, dass die Clients im LAN/WLAN/VPN diese Adresse direkt "INTERN" erreichen und nicht ggf. über einen Proxy müssen. Dann mittels set-clientaccessserver den SCP auf outlook.deineexternedomain.tld konfigurieren. Jetzt sorgst du dafür, dass deine Outlooks sich alle per https und nicht mehr per Mapi/RPC verbinden (geht per Outlook Provider) Dann Exchange 2016 CU17 installieren und dort ALLE _internen_ und _externen_ URLs auf outlook.deineexternedomain.tld konfigurieren und das Zertifikat (siehe oben) installieren. SCP mittels set-clientaccessservice ebenfalls auf outlook.deineexternedomain.tld konfigurieren DNS intern outlook.deineexternedomain.tld auf die IP vom Exchange 2016 ändern (flushdns und ttl überlasse ich mal der Einfachheit halber deiner Fantasie) Wenn jetzt alles geht, bist du fast fertig, denn dann fehlt das nur noch in der Firewall, dass du dort eingehende Anfragen an den neuen Exchange schickst. Eigentlich könnte man auch einfach mal das MS Whitepaper für sowas lesen! Bye Norbert Nein RPC Client Access Array benötigte man bei Exchange 2010, damit bei RPC/Mapi der Servername egal war! Für https Zugriffe war das NIE NIE NIEMALS zuständig. Lies dir lieber die MS Whitepaper durch bzw. auch mein Geschreibsel oben. Üblicherweise macht mans andersrum und konfiguriert den Exchange 2010 richtig, denn meist ist der falsch konfiguriert. Das ist doch vollkommen egal, wann und wie lange. WEnn der Zugriff über den Exchange 2016 läuft, gibts Zeit ohne Ende in Ruhe (sogar tagsüber) die Postfächer zu migrieren. Davon bekommt der Nutzer bei vernünftiger Planung und Konfiguration nichts mit, ausser einem Neustart von Outlook. Wenn mans richtig macht. ;)

Und das ist auch völlig egal, weil den exchange das auch nicht pro Termin interessiert, sondern bei ms mal jemand dachte, dass derjenige der den Raum bucht, vorher evtl. wissen sollte wieviele Personen da reinpassen. Eine technische Verknüpfung gibts also weder pro Termin oder Tag oder überhaupt.

Man benötigt kein rpc cas Array. Jedenfalls nicht für die Migration und wie der Name schon sagt, wärs eh ungünstig, wenn da der Name des https zugriffspunktes verwendet würde.