Enabling VMR scheduling in single-use VMRs
The VMR Scheduling for Exchange feature 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:
- Enabling VMR scheduling in single-use VMRs
- Process flow - single-use VMRs
- PXPS:- and TOK:- security tags
- Using application impersonation
- Recurring meetings
- Next step
Enabling the use of single-use VMRs within your VMR Scheduling for Exchange service involves the following steps:
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.
- 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.
- 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 scheduled conferences.
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 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 .
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 will forward 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 be used for the meeting. If no Conferencing Node can be contacted at this stage, the user will get a message in the add-in pane of their client informing them that the add-in is not available.
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:
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 will also add the equipment resource as a required attendee. This equipment resource must be included in all subsequent requests relating to this meeting.
When the user sends the meeting request, a message is sent to the equipment resource's mailbox. The Management Node monitors this mailbox using the service account. 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 will be created as soon as the Management Node receives the meeting request, but meeting participants will not be able to 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 will then replace 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 will then use the service account to send the updated request to all attendees on behalf of the meeting organizer (the request will show in the organizer's sent items folder). This updated request will also be sent to the equipment resource's mailbox.
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 will be 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 will generate a VMR alias and PXPS:- ID and send 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.
The use of Exchange impersonation is common in business applications that work with mail, when a single account needs to access many accounts.
The service account used by VMR Scheduling for Exchange uses impersonation as follows:
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 is service account is not permitted to impersonate users, the users will still be able to schedule and update meetings as usual, but the following scenarios will not be supported in your deployment:
- 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 will then update 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.
The following information from Microsoft provides further background on the use of impersonation in Exchange:
- https://docs.microsoft.com/en-us/exchange/client-developer/exchange-web-services/impersonation-and-ews-in-exchange for guidelines on when to use impersonation in your Exchange service applications.
- https://blogs.msdn.microsoft.com/exchangedev/2009/06/15/exchange-impersonation-vs-delegate-access/ for information on the differences between impersonation and delegate access.
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 will only be able to join this VMR during any of the scheduled meeting times.