Provisioning VMRs, devices and users from Active Directory via LDAP

In large organizations with many employees and users of video conferencing, you may need to configure lots of Virtual Meeting Rooms (VMRs) and associated records to support those employees. Much of this data can be bulk-provisioned from directory information contained in a Windows Active Directory LDAP server, or any other LDAP-accessible database.

The following Pexip Infinity configuration settings can be provisioned directly from an LDAP data source:

  • Virtual Meeting Rooms (VMRs): this provides a simple way to 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 PINs, the layout and theme can also be assigned, depending upon your VMR template configuration.
  • Device aliases: these are the aliases that people can use to register their endpoint or Connect app to a Conferencing Node, and how those devices can be authenticated.
  • User records: these are required for two optional features:

    • Scheduling meetings in personal VMRs — part of the VMR Scheduling for Exchange feature. See Enabling Exchange Scheduling in personal VMRs for more information.
    • Participant avatars — conference participants and directory contacts within Pexip Infinity can be represented by an avatar or image. You can configure user records to represent those participants/contacts and associate each user with an avatar URL that points to an external service (such as Gravatar) which can be used to retrieve that user's avatar/image. The user's Email address is used as the primary identifier of each user record, and this must match the Owner's email address associated with the device alias of the conference participant. To use your avatar URLs, you must set up a policy profile that has Use local avatar configuration enabled. See Applying user records for more information.

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

If Pexip Infinity is 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. Emails are not sent for any user records that are created.

Configuration summary

To provision your Virtual Meeting Rooms, device aliases or user records 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 an LDAP synchronization template that controls what to synchronize — VMRs, device aliases or users — and how individual settings such as the VMR name, dialable alias and PINs 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.

  3. 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.
  4. Generate the VMRs, device aliases and user records 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 Status > LDAP sync.
  • Delete all of the VMRs, devices and users 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. Note that this uses ports 3268 (TCP) and 3269 (TLS).

    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 an LDAP synchronization template

LDAP synchronization templates control what to synchronize — VMRs, device aliases and/or users — and how individual settings such as the VMR name, dialable alias and PINs 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.

Many of the VMR, device and user settings are based on patterns in the template that define how that setting is generated (such as using an email address as the device alias). See Using templates, variables and filters when provisioning VMRs, devices and users for more information.

