Scheduling Pexip Infinity meetings using Microsoft Exchange
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 schedule meetings using Pexip VMRs as a meeting resource.
VMR Scheduling for Exchange is an optional licensed feature within the Pexip Infinity platform. When this feature has been enabled, you can create VMR scheduling for Exchange integrations to one or more Microsoft Exchange deployments.
In this topic:
- Supported Exchange deployments
- Supported clients
- Support for delegate access to calendars
- Enabling VMR Scheduling for Exchange
- Process flow
- PXPS:- and TOK:- security tags
- Recurring meetings
- Network architecture and firewalls
- Using application impersonation
Pexip Infinity VMR Scheduling for Exchange is supported on the following Microsoft Exchange deployments:
- Office 365
- Exchange 2013 (with the latest updates)
- Exchange 2016 (with the latest updates)
- Exchange 2019 (with the latest updates)
The Pexip Infinity VMR Scheduling for Exchange add-in is supported on all Outlook clients that support the Microsoft Outlook add-in API. At the time of release, this includes the following clients:
- Outlook as part of Office 2013 and later on Windows
- Outlook as part of Office 2016 and later on Mac
- Outlook as part of Office 365 on Windows and Mac
- Outlook Web Application (OWA) when connected to any supported Microsoft Exchange deployment.
There are some minor usability issues when using Outlook add-ins under certain circumstances; see Troubleshooting VMR Scheduling for Exchange for more information.
The Pexip Infinity VMR Scheduling for Exchange add-in is dependent on the Microsoft Outlook add-in API. Any changes to the API should be backwards-compatible, but may impact the functionality of the Pexip add-in.
A recent update to the Microsoft Outlook add-in API enabled add-ins for users managing a calendar to which they have delegate access. Pexip Infinity version 24 supports this API update, enabling the use of the VMR Scheduling for Exchange add-in within delegate calendars. To enable this:
- Users must be using Office 365 and a version of Outlook that supports add-ins for delegates. At the time of writing, this only applies to Outlook on Windows as part of an Office 365 subscription. Outlook should be updated to version 1910 (build 12130.20272) or newer. For more information about which Outlook clients support which features, see Microsoft's documentation.
- Delegate users must be set up in accordance with Microsoft's instructions for granting delegate access.
- If you have upgraded Pexip Infinity from a version prior to v24, after upgrading you must download and re-upload the manifest file. For instructions on how to do this, see Making the scheduling add-in available to users. Note that users will then need to restart Outlook, and may need to wait up to 24 hours for the add-in to be enabled.
Enabling the VMR Scheduling for Exchange service within your Pexip Infinity deployment is a three-step process:
- Configuring Microsoft Exchange on-premises or Configuring Office 365 with a service account and equipment resource.
- Configuring Pexip Infinity to connect to a Microsoft Exchange deployment and create the 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; 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.
For recurring meetings, 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.
The diagram below summarizes the connectivity required between the components of the Pexip and Exchange/O365 deployments.
In this example, there are firewalls in place between the Pexip Infinity deployment and the Exchange and Office 365 deployments. Your own deployment may or may not have these, but in all cases you must ensure the following connections are permitted:
- from the Pexip Infinity Management Node to each Microsoft Exchange server: HTTPS, TCP port 443
- from the Pexip Infinity Management Node to login.microsoft.com (if you are using OAuth)
- from the Pexip Infinity Management Node to the load balancer (if you have one): HTTPS, TCP port 443
- from the Outlook clients to the hostname specified by the Add-in server FQDN. This must be reachable either directly, or by using split DNS to resolve to a Transcoding Conferencing Node, Proxying Edge Node, or reverse proxy: HTTPS, TCP port 443
It is possible to host these resources locally for deployments that are entirely offline. For more information, see Advanced options.
VMR scheduling for Exchange integrations support the use of load balancers in front of the Exchange servers. In all deployments using load balancers:
- All FQDNs of all Exchange servers used in the deployment must still be configured in the list of Exchange domains, even if the EWS URL uses the address of the load balancer.
- Each of the individual Exchange servers in the deployment will need a trusted certificate, because the Pexip Exchange integration will be connecting to them directly.
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.