NorbertFe

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.

Im Idealfall kann ein Domänenadmin sich gar nicht am PC anmelden. Dann brauchst auch die Übernahme der Richtlinie nicht verweigern. (und ja, das is wirklich schon "alt")

Das war keine Frage zum Thema "Religionskrieg", sondern dazu, ob und inwieweit man hier Äpfel mit Äpfel oder mit Birnen vergleicht.

Hmm wieviele Verzeichnisdienste kennst du im Linuxumfeld, bei denen das "einfacher vorstellbar" ist?

Empfehle ich inzwischen per policy für alles zu setzen , denn auch Clients haben inzwischen immer wieder .net Applikationen, die tls 1.2 erwarte . ;)

Bitte. Das offline address Book zeigt ja nur Kontakte an, die dafür vorgesehen sind. Inhalte von Postfächern haben damit nichts zu tun.

Das offline address Book hat damit auch nichts zu tun. get-calendarprocessing dein-raum | fl

;) bei mir nicht. Bin ja auch nicht dein Kunde :p

Nö warum? Kann die dkim?

Wie ist denn die kalenderautomatik für die Räume konfiguriert? Poste doch mal die komplette Ausgabe eines Postfachs.

Kein Ding, wir haben viele Kunden auch in diesem Umfeld. Ich kenn also auch die Herausforderungen. :)

Naja ich bin Dienstleister, manchmal kann man sich auch drauf verlassen, was der dl so sagt. ;)

Wenn ich dran denke ;) wieviele Produkte hattet ihr denn in der Auswahl?

Ok danke. :)

Hab ich vermutet. Ich vermute eben weil es on prem ist, oder?

Aha einen Authenticator haben die meisten ja sowieso im Einsatz. ;) welche Lösung nutzt ihr zukünftig?

Als externer Dienstleister hab ich gern sowas wie ein OTP Soft-Token, sonst hat man irgendwann 17 solche Dongles in der Tasche. ;)

Naja das bieten aber inzwischen eigentlich fast alle Hersteller solcher Lösungen. Dritte Variante ist meist ein Rückruf.

Also bei meinen Kunden kommt auch nur das Ergebnis aus den Daten auf die der Nutzer zugriff hat. Keine Ahnung warum das bei dir anders sein soll.

ANforderungen ist das richtige Wort. Denn wo der MX liegt bei O365 ist ja egal. Da gibts genauso viele oder wenige Optionen wie ohne O365. ;) Und wenn der MX hier das Kriterium sein sollte, würde mich die Anforderung interessieren. Bye Norbert

Wenns ein Windows Fileserver ist, installier doch einfach die Suche darauf. Die triggern normale Windows Clients dann an und bekommen den Inhalt zurück. Funktioniert relativ gut, hat aber Einschränkungen.

Dann wäre die frage, ob das Dsgvo konform wäre, solche Logs zu archivieren. Ist ja doch ziemlich persönlich was darin erkennbar ist. ;)

Und selbst wenn, wäre das anhand solcher Logs schwierig nachzuweisen.