To configure Pexip Infinity with an LDAP synchronization template:

  1. Go to Utilities > LDAP sync templates.
  2. Select Add LDAP 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.

    Sync VMRs

    Enables VMR synchronization for this template.

    Default: enabled.

    Sync devices

    Enables device alias synchronization for this template.

    Default: disabled.

    Sync users

    Enables user record 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, devices and users 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, device or user record in Pexip Infinity will be deleted via the next daily sync.

    As template synchronization can result in the automatic creation, modification or deletion of large numbers of VMRs, devices and users, 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.

    All automatic synchronizations are initiated at 01:00 UTC (this start time cannot be configured). After an initial sync, which can take several minutes in a large organization, an ongoing daily sync is typically much faster as it only processes changes since the previous sync.

    Default: disabled.

    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 templates, variables and filters when provisioning VMRs, devices and users.

    Default: {{mail}}

    If a device with the generated alias already exists, that existing device configuration is left unchanged.

    Device tag pattern

    Allow device tag to be manually overridden

    The pattern for the unique identifier used to track usage of the device.

    You can also allow the auto-generated device tag to be manually overridden for each device alias.

    Device description pattern

    Allow device description to be manually overridden

    The pattern to use when generating the optional description of this device alias.

    You can also allow the auto-generated device description to be manually overridden for each device alias.

    Device username pattern

    Allow username to be manually overridden

    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}}

    You can also allow the auto-generated username to be manually overridden for each device alias.

    Device password pattern

    Allow password to be manually overridden

    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) }}

    You can also allow the auto-generated password to be manually overridden (by the administrator) for each device alias.

    Sync disabled accounts

    Syncs all device aliases, even if the corresponding LDAP account is disabled.

    By default, device aliases are only provisioned if the corresponding LDAP account is enabled in the LDAP directory. If Sync disabled accounts is selected, a device alias will be created for LDAP accounts that are marked as disabled. This may be useful, for example, if you have a disabled machine account in LDAP corresponding to a SIP or H.323 room system — however it is not generally useful for staff accounts because if an employee leaves an organization you usually want their device record to be deleted automatically after their account is disabled in the corporate LDAP directory.

    Default: disabled.

    Device registration settings (shown when Sync devices is selected)
    Enable SIP registration Allows this device alias to register over the SIP protocol.
    Enable H.323 registration Allows this device alias to register over the H.323 protocol.
    Enable Infinity Connect registration (non-SSO) Allows a Connect app (or any other device using the Pexip client API) to register using this alias (not using SSO services).
    Enable Infinity Connect registration using SSO Allows a Connect app (or any other device using the Pexip client API) to register using this alias, using AD FS SSO to authenticate the registration.
    Allow registration settings to be manually overridden Allows all of the auto-generated device registration settings to be manually overridden for each device.
    VMR name and description (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 templates, variables and filters when provisioning VMRs, devices and users.

    Example: {{givenName}} {{sn}} VMR

    If a VMR with the generated name already exists, that existing VMR configuration is left unchanged.

    VMR description pattern

    Allow VMR description to be manually overridden

    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.

    You can also allow the auto-generated VMR description to be manually overridden for each VMR.

    VMR Participant Authentication settings (shown when Sync VMRs is selected)
    Host PIN pattern

    The pattern to use to generate the Host PIN (if required).

    For example, if you want a VMR to keep the same random PIN after every resync you could use a pattern like this:

    {% set pl=6 %}{% set hp=(("an ungu3ssable Pa$$phr4s3" ~mail)|pex_hash|pex_tail(pl)) %}{{hp}}

    where you:

    • set pl to the number of digits required in the PIN (it is set to 6 in this example, but can be from 4-20), and
    • replace "an ungu3ssable Pa$$phr4s3" with your own passphrase string (we recommend at least 14 characters long).

    This will generate a random number that is pl digits long, but it will always generate the same number per VMR (assuming the VMR owner's LDAP mail field remains unchanged). If you want to do a periodic update of all of the PINs associated with VMRs generated from this template, then just change the passphrase string and they will be updated to a new random PIN (assuming Allow PIN settings to be manually overridden is not selected).

    Note that the ~ operator is similar to a + and converts arguments, nulls etc. safely to strings.

    Allow Guests

    Yes: the conference can 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 have Host privileges.

    Default: No.

    Guest PIN pattern

    The pattern to use to generate the Guest PIN (if required).

    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, for example:

    {% set pl=6 %}{% set hp=(("an ungu3ssable Pa$$phr4s3" ~mail)|pex_hash|pex_tail(pl)) %}{% set gp=(("a different Pa$$phr4s3" ~mail)|pex_hash|pex_tail(pl)) %}{% if hp == gp %}{{("00000000000000000000"~((gp|int)+123))|pex_tail(pl)}}{% else %}{{gp}}{% endif %}

    This works in conjunction with the example above that is used to generate the Host PIN. The pattern includes the recipe used to generate the Host PIN (hp) and uses the same technique to generate a random Guest PIN (gp). It then checks if the Guest PIN accidentally clashes with the Host PIN. If it does clash, the Guest PIN is adjusted (it is incremented by 123 in this example).

    As with the Host PIN pattern, you should:

    • set pl to the number of digits required in the Host and Guest PINs, and
    • replace "an ungu3ssable Pa$$phr4s3" and "a different Pa$$phr4s3" with your own passphrase strings (both strings must be different).
    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.

    Host Identity Provider Group

    The set of Identity Providers to be offered to Hosts to authenticate with, in order to use the service. If this is blank, Hosts are not required to authenticate.

    For more information, see see About participant authentication.

    Default: none selected

    Guest Identity Provider Group

    The set of Identity Providers to be offered to Guests to authenticate with, in order to use the service. If this is blank, Guests are not required to authenticate.

    For more information, see About participant authentication.

    Default: none selected

    Allow IdP settings to be manually overridden

    Allows the Host and Guest Identity Provider Group settings to be manually overridden for each VMR.

    Default: disabled.

    Other Participants

    Allow Other Participants setting to be manually overridden

    Determines whether participants joining a SSO-protected service from devices other than the Connect web app (for example SIP or H.323 endpoints) are allowed to dial in to the service.

    • Disallow all: these devices are placed in a waiting room where they must wait to be admitted by a Host.
    • Allow if trusted: these devices may join the service if they are locally registered. They must still enter a Host PIN or Guest PIN if either is required. All other devices are placed in a waiting room where they must wait to be admitted by a Host.

    For more information, see About participant authentication.

    Default: Disallow all

    You can also allow the Other Participants setting to be manually overridden for each VMR.

    VMR layout and theme (shown when Sync VMRs is selected)

    Layout

    Show name of active speaker

    Show names of participants

    Allow layout settings to be manually overridden

    The layout controls the maximum number of other participants that each participant will see, and how the participants are arranged on the screen. For more information, see Conference layouts and speaker names.

    Default: Large main speaker and up to 7 other participants (1+7 layout).

    If participant name overlays are enabled, the display names or aliases of all participants are shown in a text overlay along the bottom of their video image. For more information, see Showing the names of active speakers and participants.

    You can also allow the type of layout and whether to show names of participants to be manually overridden for each VMR.

    Theme

    Allow theme to be manually overridden

    The theme for use with this VMR. For more information, see Customizing conference images and voice prompts using themes.

    Default: <use Default theme> (the global default theme is used).

    You can also allow the auto-generated theme to be manually overridden for each VMR.

    VMR aliases (shown when Sync VMRs is selected)
    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 is left assigned to that existing VMR.

    Description 1 pattern

    The pattern to use to generate a description of the alias. This field is optional.

    Example: The alphanumeric URI alias

    VMR alias 2...8 pattern and descriptions

    You can optionally enter patterns for a further 7 alternative aliases, such as an E.164 alias, to associate with this VMR. (Aliases 5-8 are configured by expanding the Advanced VMR alias options section.)

    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) }}

    Allow aliases to be overridden

    (This option is configured by expanding the Advanced VMR alias options section.)

    Allows aliases and alias descriptions for a VMR to be added, removed or modified in any way. When enabled this means that after the initial creation of a VMR and its aliases, subsequent syncs will not change any of the aliases or their descriptions (including any which were created by VMR alias 1..8 pattern and Description 1..8 pattern even if those patterns are modified in this template).

    Advanced options (shown when Sync VMRs is selected)

    Guests can present

    Allow Guests can present to be manually overridden

    Controls whether the Guests in the conference are allowed to present content.

    • Yes: Guests and Hosts can present into the conference
    • No: only Hosts can present

    Default: Yes

    You can also allow the auto-generated Guests can present setting to be manually overridden for each VMR.

    Direct media enabled

    Allow direct media to be manually overridden

    Allows this VMR to use direct media between participants. When enabled, the VMR provides non-transcoded, encrypted, point-to-point calls between any two WebRTC participants. The options are:

    • Best effort: use direct media in this VMR where possible (when there are two WebRTC participants only), otherwise use standard, transcoded media connections via a Conferencing Node.
    • Always: allow direct media calls only — this limits all calls in this VMR to two WebRTC participants.
    • Never: do not use direct media in this VMR.

    Default: Never

    Note that direct media is not supported if breakout rooms are also enabled for this VMR.

    See Direct media (end-to-end encrypted calls) for more information.

    You can also allow the direct media setting to be manually overridden for each VMR.

    Direct media notification duration

    Allow the direct media notification duration to be manually overridden

    The number of seconds to show a notification to participants before being escalated into a transcoded call, or de-escalated into a direct media call. Range: 0 to 30 seconds.

    Default: 0 seconds

    You can also allow the direct media notification duration setting to be manually overridden for each VMR.

    Enable chat

    Allow enable chat to be manually overridden

    Whether chat messaging is enabled for the conference:

    Default: Use global chat setting.

    You can also allow the auto-generated enable chat setting to be manually overridden for each VMR.

    Maximum inbound call bandwidth (kbps)

    Maximum outbound call bandwidth (kbps)

    Allow maximum bandwidth settings to be manually overridden

    Specifying a maximum inbound call bandwidth will limit the bandwidth of media received by Pexip Infinity from each individual participant dialed in to this VMR. For more information see Managing and restricting call bandwidth.

    Specifying a maximum outbound call bandwidth will limit the bandwidth of media sent from Pexip Infinity to each individual participant dialed in to this VMR. For more information see Managing and restricting call bandwidth.

    You can also allow the auto-generated maximum inbound and outbound call bandwidth to be manually overridden for each VMR.

    Participant limit

    Allow participant limit to be manually overridden

    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.

    You can also allow the auto-generated participant limit to be manually overridden for each VMR.

    Service tag pattern

    Allow service tag to be manually overridden

    This optional field lets you assign a unique identifier to this VMR, which you can then use to track use of the service.

    You can also allow the auto-generated service tag to be manually overridden for each VMR.

    Conference capabilities

    Allow conference capabilities to be manually overridden

    Allows you to limit the media content of the conference. For more information, see Controlling media capability.

    Default: Main video + presentation.

    You can also allow the auto-generated conference capabilities to be manually overridden for each VMR.

    Maximum call quality

    Allow maximum call quality to be manually overridden

    Controls the maximum call quality for participants connecting to this service:

    • Use global setting: use the global maximum call quality setting.
    • SD: each participant is limited to SD quality.
    • HD: each participant is limited to HD (720p) quality.
    • Full HD (1080p): allows any endpoint capable of Full HD to send and receive its main video at 1080p.

    Default: Use global setting

    See Setting and limiting call quality for more information.

    Media encryption

    Allow media encryption to be manually overridden

    Controls the media encryption requirements for participants connecting to this service.

    • Use global setting: use the global media encryption setting.
    • Best effort: each participant will use media encryption if their device supports it, otherwise the connection will be unencrypted.
    • Required: all participants (including RTMP participants) must use media encryption.
    • No encryption: all H.323, SIP and MS-SIP participants must use unencrypted media. (RTMP participants will use encryption if their device supports it, otherwise the connection will be unencrypted.)

    Default: Use global setting

    You can also allow the auto-generated media encryption setting to be manually overridden for each VMR.

    User basic options (shown when Sync Users is selected)

    User description pattern

    Allow user description to be manually overridden

    The pattern to use to generate the user description. This field is optional.

    Examples: The user for {{displayName}}

    You could use a more advanced pattern such as:

    The user for {{displayName}} {% if title or department%}({% if title %}{{title}}, {%endif%} {%if department %}{{department}}{% endif %}){% endif %}

    which will include the user's job title and department name if they are specified in the LDAP source.

    You can also allow the auto-generated user description to be manually overridden for each user.

    User name options (shown when Sync Users is selected)
    First name pattern

    The pattern to use to generate the first name of the user.

    Default: {% if givenName %}{{givenName}}{% endif %}

    Last name pattern

    The pattern to use to generate the last name of the user.

    Default: {% if sn %}{{sn}}{% endif %}

    Display name pattern

    The pattern to use to generate the display name of the user.

    Example: {% if displayName %}{{displayName}}{% endif %}

    Note that the display name is not currently used in Pexip Infinity (for example, it does not affect participant name overlays and cannot be used when provisioning Connect apps).

    Allow user names to be manually overridden Allows the auto-generated user names to be manually overridden for each user.
    User contact options (shown when Sync Users is selected)
    Telephone number pattern

    The pattern to use to generate the telephone number of the user.

    Default: {{telephoneNumber|pex_clean_phone_number}}

    Mobile number pattern

    The pattern to use to generate the mobile number of the user.

    Default: {{mobile|pex_clean_phone_number}}

    Allow user contacts to be manually overridden Allows the auto-generated user contact information (telephone and mobile numbers) to be manually overridden for each user.
    User other options (shown when Sync Users is selected)
    Title pattern

    The pattern to use to generate the title of the user.

    Default: {% if title %}{{title}}{% endif %}

    Department pattern

    The pattern to use to generate the department of the user.

    Default: {% if department %}{{department}}{% endif %}

    Avatar URL pattern

    The pattern to use to generate the avatar URL of the user. Note that:

    • The avatar URL must be an unprotected resource (username and password credentials cannot be supplied with the request), and it must be reachable from Conferencing Nodes.
    • The image retrieved from the avatar URL must be a JPEG.
    • When a Conferencing Node sends an image request to the avatar URL, Pexip Infinity adds on extra URL parameters that specify the required dimensions, for example ?width=100&height=100&s=100 (the s is a size parameter used by Gravatar). Pexip Infinity only ever requests square images.
    • The Connect app requests a 460x460 image size.
    • All JPEG images must use the RGB or RGBA color space (CMYK is not supported), and be of the requested size (width, height).

    See Applying user records for more information.

    Default: https://www.gravatar.com/avatar/{{mail|trim|lower|pex_md5}}?d=404

    Allow the user's other personal details to be manually overridden Allows the auto-generated user personal information (title, department and avatar URL) to be manually overridden for each user.
    User advanced options (shown when Sync users is selected)
    UUID pattern

    The pattern to use to generate the UUID of the user.

    This field is required and must be unique for each user and must be in a UUID format. Therefore it is strongly recommended to use {{objectGUID|pex_to_uuid}} as the value of this pattern.

    Default: {{objectGUID|pex_to_uuid}}

    Exchange mailbox UUID pattern

    The pattern to use to generate the Exchange Mailbox UUID of the user. This field is not required but if included it must be in a UUID format and be unique for each user.

    Default: {% if msExchMailboxGuid %}{{msExchMailboxGuid|pex_to_uuid}}{% endif %}

    Allow user advanced options to be manually overridden Allows the auto-generated user advanced options to be manually overridden for each user.
    Email options

    Send emails

    VMR / device owner's email address

    Allow email address to be manually overridden

    SMTP server

    These 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.

    The VMR/Device owner's email address:

    • Defaults to {{mail}}
    • Is used as the email address of the user records that are created when syncing users.
    • When using the VMR self-service portal, it determines which VMRs can be viewed and edited (the LDAP mail attribute of the user logged into the VMR portal must match the VMR owner's email address).

    See Sending provisioning emails to VMR and device owners for more information about these options.

    VMR email options

    VMR email subject

    VMR email template

    Templates for the subject line and body of the email to be sent when a VMR is created or updated.

    See Sending provisioning emails to VMR and device owners for more information about these options.

    Device email options

    Device email subject

    Device email template

    Templates for the subject line and body of the email to be sent when a device alias is created or updated.

    See Sending provisioning emails to VMR and device owners for more information about these options.

  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 settings can be tagged as "overridable" which means if that setting is manually overridden after the VMR, device or user 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.

If you make a field overridable you do not have to wait for another sync before making your override changes to the relevant field. 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 setting tagged as overridable via one template could still be modified by a different template.

All of the override options are disabled by default.

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 LDAP directory 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)))

