Download Administrator guide as PDFProvisioning VMRs and devices from Active Directory via LDAP
Pexip Infinity Virtual Meeting Rooms and device aliases 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.
You can also automatically provision Pexip Infinity with the device aliases that people can use to register their endpoint or Infinity Connect client to a Conferencing Node.
Each sync template can be configured to automatically synchronize against its LDAP sync source once per day. This ensures that the Pexip Infinity VMR and device configuration stays in step with all additions and removals that have occurred in the source directory. Many of the VMR / device settings can be tagged as "overridable" which means that if that setting (the VMR PIN number for example) is manually overridden after the VMR or device has been created, a subsequent resynchronization will not reset it back to another value.
If Pexip Infinity has been configured with the details of an SMTP server, you can send an email to the VMR owner whenever a synchronization creates a new VMR or modifies an existing VMR, or to inform a user of the device alias and credentials that they need to use to register their device.
Configuration summary
To provision your Virtual Meeting Rooms or device aliases from an LDAP database you must:
- 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).
-
Configure an LDAP synchronization template that controls what to synchronize — VMRs, device aliases or both — and how individual settings such as the VMR 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). For example, you may want to use a different template for VMR syncing than the template used for device alias syncing if you need to use different LDAP filter criteria for those two user bases.
- Configure an SMTP server and construct an email template, if you want to send a provisioning notification email to the VMR owner or intended user of a device alias.
- Generate the VMRs and device aliases 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 LDAP template synchronization processes via .
- Delete all of the VMRs and devices 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:
- Go to .
-
Select , 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).
-
Select .
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 an LDAP synchronization template
LDAP synchronization templates control what to synchronize — VMRs, device aliases or both — and how individual settings such as the VMR name, dialable alias and PIN numbers are generated, and what to include in provisioning notification emails sent to the VMR or device owner. You must also tell the template which LDAP data source to use.
To configure Pexip Infinity with an LDAP synchronization template:
- Go to .
-
Select , 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.Sync VMRs Enables VMR synchronization for this template.
Default: enabled.
Sync devices Enables device alias synchronization for this template.
Default: disabled.
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 and devices, 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.
Device settings (shown when Sync devices is selected) Device alias pattern The pattern for the alias that will be registered by the device and be used by people trying to call the device.
For more information, see Using patterns to format the VMR and device properties (name, alias etc).
Default: {{mail}}
If a device with the generated alias already exists, that existing device configuration will be overwritten with the data generated from this template.
Device tag pattern The pattern for the unique identifier used to track usage of the device. Allow device tag to be manually overridden Allows the auto-generated device tag to be manually overridden for each device alias. Device description pattern The pattern to use when generating the optional description of this device alias. Allow device description to be manually overridden Allows the auto-generated device description to be manually overridden for each device alias. Device username pattern The pattern for the device username. Note that you can use the same username for different device aliases (although we recommend you only do this for multiple devices used by the same person).
Default: {{mail}}
Allow username to be manually overridden Allows the username to be manually overridden for each device alias. Device password pattern The pattern to use when generating the password for this device. A password pattern must be specified if a username pattern is configured.
Example: {{ ("some random string"+(mail|pex_reverse))|pex_hash|pex_tail(16) }}
Allow password to be manually overridden Allows the password to be manually overridden (by the administrator) for each device alias. VMR settings (shown when Sync VMRs is selected) 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 and device 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.
Examples: {{givenName}} {{sn}}'s meeting room
You could use a more advanced pattern such as:
{{givenName}} {{sn}}'s {%if department %} ({{department}}){% endif %} meeting room
which will insert "(<department name>)" before "meeting room", but only if a value exists in the LDAP department field.
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.
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).
Show names of speakers If enabled, the display name or alias of each main speaker is shown. For more information, see Showing the names of speakers. Allow layout settings to be manually overridden Allows the type of layout and whether to show names of speakers to be manually overridden for each VMR. Theme The theme for use with this VMR. 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) }}Email options Send emails
VMR / device owner's email address
Address override
SMTP serverThese email options allow you to send an email to the VMR owner whenever a synchronization creates a new VMR or modifies an existing VMR, or when a synchronization creates a new device alias or modifies an existing device alias.
See Sending provisioning emails to VMR and device owners for information about how to configure these options.
Advanced options (shown when Sync VMRs is selected) 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 VMR. 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 VMR. 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 VMR. 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.
Allow service tag to be manually overridden Allows the auto-generated service tag to be manually overridden for each VMR. Conference capabilities Allows you to limit the media content of the conference. For more information, see Controlling media capability.
Default: Main video + presentation.
-
Select .
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 and device properties (name, alias etc)
When you configure an LDAP synchronization template, you define patterns for how some of the VMR or device properties — such as its name and the aliases — are generated from the data in the LDAP sync source.
Pexip Infinity's
These
- 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
- delimiters such as {{...}} and pipes | which are used to
- 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 |
| employeeID * | Employee reference number |
| givenName | First name |
| 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:
- Go to .
-
Select , 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.
-
Select .
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'.
pex_base64
Performs Base64 encoding on the input field.
Example usage: {{provisiondata|pex_base64}}
In this example, a local variable named provisiondata is encoded as Base64.
Generating / syncing VMRs and devices with LDAP
After you have configured a sync source and a template you can generate your VMRs and devices 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 and devices were updated.
When synchronizing a template:
- Pexip Infinity checks all of the VMRs and devices previously created by that template and it updates, deletes or creates new VMRs / devices 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 and device alias will be deleted.
- If a generated VMR name or device alias already exists (either created manually or via a different template), that existing VMR or device alias 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.
Changes to device aliases are also replicated to all Conferencing Nodes within 60 seconds and applied to any subsequent registration requests.
The template synchronization process can take several minutes if you have a large number of VMRs or devices. 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:
- Go to .
- Select the template you want to use (to open the page).
- Select Enable automatic daily sync.
- Select .
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 and devices, 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 and devices in Pexip Infinity with the LDAP data source:
- Go to .
-
Select the template you want to use (to open the page).
- Scroll down to the bottom of the page and select .
-
A status page is displayed which shows the progress of the synchronization.
You can safely navigate away from this page without affecting the synchronization.
- For large imports that take a long time to complete, you can monitor the ongoing status of the import at any time via .
Alternatively, you can sync one or more templates by going to , selecting the check box next to the templates that you want to use, and then from the Action drop-down menu, select Sync selected LDAP sync templates and then select .
Deleting all VMRs and devices associated with a template
You can easily delete all of the VMRs and devices 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 and devices associated with a synchronization template:
- Go to .
- Select the template whose associated VMRs and devices you want to delete (to open the page).
- Scroll down to the bottom of the page and select .
- Confirm that you want to proceed.
- The VMRs and devices will be deleted and a status message is displayed confirming the number of VMRs and devices that were deleted.
Deleting a template
If you delete a synchronization template, all of the VMRs and devices associated with that template will also be deleted.