Page Comparison

...

The following example shows how to change a user’s password with a PATCH method. The password has to be in plain format. The effect of the change take place immediately after a successful PATCH update request.

PATCH https://VFC_MR_DOMAIN/verba/restapi/v1/users/16
Content-Type: application/json

{
  "password": "new plain password"
}

...

The following example shows how to change the login name and the password for an LDAP server in the same request. The password has to be in plain format. The effect of the change take place immediately after a successful PATCH update request.

Request

PATCH https://VFC_MR_DOMAIN/verba/restapi/v1/adSyncProfiles/13F72189-2EEB-425F-885B-7D1BBA83DDEB
Content-Type: application/json
Accept: application/json

{
  "userName": "john.doe",
  "ldapPassword": "new plain password"
}

...

The following example shows how to change credentials for an Amazon S3 storage target in the same request. The password has to be in plain format. The effect of the change take place immediately after a successful PATCH update request.

Request

PATCH https://VFC_MR_DOMAIN/verba/restapi/v1/storageTargets/11
Content-Type: application/json
Accept: application/json

{
  "accessKeyId": "amazons3_storage_keyid",
  "secretAccessKey": "new plain password"
}

...

The following example shows how to change credentials for an Zoom Phones import source in one request. The password has to be in plain format. The effect of the change take place immediately after a successful PATCH update request.

Request

PATCH https://VFC_MR_DOMAIN/verba/restapi/v1/importSources/1 
Content-Type: application/json
Accept: application/json

{
  "apiKey": "zoom_api_key",
  "apiSecret": "new plain password"
}

...

POST https://VFC_MR_DOMAIN/verba/restapi/v1/importSources/1/password/verify
Content-Type: application/json
Accept: application/json

{
  "property": "apiSecret",
  "value": "new plain password"
}

Server Configuration

A VFC deployment usually contains multiple servers with different server roles. There are two strategies to maintain the configurations of these servers.

Approach A: Change the configurations individually by every server. The solution is not recommended for deployments with multiple servers within.

Approach B: Organize the common server configurations to Configuration Profiles by server roles. This approach allows to maintain the common configurations in on location. The solution is recommended for deployments with multiple servers within.

To read more about the topic visit the next page: Server and service configuration.

The server configurations are stored in two location in the system: in a central database that allows to manage and review them via the user interface; and in every server’s registry that allows the local services to read them. A server configuration change in both approach require the following steps:

Step 1: Change the configurations in the central database. The changes don’t have a direct effect on the behavior of services after this change.

Step 2: After the change there can be a differences between the values in the central database and the registry values on certain servers. The differences has to be resolved for every affected server configuration key by configuration key to decide which value should be pushed to the actual server registry. During the resolution process configuration tasks have been created by the system for every affected server. These tasks contains actions for the affected services on the related server. After the configurations have been modified in the server’s registry, the services are needed to be notified about the configuration change to reread them.

Step 3: When the configuration tasks have been created for every server, these tasks have to be applied. The configuration tasks have to been applied for each servers. After applying the new configuration values has been pushed to the local registry and the services reread the new values and started to work based on the new values.