Back in November there was a discussion thread with the title “User can’t accept password recovery information” which ended without resolution. I have come to exactly the same conclusion as Steve Toft and searching technotes etc. has not produced a solution either and so I’m creating a new thread in the hopes this raises some new discussion.
I’m rolling out ID recovery and users cannot email their IDs into the mail-in database. They are receiving the password recovery information into their IDs during authentication with the server and so when they receive the ID recovery email from me it gives them the error “The recovery information could not be accepted because it is older then your current recovery information”. If they receive recovery information during authentication then they will never be able to use the menu option Actions - Accept Recovery Information.
Is anyone using 6.0.3 and not having this problem?
Subject: Older or identical to, actually…
In ND6, recovery information is added to ID files during the process of authentication, removing the need to explicitly export recovery information to users. In order to prevent them from re-accepting the same information every time that they authenticated, the check was changed from preventing the ID from accepting “old” recovery information to preventing the ID from accepting recovery information that wasn’t newer than the current recovery information. However, it appears that the error message was never updated to reflect that change.
Additionally, in ND6, the process of sending the encrypted backup to the ID repository was made silent, at the request of administrators who didn’t like having their users cancel out of the mail/send dialog box.
You might want to confirm that the users who aren’t sending out encrypted backups are allowing the Notes client to go idle. Since the process of generating and sending an encrypted backup involves authenticating to a server and a fair bit of crypto as well, the send is deferred until the Notes client has been idle for 5 minutes with no dialog or message boxes raised. In almost all of the cases that I’ve seen, the “stuck” users are never letting the client sit idle (and logged in) for long enough for the send to take place.
Hope that helps,
dave
Subject: RE: Older or identical to, actually…
I agree. However, I think the design is really bad. We’re planning on setting up the password/ID recovery system on our live Notes server. We’ve been testing it on a test server for a couple of weeks.
I’ve determined that the client not only has to be idle, but it can’t even have the users’ mail databases(or any databases for that matter) open. I left a Notes client logged in with my mail database open for an entire weekend and it never sent a backup copy of the updated user.id file. On Monday, I left a Notes client(pretty much by accident) open without any databases open. It was just at the workspace. It sent the backup copy about 1.25 minutes after logging in. I retested and confirmed this multiple times.
100% of our users open their mail databases immediately upon launching Lotus Notes and don’t close their databases until seconds before they completely close the Notes client. I would bet that most sites’ primary usage for Notes is as a mail client. Hardly anyone is going to leave the client idle at the workspace without any databases open for more than 20 seconds unless it’s by accident.
Does anyone know if there’s something that can be changed in the notes.ini file or any ini file to shorten or do away with the wait time? Any feedback would be helpful. Thanks.
Subject: RE: Older or identical to, actually…
Thanks for your feedback Dave. Indeed I’m now seeing ID’s being collected. I was wondering why some users were sending their ID’s and other were not so I guess it’s because they are not allowing the client to go idle.It’s great that the ID’s are harvested silently from the user but I agree with Joe and I can imagine most of my users will have their mail open for the whole client session. If Joe is right and no databases can be open what I’ll need to do is cross-check what users have not sent their ID’s in and follow up with them which kind of defeats the object of the silent collection. It also means that when users are renamed or recertified I cannot be confident that their updated ID is collected.
An ideal situation would be that ID collection occurs directly after authentication with the server so up-to-date ID’s are almost guaranteed to exist in the mail-in database.