Mit dem Anfang der Woche veröffentlichten iOS 12 für iPhone und iPad gibt es Probleme bei der Traveler-Synchronisation. Diese treten ein, wenn die nativen iOS Mail, Kalender und Kontakte für die Traveler Anbindung genutzt werden und Session Authentication (entgegen IBMs Empfehlung) statt Basic Authentication genutzt wird. Die Ursache dafür ist eine veränderte Handhabung der http Autorisation ab iOS 12.

 

Welche Methode genutzt wird, lässt sich mit dem Aufrufen folgender URLs prüfen:

- https://servername/servlet/traveler

- https://servername/travelerclients

- https://servername/traveler

- https://servername/Microsoft-Server-ActiveSync

Welche URL hier funktioniert, hängt von der Konfiguration des Traveler-Servers ab. Bei uns hat letztendlich die URL https://servername/traveler funktioniert. Wenn ein Popup des Browsers mit der Aufforderung zur Authentifizierung erscheint, ist der Traveler-Server korrekt konfiguriert. Erscheint hingegen eine HTML Loginmaske, sollte die Konfiguration korrigiert werden.

 

Es gibt zwei Möglichkeiten:

  • Session Authentication im Server Dokument deaktivieren: Session Authentication wird für den gesamten Server deaktiviert
  • Override Session Authentication aktivieren: Diese Variante definiert für alle Traveler Anfragen eine Ausnahme, so dass Basic Authentication genutzt wird. Hierfür ist es notwendig, dass der Server Internet Site Dokumente nutzt. Für die vom Traveler genutzten Internet Sites muss eine Override Session Authentication Regel angelegt werden (s. Abb.1).

Abb.1

 

Weitere Informationen findet ihr hier:

- IBM Technote : https://www01.ibm.com/support/docview.wss?uid=ibm10731987&myns=swglotus&mynp=OCSSYRPW&mync=E&cm_sp=swglotus-_-OCSSYRPW-_-E

- http-Authentication: https://www.ibm.com/support/knowledgecenter/SSYRPW_9.0.1/httpauthentication.html

 

Habt ihr Fragen oder Anregungen? Ruft uns einfach an unter 05251 288160 oder schreibt uns eine E-Mail an info@itwu.de.

Vor ein paar Tagen habe ich von einem guten Bekannten einen Anruf bekommen. Dieser klang höchst erstaunt und er fragte mich ganz aufgeregt, was denn bei mir passiert wäre und ob ich einen neuen Job suche. Meine Überraschung war nicht viel kleiner als er mir erklärte, dass er doch eine Abwesenheitsbenachrichtigung bzw. Out-of-Office (OOO) von mir erhalten hätte, in der ich bis zum 31.12.2050 abwesend wäre und dass es dafür doch nur eine Erklärung geben könne.

Die Fehleranalyse war sehr einfach. Ich habe die Abwesenheitsbenachrichtigung mit der IBM Notes Traveler Companion App erstellt. Die Companion App bietet eine Option, um eine unendliche Dauer der Abwesenheit einstellen zu können. Dies erschien mir sehr praktisch weil die Dauer meiner tatsächlichen Abwesenheit noch unklar war.

 

Abb. 1: Hier schaltet man im IBM Traveler Companion die
Abwesenheitsbenachrichtigung ein

Abb. 2: Hier setzt man die Dauer der
Abwesenheitsbenachrichtigung auf unendlich

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Leider ist diese Option für den Domino Server nicht umsetzbar und so konnte man auf der tatsächlichen Abwesenheitsbenachrichtigung lesen „… and will not return until 31.12.2050“

 

Abb. 3: Die daraus resultierende Abwesenheitsbenachrichtigung

 

Um es kurz zu machen: Man sollte besser nicht den Schalter „Unendlich“ in der IBM Notes Traveler Companion App verwenden.