Provisioning VMRs from Active Directory via LDAP

Pexip Infinity Virtual Meeting Rooms can be bulk-provisioned from directory information contained in a Windows Active Directory LDAP server, or any other LDAP-accessible database.

This means, for example, that you can automatically provide a personal VMR for every employee in an organization. Data such as employee names can be imported from the directory and used to generate a unique name and alias for each VMR, following a pattern such as meet.<username>@example.com. Other VMR settings such as PIN numbers, the layout and theme can also be assigned, depending upon your VMR template configuration.

Each VMR template can be configured to automatically synchronize against its LDAP sync source once per day. This ensures that the Pexip Infinity VMR configuration stays in step with all additions and removals that have occurred in the source directory. Many of the VMR settings can be tagged as "overridable" which means that if that setting (the PIN number for example) is manually overridden after the VMR has been created, a subsequent resynchronization will not reset it back to another value.

Configuration summary

To provision your Virtual Meeting Rooms from an LDAP database you must:

1. Configure the connection details of an LDAP data source. You must also ensure that Pexip Infinity has trusted CA certificates for the authority that signed the LDAP server’s certificate (if a TLS connection is required).

2. Configure a VMR synchronization template that controls how the VMR settings such as its name, dialable alias and PIN numbers are generated, which of those values can be manually overridden, and whether to synchronize automatically against the LDAP data source.

   If required, you can configure multiple synchronization templates that use the same LDAP data source (or different templates that use different LDAP sources).

3. Generate the VMRs using your template and LDAP data source. Set the template to sync automatically when you are happy that the template is configured correctly.

These configuration steps are described in more detail in the following sections.

In addition, you can also:

• View the status of ongoing or completed VMR template synchronization processes via Status > VMR sync status.
• Delete all of the VMRs that have been created from a specific template.

Configuring an LDAP data source

To configure Pexip Infinity with the connection details of an LDAP data source, such as a Windows Active Directory LDAP server:

1. Go to Utilities > LDAP sync sources.

2. Select Add LDAP sync source, and then complete the following fields:

   Option	Description
   Name	The name used to identify this LDAP sync source.
   Description	An optional description of the sync source.
   LDAP server address	The domain name (for DNS SRV lookup), FQDN (for DNS A/AAAA lookup) or IP address of the LDAP server. If using a domain or an FQDN, ensure that it is resolvable over DNS. You must also ensure that Pexip Infinity has trusted CA certificates for the authority that signed the LDAP server’s certificate (if a TLS connection is required). We strongly recommend that you do not use an IP address. If an IP address is used, and a TLS connection is required, this will only work if the IP address is specified as the common name in the LDAP server's certificate. See Troubleshooting LDAP server connections for more information about how the system establishes a connection to the LDAP server and how to troubleshoot connection issues.
   Search global catalog	Select this option to expand the scope of the search to the entire Active Directory Global Catalog instead of traditional LDAP.
   Allow insecure transport	By default the system will attempt to establish a secure TLS connection with the LDAP server. Select this option if you want to allow the system to fall back to a TCP connection (using SASL DIGEST-MD5). You cannot specify the LDAP server by IP address if this option is selected.
   LDAP bind username and password	The username and password of the bind account on the LDAP server. This should be a domain user service account, not the Administrator account.
   LDAP base DN	The base DN (distinguished name) of the LDAP forest to query (e.g. dc=example,dc=com).

3. Select Save.

   You can save the sync source details only if Pexip Infinity can successfully contact the specified LDAP server.

Note that all LDAP distinguished names must be entered as per the LDAP standard (RFC 4514). LDAP configuration is case insensitive.

Configuring a VMR synchronization template

VMR synchronization templates control how the VMR settings such as its name, dialable alias and PIN numbers are generated. You must also tell the template which LDAP data source to use.

To configure Pexip Infinity with a VMR synchronization template:

1. Go to Utilities > VMR sync templates.

