Information Systems:Microsoft 365 Exchange Online - Setup and Configuration

Overview

This wiki page attempts to document and discuss major topics of Exchange setup and configuration. This will be a mix of design/strategy talk and some how-tos for technical administration. Ultimately, another page should be made to adapt the information discussed here into more concise technical instructions for specific administration tasks.

Check this page for how-tos. Any instructions below should eventually be migrated to that page as well.

Mailboxes

Users are essentially mailboxes in Exchange i.e. there is no Users section. In Exchange Online, a mailbox shows up when a user is created in 365 Admin Center.

Shared Mailboxes

Like groups/lists, shared mailboxes are communal to a group of users. But unlike groups/lists, they are actual mailboxes that accumulate mail. The company requires a few of these:

• Accounts Payable: accountspayable@unipharm.com
• Accounts Receivable: accountsreceivable@unipharm.com
• EDI Support: edisupport@unipharm.com
• Customer Service Voicemail: csvm@unipharm.com
• Information Technology Communal email: it@unipharm.com

Adding a shared mailbox

Given the limited number of shared mailboxes, and the company's particular use of them as mailbox "identities" rather than a communal email "sink", it has been decided to add shared mailboxes as separate accounts as opposed to opening them as additional mailboxes.

To add a shared mailbox:

• Remove any shared mailboxes previously opened as additional mailboxes (and not added as accounts).
• Perform the steps to add another email account (Office 365).
• Enter in the shared mailbox email.
• Instead of entering a password, click Sign in as another account.
• Enter in the user's credentials. This will only work if the user has Full Access permissions to the shared mailbox (do this in EAC).

Other methods

The other ways of adding shared mailboxes are discussed here just for reference:

Manually opening a shared mailbox

• In Outlook 2019, File -> Account Settings -> double-click account -> More Settings -> Advanced
• In the Mailboxes section -> Add -> Enter exact Display Name of shared mailbox
• Save/Apply

Automapping

Note: Automapping has been disabled for all shared mailboxes.

• Automapping is a feature that makes the shared mailboxes which a user has access to automatically visible in Outlook i.e. the shared mailboxes are automatically mapped to the user. This is enabled by default. There are implications:

• Automapping lumps the data of shared mailboxes in the same OST file as the user's own mailbox. This is one of the reasons there is official documentation on how to disable automapping and how to reset an automapped Outlook configuration. Considering the company's user base and computer/desktop assignments, this isn't expected to be a problem. But it's something to keep aware of. Imagine a case of 3 users that access 2 shared mailboxes ecah including their own, all logging in to the same computer with a 120GB SSD, with Outlook set to sync all mail. It is feasible for this to grow massively.
• Automapping appears to be very finicky when mailbox delegation (permissions) are set to security groups instead of users. Discussion on the internet refers to having to reset permissions.

Granting a user access to another mailbox

The preferred method of granting a user access to another mailbox is to have them access to read (and send from, if necessary) using Outlook for web (OWA). This is especially true when access is only needed on a temporary basis. The commands can be found here.

Contacts and Groups

Contacts

Contacts (or more accurately, Mail Contacts) in Exchange are analogous to address book entries: they're simply names with email addressses (and other attributes like address and phone numbers). This is in contrast with full Exchange "Users" that have mailboxes. Currently, the primary use of contacts is to maintain distribution lists (we don't maintain a company directory outside CNS, oddly enough).

Shareholder email addresses

In an attempt to maintain clean and consistent entries, several conventions for creating contacts have already been adopted, best depicted in the following example entry for the personal email associated with Marks Marine Pharmacy (the one that would go in the private/sensitive list). The Classic Exchange Admin Center is shown, as it exposes more fields:

Recommendations when creating new entries:

• If this contact/email will be used in private/confidential list only, prefix the Display Name with [Private]. Also, check the 'Hide contacts from the address list'. You may need to do this in Classic EAC.
• If this contact will be a member of both private and general/publicly-visible distribution lists, do not prefix the name.

Groups

The term "groups" in Exchange can mean 1 of 4 things: Microsoft 365 Groups, Distribution Lists, Dynamic Distribution Lists, and Mail-enabled Security Groups. The first is not used whatsoever.

Distribution Lists

Distribution Lists are akin to the conventional mailing list, wherein an email sent to the group address is distributed to its members. This group type is used for the shareholder mailing lists (both general and private/confidential lists).

