Enabling Exchange Scheduling in single-use VMRs

The VMR Scheduling for Exchange feature (also known as Secure Scheduler for Exchange) allows you to create an add-in that enables Microsoft Outlook desktop and Web App users in Office 365 or Exchange environments to quickly and easily add a Pexip VMR to their meeting invitations, enabling any meeting to be held over video.

This topic gives an overview of the process and prerequisites for using VMR Scheduling for Exchange with single-use VMRs. These VMRs are created dynamically for a specific meeting, and are only available for the duration of that meeting (and any scheduled recurrences).

You can also enable VMR Scheduling for Exchange with personal VMRs, either instead of, or in addition to, single-use VMRs.

In this topic:

Overview

Enabling the use of single-use VMRs within your VMR Scheduling for Exchange service involves the following steps:

  1. Configuring Microsoft Exchange on-premises or Configuring Office 365 with an equipment resource and either a service account or app registration, and enabling the use of application impersonation.

    This step is required if you wish to enable single-use VMRs. It is not required if you are only enabling personal VMRs in your deployment.

  2. Configuring Pexip Infinity, including enabling single-use VMRs, providing the information required to connect to your Microsoft Exchange deployment, and generating the associated add-in.
  3. Making the add-in available to users within your Microsoft Exchange deployment.

See Using Outlook to schedule meetings in VMRs for a guide for end users on how to use the add-in.

When VMR Scheduling for Exchange has been implemented, you will be able to view scheduled VMRs in the same way as existing VMRs. For more information, see Managing conferences created by Exchange Scheduling.

Process flow - single-use VMRs

The diagram below outlines the process that is initiated when users activate the Pexip VMR Scheduling for Exchange add-in from their Outlook client and select the Single-use VMR option; this process is described in more detail in the paragraphs that follow.

The fields described in the following process are configured on the Management Node via System > VMR Scheduling for Exchange Integrations.

Add-in requests aliases

When a user activates the Pexip VMR Scheduling for Exchange add-in from within their Outlook client meeting request, the add-in sends a request to the reverse proxy or Conferencing Node identified by the Add-in server FQDN field. If a reverse proxy is used, it forwards the request on to an appropriate Conferencing Node. The Conferencing Node then forwards the request to the Management Node and asks for an alias for the VMR to use for the meeting. If no Conferencing Node can be contacted at this stage, the user sees a message in the add-in pane of their client informing them that the add-in is not available.

Management Node generates aliases and join instructions

If the Management Node is online, it generates a unique number for the VMR and then uses this to create two aliases (one with a domain appended and one without), using the information in the following fields:

For example, if we have configured a prefix of 555, a suffix length of 6 and a domain of example.com, the two aliases created for one particular VMR could be:

  • 555123456
  • 555123456@example.com

The alias suffix length used must result in aliases of a sufficient length to ensure security and quantity within your deployment:

  • security: the longer the alias, the less susceptible your deployment is to external attacks by third parties (such as SIP scanners) attempting to guess meeting aliases
  • quantity: if your deployment is generating a high volume of scheduled meetings, longer aliases mean you are less likely to run out of numbers.

The Management Node also generates some joining instructions for the VMR, based on the VMR's alias and the Joining instructions template field. This information is sent back to the Conferencing Node which forwards it to the add-in as a response to the request. The add-in then inserts the join instructions into the top of the meeting request email. A unique security ID (in the format PXPS:-<xxx>#) is also obtained from the Management Node and inserted into the email; this text must not be edited or deleted.

If the Management Node cannot be contacted by the Conferencing Node, the Conferencing Node will respond to the add-in with the placeholder text from the Placeholder instructions text field. A multi-line security token in the format TOK:-<xxx># (obtained directly from the Microsoft Exchange server by the add-in) is also inserted into the email; again, this text must not be edited or deleted.

The add-in also adds the equipment resource as a required attendee. This equipment resource must be included in all subsequent requests relating to this meeting.

Management Node creates VMRs

When the user sends the meeting request, a message is sent to the equipment resource's mailbox. The Management Node monitors this mailbox using EWS impersonation. For each new meeting request received, the Management Node generates a VMR with the required aliases (one numeric, the other numeric with domain). For recurring meetings, the same alias is used for all instances of the meeting. For meeting updates and cancellations, the Management Node will update the associated VMR accordingly.

The VMR is created as soon as the Management Node receives the meeting request, but meeting participants cannot use the VMR until they are within the period of time configured by the Join before buffer and Join after buffer. Participants who have successfully joined the VMR can continue to use it until the last participant has left; the conference will not be terminated automatically by the scheduling service, although it may be automatically terminated for other reasons.

