Are Guest Accounts Better Than Mail Contacts?

During an online discussion following publication of my article about how to purge guest accounts with unredeemed invitations from Azure AD, Microsoft’s Jef Kazimer said that he sees many Microsoft 365 organizations using guest accounts instead of mail contacts because guest accounts have better lifecycle management, even if the guests never sign in.

That idea got me thinking. Exchange Online is the largest Microsoft 365 workload and some organizations create many thousands of mail contacts for different reasons. For instance, they might have contacts for people in partner organizations so that users can easily find those contacts in the Global Address List (GAL). Mail contacts also exist in Exchange Server and many of the contacts now in Exchange Online originated. Hybrid organizations can synchronize on-premises contacts to Azure AD, but the management of those objects must be done on-premises.

Understanding Mail Contacts

Before comparing mail contacts with Azure AD guest accounts, we need to understand what a mail contact is. Mail contact objects exist in both the Exchange directory (EXODS) and Azure AD. For example, to create a mail contact, you run the New-MailContact cmdlet:

New-MailContact -Name Jef.Kazimer -DisplayName "Jef Kazimer" -ExternalEmailAddress "Jef.Kazimer@contoso.com" -FirstName "Jef" -LastName "Kazimer"

This action creates a contact object in both Exchange Online and Azure AD. The Exchange object is what people think of when they think about a mail contact. The Azure AD object exists to hold properties unrelated to email processing. Because it uses mail contacts as addressable email recipients, all Exchange Online really cares about is the email address. Once an object has an email address, Exchange can route messages to it and allow the object to participate in distribution lists. The Get-MailContact cmdlet confirms the details of the new contact object:

Get-MailContact -Identity Jef.Kazimer | Format-Table DisplayName, ExternalEmailAddress

DisplayName ExternalEmailAddress
----------- --------------------
Jef Kazimer SMTP:Jef.Kazimer@contoso.com

The external directory object identifier stored in the mail contact points to the Azure AD object, which we can retrieve using the Get-MgContact cmdlet from the Microsoft Graph PowerShell SDK:

Get-MgContact -OrgContactId (Get-MailContact -Identity Jef.Kazimer).ExternalDirectoryObjectId | Format-Table displayName, proxyAddresses

DisplayName ProxyAddresses
----------- --------------
Jef Kazimer {SMTP:Jef.Kazimer@contoso.com}

The mail contact is a sparse object so far. To populate the other properties that you might want users to see in the GAL (Figure 1), you must run the Set-Contact cmdlet to update the Azure AD object:

Set-Contact -Identity Jef.Kazimer -StreetAddress "14, Preston Villas" -City "Bellevue" -StateorProvince "Washington" -PostalCode "98004" -Phone "+1 425-214-765" -MobilePhone "+1 425-214-705" -Pager $Null -HomePhone "+1 425-270-765" -Company "Contoso" -Title "Azure AD Guru" -Department "Information Technology" -Fax "+1 425-214-761" -Initials "JK" -Notes "Distinguished Person" -Office "Liberty Square" -CountryOrRegion "United States"

The Get-MgContact cmdlet reports the newly-populated properties as does the Get-ExoRecipient cmdlet. There are some exceptions and caveats:

• Remember to include the PropertySet All parameter to force Get-ExoRecipient to retrieve the full set of properties.
• Get-ExoRecipient doesn’t retrieve the street address because it’s not included in the GAL.
• Get-MgContact uses compound properties to hold some information. For instance, to see the elements of a contact’s address, you must expand the properties stored in the Addresses property:

Get-MgContact -OrgContactId (Get-MailContact -Identity Jef.Kazimer).ExternalDirectoryObjectId | Select-Object -ExpandProperty Addresses


City     CountryOrRegion OfficeLocation PostalCode State      Street
----     --------------- -------------- ---------- -----      ------
Bellevue United States   Liberty Square 98004      Washington 14, Preston Villas

Managing Mail Contacts

A Set-MailContact cmdlet is available to update properties of the Exchange objects, including the set of custom attributes available for all mail-enabled objects. The Set-Contact cmdlet updates the information held in Azure AD contact objects such as the address data shown above.

When administrators manage mail contacts through the Microsoft 365 admin center or Exchange admin center, they can work with both Exchange Online and Azure AD object properties. The GUI hides the fact that the settings presented to the administrator come from two directories, much like it disguises the interaction between Azure AD and Exchange when managing mailbox-enabled user accounts.

Guest Accounts and Guest Mail Users

Now that we understand mail contacts, let’s discuss the relationship between Exchange Online and Azure AD guest accounts. Following the creation of a guest account, a background process creates a special type of mail user object with a RecipientTypeDetails setting of GuestMailUser based on the properties of the guest account. The mail user object allows:

• Guest members of Outlook groups to participate in group conversations via email.
• Mail routing to guest accounts.
• Guest accounts to appear in the GAL and other Exchange address lists.

Guest mail user objects exist in the Exchange directory until the removal of their linked guest accounts from Azure AD. Although you can view guest mail user objects through the Exchange admin center, the GUI won’t allow you to update their properties.Changes must be made to the guest account using the Azure AD admin center or with a Graph API (including the Microsoft Graph PowerShell SDK cmdlets). You can update the Exchange-specific properties with the Set-MailUser cmdlet.

To see the set of guest mail user objects, run the Get-ExoRecipient cmdlet:

Get-ExoRecipient -RecipientTypeDetails GuestMailUser | Format-Table DisplayName, PrimarySmtpAddress, HiddenFromAddressListsEnabled

