If you look in the hidden view ($users) look for  that name does it resolve?    Maybe it is a corrupt view that you just need to run the updall task on.

Everything in ($users) looks fine.  I ran updall -C on names.nsf anyway.  Still no joy.  What next?

After 4 hours I figured this out, already reported it to IBM.  You can see this occurring in the log folder for traveler under the ibm support folder in the data folder.  Never knew it was there until I had to do digging for this one.

The users which were getting this error in our organization had the replicate unread marks in the mail database set to "Never".  Changed it to "All Servers" and either waited about 30-60 minutes, or ended traveler and restarted.  At that time they could register their phone.  Note, you may also need to clear the cache on the phone.  To make this easier after discovering I was using a computer exclusively to troubleshoot, they are much more forgiving!

Not sure if this is an "enhancement" or a bug.  I have requested IBM give me an answer on this, but on late Friday afternoon their Traveler developers were "on an outing".  I hope to here back on Monday.  This is an issue exclusive to 9.01.

Personally I hate the default value of never for this setting, but I know we have many like that.  Back in the early days we did not modify the mail template and new users got the never value.

Here I was spending all that time trying to figure out what was wrong with the person doc in the address book, and it was a completely unrelated db setting.  I saw your posting and decided it was just crazy enough to be possible, so much so that I remoted in over the weekend and tried it.  Thank you.  This is where I tell you I owe you a beer or something.  In all seriousness, thank you, I really appreciate the info.

Thanks to Lance, I'm figured out too by setting to replicate the unread marks on all servers, there's another beer here.

I suggest to IBM to be more clear on error messages, the error "The IBM notes traveler server cannot resolve your user id CN=John Doe/0=Mycompany to a mail database"

is not very clear and is suggesting to look at the NAB or LDAP.

Maybe IBM will give us a 20% discount on our passport for figuring this out while their development was "on an outing"?

We actually came acrooss this problem before, only with different symptomps and error messages but basically the same problem and was fixed on the latest hotfix of Traveler 901:  APAR: LO77846 - User synch fails with "Traveler access rights.". The workaround that was published in this APAR was basically the same thing that you have done only on the notes.ini parameter: NTS_BACKENDMANAGER_SET_UNREAD_REPLICATION=true. The user should
be able synch with in 4 hours or Tell Traveler User <userId>
would refresh the cache or a restart of Notes Traveler.