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 the VMR Scheduling for Exchange feature has been enabled, you can create Pexip Exchange Integrations to one or more Microsoft Exchange deployments.
In this topic:
- Supported Exchange deployments
- Supported clients
- Enabling VMR Scheduling for Exchange
- Process flow
- PXPS:- and TOK:- security tags
- Recurring meetings
- Network architecture and firewalls
Pexip Infinity VMR Scheduling for Exchange is supported on the following Microsoft Exchange deployments:
- Office 365
- Exchange 2013 (SP1 or later)
- Exchange 2016
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 2013 and Outlook 2016 for Windows. (Internet Explorer must be installed and up-to-date.)
- Outlook Web Application (OWA).
- Outlook 2016 for Mac (with the latest updates).
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.
Enabling the VMR Scheduling for Exchange service within your Pexip Infinity deployment is a three-step process:
- Configuring Microsoft Exchange/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 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.
Pexip 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.