The last property is True (the default) if the guest account isn’t visible to Exchange address lists. Run the Set-MailUser cmdlet to update HiddenFromAddressListsEnabled to True to expose the object. Here’s an example:

Set-MailUser -Identity warren.gatland@o365maestro.onmicrosoft.com -HiddenFromAddressListsEnabled $False

Note that it takes at least a day before newly exposed objects show up in the offline address look (OAB).

Adding Guest Mail Users to Distribution Lists

Because the guest mail users are routable objects, they can be added to distribution lists. This example spells things out, but it’s possible to add a guest mail user to a distribution list by passing its display name or email address without going to the bother of fetching the object with Get-MailUser.

$GuestMailUser = Get-MailUser Get-MailUser -Filter {DisplayName -eq "Warren Gatland" -and RecipientTypeDetails -eq "GuestMailUser"}
Add-DistributionGroupMember -Identity "o365maestro Contacts" -Member $GuestMailUser.Name

Move to Guest Accounts or Stay with Mail Contacts

Getting back to the original point, Jef says that guest accounts have better lifecycle management. In other words, if an organization invests in creating guest accounts instead of mail contacts, they’ll benefit from the work Microsoft does to improve how Azure AD manages external identities.

There’s some truth here. An Azure AD guest account supports more properties, including custom security attributes and support dynamic Azure AD Groups and dynamic Azure AD administrative units. They’re a Microsoft 365 entity rather than being restricted to just Exchange Online. Azure AD development for external identities, including guest accounts, is active whereas I suspect the development effort for Exchange mail contacts entered an “only fix bugs” maintenance stage years ago. On the other hand, mail contacts are simple and effective and work across hybrid Exchange organizations.

If you’re a cloud-only organization, the choice exists to use either. If you decide to use Azure AD guest accounts, the existence of guest mail user objects smoothen the transition and make sure that address lists, distribution lists, an email routing continue working. Azure AD guest accounts are a better long-term bet, but that doesn’t mean that anyone should switch anytime soon.

Learn more about how the Microsoft 365 applications like Exchange Online and Azure AD really work on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Exchange Public Folders or Mail Contacts

A recent post to the Office 365 Technical Discussions Facebook group came from a small Office 365 tenant (a voluntary fire brigade with 47 members) who wanted to share global contacts such as the town mayor or local companies. The only solution they had discovered was to create a public folder to hold contacts. This will work, but it’s an Outlook-only solution because Outlook is the only email client that understands how to use the shared contacts from a public folder as an address list (see below)

Mail Contacts Have Best Client Support

Given the widespread use of mobile devices and the undesirability of setting up and managing public folders in a small Office 365 tenant, mail contacts seem like a better approach. A mail contact is an object created in Exchange for someone outside your organization. Each contact has an email address and other properties that you’d expect to find in an address book, such as first and last name, display name, mailing address, and phone numbers. The email address used for a mail contact must be unique. In other words, it cannot be assigned to another mail-enabled object already known to your organization (including guest user accounts).

Mail contacts are included in the Exchange Global Address List (GAL) and Offline Address Book (OAB), so they are available to all the Microsoft email clients – Outlook desktop (Windows and Mac), OWA, and Outlook for iOS and Android. Because mail contacts exist in the Exchange directory, they are also available to third-party email clients, if those clients choose to include the necessary support (here’s one example that does).

The Downside of Mail Contacts

The downside of mail contacts is that these objects can only be added by an Exchange administrator (or more precisely, an account that has been assigned the Mail Recipients RBAC role). Once your account has the necessary permissions, it can add or update mail contacts using the Office 365 Admin Center (Users – Contacts), the Recipients section of the Exchange Admin Center (EAC), or by running the New-MailContact PowerShell cmdlet.

Use PowerShell to Import Contacts from a CSV File

One way to approach the problem is to ask someone who doesn’t have administrative permission to maintain a CSV file holding details of the common contacts. You can add as many of the properties supported by Exchange for mail contacts as you wish. Once the file is ready, PowerShell can process its contents.

This very simple PowerShell code reads the CSV file shown above and creates a new mail contact for each line found in the file. Note that the New-MailContact cmdlet creates a new mail contact and the Set-Contact cmdlet updates some of the extended properties, like phone numbers.

$InputContacts = import-csv c:\temp\inputcontacts.csv
Write-Host $InputContacts.Count "contacts found"
ForEach ($Contact in $InputContacts) {
    $Alias = $Contact.First + "." + $Contact.Last
    # Real simple code to make sure that we have an alias
    If ($Alias -eq $Null) { $Alias = $N.Name.Split("")[0] + "." + $N.Name.Split("")[1] }
    If ((Get-Recipient -Identity $Contact.EmailAddress -ErrorAction SilentlyContinue) -eq $Null) {
       # Recipient is not known, so we can add them
       Write-Host "Adding contact" $Contact.EmailAddress
       New-MailContact -Name $Contact.Name -ExternalEmailAddress $Contact.EmailAddress -Alias $Alias -FirstName $Contact.First -LastName $Contact.Last
       # Update country and phone numbers
       Set-Contact -Identity $Alias -MobilePhone $Contact.MobilePhone -Phone $Contact.WorkPhone -CountryOrRegion $Contact.Country -Company $Contact.Company }
}

Free Book about Eradicating Public Folders

If your organization is considering moving from public folders, consider reading the eBook “The Complete Guide to Eradicating Legacy Public Folders” to get some ideas for how you might approach the task.

For more information about public folders, see Chapter 8 of the companion volume for the Office 365 for IT Pros eBook. Mail contacts are covered in Chapter 7 of the main book. You get both the main and companion volumes when you subscribe to Office 365 for IT Pros.