2. Select Add VMR sync template, and then complete the following fields:

   Option	Description
   Name	The name used to identify this synchronization template.
   Description	An optional description of the synchronization template.
   LDAP user search DN	The DN relative to the LDAP base DN of the sync source to query for user records (e.g. ou=people). If blank, the LDAP base DN is used. In deployments with large user bases, you may want to configure this to optimize the LDAP user queries.
   LDAP user filter	The LDAP filter used to match user records in the directory. Default: (&(objectclass=person)(!(objectclass=computer))) For more information, see LDAP search and filter examples.
   LDAP sync source	Select the LDAP data source to use when syncing records. Note that you can select which will open a new window from where you can configure a new sync source.
   Enable automatic daily sync	Select this option to instruct Pexip Infinity to automatically synchronize this template against its LDAP sync source once per day. This ensures that VMRs are regularly updated, deleted or created as appropriate based on the latest data in the sync source. Therefore, for example, if a user is removed from Active Directory or their account is disabled, their corresponding VMR will be deleted via the next daily sync. All automatic synchronizations are initiated at 01:00 UTC (this start time cannot be configured). As template synchronization can result in the automatic creation, modification or deletion of large numbers of VMRs, we recommend that you only enable automatic syncing after you have manually synced at least once and have verified that you are satisfied with your sync template configuration.
   VMR settings
   VMR name pattern	The pattern to use to generate the name of the VMR. You should structure this pattern to generate a unique VMR name. For more information, see Using patterns to format the VMR properties (name, alias etc). Example: {{givenName}} {{sn}} VMR If a VMR with the generated name already exists, that existing VMR configuration will be overwritten with the data generated from this template.
   VMR description pattern	The pattern to use to generate the VMR description. This field is optional. Example: {{givenName}} {{sn}}'s meeting room
   Allow VMR description to be manually overridden	Allows the auto-generated VMR description to be manually overridden for each VMR.
   Host PIN pattern	The pattern to use to generate the Host PIN (if required). Example: {{ [9,pex_random_pin(5)]|join }} (sets the PIN to a random 6 digit number starting with a 9) In this example you would probably also select Allow PIN settings to be manually overridden to stop the PIN being changed to another random value after every template resync.
   Allow Guests	Yes: the conference will have two types of participants, Hosts and Guests. You must configure a Host PIN to be used by the Hosts. You can optionally configure a Guest PIN; if you do not configure a Guest PIN, Guests can join without a PIN, but the meeting will not start until the first Host has joined. No: all participants will have Host privileges. Default: No.
   Guest PIN pattern	The pattern to use to generate the Guest PIN (if required). Example: {{ [2,pex_random_pin(5)]|join }} (sets the PIN to a random 6 digit number starting with a 2) Note that if you set a Host PIN and a Guest PIN for a VMR, those two PINs must be different. Therefore we recommend that you generate Host and Guest PINs of different lengths, or ensure that some aspect of each PIN will be different (as shown in the examples).
   Allow PIN settings to be manually overridden	Allows the auto-generated Host and Guest PIN settings to be manually overridden for each VMR. Note that this would also preserve the generated PIN value, even if it does not actually get manually overridden.
   View (layout)	The maximum number of other participants that each participant will see, and the layout used to show them. For more information, see Selecting the layout seen by participants. Default: Large main speaker and up to 7 other participants (1+7 layout).
   Allow host layout to be manually overridden	Allows the host layout to be manually overridden for each VMR.
   Theme	The theme for use with this Virtual Meeting Room. For more information, see Customizing images and voice prompts using themes. Default: <use Default theme> (the global default theme will be used).
   Allow theme to be manually overridden	Allows the auto-generated theme to be manually overridden for each VMR.
   VMR alias 1 pattern	The pattern to use to generate the alias (string) that participants can dial to join this VMR. You should structure this pattern to generate a unique alias for the VMR. Example: meet.{{givenName|lower}}.{{sn|lower}}@example.com or meet.{{mail}} If the generated alias is already assigned to another VMR, that alias will be reassigned to the VMR currently being created/updated from this template.
   Alias 1 description pattern	The pattern to use to generate a description of the alias. This field is optional. Example: {{givenName|lower}}'s full URI
   VMR alias 2...4 pattern and descriptions	You can enter optionally enter patterns for a further 3 alternative aliases, such as an E.164 alias, to associate with this VMR. Note: do not use the pex_random_pin() filter to generate numeric aliases as this is likely to generate duplicate aliases. Where possible, it is best to use a phone number, employee ID or other typically unique value as the basis of a numeric alias. If a unique value does not exist, a good fallback is to use a pex_hash() expression such as the following to generate a consistent 6-digit random E164-type alias from a hash of each user's email address: {{ ("my alias passphrase"+(mail|pex_reverse))|pex_hash|pex_tail(6) }}
   Advanced options
   Maximum inbound call bandwidth (kbps)	Enter a value in this field to limit the bandwidth of media being received by Pexip Infinity from each individual participant dialed in to this Virtual Meeting Room. For more information see Restricting call bandwidth.
   Maximum outbound call bandwidth (kbps)	Enter a value in this field to limit the bandwidth of media being sent from Pexip Infinity to each individual participant dialed in to this Virtual Meeting Room. For more information see Restricting call bandwidth.
   Allow maximum bandwidth settings to be manually overridden	Allows the auto-generated maximum inbound call bandwidth and outbound call bandwidth to be manually overridden for each VMR.
   Participant limit	This optional field allows you to limit the number of participants allowed to join this Virtual Meeting Room. For more information see Limiting the number of participants.
   Allow participant limit to be manually overridden	Allows the auto-generated participant limit to be manually overridden for each VMR.
   Service tag pattern	This optional field allows you to assign a unique identifier to this service, which you can then use to track use of the service. For more information, see Tracking usage with a service tag.
   Allow service tag to be manually overridden	Allows the auto-generated service tag to be manually overridden for each VMR.