• Some groups are meant to be internal (e.g IT group), while others are meant to also be addressable by users outside the organization (e.g. Returns). Check related permissions and set up aliases accordingly. For example, Returns group follows the convention returnsgroup@unpharm.com, but it is logical to have returns@unipharm.com as an alias, as this is a more common format for a public-facing contact email address (same as customerservice@unipharm.com).

Mail-enabled Security Groups

This type of group is appropriate for the departments, as the group can be used to send to its members as well as for permissions (hence, "mail-enabled security group").

• The email address convention for department groups (and most other groups) is departmentgroup@unipharm.com.
• The following is an example of a configured group. The manager has been specified as a group owner (in addition to IT) to enable self-management.

Microsoft 365 groups

This type of group has additional functionality to enable better collaboration for the group's members. The company currently does not collaborate in such a fashion for these to be useful (e.g. no Sharepoint, no Teams, no shared folders on cloud storage).

Dynamic Distribution List

This is a good concept on paper as it allows distribution list membership to be dynamic based on attributes e.g. a Customer Service list could be set up to include any users with the "Department" user property set to "Customer Service". However, it was tested to have one major showstopping limitation - it is very inconvenient viewing current members of a DDL (i.e. has to be in PowerShell, and even then, it requires list iteration and filtering). Not being able to see the recipients severely limits its usefulness, and therefore, setting up the departments as dynamic lists was forgone as an endeavor to keep things simple.

Nested groups

A word of caution regarding nested groups.

Nesting groups within other groups generally leads to better-structured and therefore easier to manage permissions. This is especially true with Microsoft AD, where object hierarchy and the concept of RBAC are predominant (a user can be assigned one or more roles, which grants them the specific set of permissions associated with those roles). However, issues have been encountered with group nesting during setup, primarily related to "trying to get too fancy". The ultimate goal was to have permissions and group membership dynamically assigned based on attribute e.g. the user's department. This was found to not even be remotely achievable in Exchange. These general rules of thumb have been surmised from experimentation with group nesting:

• Nesting like group types appears to work. Distribution lists groups are ok to nest within other distribution list groups. The same goes for mail security groups.
• Nesting security groups can lead to some quirks, but is still recommended. For example, nested security groups seems to break shared mailbox automapping and ownership.
• Distribution list groups should not be nested within security groups (see point #1).

TL;DR - exercise caution when using group nesting, and assign permissions to users as a fallback (troubleshoot later).

Address Book

With Exchange address books, there exists two types of implementations: out-of-the-box or address book policies. This fork on the road comes early; either accept the out of the box functionality and do nothing else, or enter the world of address book policy routing and accept the more complex management. This of course depends on the needs of the company, and we needed and decided on the latter. This path also requires PowerShell (no options or visibility exists in EAC, besides the ability to assign an existing policy (created with PowerShell) to a user).

Address book policies

An address book policy allows you to customize what a user sees, from the sublists, to the contacts viewable in those sublists. For example, the default address book policy has the following address lists: All Groups, All Users, All Distribution Lists etc. It is both unintuitive if you are not fully invested in the Microsoft way. For example, we don't use Microsoft groups, so All Groups is empty, and what we know as groups are actually, Distribution Lists. All Users, on the other hand, contains staff, but also shared mailboxes and resources (Projector, iPad), but not rooms. To make even one customization to all of this, ABPs are needed.

• ABP routing is an Exchange flag that has been enabled for our domain.
• An address book policy specifies the following:

* 1 x Global Address List (GAL) - contains all objects (mailboxes, contacts, rooms etc.) that a user is able to "see". An ABP is linked to 1 GAL and therefore a user can only see 1 GAL.

* 1 x Offline Address Book (OAB) - specifies one or more address lists to download/cache. To make it more confusing, the Offline Address Book behaves more like an address list.

* 1 x Room Address List

* 1 or more custom (or built-in) Address Lists - Address Lists are groupings that are subsetted from the GAL. For example, the built-in All Rooms address list filters for GAL objects where the ObjectType is RoomMailbox (not quite, but something to that effect).

Again, all these are created/set in PowerShell.

Get-Mailbox gurneetk@unipharm.com | Select DisplayName,AddressBookPolicy //this is to check if the user has Staff Address Book Policy or Address Book Policy Set-Mailbox gurneetk@unipharm.com -AddressBookPolicy $null //this is to give user access to GAL

Current address book policies

There are two ABPs (default still exists but is not meant to be used).

Address Book Policy	Global Address List	Offline Address Book -> Offline Address List	Room List	Address Lists	Notes
Staff Address Book Policy	Staff Global Address List	Staff Offline Address Book -> Offline Address List (Staff)	Rooms and Resources	Company Contacts, Distribution Lists, Staff, Public Folders	Should be the default assigned to staff members.
Executive Address Book Policy	Executive Global Address List	Executive Offline Address Book -> Offline Address List (Executive)	Rooms and Resources	Company Contacts, Company Contacts (Executive), Distribution Lists, Distribution Lists (Executive), Staff, Public Folders	Can see what staff see, and the private lists/contacts.

Congrats if you're still following at this point.

Address Lists and Filtering

The usefuleness of address book policies lies in filtering (inclusion filtering), which is used to produce address lists. This is a big topic and is mostly PowerShell talk. Therefore, this is left for official technical docs, but provided are two examples to try and explain the concept:

• The address list Distribution Lists (Executive) specifies a filter that translates to:

Include only objects where:

• ObjectClass equals 'group'
• DisplayName is like '*(Private)'

• The address list Staff specifies a filter that translates to:

Include only objects where:

• ObjectCategory equals 'person' AND 'user'
• RecipientType does not equal 'RoomMailbox'
• RecipientType does not equal 'EquipmentMailbox'

These are not the exact filters used, they're meant to explain the concept only.

Relationship between contact management and ABPs

It should be noted that contacts, groups, and group membership are not affected by address book policies. ABPs only affect what a user sees in the address book. A not-good analogy: you can take out pages of a phone directory and group them differently or put stickers over some entries so they're not visible (ABPs), but you don't change what's printed in the directory (that's contact management).

