Resource Central with OfficePlace requirements for O365

1. Application server system requirements

System requirements for Resource Central 4.3 - Add-On Products

Diagram:

2. Pre-installation steps

The configuration detailed in this section must be carried out before Resource Central can be installed.

SQL server

The SQL server must allow SQL authentication, and we need a login during installation that allows us to create a database for Resource Central. Once the database is created DB_Owner rights suffice.

Further requirements:

• “Full-Text and Semantic Extraction for Search” feature must be installed.
  Check with the following query:

Application server

We have the following requirements for the Windows Web server.

• English language.
• .NET Framework 4.8
• .NET 8 Webhosting bundle (download here)
• IIS and asp.net – see detailed list in box below:

Furthermore, these are strong recommendations:

• Assign a DNS A record (or a cname).
• We recommend using an SSL certificate for the website.
• Exclude services and folders as exemplified with Defender exclusions in box below:

O365 service account

We need a service account in O365 with the following:

• It must have a mailbox.
• Cannot be hidden in GAL.
• Must be member of “View-Only Organization Management” Exchange role.

With OfficePlace we can connect to your tenant with either Application permission or Delegated permissions. If you choose to use delegated permissions, then the service account must be granted the following permissions.

See more details here: Required permissions for Service Account with delegated access 

1. Full Access & Send As to resource mailboxes
2. Calendar Editor rights to user mailboxes (Optional depending on the usage scenarios)

Microsoft Graph access for OfficePlace

Resource Central uses OfficePlace as connector to provide needed data sync from your Office 365 tenant via Microsoft Graph. To establish this connection you will need to create an Entra ID Application. There are two fundamentally different permission methods that can be selected, where we either connect on behalf of a service account or where we utilize application permissions. You need to select the method that fits your needs.

Delegated access

With delegated access it is important that the service account has the required permission to work as mentioned in the section above. We have two guides that provide guidance on how to configure this method in your Entra ID:

• Manual method: Entra ID Application setup for Delegated permission type 
• Powershell method: Entra ID Application setup for Delegated permission type using Powershell 

Application access

With application access the permissions are granted to the Entra ID application, which by default provides access to the entire organization. In this scenario you can follow these guides.

• Manual method: Entra ID Application setup for Application permission type 
• Powershell method: Entra ID Application setup for Application permission type using Powershell 

It is possible to use role based access control in Exchange Online to limit the access to an Entra ID app that relies on application permissions. In this scenario you must prepare an Exchange security group with your resources, and similarly create an Exchange security group with your users that must be managed by Resource Central with features like Booking Manager. This can only be achieved with Powershell as described here:

Entra ID Application setup for Application permission type using Powershell & RBAC 

The outcome of the above regardless of method will be these values.

• Tenant ID
• Application ID
• Secret Key

Single Sign-On for OfficePlace

With OfficePlace we require that SSO is configured to secure the admin access, and this will require an additional Entra ID Application. We provide a manual and a scripted method as described here:

• Manual method: Entra ID Application setup for External Authentication 
• Powershell method: Entra ID Application setup for External Authentication using Powershell 

Resource mailboxes

Resource mailboxes must be created for rooms, equipment or other kinds of resources that should be part of Resource Central. We recommend that the following is prepared:

• Add all rooms intended for Resource Central to a flat security group (or distribution list) for management purposes.
• Ensure that resource scheduling is correctly set up.
• We recommend that you take steps to preserve the subject of meetings.
  Below sample script does this for all resources in your organization:

• Use policies in Exchange to control who can book or request a room. (described here)
  

3. Post-installation steps

The points below cannot be implemented until the Resource Central environment is running.

Office add-in deployment

We always recommend implementing FQDN for the Resource Central web site to get a nice name for the users that will connect to the backend, but also to allow for easy replacement in case a server dies.

In this case where the Office Add-in is a topic, the following is required for the Resource Central web site:

• Must have a DNS A record (or a cname).
• The site must have a valid public SSL certificate.
• The site must be accessible to the public. (Implementation of the Office add-in involves importing a manifest that points back the Resource Central website, and O365 must be able to make the connection and requires a valid SSL certificate.

Here is some additional information surrounding the Office add-in from our knowledgebase.

- Entra ID app guide: How to configure Entra ID Application for the New Outlook Add-in

- Installation guide: Client Apps Installation Guide (New Outlook Add-in)

- User guide: Outlook Add-In User Guide

External authentication - SSO

Resource Central supports several SSO methods that can be tied to O365.

We do not recommend the use of SAML as Microsoft Teams lacks support for it.

The preferred method is described in this support article:
External Authentication Details for OpenID Connect in Azure

Conditional access rule protecting the service account.

Once the environment is in place a fixed IP will be assigned, and with this it is possible to create a conditional access policy in your tenant that restricts the service account login to this IP

The methods are described in this support article: 

Block external access for O365 Service Accounts using Conditional Access in Azure AD

Properties

Applies to: RC 4.3 SR3+

Last updated: Jan 14, 2025