Am 15. November hat IBM ein neues Update für den Traveler veröffentlicht. Die Änderungen sind vor allen Dingen für Administratoren wichtig und umfassen u.a.:
- Device Wipe ist seit iOS 10 nicht mehr verfügbar und nun auch aus Traveler entfernt
- Traveler zeigt eine Statusänderung (tell traveler status), wenn Endgeräte den Server als nicht vertrauenwürdig einstufen. Siehe dazu auch: Neue Richtlinien für IBM Traveler und TLS/SSL veröffentlicht (bis zum 01.01.2017 umzusetzen)
- Einführung eines neuen Konsolenbefehls "tablerepair"
Achten Sie beim Update darauf, eine Sicherung angelegt zu haben, da die Traveler-Datenbank ein Schema-Update erhält, das nicht durch eine einfache Deinstallation rückgängig gemacht werden kann. Bei dem Schema-Update scheint es vereinzelt(?) zu Problemen zu kommen, zu deren Lösung auch schon der neue Befehl "tablerepair" genutzt werden kann.
Achten Sie beim ersten Start nach dem Update auf Fehler in der Konsole. Wenn alles richtig läuft, sieht es dann so aus:
17.11.2016 13:20:46 Traveler: Upgrading IBM Traveler Database schema from version 20160301 to version 20160812
17.11.2016 13:20:50 Traveler: GUIDMAP has no records violating the constraint.
17.11.2016 13:20:50 Traveler: Primary key PK_GUIDMAP successfully created.
17.11.2016 13:20:50 Traveler: GUIDMAP table is repaired.
17.11.2016 13:20:50 Traveler: TS_FILTERS has no violating records.
17.11.2016 13:20:50 Traveler: Primary key PK_TSFILTERS successfully created.
17.11.2016 13:20:50 Traveler: TS_FILTERS table is repaired.
17.11.2016 13:20:50 Traveler: PUSH has no violating records.
17.11.2016 13:20:50 Traveler: Primary key PK_PUSH successfully created.
17.11.2016 13:20:50 Traveler: PUSH table is repaired.
17.11.2016 13:20:50 Traveler: REPLICAS has no violating records.
17.11.2016 13:20:50 Traveler: Primary key PK_REPLICAS successfully created.
17.11.2016 13:20:50 Traveler: REPLICAS table is repaired.Wenn hier jedoch Fehler auftreten, kann die entsprechende Tabelle mit:
tell traveler repairtable <%tablename%> *repariert werden. Aber Achtung: in diesem Fall wird für die reparierten Datensätze/Accounts ein Primesync ausgeführt. Wenn das allzu viele Nutzer betrifft, empfiehlt es sich, den obigen Befehl zu verfeinern und in kleinen Batches zu reparieren.
