Ich hatte gerade letzte Woche eine nette kleine Servermigration mit einem Traveler-Server. Da kam das ganze Paket zusammen. Der Server sollte die Hardware wechseln. Der Domino- und Traveler-Server sollten beide auf den aktuellsten Stand gebracht werden und der externe DNS-Alias des Traveler-Servers sollte sich ändern. Alles in einem Rutsch.
Das hat ziemlich gut geklappt, wenn man davon absieht, dass der Provider den Alias nicht zum vereinbarten Zeitpunkt geändert hat, aber irgendwas ist ja immer 
.
Ich habe es mir leicht gemacht, indem ich einfach das gesamte Domino-Datenverzeichnis des Quell-Servers auf den Ziel-Server kopiert habe, um dann Domino und Traveler mit diesem Datenverzeichnis zu installieren. Dann habe ich die Updates durchgeführt. Man muss nicht das gesamte Datenverzeichnis kopieren. Statt dessen gibt es Migrationsanleitungen für Domino und worauf es beim Traveler ankommt, beschreibt Daniel Nash in seinem Blog sehr gut. Okay - es ist praktisch fast das komplette Verzeichnis - also was solls 
.
Nach der Migration konnten 70 Nutzer mit etwas mehr Geräten (100% iOS) weiterarbeiten als wäre nichts passiert. -> Operation gelungen und es war nicht einmal schwer .
Einen Unterschied zu vorher gab es aber doch. Und der hatte eigentlich nichts mit der Migration, sondern "nur" mit dem Update des Traveler zu tun. Und zwar konnte auf den Endgeräten nachher keine Adress-suche auf dem Globalen Adressbuch (GAL) bzw. Domino-Directory durchgeführt werden.
Wenn man einen Versuch durchführte, flimmerte gleichzeitig die folgende Meldung über die Domino-Konsole:
Lotus Traveler: SEVERE CN=Nutzername/OU=OU/O=Organisation [?] Error handling inbound ActiveSync message for command Search.
Eine Suche im Domino-Forum ergab auch recht bald eine Antwort.
Und zwar soll anscheinend beim Update auf Traveler 8.5.3.1 (oder später) die ntsconfig.xml Konfigurationsdatei migriert werden, um neueren Features gerecht zu werden. Das ist in diesem Fall offensichtlich nicht passiert und wie es scheint, bin ich auch nicht der Einzige, dem das nicht passiert ist.
Der verlinkte Diskussionsbeitrag schlägt vor, einfach die ntsconfig.xml zu löschen und dann den Traveler-Server einmal durchzustarten. Die Datei findet sich im Verzeichnis \Traveler\cfg relativ zum Domino-Datenverzeichnis. Sie wird mit dem Traveler-Neustart mit (funktionierenden) Standardwerten neu angelegt.
Das hat für mich funktioniert, da ich keine weiteren Anpassungen an der ntsConfig vorgenommen hatte. Andernfalls wären diese verloren gewesen.
Ich habe dann nichts weiter probiert, aber die kritischen Zeilen scheinen diese hier zu sein (Leerzeichen manuell eingefügt):
<PROPERTY NAME="nameLookupNamespace" VALUE="($Users),($MailGroups),Mail-In Databases"/>
<PROPERTY NAME="nameLookupFlags" VALUE="40"/>
<PROPERTY NAME="nameLookupItems" VALUE="LastName, FirstName, MiddleInitial, ListName, FullName, InternetAddress, $$NoteID, Type, Title, Suffix, OfficeStreetAddress, OfficeCity, OfficeState, OfficeZIP, OfficeCountry, StreetAddress, City, State, Zip, country, JobTitle, CompanyName, Department, CellPhoneNumber, PhoneNumber, OfficePhoneNumber, WebSite"/>
<PROPERTY NAME="nameLookupEmailAddressItems" VALUE="InternetAddress"/>
<PROPERTY NAME="nameLookupUniqueItems" VALUE="InternetAddress,$$NoteID"/>
Wer also eine angepasste ntsConfig hat, sollte sich die obigen Werte einmal ansehen.
Fazit: Obwohl es immer noch relativ einfach und unkompliziert ist, ein Traveler-Update durchzuführen, habe ich vielleicht in den letzten Wochen den Mund doch etwas voll genommen, wenn ich sagte, dass man immer schön seine Updates installieren sollte, weil das ohnehin in 30min erledigt sei.
Vielleicht sollte man doch etwas mehr Zeit einplanen .
