Hi All,
Trying to take advantage of the new ID Vault features, and am having some trouble…
Any newly registered user has a copy of their ID file made in the ID Vault database, that works fine.
The problem is when I attempt to configure the client, it ALWAYS asks to browse for the ID file, and doesn’t ever get it from the vault.
All other feature of the vault work fine. I can delete the ID, and it gets recovered. I can change passwords, works great.
Any ideas?
Thanks in advance!
Subject: Update
I’m still having the same problem, but I’m adding something new…
I created several test accounts to reproduce the reported problem, and received this strange error while trying to delete the accounts. Note that I deleted these accounts one at a time, and selected the option to have the ID file removed from the ID Vault at the time of deletion.
Delete from ID vault cannot be done for user ‘CN=Charles Darwin/O=TSI’. Reason: Server error: File does not exist. The Administration Process will handle the completion of this request.
So, the server thinks it can’t find the ID file, which appears to be the same reason why it won’t grab from the ID from the vault during first time client setup. This is strange because it finds the ID fine for the user if I delete the user’s ID file after client is already setup, I can also reset the users password and the changes are pushed to the client.
Anybody?
Subject: Delete from ID vault cannot be done for user
The error message “Delete from ID vault cannot be done for user…” is cause by the Idvault database filename containing a space. The issue has been reported under SPR# RCAA7QWV55
Subject: Follow up question
Any newly registered user has a copy of their ID file made in the ID Vault database, that works fine. The problem is when I attempt to configure the client, it ALWAYS asks to browse for the ID file, and doesn’t ever get it from the vault.
Hi!
Can you give me a more detailed steps of what happens in the scenario when you have a problem?
Is this what you do?
Register a brand new user
Install a new client installation
Start the newly installed client which starts the configuration and then prompts to browse for ID file?
Can you verify or correct the steps to reproduce the problematic scenario?
Subject: Follow-up response
Hi Julie,
You’re spot on with the steps taken to produce the problem.
Create a new user account, verifying that the ID file was copied to the ID Vault during creation.
Tested the following clients, all with the same result: 8.0.2 basic and standard, 8.5 basic and standard.
Test were both on brand new installs and client reconfigurations (clearing notes.ini)
The problem is 100% reproducible.
Notes:
Will not prompt for user id if id was saved to Domino directory.
Client installs and functions as it should if I specify the id file.
Once installed, the other ID Vault features work as they should…(changing password, ID recovery)
Help!
Subject: Thank you for additional input!
For the client install issue, can you also check for any errors in the log.nsf on the client and the server (in the security section)? I take it there is no error displayed on the client, but there might be one logged.
Before doing the install, did you open the ID vault database and verified that in fact that user’s id is in fact in the vault?
I just got a note from our QE team that this scenario is working for them, and they asked a couple all of follow-up questions to see what might be different in your situation:
Is the user’s home server (mail server) available (up & running) at the time of the setup.
Has the user registration information replicated to the user’s home server?
Is the vault server available (up & running) at the time of the setup.
Which type of client setup is being attempted, e.g. is this a roaming user setup or regular notes setup.
Is the home server, referenced by name or IP address in the setup.
Subject: Enter the IP address into the servernames field.
I had exactly the same issues and after I entered the IP address into the servername field, everything worked well.
Look here: http://www.domblog.de/domblog.nsf/d6plinks/TLAG-7Q3LL7