Who is this article for?

Administrators responsible for managing Please Review.

Server Access will be required to implement this update.

This article explains explains how to update the password for an integration where PR syncs against it and/or has the login stored for it in the server configuration. This is explained in the installation guide for the integrations so if unsure on this, the specific integration should be referred to, but the basics for all integrations are as follows:

1. Arrange a suitable time for this

This involves restarting the application pool which will log all the users out so you may need to schedule a suitable time for this change to take place, if this is not appropriate for the users of the system to be interrupted like this, at just any time.

2. Backup existing config file

Each integration config that includes a login, typically has a file for it under [Please Review folder]\Runtime\config\ with the name [Integration type]Login.xml.

For example, for Veeva Vault, the file is named VeevaVaultLogin.xml and for Documentum, it is DCTMLogin.xml. Please see the install guides for other formats if unsure which file to update.

1. Please Review folder\Runtime\config

2. Backup the config file, as a precaution.

3. Encode the password

Some integrations may work with an unencrypted password but it is best practice to encrypt the password and some integrations will only work with an encrypted password, so therefore, we should encrypt it before saving it into the configuration file. This can only be decrypted by Please Review running on the same server.

Note that if the PR instance is running in a load balanced setup, this will need to be repeated on each server, separately.

1. Launch the AdminClient.exe from [Please Review folder]\Runtime\bin as Administrator.

2. Use the Password Encoder from the System Utils drop down menu

3. Enter the password for that the user would use in the authentication system.

4. Press Encode and then copy the password. If the tick box was set to copy the password on encoding, this will already be copied

5. In the [Integration]Login.xml file, look for <password> key area and ensure the <username> is the same with what user provided. For example, it might look similar to this:
Note that some installations have more than one repository/vault/domain/etc so ensure that the correct one is being updated. If the username applies to more than one of these, be sure to update under each one. For Veeva Vault, for example, the VaultName can help with this. If the usernames are the same here, it might be worth asking if it needs updating in the other repositories/vaults/domains/etc.

6. Replace the password with the copied key (step 4) 

7.  Restart both TaraWeb and TaraService using the AdminClient. Note that you will need to to have run this as Administrator for this to work. Note that restarting TaraWeb will log all the users out so you may need to do this at a suitable time.

4. Testing update

Locked workgroup sync test

1. Login to the client Please Review site as sysadmin

2. Go to Admin > workgroup management > click on select against a locked workgroup. For Veeva, this would be a workgroup ending with PR_VaultUI,

3. On there click Members

4. Click the sync button. If the password is valid, then you should receive:

5. Note that if they have too many members for it to complete in the time allowed for a web page (the execution timeout) so this may timeout in the UI. Also with some integrations you don't have to have a locked workgroup, In either of those cases, follow these steps...

Full sync test

The other way to check would be to:

1. Login to the server

2. Go to the [Please Review folder]\Runtime\bin folder in File Explorer

3. Run AdminClient.exe

4. Expanding Queue > Periodic entries > ExternalSync

5, Select 'Run immediately' and when the clock ticks over the next minute, this will start syncing.

6. After some minutes have passed check TaraService.log to ensure it doesn't show error with that latest sync attempt, ignoring any earlier attempts that day that may have failed if the password was wrong at that time.

Note that there could be errors if the users are duplicating emails or making other such unsupported changes so to verify this we are looking to see if there is an error logging or not here. If there are other sync errors unrelated to logging in, then those should be investigated separately.