3. Select Save.

   You must save the template before you can use it to generate VMRs.

Allowing generated fields to be manually overridden

Many of the VMR settings can be tagged as "overridable" which means that if that setting is manually overridden after the VMR has been created, a subsequent resynchronization of that template will not reset it back to another value.

For example, you could configure the template with Allow PIN settings to be manually overridden selected. Then, after generating a VMR with a random Host PIN, the administrator could manually change the PIN to another specific value. This "overridable" setting ensures that the new value is protected and is not reset to another random value when that template is next used to synchronize the VMRs.

To make a field modifiable via the template again, you must clear the relevant Allow <field> to be manually overridden template setting and then re-sync with that template. Note that a VMR setting tagged as overridable via one template could still be modified by a different template.

LDAP search and filter examples

You can configure multiple synchronization templates that all use the same LDAP data source (or different LDAP sources, if required), but that apply different filters to that LDAP source. This means that you could apply different VMR configuration patterns based on different LDAP organizational groups. For example, you could configure the VMRs for all members of the European sales team to have a Guest PIN and a different theme to those VMRs generated for the American accounting department.

If you want to apply different VMR patterns to different types of users, you can use the LDAP user search DN and LDAP user filter template fields to filter the records from the LDAP sync source that are used to generate VMRs via that template.

This section contains some examples that you could use in a Windows Active Directory environment. Note that all LDAP user search and user filter contents are not case sensitive.

Filtering based on group membership

To import users that belong to a specific group, you can filter on the memberOf AD attribute. For example, to only import users who are members of the cn=sales,ou=groups,dc=example,dc=com group, you would set the LDAP user filter on your template to:
(&(objectCategory=person)(objectClass=user) (memberOf=cn=sales,ou=groups,dc=example,dc=com))

You could then configure a second template for the accounting department that uses the same LDAP sync source but with the LDAP user filter set to:
(&(objectCategory=person)(objectClass=user) (memberOf=cn=accounting,ou=groups,dc=example,dc=com))

To only import users who are not a member of the sales group, you would set the LDAP user filter to:
(&(objectCategory=person)(objectClass=user) (!(memberOf=cn=sales,ou=groups,dc=example,dc=com)))

Filtering by LDAP field names

To import only those users who have an email address, you can set the LDAP user filter to:
mail=*

To import all users except for some named individuals, you could use the following LDAP user filter model:
(&(objectCategory=person)(objectClass=user) (!(cn=Alice Parkes))(!(cn=Bob Lee))(!(cn=Carol Jones)))

Filtering by organizational unit (e.g. region/country)

To import users that are located in a specific organizational unit such as a region or country, you can restrict the user search to the appropriate 'ou' objects. For example, to only import users who are based in 'Europe', you would set the LDAP user search DN to:
ou=europe,ou=people
(this is the DN relative to the base DN defined in the LDAP sync source)

More information on Active Directory LDAP filtering can be found at http://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx.

Using patterns to format the VMR properties (name, alias etc)

When you configure a VMR synchronization template, you define patterns for how some of the VMR properties — such as its name and the aliases — are generated from the data in the LDAP sync source.

Pexip Infinity's pattern formats are based on a subset of the jinja2 templating language (http://jinja.pocoo.org/docs/dev/).

These patterns are made up of the following elements:

• literal text, such as prefixing every name with meet.
• variables that are substituted with values from the LDAP sync source, such as givenName
• filters that can manipulate text or modify the content of variables or text strings, such as join or lower
• delimiters such as {{...}} and pipes | which are used to enclose variables and define filter expressions
• jinja statements and control structures (see http://jinja.pocoo.org/docs/dev/templates/#list-of-control-structures)

An example pattern would be meet.{{givenName|lower}}.{{sn|lower}}. This concatenates the literal text meet. with the content of the givenName variable that has been converted to lower case by the lower filter. This is then concatenated with a period . and then the sn (surname) variable, also piped through the lower filter.

Therefore if Alice Parkes had an entry in the LDAP directory with givenName=Alice and sn=Parkes, the example pattern above would produce meet.alice.parkes.

The following sections provide more information about the supported variables and filters, and how to format expressions.

Supported variables

When syncing each VMR, Pexip Infinity extracts LDAP fields from each user entry in the LDAP data source and makes them available as variables (with the same name) for use in the template. Pexip Infinity offers several standard fields, and administrators can also add their own custom set of fields.

When using variables:

• You must enclose the variable name within {{...}} delimiters, for example {{givenName}}.
• Any combination of the variables can be used in any VMR synchronization template pattern field.
• Fields that are not present in the LDAP source will appear as "None".
• Capitalization of the variable name is important. The variable must be spelled exactly as shown below.

Standard LDAP fields

Pexip Infinity automatically extracts and makes available the following standard LDAP fields:

Variable name	Description
company	Company/organization name
department	Department name
displayName	User's preferred display name
dn	Distinguished name
employeeID *	Employee reference number
givenName	First name
mail	Email address
mailNickname *	Typically used to store an alternative email address (e.g. based on a maiden name); see Change of name below
mobile	Mobile phone number
objectGUID	Globally unique identifier for the directory object (user entry)
sAMAccountName	Logon name (domainname\username format)
sn	Last name or surname
telephoneNumber	Telephone number
title	Job title
userPrincipalName	Logon name (username@domainname format)
* not present in all AD schemas

Custom LDAP fields

In addition to the standard set of fields made available automatically by Pexip Infinity, administrators can configure their own custom set of fields to support additional attributes in their LDAP/AD schemas.

To add a custom LDAP field:

1. Go to Utilities > LDAP sync fields.

2. Select Add LDAP sync field, and then complete the following fields:

   LDAP field name	The name of LDAP field to be read from the LDAP server. The name is case sensitive. If the name does not match exactly against a field in the LDAP data source its value will appear (when used in a template) as "None".
   Template variable name	The name of the variable to use in VMR sync templates that will contain the value of the LDAP field. We recommend that you set this name to something similar to the LDAP field name, but note that this name cannot contain hyphens.
   Description	An optional description of the LDAP attribute.
   Is binary (advanced options)	In advanced scenarios, some binary LDAP fields such as GUIDs require special encoding. In such cases, expand the advanced options and select Is binary. Do not select this option for ordinary textual or numeric LDAP fields.

3. Select Save.

   The Template variable name that represents the custom LDAP field can now be used in a template along with the standard LDAP fields.

Change of name

A typical scenario encountered by IT administrators is when someone changes their name (e.g. after getting married) and wants to preserve their original contact address alongside their new contact details.

One way in which you could support this in Pexip Infinity is by defining multiple VMR alias patterns in your template. This example approach assumes that the LDAP mail field holds the user's contact address, and a mailNickname field is used to hold an alternative address. Thus, you could define the following patterns:

VMR alias 1 pattern:	meet.{{mail}}
VMR alias 2 pattern:	{%if mailNickname %}{#Add alias based on user's maiden name mailNickname#}meet.{{mailNickname}}{% else %}{#intentionally leave the alias blank#}{% endif %}

For most users, this will generate a single VMR alias in the format meet.<email address>, and the VMR's second alias will remain blank as the LDAP mailNickname field for those users will be empty.

For example, user Ann Jones has her LDAP mail field set to ann.jones@example.com and her LDAP mailNickname field is blank. Her VMR will have a single alias of meet.ann.jones@example.com.

When a user changes their name, the administrator would update the user's LDAP mail field to match their new name and populate the mailNickname field with the previous value of the mail field.

Now, the next time the administrator performs a template synchronization, the user's VMR aliases will be updated. The first alias will be changed to a new string based on the user's new email address, and a second alias will also be generated based upon the mailNickname field. This means that the user can be contacted via either their previous VMR alias or the new alias.

In our example, let's assume that Ann Jones changes her name to Ann Smith. The administrator changes her LDAP mail field to ann.smith@example.com and sets her LDAP mailNickname field to ann.jones@example.com. Her VMR will now have two aliases: meet.ann.smith@example.com and meet.ann.jones@example.com.

Supported filters

Pexip Infinity supports a subset of filters from the jinja2 templating language. Any jinja filters that are not listed below have been disabled in Pexip Infinity. See http://jinja.pocoo.org/docs/dev/templates/#filters for more information about these filters.

abs	float	last	striptags
capitalize	format	lower	trim
default	int	replace	truncate
first	join	round	upper

To use a filter you would typically follow the syntax {{<source_value>|<filter_name>}}.

In most cases the <source_value> is likely to be a variable, for example {{givenName|upper}}, although it could be one or more literal values, for example {{ [1, 2, 3, 4]|join }}.

Some filters take parameters, for example {{sn|truncate(5)}}. You can also use multiple filters in the same expression, for example {{sn|truncate(5)|upper}}.

The replace filter is often used. This replaces one string with another string. The first argument of the filter is the substring that should be replaced, the second is the replacement string. If the optional third argument count is given, only the first count occurrences are replaced.

Example usage: {{ department|replace("Personnel", "HR") }}

If the department field contained "Personnel Department Personnel", this would be converted to "HR Department HR".

Example usage: {{ department|replace("Personnel", "HR", 1) }}

In this case a count of 1 is specified, thus if the department field contained "Personnel Department Personnel", it would be converted to "HR Department Personnel".

For more complicated search and replace patterns, use the custom Pexip pex_regex_replace filter described below.

Custom Pexip filters

In addition to the jinja filters, Pexip also provides the following custom filters:

pex_regex_replace('find_regex', 'replace_string')

This performs a regex find and replace.

Example usage: {{ givenName|pex_regex_replace('(e|o)', 'i') }}

This example replaces occurrences of 'e' or 'o' with 'i' in the givenName variable.

See Regular expression (regex) reference for information about writing regular expressions.

pex_reverse

This reverses the characters in the input field.

Example usage: {{ givenName|pex_reverse|lower }}

In this example, if givenName is 'Alice', this expression would return 'ecila'.

pex_clean_phone_number

This extracts only +0123456789 characters (and removes ()&%#@|"':;, A-Z,a-z etc).

Example usage: {{ telephoneNumber|pex_clean_phone_number }}

In this example, if telephoneNumber is '+44 (20) 12345678', this expression would return '+442012345678'.

pex_strlen

This returns the length of string.

Example usage: {%set a = telephoneNumber|pex_clean_phone_number|pex_head(8)%}{%set b = mobile|pex_clean_phone_number|pex_head(8)%}{%if a|pex_strlen== 8%}{{a}}{%else%}{{b}}{%endif%}

In this example, the expression returns the value of the telephoneNumber field if it is present and at least 8 characters long after cleaning and truncation, otherwise it returns the value of the mobile field that has been cleaned and truncated to at most 8 characters.

Example usage: {%if telephoneNumber|pex_strlen == 5 %}{#return user's phone number#}{{telephoneNumber|pex_clean_phone_number}}{% else %}{#intentionally leave blank#}{% endif %}

In this example, the expression returns a cleaned value of the telephoneNumber field if it is 5 characters long, otherwise it returns an empty string.

pex_require_min_length(length)

You can use this filter to control if VMRs are created or not, based on the length of a string or variable.

For example, you could set the VMR description pattern as {{ mail|pex_require_min_length(1) }}. This means that the VMR will not be created if the mail variable is empty. (When subsequently syncing, the VMR would be deleted if the condition is not met.)

Example usage: {{ telephoneNumber|pex_require_min_length(4) }}

This example ensures that a VMR is created only if telephoneNumber is at least 4 characters long.

pex_random_pin(length)

Generates a random PIN of the given length. Note that this filter does not take any input.

Example usage: {{ [9,pex_random_pin(5)]|join }} for the host PIN, and {{ [2,pex_random_pin(5)]|join }} for the guest PIN.

A usage pattern such as this (where the host PIN starts with a 9, and the guest PIN starts with a 2) ensures that a VMR can never be configured with a host PIN that is the same as the guest PIN.

You would typically use this filter in conjunction with the Allow PIN settings to be manually overridden option to ensure that the PIN is not reset every time a template resync is performed.

Do not use pex_random_pin() to generate aliases. This filter generates a truly random number, with each number generated independently of any previous output. Therefore, with many thousands of users, a 5 digit numeric alias (e.g. pex_random_pin(5) ) is statistically quite likely to clash with a random alias generated using pex_random_pin(5) for another user. With 10,001 or more users and a 4 digit random alias, a clash is guaranteed (with multiple clashes being likely).

pex_uuid4()

This generates a uuid (universally unique identifier). Note that this filter does not take any input.

Example usage: {{ pex_uuid4() }}

In a similar manner to the pex_random_pin filter, you would typically use this in conjunction with the appropriate Allow <field> to be manually overridden template setting, to ensure that after a uuid has been assigned to a field, another different uuid is not assigned every time a template resync is performed.

pex_hash

Performs a hash of a field. You could use this, for example, to generate random-looking PINs based on a hash of one or more fields from the directory (you would also need to apply another filter such as pex_tail to set the PIN to an appropriate valid length).

Example usage: {{ sAMAccountName|pex_hash|pex_tail(6) }}

pex_head(maxlength):

Returns, at most, the first maxlength characters from the input field.

Example usage: {{ givenName|pex_head(4) }}

In this example, for a givenName of 'Alice' this expression would return 'Alic', and a givenName of 'Bob' would return 'Bob'.

pex_tail(maxlength):

Returns, at most, the last maxlength characters from the input field.

Example usage: {{ telephoneNumber|pex_tail(4) }}

In this example, if telephoneNumber is '+44 (20) 12345678', this expression would return '5678'.

Generating / syncing VMRs with LDAP

After you have configured a sync source and a template you can generate your VMRs for the first time, or you can synchronize them to any changes that have occurred in the LDAP database since the last time the VMRs were updated.

When synchronizing a template:

• Pexip Infinity checks all of the VMRs previously created by that template and it updates, deletes or creates new VMRs as appropriate based on the current data in the sync source. Therefore, for example, if a user is removed from Active Directory or their account is disabled, then their corresponding VMR will be deleted.
• If a generated VMR name already exists (either created manually or via a different template), that existing VMR will be updated with the new settings generated from the template.
• If a generated alias for a VMR is already assigned to another VMR, that alias will be reassigned to the VMR currently being created/updated.

Any configuration changes made to Virtual Meeting Rooms are replicated to all Conferencing Nodes within 60 seconds and applied to any subsequent conferences in that Virtual Meeting Room. If there are any conferences already in place that use the Virtual Meeting Room, any attempts to join it after the configuration has been replicated may be affected by the new configuration settings.

The template synchronization process can take several minutes if you have a large number of VMRs. Therefore you must wait for 60 seconds after the entire synchronization process has completed to ensure that all synced data has been replicated to all Conferencing Nodes.

For these reasons, we do not recommend changing Virtual Meeting Room configuration while a conference is in progress as this may lead to an inconsistent user experience.

Automatic synchronization

To automatically synchronize a template on a daily basis:

1. Go to Utilities > VMR sync templates.
2. Select the template you want to use (to open the Change VMR sync template page).
3. Select Enable automatic daily sync.
4. Select Save.

All automatic synchronizations are initiated at 01:00 UTC (this start time cannot be configured).

As template synchronization can result in the automatic creation, modification or deletion of large numbers of VMRs, we recommend that you only enable automatic syncing after you have manually synced at least once and have verified that you are satisfied with your sync template configuration.

Manual synchronization

To manually generate (for the first time) or synchronize the VMRs in Pexip Infinity with the LDAP data source:

1. Go to Utilities > VMR sync templates.

2. Select the template you want to use (to open the Change VMR sync template page).

3. Scroll down to the bottom of the page and select Sync VMRs now.

4. A status page is displayed which shows the progress of the synchronization.

   You can safely navigate away from this page without affecting the synchronization.

5. For large imports that take a long time to complete, you can monitor the ongoing status of the import at any time via Status > VMR sync status.

Alternatively, you can sync one or more templates by going to Utilities > VMR sync templates, selecting the check box next to the templates that you want to use, and then from the Action drop-down menu, select Sync selected VMR sync templates and then select Go.

Deleting all VMRs associated with a template

You can easily delete all of the VMRs that have been created from a specific template, for example if you have incorrectly specified the template's LDAP user filter.

To delete all VMRS associated with a synchronization template:

1. Go to Utilities > VMR sync templates.
2. Select the template whose associated VMRs you want to delete (to open the Change VMR sync template page).
3. Scroll down to the bottom of the page and select Delete all VMRs created from this template.
4. Confirm that you want to proceed.
5. The VMRs will be deleted and a status message is displayed confirming the number of VMRs that were deleted.

Deleting a template

If you delete a synchronization template, all of the VMRs associated with that template will also be deleted.