If the Management Node has been offline, when it comes online it connects to the equipment resource's mailbox and reads the requests. At this point it creates and updates VMRs. For meetings that were not assigned a PXPS:- ID, the Management Node will generate an alias and create the VMR. It then replaces the Placeholder instructions text and security token (TOK:-<xxx>#) in the original meeting request with a PXPS:- ID, along with details of the aliases and the joining instructions. The Management Node then uses impersonation to send the updated request to all attendees on behalf of the meeting organizer (the request is shown in the organizer's sent items folder). This updated request is also sent to the equipment resource's mailbox.

PXPS:- and TOK:- security tags

To ensure that the VMR Scheduling for Exchange service processes only those meeting requests created using the add-in, and in order to track each meeting request, each request contains a security tag in the format of either TOK:- or PXPS:-.

When the add-in is activated, it obtains a TOK:- security tag from the user's Microsoft Exchange server. This TOK:- is then passed to the Management Node when it is asked to allocate an alias for the VMR. If the TOK:- is valid, the Management Node will generate the alias and return a PXPS:- ID to the Conferencing Node. The PXPS:- ID is passed back to the add-in and inserted into the body of the meeting request.

In normal circumstances, end users will not see the TOK:- tag because the request to generate a VMR alias is actioned immediately by the Management Node. However, if the Management Node is offline at the time the request is sent, and therefore a VMR alias is not generated immediately, the TOK:- will be inserted into the body of the meeting request. When the Management Node comes back online, it will process the requests; for any with a valid TOK:- it generates a VMR alias and PXPS:- ID and sends an updated meeting request that includes these.

Note that the TOK:- is only valid for a limited amount of time. If the Management Node processes the request after the TOK:- expires, it will be considered invalid. In such cases, the meeting organizer must create a new meeting request using the add-in.

Using application impersonation

The use of Exchange impersonation is common in business applications that work with mail, when a single account needs to access many accounts.

The VMR Scheduling for Exchange feature uses EWS impersonation of resources (required) and users (optional) for the following purposes:

  • To access the mailbox of the equipment resource used for VMR Scheduling for Exchange. This impersonation is required in order for the VMR Scheduling for Exchange feature to work.

  • To send emails on behalf of all VMR Scheduling for Exchange users. This impersonation is only required in the two scenarios described below. If the service account / app is not permitted to impersonate users, the users can still schedule and update meetings as usual, but the following scenarios are not supported:

    • If an invitation was sent when the Management Node was offline. In this case, when the Management Node comes back online it will generate a new alias and joining instructions for the meeting. It then updates the meeting invitation using impersonation, so that it appears as though the meeting organizer is sending out the updated joining instructions to all the attendees.
    • When the scheduling recovery tool is run after the Management Node has been restored from a backup. The recovery tool queries the room resource mailbox and finds all meetings that have previously been accepted, and checks whether they are in the scheduling service's database. If not, the Management Node will generate a new alias and new joining instructions for that meeting. This meeting update is sent using impersonation so that it appears as though the meeting organizer is sending out the updated joining instructions to all the attendees.

We recommend permitting the service account / app to access all users (in addition to the equipment resource) to enable the full functionality of the VMR Scheduling for Exchange feature, but we also provide instructions for permitting the service account / app to access the equipment resource only if this is more appropriate for your environment.

The following information from Microsoft provides further background on the use of impersonation in Exchange:

Recurring meetings

For recurring meetings in single-use VMRs, the VMR Scheduling for Exchange service creates a single VMR which exists until after the last meeting in the series has taken place. However, participants can only join this VMR during any of the scheduled meeting times.

PINs and authentication

By default, single-use VMRs are created without PINs, meaning participants do not need to enter a PIN and all participants join with Host privileges.

You can optionally require that all participants must authenticate with an Identity Provider in order to join a single-use VMR; this is configured on a per-VMR Scheduling for Exchange Integration basis, using the Identity Provider group and Other participants settings.

When enabled for single-use VMRs, the requirement for participant authentication applies to all meetings scheduled using the add-in associated with that integration. To allow users to choose between scheduling authenticated and unauthenticated meetings, create two integrations and associated add-ins, one with authentication enabled and one without.

In addition, after an individual single-use VMR has been created, you can edit the configuration for that VMR to add Host PINs and Guest PINs, and/or require participant authentication.

Next step