Configuring Exchange on-premises for scheduling
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.
To enable users to schedule meetings in single-use VMRs in an
Creating a service account. The Pexip Infinity VMR Scheduling for Exchange feature uses a unique service account to log into Exchange.
This should be a different service account to any used for One-Touch Join, because the configuration will be different.
Configuring Application Impersonation on the service account. This allows the service account to impersonate all users and resources in Exchange.
As an alternative, you can allow the service account to impersonate the VMR Scheduling for Exchange equipment resource only, but this will limit the functionality of the feature. For more information, see Using application impersonation.
Create an equipment resource. This resource will be added as an attendee to all meetings scheduled using the Pexip add-in.
- Configure the equipment resource.
- Enable the authentication method used for the service account — either NTLMv2 or basic authentication.
PowerShell commands are provided for all steps; parameters to be replaced with your own relevant information are shown in the format <your info here>.
Before you start, ensure you have access to your Exchange Admin Center (EAC) web interface, and access to Exchange Management PowerShell.
In this step, you create the service account to be used by VMR Scheduling for Exchange.
The VMR Scheduling for Exchange feature uses a service account to log into Exchange. You can use an existing service account (the same service account can be used by more than one VMR scheduling for Exchange integration), or create a new account.
You need to provide the authentication credentials of this service account when configuring Pexip Infinity to integrate with a Microsoft Exchange deployment.
A single service account can be used by more than one VMR scheduling for Exchange integration.
Changes to the service account may take some time to take effect, depending on the cache lifetime configured on the Microsoft Exchange server.
You can create a new service account using either EAC or PowerShell, as follows:
The first command lets the administrator type in a password for the service account as a secure string. This password variable is then used in the second command to create a mailbox for the service account. The third command ensures the password of the service account will not expire.
$password = Read-Host "Enter password" -AsSecureString
New-Mailbox -Name "<Account Name>" -UserPrincipalName "<UPN>" -Password $password -Alias "<Account Alias>" -FirstName "<Account First Name>" -LastName "<Account Last Name>" -DisplayName "<Account Name>"
Set-ADUser -Identity "<UPN>" -PasswordNeverExpires $true
New-Mailbox -Name "Service Account" -UserPrincipalName email@example.com -Password $password -Alias pexip -FirstName Service -LastName Account -DisplayName "Service Account"
Set-ADUser -Identity firstname.lastname@example.org -PasswordNeverExpires $true
In this step you configure the service account with a Role of Application Impersonation. This allows the service account to impersonate the equipment resource that is to be used for the VMR Scheduling for Exchange, and all users who will be using this service. Alternatively, you can allow impersonation of the equipment resource only, but this will limit the functionality of the VMR Scheduling for Exchange feature. For more information, see Using application impersonation.
The VMR Scheduling for Exchange service impersonates users when sending email updates containing joining instructions (in cases where these instructions could not be added at the time of scheduling). This makes it appear to the recipients that the joining instructions were sent from the meeting organizer, instead of the service account. The service account also impersonates the VMR Scheduling for Exchange equipment resource in order to read the calendar.
To check if your service account has Application Impersonation already configured, use the PowerShell command:
Get-ManagementRoleAssignment -RoleAssignee "<email_of_service_account>" -Role ApplicationImpersonation | Format-List
Below is an example of the output of the command when the service account already has Application Impersonation configured:
If the service account does not have Application Impersonation configured, then the above command will not return anything at all. If this is the case, enable Application Impersonation as follows:
New-ManagementRoleAssignment -name:"<role_name>" -Role:ApplicationImpersonation -User:"<email_of_service_account>"
New-ManagementRoleAssignment -name:PexipSchedulingService -Role:ApplicationImpersonation -User:email@example.com
This will enable the service account to impersonate all users and resources in the organization.
For more information on these commands, see Microsoft help:
- Configuring Application Impersonation: https://msdn.microsoft.com/en-us/library/office/dn722376%28v=exchg.150%29.aspx
- Get-ManagementRoleAssignment command: https://technet.microsoft.com/en-us/library/dd351024(v=exchg.150).aspx
- New-ManagementRoleAssignment command: https://technet.microsoft.com/en-us/library/dd335193(v=exchg.150).aspx
- Set-ManagementRoleAssignment command (used if you need to edit the role assignment): https://technet.microsoft.com/en-us/library/dd335173(v=exchg.150).aspx
If you do not want to permit the service account to access all users and resources in your organization, you can instead permit it to access the VMR Scheduling for Exchange equipment resource only, but this will limit the functionality of the feature. For more information, see Using application impersonation.
To do this, you must first create the equipment resource and assign it an email address.
Then use the following PowerShell command:
$restriction_filter = "UserPrincipalName -eq ""<email_of_equipment_resource>""" $scheduling_service_account = "<email_of_service_account>" $management_scope_to_create = "Pexip Scheduling Management Scope" $impersonation_role_name_to_create = "Pexip Scheduling Impersonation" New-ManagementScope -Name $management_scope_to_create -RecipientRestrictionFilter $restriction_filter New-ManagementRoleAssignment -Name $impersonation_role_name_to_create -Role ApplicationImpersonation -User $scheduling_service_account -CustomRecipientWriteScope $management_scope_to_create
In this step you create an equipment resource to be used by VMR Scheduling for Exchange. This resource is added as an attendee to all meetings scheduled using the Pexip add-in. The scheduling service monitors the equipment resource's mailbox, processes all meeting requests sent to it, and schedules the meetings as appropriate.
An equipment resource can only be used by a single VMR scheduling for Exchange integration. If you have separate test and development environments, you must use a different resource for each.
The equipment resource will be added as a resource attendee to all VMR Scheduling for Exchange meetings. Users will see replies from this resource when it accepts or rejects a meeting request.
Each equipment resource can be used by only one VMR scheduling for Exchange integration.
Previously we recommended using a room resource, but this may cause issues if users are using the Room Finder tool. For this reason, we now recommend using an equipment resource.
You can create an equipment resource using either EAC or PowerShell, as follows:
This command creates an equipment resource with the specified Name, Alias and Display Name. Name and Display Name should be the same, and will appear as the location of any meeting requests, and as a recipient. The Alias (also known as the mail nickname) will be used as the email address.
New-Mailbox -Equipment -Name "<Equipment Name>" -Alias "<Equipment Alias>" -DisplayName "<Equipment Name>"
New-Mailbox -Equipment -Name "Pexip Meeting" -Alias pexipmeeting -DisplayName "Pexip Meeting"
In this step you disable automatic processing for the equipment resource, so that the processing can be done by the scheduling service. You must also configure it to permit conflicts, because meetings may be scheduled at the same time by different users.
This configuration is done using the following PowerShell command:
Set-CalendarProcessing -Identity "<email_of_equipment_resource>" -AutomateProcessing None -AllowConflicts $true -BookingWindowInDays 1080 -MaximumDurationInMinutes 0 -AllowRecurringMeetings $true -EnforceSchedulingHorizon $false -ScheduleOnlyDuringWorkHours $false -ConflictPercentageAllowed 100 -MaximumConflictInstances 2147483647
To verify that the above command has configured everything correctly, use the PowerShell command:
Get-CalendarProcessing -Identity "<email_of_equipment_resource>" | Format-List
The output should look something like this:
For more information on these commands, see Microsoft help:
- Set-CalendarProcessing command: https://technet.microsoft.com/en-us/library/dd335046(v=exchg.160).aspx
- Get-CalendarProcessing command: https://technet.microsoft.com/en-us/library/dd298137(v=exchg.160).aspx
In this step you enable your Exchange on-premises deployment to support your chosen authentication method for the service account. VMR Scheduling for Exchange uses basic authentication by default, but you can elect to use NTLMv2 authentication instead.
For both forms of authentication, Pexip Infinity stores the credentials in encrypted form and all authentication is carried out over a secure TLS channel.
In most on-premises Exchange deployments, NTLMv2 authentication is enabled by default. To confirm that it has been enabled in your environment:
- Open Server Manager and select the server on which Exchange is installed.
- From the top right options select Tools > Local Security Policy.
- On the tree on the left, expand Local Policies then select Security Options.
- Scroll down to Network security: Restrict NTLM: Incoming NTLM traffic.
- Ensure this is either left to the default value of Not Defined, or set to Allow All.
If you are using basic authentication with on-prem Exchange you need to ensure it is enabled for Exchange Web Services (EWS).
You can do this using either Windows Service Manager or PowerShell, as follows:
|Windows Service Manager||PowerShell|
This command enables basic authentication for EWS on a specific server:
Set-WebServicesVirtualDirectory -Identity "<server>\EWS (Default Web Site)" -BasicAuthentication $true
For example, if your server name is PEXCHANGE then:
Set-WebServicesVirtualDirectory -Identity "PEXCHANGE\EWS (Default Web Site)" -BasicAuthentication $true
There may be occasions, such as when troubleshooting, that you want to view the equipment resource's mailbox or calendar. To do this, you first need to assign full access to the equipment resource's mailbox to a delegate account, and then view the mailbox or calendar using the delegate account. (The delegate account could be the service account, or it could be, for example, an administrator's account.)