IBM Traveler 9.0.1 on Android - "Invalid Password" Fix

Bill Malchisky  December 5 2013 01:00:00 AM

I upgraded a customer site from Domino on Linux 8.5.3 to 8.5.3 FP3 HF210 so they could upgrade Traveler, which is now running at version "Lotus Notes Traveler 8.5.3.200 Build 201307170759", all on Linux. The upgrades went smooth and they are happy, as they can now start planning the upgrade to Domino 9.0.1 and give the users some additional benefits with mobile mail while IT gets the plan in-place. Everything looked great, so we upgraded the Traveler client version on a few mobile phones starting with Android. Google Play Store had the 9.0.1 client which supports the upgraded Traveler version on the server. It was all going so smooth, until...

"Invalid Password" received after setting up the Traveler client. This seemed odd. Verified the correct password was entered. Same thing. Did some research and learned that this error was loosely correlated to APAR LO72379 with a fix for the supported setup implemented. Since my error was close but not a precise match, the upgrade provided some confidence. In a sense, it is mostly fixed in my estimation. The error occurs before the client talks to the server -- the message is displayed instantaneously after entering the password; nothing appears in the Traveler logs; and the error did not appear on newer devices.


Steps to Solve
WARNING: What I did worked on the affected smartphones without data loss, but may or may not work on your particular Android version; thus backup your data first.

Solution- deactivate the Android Administrator security for IBM Traveler, accept the warning for erasing all your data (see warning above); then reactivate IBM Traveler from the same screen. Close the screen and Enter the Calendar now, fill-in the prompts and proceed. Worked perfectly; mail, calendar, and ToDos all synchronized sans issue. Quite counter-intuitive, I realize. And I did not cause a factory data reset or lose any data either.


Summary
From additional testing afterwards, it appears that the security settings were stuck, preventing acceptance of the enhanced password requirements from the newly acquired Traveler security settings profile document. The combination of the simultaneous policy and client upgrade appeared to cause the lock-out, ultimately killing the new client's ability to process the password correctly with the new password security settings.


Update: With Traveler 8.5.3 UP2 IF5 being released on 20 November, the customer upgraded the back-end to stay current, but the UP2 IF5 released fix appeared after the previous upgrade and was not tested for this article.

• Comments [0]