Since I have been here we have noticed that the design of the solution is not fit for purpose for this company, but was fit for purpose for the "other" joint head office. The solution was tested, but not tested enough and the scenarios of the varied working practices were not fully understood.
We have many scenarios, such as
- A roaming user may use one machine for 10 minutes and then move to another machine.
- One user might work on three or more computers in a single day within various buildings, or sites.
- One user may not move computer at all, or may have a dedicated laptop.
Previously, users would switch location to change id, which was working perfectly, but since we have implemented roaming, we have stopped this working practise. The company is in the retail sector, so users not working at this time of year (so close to Christmas) is a very serious matter.
The main issues are as follows...
ID Vault
- For new users, it can take up to 8 hours for the id file to get created in the ID Vault. This is a random time between 0 and 8 hours. We have users that do not login to a single machine for 8 hours and potentially the id never arrives in the vault.
- If a user changes the password on computer A and subsequently logs into computer B (that they have previously logged into), they are asked for the old password according to the id file on that machine. The login will then work, if the password is the expected password, but the user will not be able to access the servers, as the password is different in the ID Vault. The helpdesk need to find the id file from machine A and copy it to machine B. The user can then login.
- In the scenario above, if the user cannot find a last know "good" id file, then the password must be reset and the password digest is usually cleared, which then has a knock on effect in the future password changes and this solution does not actually fix the original issue of ID Vault sync.
- For some users the ID Vault is not updating with password changes, but for others, it is updated almost instantly.
- We seem to have three areas to check - The Person doc (password digest and last password change date), ID Vault (last modified date, should be the same as the person document) and then the local profile directory for id file.
We have a few further complication that might be confusing matters...
- Roaming files are not on the users home notes server, but are located on a network drive. When a user is working remotely, the network drive is not available, so the roaming files cannot be found.
- A new VB Login script is required to copy roaming files from the network into the local profile folder on the computer. Occasionally the user does not wait for this copy process to complete and will try to login into Notes, causing all sorts of issues.
- Users will sometimes close Notes and not Replicate the roaming files, back to their network folder.
- If something is not present in terms of files, the user is sometimes prompted with the blank configuration boxes. They try to complete the information, but often this leads to more problems.
We actually have IBM coming in this afternoon to try to help us iron out our issues, but I thought I would share a few facts with you all and see how your implementations have gone.
ID files of _new_ users should be in the ID vault immediately after registering them. There's an option in the registration dialog for that. It is not necessary to let the client push the ID into the vault within those 8 hours.
ReplyDeleteYour password change issue rather sounds like a digest issue than an ID vault issue. I don't think the server is checking the password that's saved in the vault.
Is there a reason not to use Domino roaming instead of your file server? Looks like this might solve your issues regarding the copying of the files.
Impressive web site, Distinguished feedback that I can tackle. Im moving forward and may apply to my current job as a pet sitter, which is very enjoyable, but I need to additional expand. Regards. Underground Cable Locating Services Gaithersburg MD
ReplyDelete