Domino 9 und frühere Versionen > ND9: Administration & Userprobleme

Traveler an entfernten Standorten

<< < (2/2)

DomAdm:
Hallo,

die IBM schreibt dazu:
https://www.ibm.com/support/knowledgecenter/SSYRPW_10.0.0/capacity_network.html

"In general, geographical proximity improves network performance. The closer all the components are the faster the network is between them. In a perfect environment, all components of a Traveler environment are in the same lab on the same subnet.
When possible, set up Traveler environments that are geographically close to your user base. In general, the closer your users are to your Traveler environment, the more responsive the service is."

"In general, a ping time of <50ms is desirable for communication between Traveler and mail servers. "

Jacob

Tode:
Ja, so ist unserer Erfahrung: Auch kleine Standorte brauchen -für eine performante Traveler- Anbindung- einen Traveler- Server vor Ort.
Die Netzwerk- Performance zwischen SEG (bzw. MobileIron Sentry) und Traveler hatte dabei interessanterweise keine messbaren Auswirkungen auf die Performance:
Die "Proxies" konnten also tatsächlich an einem Ort stehen, nur die Traveler mussten zu den Mailservern gestellt werden.

Tannibal:
Vielen Dank für eure Antworten.
Werden wir so planen und umsetzen :)

maxritti:

--- Zitat von: Tode am 09.11.18 - 08:11:46 ---Off Topic: Einen Traveler ohne vorgeschaltetes MDM zu betreiben ist nicht nur höchst bedenklich, sondern kann inzwischen (Dank DSGVO) so richtig teuer werden.
--- Ende Zitat ---

Hast Du dazu ggf noch ein paar hilfreiche Infos bzw Links?
Ich habe mich mal mit einer Bekannten Juristin unterhalten. Irgendwie waren die beiden Ansichten technisch und juristisch aber nicht unter einen Hut zu bringen.

Geht es darum, dass der Traveler indirekt auf Personen bezogene Daten (nämlich die Postfächer) zugreifen kann, was durch ein MDM mehr oder weniger "verschleiert" wird?


--- Zitat von: Tode am 09.11.18 - 08:11:46 ---Mit MDM stellt sich die Frage nach dem Einstiegspunkt aber gar nicht.
--- Ende Zitat ---

D.h. dass das MDM eine Verbindung zum Endgerät aufbaut und quasi nicht das Endgerät die Verbindung startet?
Und bei mehreren Traveleren (nehmen wir an pro Kontinent gibt es einen) ordnet das MDM dem Endgerät dann quasi den richten Tarveler zu?

Sorry, wenn ich so dumm Frage, bin aber durch Google & Co nicht wirklich weitergekommen.  ;)

Tode:
Also zur DSGVO: Ihr habt personenbezogene Daten von ANDEREN auf den mobilen Endgeräten (Adressen, Telefonnummern, EMail- Adressen, Mails, etc.) und diese personenbezogenen Daten sind quasi "ungeschützt", und das ist das Haupt- Problem. Ihr könnt sie nicht zuverlässig von den Geräten entfernen, und auch nicht gewährleisten, dass niemand unbefugtes Zugriff erhält. Ihr könnt z.B. ohne MDM nicht verhindern, dass der User WhatsApp installiert und damit sämtliche Kontaktdaten beim Datenmoloch Facebook landen. Das selbe gilt für sämtliche Apps mit Kontakt- Zugriff.

Wir haben hier eine ganze Abteilung, die solche Analysen für unsere Kunden durchführen und für DSGVO- Konformität (nicht nur auf den mobilen Endgeräten) sorgen, und die haben auch die ganzen relevanten Links und noch viel mehr zu dem Thema, damit kann ich also leider nicht dienen.

Zu MDM / Traveler: Im MDM werden entsprechende Mail- Profile hinterlegt, und in diesen sind die Traveler- Server konfiguriert. Und diese Mailprofile werden per Gruppenzugehörigkeit, Standort, oder sonstigen Kriterien den Benutzern vollautomatisch oder auch manuell (je nach Wunsch) zugewiesen. Damit ist gewährleistet, dass jeder auf den Traveler zugreift, der für ihn am geschicktesten ist.

Das Endgerät spricht dann entweder direkt mit dem MDM (z.B. mit der MobileIron Sentry), und das MDM leitet die Anfragen an den internen Traveler weiter, oder aber (im Fall von Verse) baut ein Per- App- VPN zum Traveler auf, und spricht dann direkt mit dem Traveler (weil die Produkte der MDM Hersteller eben nur ActiveSync sprechen und nicht das für die Verse- App notwendige SyncML), aber eben durch einen geschützten VPN- Tunnel.

Navigation

[0] Themen-Index

[*] Vorherige Sete