DO NOT do this! in Exchange Online
Krähe mit Hut
In IT, there's often no single "one" solution for everything. Configurations, malfunctions, and problems can be handled in various ways, for example, via graphical interfaces, command-line solutions, or third-party tools. Personal approaches can also vary greatly. This has a lot to do with individual experience, but also with when you entered the IT field.
Therefore, a procedure isn't inherently right or wrong just because it doesn't align with your personal approach. However, there are things that are ALWAYS wrong—regardless of experience, entry point, or personal preferences. Yes, there are even things that are downright nonsense and should therefore never be done. This article is part of a series about things you should avoid or ABSOLUTELY NOT do. This article focuses on Exchange Online.
Do NOT modify the role "Organization Management"!
This warning could actually apply to all roles in the Microsoft Cloud. However, let's use Exchange Online as an example to explain why modifying default roles is a bad idea.
The role based access model (RBAC)
Microsoft uses a role-based access control (RBAC) model for its services. Roles are provided in the form of groups, each with a predefined set of permissions for the respective service. Users can then be assigned to these roles and thereby receive the permissions associated with that role.
Of course, some roles have very broad permissions. The Organization Management role, for example, has full administrative permissions for Exchange Online. Furthermore—and this is where the first problem arises—this role also grants permissions for other services, such as the Defender portal (email security via Defender for Office 365) and the Purview portal (retention and MRM policies).
These roles are also used internally by Microsoft for automated processes, in addition to authorizing user accounts.
Please do not change anything!
Someone might think, "This role has far too many privileges, and we don't use Purview anyway. I'll just remove these roles!" Or, one might remove the "Global Administrator" role from the assignment to restrict its privileges.
However, this is definitely not a good idea!
As previously explained, these roles are also used in the background to automate tasks. If changes are made, these tasks may no longer be able to execute, leading to malfunctions. The dangerous aspect here is that these malfunctions don't always occur immediately. Therefore, it can be difficult to determine the actual cause later on.
The following example clearly illustrates the potential consequences of role changes. In this example, the Exchange Hybrid Deployment Wizard no longer works because a command is missing: The term Get-OrganizationConfig is not recognized - ALI TAJRAN
Therefore: leave the roles as they are! If you have individual requirements, create additional, custom roles instead and use these for your rights and roles concept.
Do NOT create mailbox move requests!
In on-premises Exchange Server environments, it is quite common to move mailboxes between databases. This can be done both via the graphical interface and using the Exchange Management Shell, as illustrated below.
# First, start the Exchange Management Shell or connect to the Exchange Server, then run the following command.
New-MoveRequest -Identity 'john.doe@microwsoft.de' -TargetDatabase 'MBX-DB-01'When do I need mailbox move requests?
There can be various reasons for moving a mailbox to a different database. Examples include:
- Database performance issues
- The database is running out of storage space
- Upgrading to a newer Exchange version (this should be unnecessary with the Subscription Edition 😉)
It is a common misconception that mailbox migrations also involve repairs to the mailbox. The mailbox is simply transferred 1:1—including all errors, as far as possible—to the new database. If too many errors occur during this process, they can be ignored. However, this does not resolve the issues. Instead, the affected elements are not migrated.
A dedicated PowerShell command is available for repairs. Details regarding the parameters can be found in the official article: New-MailboxRepairRequest (ExchangePowerShell) | Microsoft Learn
# Create a new repair request - the parameter -Archive is only necessary if the mailbox has an online archive.
New-MailboxRepairRequest -Mailbox 'john.doe@microwsoft.de' -CorruptionType AggregateCounts,FolderView,ProvisionedFolder,SearchFolder -ArchiveLet Exchange Online do it itself!
In Exchange Online, however, this functionality is not available—at least not in the graphical interface. Here, only move requests to/from other systems (e.g., Exchange Server, Google Workspace) can be configured.
Like Exchange Server, Exchange Online also provides access via PowerShell. Since there are some additional functions that are exclusively available through PowerShell, one might assume that move requests can still be created here, for example, in the event of a problem.
However, this is definitely not a good idea!
Exchange Online is designed to intelligently and automatically balance mailboxes and even entire organizations across Exchange clusters. Appropriate automations are in place for this purpose. Manually creating a move request can significantly disrupt these processes. The following article clearly describes this and Microsoft's statements on the matter: Microsoft warns IT admins against using this unsupported Exchange Online configuration - Neowin
Microsoft also provides a hint regarding the intended use in the official article about the command: New-MoveRequest (ExchangePowerShell) | Microsoft Learn
Note: After April 15, 2020, you shouldn't use this cmdlet to manually move mailboxes within an Exchange Online organization. You can only use this cmdlet for migrating to and from Exchange Online. If you have issues with a mailbox and want to fix it by moving the mailbox within your Exchange Online organization, please open a Microsoft Support request instead.
Therefore: trust the automated processes set up in Exchange Online! Always check whether a PowerShell command is enabled for Exchange Online before using it.
Do NOT import PST files via Outlook!
PST files were once a common way to create mailbox archives. This allowed users to keep their mailboxes relatively small while still having access to all their emails. PST files are also frequently used for migrations because they allow all mailbox contents to be transferred. However, migration solutions often encounter problems when the source environment uses outdated protocols like POP and IMAP.
Loved by users, hated by IT
However, for IT support staff, they are usually an object of hatred, as they bring with them several issues:
- Storing files on network drives is not supported.
- Storage in OneDrive is not recommended, as PST files use an older format that can cause synchronization problems.
- Archive files are very fragile and can be easily corrupted. This necessitates repair, which can take a very long time for larger files.
Aus diesen Gründen wird mittlerweile vom Einsatz von PST-Dateien generell abgeraten. Microsoft hat mit dem Online-Archiv eine moderne und einfach zu verwendende Alternative geschaffen. Die Empfehlung lautet daher, PST-Dateien in das Online-Archiv zu importieren.
Import PST files - but NOT via Outlook!
Even in local Exchange Server environments, simply importing PST files via Outlook was never a good idea. The reasons are simple:
- The import function is not designed for large amounts of data. If the import is interrupted prematurely (e.g., due to a program crash), it must be restarted completely. While the import function offers duplicate detection, this does not significantly speed up the import process.
- Outlook is completely blocked for the duration of the import. Therefore, the user cannot use Outlook during this time and must resort to alternatives (and no, granting the administrator full access to the mailbox and importing on a different system is not a good idea for data privacy reasons! 😉).
- Exchange Cached Exchange Mode is not designed for uploading large amounts of data. Therefore, significant performance issues may occur in Outlook after the import.
For this reason, there is a dedicated PowerShell command for this in Exchange Server (requires the assignment of the 'Mailbox Import Export' role):
# First, create a shared folder and place the PST files to be imported into it, then execute the following command.
New-MailboxImportRequest -Mailbox 'john.doe@microwsoft.de' -FilePath '\\<server name>\<share name>\archive.pst -IsArchiveUnfortunately, this command is no longer available in Exchange Online – likely for the same reasons as New-MoveRequest (see above). Instead, the network upload service must be used. This uploads the PST files to be imported to an automatically provided Azure storage account and maps them to the mailboxes they are to be imported into using a CSV file. Further details can be found in the following article: Use network upload to import PST files | Microsoft Learn
Do NOT use a mail system with multiple Exchange Online tenants!
Exchange Online does not always have to be used as the primary email system. There may be cases where an on-premises mail gateway is still required, for example:
- If an application or system does not support authentication or only supports basic authentication
- If bulk email sending is needed
- If Exchange Web Services must be used (these are expected to be decommissioned in Exchange Online by the end of 2026).
Using Exchange Online for outbound emails
You can configure a local mail gateway to send outgoing emails via Exchange Online, thus utilizing its mail filter, for example. This requires creating a connector in Exchange Online. For authorizing third-party systems, you can use the system's public IP address or a certificate.A certificate is the significantly better approach, as it provides a higher level of security. A system must have a valid certificate; otherwise, the connection will be rejected. With public IP addresses, no further restrictions can be applied, meaning a malicious system could potentially be hiding behind the public IP address.The certificate should be chosen to include one of the accepted domains, as this offers the highest level of security. However, you can also simply check the validity of the certificate.
Use a suitable certificate and a one-to-one relationship!
However, these two limitations (IP address and the use of any valid certificate) can lead to several misconfigurations.Case 1: Multiple systems use the same certificate to authenticate with multiple Exchange Online tenants. The certificate contains no domains or only one of the accepted domains from one of the tenants.Case 2: A public IP address is permitted for email delivery in multiple Exchange Online tenants. This can occur, for example, when a company migrates from one tenant to another during an integration or spin-off, resulting in duplicate connectors.Since Exchange Online is a multi-tenant environment, specific mechanisms are in place to determine which tenant a message belongs to. If one of the misconfigurations described above is present, Exchange Online may no longer be able to determine the correct tenant, and delivery will fail. Similarly, internal processes such as migration operations between Exchange clusters can cause such configurations to suddenly stop working.
Microsoft clearly describes the problem in a post in the M365 message center: https://admin.cloud.microsoft/?ref=MessageCenter/:/messages/MC1226222
For these reasons:
- Use a separate certificate for each system that includes an accepted domain. Configure the connector to check the certificate name, not just its validity.
- If you need to use public IP addresses, ensure they are shared only within a single Exchange Online tenant.
Do you know of any other things you should NOT do in Exchange Online? Then leave a comment!
Liked this article? Share it!