To import users that belong to a specific group and any other group nested within that group, you can use the memberOf:1.2.840.113556.1.4.1941 filter for users. For example, to import users who are members of the cn=sales,ou=groups,dc=example,dc=com group or are members of a group nested within the sales group, you would set the LDAP user filter on your template to:
(&(ObjectCategory=user)(memberOf:1.2.840.113556.1.4.1941:=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)

Escaping special characters in search/filter strings

If your search/filter strings include the following special characters: ()*\ you must use a single \ to escape those characters.

For example if you have a group cn=group-with-parenthese(s)-in-name,ou=groups,dc=example,dc=com then you would set the memberOf filter to:
(memberOf=CN=group-with-parenthese\(s\)-in-name,ou=groups,dc=example,dc=com))

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

Generating / syncing VMRs, devices and users with LDAP

After you have configured a sync source and a template you can generate your VMRs, devices and users 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, devices and users were updated.

When synchronizing a template:

  • Pexip Infinity checks all of the VMRs, devices and user records previously created by that template and it updates, deletes or creates new records 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, device alias and user record will be deleted.
  • If a generated VMR name, device alias or user email address already exists (either created manually or via a different template), or if a generated alias for a VMR is already assigned to another VMR, those existing VMR properties, VMR-to-alias assignments, device aliases or user records are not overwritten.

