Meetings/Planner connects to Microsoft 365 through Enterprise Applications, which can access every mailbox and room in your organization by default. This article shows Microsoft 365 administrators how to limit that access to the mailboxes they choose. There are two ways to do this:
Note - This setup is optional. Meetings/Planner works as expected without it, and only accesses the users, rooms and groups you configure in Meetings/Planner.
Before you begin
You need the App ID of each application you want to limit. Meetings/Planner uses two Enterprise Applications in Microsoft Entra:
Enterprise Application | App ID | Permissions |
Meetings/Planner - Outlook Add-In | aec43bb4-8f84-4621-a44c-41201195256d | Application Calendars.Read |
Calendar Service | 351d434c-2e44-41d7-ba28-268ecd8f56c2 | Application Calendars.ReadWrite |
You will also need:
An account with sufficient admin access to Microsoft Entra ID and membership of the Organization Management role group in Exchange Online.
The Exchange Online PowerShell module. See Connect to Exchange Online PowerShell.
Which option to choose
RBAC for Applications is the go-forward method recommended by Microsoft for securing Enterprise Application level permissions. Both work correctly within the Meetings/Planner solution and are both documented below. Neither option limits Delegated permissions, where the app acts as the signed-in user.
Note - Microsoft RBAC does NOT support nested security groups. AAP does but is deprecated in favour of RBAC by Microsoft.
Option 1: RBAC for Applications
RBAC for Applications grants an app its mailbox permissions in Exchange Online, limited to a management scope.
1. Create the group. In the Microsoft 365 admin centre, create a mail-enabled security group and note its email address.
2. Add members. Add every mailbox and room the policy should cover. All users and rooms that you want to use in Meetings/Planner must be in this group.
Repeat steps 3–9 for each Enterprise Application listed in the table above.
3. Find the app's Object ID. In the Microsoft Entra admin centre, open Enterprise applications and select the app. Copy its Object ID. Don't use the IDs on the App registrations page: they are different values.
NOTE - The Object ID for an Enterprise App is different for each Microsoft tenant, unlike the App ID, which is consistent across multiple environments.
4. Check which permissions to scope. On the app's Permissions page, note every permission with Type Application. For Meetings/Planner’s two Enterprise Applications, the Application permissions are listed in the table above.
5. Connect to Exchange Online and set your values.
Connect-ExchangeOnline -UserPrincipalName [AdminEmail]
$appId = "[AppId]"
$spObjId = "[ObjectId]"
$scopeName = "[AppName] - Mailbox Scope"
$roles = @("[Permissions]")
6. Register the app in Exchange Online.
New-ServicePrincipal -AppId $appId -ObjectId $spObjId -DisplayName "[AppName]"
7. Create the scope. The .Replace part stops an apostrophe in the group's name from breaking the filter.
$groupDN = (Get-DistributionGroup "[GroupEmail]").DistinguishedName.Replace("'", "''")
New-ManagementScope -Name $scopeName -RecipientRestrictionFilter "MemberOfGroup -eq '$groupDN'"
8. Assign the roles to the scope.
foreach ($r in $roles) {
New-ManagementRoleAssignment -App $spObjId -Role $r -CustomResourceScope $scopeName -Name "[AppName] - $r"
}
9. Remove these permissions from Entra ID. RBAC permissions are added on top of any permissions granted in Entra. Therefore, while permissions are still granted in Entra, the scope has no effect.
In the Microsoft Entra admin centre, open Enterprise applications, then the app, then Permissions.
On the Admin consent tab, select Revoke permission for the Application permissions you’ve granted with RBAC.
Leave the sign-in permissions (openid, profile, email, offline_access) and any directory permissions (such as User.Read.All or Group.Read.All) in place.
Exchange can't scope them, and removing them stops the app working.
Note - If an administrator later selects Grant admin consent for the app in Entra, the removed permissions return and the RBAC scope stops working.
Check RBAC works
Test one mailbox that should be allowed and one that should be blocked. Use the command for the option you set up, and compare the result with the table below.
Method | Command | Allowed result | Blocked result |
RBAC | Test-ServicePrincipalAuthorization -Identity [ObjectId] -Resource [MailboxEmail] | InScope: True | InScope: False |
To change who has access, simply add/remove mailboxes from the group as needed.
Note - Changes can take up to 2 hours to propagate through to Meetings/Planner. The test commands confirm the configuration, not that Meetings/Planner is enforcing it yet.
See What users see when access is blocked to confirm the change in Meetings/Planner.
Option 2: Application Access Policies
An Application Access Policy limits an app to the members of a group.
Note: Microsoft has replaced Application Access Policies with RBAC for Applications.
1. Create the group. In the Microsoft 365 admin centre, create a mail-enabled security group and note its email address.
2. Add members. Add every mailbox and room the policy should cover. All users and rooms that you want to use in Meetings/Planner must be in this group.
3. Connect to Exchange Online.
Connect-ExchangeOnline -UserPrincipalName [AdminEmail]
4. Create the policy. Run one command per application.
New-ApplicationAccessPolicy -AppId [AppId] -PolicyScopeGroupId "[GroupEmail]" -AccessRight RestrictAccess -Description "Restrict [AppName] to members of [GroupEmail]"
Check Application Access Policies works
Test one mailbox that should be allowed and one that should be blocked. Use the command for the option you set up, and compare the result with the table below.
Method | Command | Allowed result | Blocked result |
AAP | Test-ApplicationAccessPolicy -AppId [AppId] -Identity [MailboxEmail] | Granted | Denied |
To change who has access, simply add/remove mailboxes from the group as needed.
Note - Changes can take up to 2 hours to propagate through to Meetings/Planner. The test commands confirm the configuration, not that Meetings/Planner is enforcing it yet.
See What users see when access is blocked to confirm the change in Meetings/Planner.
What users see when access is blocked
Once the policy or scope is in place, Meetings/Planner can't access blocked mailboxes. Users see the same error messages irrespective of the option chosen.
Meetings Outlook add-in
When any user tries to book a blocked room, the add-in shows Unable to save the meeting with the message An error occurred fetching calendar appointments from Microsoft 365. The meeting is not saved.
Meetings/Planner web
When a user whose own mailbox is blocked books any room, Meetings/Planner shows The meeting could not correctly be linked to exchange.
Troubleshooting
Message or symptom | Cause | Fix |
Meetings/Planner is still blocked after a mailbox was added to the group | Changes haven't applied yet | Wait up to 2 hours |
Invalid filter syntax ... at position NN from New-ManagementScope | The group's name contains an apostrophe, which ends the filter early | Use the .Replace("'", "''") line from Option 1, step 7, or rename the group |
The [name] management scope wasn't found | The scope wasn't created, or its name doesn't match exactly | Run Get-ManagementScope and copy the name. Use the $scopeName variable in both steps |
The "[permission]" management role can't be found | The permission isn't a mailbox permission, or Application is missing from the name | Use names such as Application Calendars.Read. Leave out openid, profile, email, offline_access, User.Read.All and Group.Read.All |
Test shows the mailbox is blocked, but Meetings/Planner can still access it | The same permission is still granted in Entra ID | Revoke it in Entra, as in Option 1, step 9 |
A mailbox was not added to the scope after being added to the group | The mailbox is a member only through a nested group | Add the mailbox to the group directly |
Note - If you run into any issues that aren’t listed here, please contact our support team
Blocking a group
The steps above let Meetings/Planner access only the group's members. To block the group's members and let Meetings/Planner access every other mailbox instead, follow the same steps with the changes below.
Option 1: RBAC for Applications
RBAC for Applications has no deny setting. Instead, the scope includes every mailbox except the group's members. This translates as creating the scope with -ne instead of -eq:
New-ManagementScope -Name $scopeName -RecipientRestrictionFilter "MemberOfGroup -ne '$groupDN'"
Option 2: Application Access Policies
In step 4, use DenyAccess instead of RestrictAccess:
New-ApplicationAccessPolicy -AppId [AppId] -PolicyScopeGroupId "[GroupEmail]" -AccessRight DenyAccess -Description "Deny [AppName] to members of [GroupEmail]"
If an app has both a DenyAccess and a RestrictAccess policy that cover the same mailbox, DenyAccess takes priority.