Taveler in eigener Domäne

[smokyly]

Hallo zusammen,

wir sollen nun leider doch weg vom BES zum Traveler. Derzeit haben wir einen Cluster mit zwei Dominos in einer Domäne.
Nun meinte der Berater, der Traveler wäre in einer eigenen Domäne besser aufgehoben, weil somit die Updates der einzelnen Servern unabhängiger wären.
Welche Einschränkungen hat denn diese Konstellation, bzw. welche Vorteile hätte es, alle Dominos in einer Domäne zu halten?

Falls das wichtig ist: Der Traveler steht hinter der DMZ und wird über VPN erreichbar sein.

Gruß

[Driri]

Wir betreiben unseren Traveler-Server seit ca. 2 Jahren und von Anfang an in einer eigenen Domäne.

Nachteile liegen vor allem darin, daß man sich bei der Konfiguration des Servers etwas mehr Gedanken machen muß :
- Querzulassung
- Directory Assistance
- Zugriffe des Traveler-Servers auf die Mailfiles der User
...

Der Vorteil, den Traveler-Server dafür immer up-to-date halten zu können, wiegt die paar "Nachteile" aber mehr als auf. Unsere internen Domino-Server werden z.B. sicherlich noch 1 Jahr lang unter 8.5 laufen. Den Traveler-Server können wir trotzdem schon vorher auf Domino / Traveler 9 bringen und müssen uns dabei um die Produktivumgebung keine Gedanken machen.

[Thomas Pfau]

Hallo smokyly,

die Empfehlung ist ganz gut. Die Querzulassungen und den Zugriff auf das Adressbuch per Directory Assistance sehe ich gar nicht so als Nachteil - höchstens die Stunde zum Einrichten und testen.

Die Vorteile liegen einerseits auf Seiten der Sicherheit: Man betreibt in der DMZ einen vom internen System unabhängigen Server, der abgekapselt ist und kaum Informationen enthält, die einem Angreifer viel nützen.
Ein weiterer Vorteil liegt darin, dass in den Traveler sehr häufig Innovationen einfließen, für deren Nutzung jedoch ein Upgrade des Traveler-Servers nötig ist. Hängt der Traveler-Server in der internen Domino-Domäne, ist dann zumindest der Admin-Server zu aktualisieren. Das wiederum bedeutet oft, dass auch Dritt-Software (Anwendungen, Backup, Virenscanner) ebenfalls aktualisiert werden müssen. Mit einem unabhängigen Server kann man jederzeit die aktuellste Version nutzen, ohne zu tief in das "Running system" eingreifen zu müssen.

Viele benötigen z.B. wegen des Supports der neuen Blackberry-Geräte den Traveler 9 und wollen deshalb aber nicht sofort intern auf Domino 9 gehen (BES 10 synchronisiert jetzt nämlich auch per Traveler).

Viele Grüße,
Thomas

[Tode]

Den Nachteil der Querzulassung kann man aber komplett vermeiden, indem man den Traveler-Server in der Echt- Domäne registriert, und dann diese ID und den Haupt- Zertifizierer beim Anlegen der Traveler- Domäne verwendet. Dann hat man eine eigenständige Domäne mit den genannten Vorteilen (vor allem das updaten auf die jeweils aktuellste Version ohne Rücksicht auf die Echt- Umgebung), und keine Nachteile wie Querzulassungen, Vertrauensstellungen, etc...

Auf diese Weise habe ich übrigens auch schon Server ausgelagert, die Ursprünglich in der selben Domain waren... Ohne Probleme...

[smokyly]

Vielen Dank für die Antworten.

Torsten, Dein Ansatz ist sehr schmeichelhaft, ich werde das mal zur Diskussion bringen.

VG

[(h)uMan]

Den Nachteil der Querzulassung kann man aber komplett vermeiden, indem man den Traveler-Server in der Echt- Domäne registriert, und dann diese ID und den Haupt- Zertifizierer beim Anlegen der Traveler- Domäne verwendet. Dann hat man eine eigenständige Domäne mit den genannten Vorteilen (vor allem das updaten auf die jeweils aktuellste Version ohne Rücksicht auf die Echt- Umgebung), und keine Nachteile wie Querzulassungen, Vertrauensstellungen, etc...

Auf diese Weise habe ich übrigens auch schon Server ausgelagert, die Ursprünglich in der selben Domain waren... Ohne Probleme...

@Tode: klingt sehr gut. Ich würde auch gerne unseren bestehenden Traveler Server (eigener Server) in eine eigene Domino Domain "verschieben" und dann auf Release 9 upgraden. Wie bist du bzgl. vorgegangen bzw. welche Reihenfolge ist zu beachten?

Besten Dank!

[Tode]

Mit solchen Dingen verdiene ich mein tägliches Brot...
Deshalb nur ganz kurz in Stichworten:

1. neues Adressbuch auf dem Server erstellen mit Schablone pubnames.ntf (z.B. Names2.nsf)
2. alle nötigen Dokumente rüber kopieren (Serverdokumente, konfig- dokumente, Verbindungen, Zertifizierer, wichtige Gruppen wie LocalDomainAdmins, LocalDomainServers) und Domäne ersetzen (wo nötig).
3. Directory Profile anpassen mit eigenem Domänennamen
4. Directory assistance erstellen mit Verweis auf names.nsf der "Echtdomäne" (als replik auf dem Traveler oder sicherer aber mit minimal schlechterer Performance von einem Remote server)
5. directory assistance im Serverdok eintragen
6. server runterfahren
7. adressbücher austauschen (durch umbenennen)
8. notes.ini korrigieren wo nötig
9. server wieder starten

Natrlich gibt es noch das ein oder andere zu beachten, aber grundsätzlich läufts damit mal einigermassen...

[(h)uMan]

@Tode: Besten Dank für deine Ausführungen. Werde das mal in einer Testumgebung probieren ...