Mail flow and mail rules

Connectors

Because mail hosting for unipharm.com is spread over 2 servers, configuring Exchange "connectors" is necessary to properly route mail to and from MDaemon (the on-prem mail server). This is a complex topic and should be described on another page.

Email security

Email security is handled by Exchange Online Protection, a feature that comes with all Exchange Online / 365 accounts. It "sits" before the mail routing/delivery process - for both inbound and outbound mail flows - and checks messages for threats and spam. The policies determine what gets detected as spam/threats and the outcome of those messages. Depending on if the new or classic admin portal is being used, there are various areas to configure or tweak these policies:

• In Classic Admin Center, these policies are found in the protection section.
• In New Admin Center, these policies are found in a separate Security and Compliance Admin Center altogether, under Threat management.

Malware policies

• Email servers do a fairly good job detecting and blocking viruses in emails, silently. As an organization, we also don't deal with attachment types (.exe, audio/video containers etc.) that are normally flagged as viruses. Therefore, these policies have not been changed from the defaults.

Spam policies

• Unlike spam-handling pre-Exchange that involved a user quarantine, the current spam policy is set to direct spam to a user's junk folder.

Spam scoring

There are two scores related to spam-handling: SCL (Spam Confidence Level), and BCL (Bulk Complaint Level). The Bulk Complaint Level threshold can be set, but the SCL appears to be set (at least for Exchange Online). These values are 5 (spam) and 9 (high-confidence spam), according to the docs

Note: These scores are present in the message headers, and have been validated to make it all the way to MDaemon (in messages destined for non-Exchange mailboxes). Therefore, we could potentially capitalize on the spam and bulk scoring done by EOP by having MDaemon recognize and act on these headers.

Phishing

Phishing remains the greatest threat when it comes to email security. Without Advanced Threat Prection (additional cost on top of EOP), we rely on reputation-based and heuristic-based detection mechanisms of the email security service (EOP) to flag emails that contain phishing content. Barracuda did a fantastic job (very low penetration from empirical evidence). It remains to be seen how EOP handles these types of "attacks" (they come in waves).

Security/AAA

Custom Admin Roles

Exchange allows for the creation of custom admin roles that have a specific combination of permissions. For example, the Company Directory Management role was created to allow users to manage the address book:

Password policies

• Password expiry has been disabled in 365 from the 90-day default:

• Self-service password resets have been enabled in Azure AD. Users will be notified when they reset their passwords:

• (Update this section with info on password management strategy when it gets discussed)

DNS

MX settings

The MX record for our common domains point to Exchange. We do not have a round-robin or fallback configuration. Mail routing between Exchange and MDaemon is done through connectors and smart-host configuration.

SPF record

SPF was implemented as part of the Exchange project. This article summarizes how SPF works and is configured for Exchange.

A web tool like MXToolbox can be used to verify the SPF record after changes are made:

Other Notes

• Microsoft is currently transitioning from what they're now terming Classic Exchange admin center to the New Exchange admin center. Some options remain editable only in the old portal.