O365 Resource Central requirements

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 SAAS can be installed.

SQL server

The SQL server must allow SQL authentication, and we need a login during installation that allows us to create the 2 databases. Once databases are 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 granted the following permissions.
  See more details here: New Required Permissions for Service Account after Impersonation rights are deprecated
  1. Full Access & Send As to resource mailboxes
  2. Calendar Editor rights to user mailboxes (Optional depending on the usage scenarios)

Optional requirements for use of Resource Finder permissions and Resource Data Sync:

Resource Central has some features that can collect information from Mailbox settings, Calendar settings etc. with the purpose of synchronizing values from Resources and to effective booking permissions for the individual user based on group memberships and booking policies applied to resources. The use of these features requires furthermore that:

• Must be member of “View-Only Organization Management” Exchange role.

Azure AD access with modern authentication

Resource Central needs a connection to AD to look up people, locate mailboxes and read basic information, and in O365 this information resides in Azure.

When modern authentication is enforced this Azure app is not only used for AD access, but also to provide the service account authentication endpoint for Realtime Service. Follow the instruction in this knowledgebase article to create the app:

How to set up Realtime Service with Modern Authentication

We will need the following information to configure this connection:

• Tenant name in O365. (xxx.onmicrosoft.com)
• Application ID
• Secret Key
• Scope URI

Resource mailboxes

Resource mailboxes must be created for rooms and equipment that should be part of Resource Central, and we recommend that the following is prepared:

• Add all rooms intended for Resource Central to a 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)
  
  

Firewall requirements

The Exchange connection method we use requires that traffic from Exchange EWS (in this case Exchange online) which is TCP port 10002 is allowed inbound through the firewall and subsequently NAT redirected to the server where Resource Central is running. Microsoft has a web service that can deliver updated information about the IP pool they use (described here)

A complete list of all the communication ports we use with our Exchange connection tool (Realtime Service) can be found here (focus should be on push notification on port 10002 since the other inbound are used locally on the server):
Inbound and outbound RealTime Service (RTS) ports and needed IP addresses

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 - Add-On Products

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

- User guide: Outlook Add-In User Guide - Add-On Products

Outlook COM add-in deployment

This is the full com Outlook add-in which must be deployed to the client computers.
User guide: Resource Central - User Guide

We have several Knowledgebase articles on this subject, and you will find some basic information in the guide associated with the add-in:

- Installation guide:
Resource Central - COM Add-in 4.1 Installation Guide

- Deployment guides:
How to Deploy Add-in 4.1 using Command Line, PowerShell, or Windows Terminal using command line, PowerShell or Windows Terminal 

Deploy ResourceFinder as an WIN32 App With Endpoint Manager (INTUNE).

- Additional topic:

Alerts on Add-in produced by Outlook

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 : Add-On Products

Properties

Applies to: RC 4.3+

Reference: TFS #297975

Knowledge base ID: 0305

Last updated: Jun 02, 2023

Attachments (2)

pdf

RC_O365_requ....pdf
262 KB

xF8vvixI7rAO....jpeg
67.4 KB