Any configuration changes made to Virtual Meeting Rooms are replicated to all Conferencing Nodes (typically after approximately one minute) and applied to any subsequent conferences in that Virtual Meeting Room. If there are any conferences already running 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 (again, typically after approximately one minute) and are applied to any subsequent registration requests.

The template synchronization process itself can also take several minutes if you have a large number of VMRs, devices or users. Therefore you must wait for at least one minute 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 > LDAP sync templates.
  2. Select the template you want to use (to open the Change LDAP sync template page).
  3. Select Enable automatic daily sync.
  4. Select Save.

As template synchronization can result in the automatic creation, modification or deletion of large numbers of VMRs, devices and users, 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.

All automatic synchronizations are initiated at 01:00 UTC (this start time cannot be configured). After an initial sync, which can take several minutes in a large organization, an ongoing daily sync is typically much faster as it only processes changes since the previous sync.

Manual synchronization

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

  1. Go to Utilities > LDAP sync templates.
  2. Select the template you want to use (to open the Change LDAP sync template page).
  3. Scroll down to the bottom of the page and select Sync 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 > LDAP sync.

Alternatively, you can sync one or more templates by going to Utilities > LDAP 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 LDAP sync templates and then select Go.

Deleting all VMRs, devices and users associated with a template

You can easily delete all of the VMRs, devices and users 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, devices and user records associated with a synchronization template:

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

Deleting a template

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