I'm having a problem with how Blackberry devices handle user renames in our large BES 4.1.6/Domino 7 environment. Here's the scenario:

1. Notes users with BBs add internal recipients to their personal Notes NABs. (We wish they wouldn't, but they do, partly so they can add additional contact data.)

2. Those personal NABs are synced with thee BB contacts. This works fine.

3. Because of user renames and organizational moves, Notes users are frequently renamed through the administration process. This works fine in the Notes environment. The user's old name is added as a synonym in the Full Name field in the person doc, so even if another user addresses a message to a "stale" personal NAB entry, Domino can deliver the message to the correct recipient.

4. When a BB user who has the "stale" user name in their BB contacts tries to send to that user, the message fails, as the handheld cannot find that user in the directory.

I have searched these forums and the Technical Solutions Center without success. Doesn't anyone have suggestions or experience to share?

Rupert Clayton
Chicago

It's a simple thing right? Just ask the user to delete the contact and perform a new lookup. Once found, re-add. That's all. What AdminP can't reach, it will be human intervention - as simple as that.

Or best, send an advice to all BB usrs that in order to get the up-to-date information of contacts from the Domino Directory, do not add the contacts to the BB's address book after a lookup. Everytime they want to send an email, just do a lookup. Keep things simple, works better.

Thanks for the suggestions on how to handle the human side of this process. Yes, I do think we'll have to engage in some user education.

I guess I was hoping for some great technical hack that would automatically translate outdated mail addresses.

The impact is less minor than it might appear. Imagine we're planning to move executives into a new OU. Messages failing to reach the CEO causes lots of finger pointing however much user education you engage it up front!

Thanks,

Rupert Clayton