Mailbox Provisioning in eADM

This article explains how eADM assigns User Principal Name (UPN), primary SMTP address and email aliases, and how mailbox provisioning differs across local Active Directory, hybrid (remote mailbox) and cloud-only account models.

Please note that this article is very general, since the exact mailbox provisioning rules varies from customer to customer!


How eADM assigns UPN and primary SMTP

eADM sets a user's userPrincipalName (UPN) and primary SMTP address when the account is created, based on rules configured in the synchronisation template. These rules typically use organisational data such as name, department and position code.

Usually eADM follows a single account, single password principle. One employee has one account and one password across local Active Directory, Entra ID and Google Workspace. UPN and primary SMTP can be set according to the employee's workplace. If an employee changes position, for example from a health department to a school, the mail domain can be updates automatically and the previous address is kept as an alias.

Multi-employer and multi-position users

In an eADM tenant with multiple organisations, an employee with positions in several organisations or units has their position data imported and correlated from every active employment. The national identity number links records across source systems. Access rights are additive: the user receives the sum of access from all active positions.

UPN and primary SMTP are set from the employee's main position, for example the position with the highest percentage or the longest seniority. This is configurable per customer. If one of the employments ends, only the access tied to that specific position is withdrawn. Email aliases may be created for the other employments.


Local, remote and cloud-only account models

eADM supports several levels of integration with Microsoft's directory services, ranging from a purely on-premises setup to a cloud-only tenant with no local Active Directory:

Model

Where accounts and mailboxes live

How eADM provisions the mailbox

Local

On-premises Active Directory, with Exchange also on-premises

eADM writes user attributes directly to Active Directory. The local Exchange server manages the mailbox.

Remote (hybrid)

On-premises Active Directory as source; mailbox hosted in Exchange Online

eADM writes to Active Directory and, where configured, runs a PowerShell script against the on-premises Exchange server (or Exchange Management Tools) to create a remote mailbox object linking the AD user to the cloud mailbox.

Cloud-only

Microsoft Entra ID only, no local Active Directory

eADM manages the user directly in Entra ID via Microsoft Graph. A mailbox is created automatically when a qualifying Exchange Online licence is assigned.

Local: on-premises Active Directory and Exchange

eADM writes changes directly to the local Active Directory. Existing Microsoft Entra Connect Sync then picks up changes to users, groups and attributes and synchronises them to Entra ID.

Remote: hybrid Exchange with a remote mailbox

In a hybrid environment, eADM does not manage Exchange directly. Instead, it writes the correct attributes to the Active Directory user object and, where configured, executes a PowerShell script against the on-premises Exchange server (typically Enable-RemoteMailbox.ps1), or against Exchange Management Tools if no local Exchange server remains. This creates a remote mailbox object that links the AD user to the mailbox in Microsoft 365 and ensures correct mail routing.

Note: Identum does not manage, configure or troubleshoot the Exchange server itself. Infrastructure changes to Exchange, including installation, migration and certificate management, are the responsibility of the customer's IT department or Exchange administrator.

Cloud-only: Entra ID and Exchange Online

In a cloud-only tenant, eADM manages userPrincipalName and mailNickname directly in Entra ID. The UPN is always the primary email address, and Exchange Online adds the mail nickname at the primary domain as an alias automatically once a licence is assigned. No local Active Directory or Exchange server is required.


Primary SMTP address and email aliases

In Active Directory and Exchange, a user's email addresses are stored in the proxyAddresses attribute. The primary address is marked with an uppercase SMTP: prefix; aliases use a lowercase smtp: prefix. Only one primary address exists per account at a time.

eADM supports two general approaches to keeping this attribute correct:

  • Minimal configuration. eADM sets only the mail attribute in Active Directory. Microsoft Entra Connect and Exchange Online then derive proxyAddresses and the primary address automatically, using Microsoft's default address policies. This is simple to set up but gives limited control over renames and additional aliases.

  • Script-based address management. A PowerShell script, triggered by eADM, calculates and writes the primary address and any aliases explicitly. This supports name changes with automatic retention of the old address as an alias, multi-domain rules and other customer-specific requirements, at the cost of additional scripting and maintenance.

The right approach depends on the complexity of the customer's naming rules and domain structure. Identum can advise on the most suitable model during onboarding.


What changes when you replace an Exchange server

When an organisation replaces or upgrades its on-premises Exchange server, the hostname or FQDN of the new server must be updated in the PowerShell script used by eADM. In most standard configurations, this is the $exchange variable at the top of Enable-RemoteMailbox.ps1.

Depending on how the script was originally set up, there may be additional connection parameters to review:

  • $exchange, the Exchange server hostname or FQDN

  • Service account credentials used to connect to Exchange, if not using the current Windows session

  • Any explicit URI or connection string in New-PSSession or Connect-ExchangeServer

Warning: Do not update the script in the production environment without first verifying the connection in the test environment. A misconfigured Exchange endpoint causes mailbox provisioning to fail silently for new users until the issue is corrected.

How to update the Exchange server reference

  1. Locate the Enable-RemoteMailbox.ps1 script in the eADM synchronisation configuration.

  2. Update the $exchange variable to the hostname or FQDN of the new Exchange server.

  3. Review any additional connection parameters (see list above).

  4. Test the updated script manually against the new server before saving it to the production configuration.

  5. Run a test provisioning in eADM to confirm the remote mailbox is created correctly.

  6. Contact Identum support if the script requires changes beyond the $exchange variable, or if the current script configuration is unclear.


Scope of Identum support

Identum can assist with the following when a customer's Exchange environment changes, or when moving between account models:

  • Reviewing and updating the $exchange variable and related parameters in the eADM provisioning script

  • Advising on the most suitable approach to UPN, primary SMTP and alias management for the customer's domain structure

  • Testing updated configuration in a sandbox environment

  • Verifying that new user accounts are provisioned correctly after a change

Identum does not manage, configure or troubleshoot the Exchange server or Entra ID tenant itself. Infrastructure changes, including installation, migration to cloud-only and certificate management, are the responsibility of the customer's IT department or their Exchange or Entra ID administrator.

This article explains how eADM assigns UPN, primary SMTP address and email aliases, and how mailbox provisioning differs across local Active Directory, hybrid (remote mailbox) and cloud-only Entra ID account models. It covers the proxyAddresses attribute, the Enable-RemoteMailbox.ps1 script and $exchange variable used in hybrid setups, multi-employer UPN rules, and the scope of Identum's support when Exchange servers change or customers move to cloud-only. The intended audience is IT and Exchange administrators at Identum's municipal customers.

Last updated: