Exporting Remote User Mailboxes, and Recipient Type vs Exportable RecipientTypeDetails

Purpose

In a hybrid environment, users whose mailboxes have moved to Exchange Online exist on-premises as remote mailboxes. If the export policy is not configured for that recipient type, those users are silently absent from the export — and because an import treats absent objects as deleted, their contacts can disappear at the partner.

This article covers the fix, and clears up a confusion between two similarly named settings that has produced contradictory advice.

Two settings, easily confused

This distinction matters, because one of these is deprecated and the other is not.

Selection by Recipient Type — deprecated. Choosing which objects to export by picking a recipient type such as UserMailbox on the Directory tab. As of version 8.4 this is deprecated and no longer recommended. NETsec recommends defining the selection by membership in a group instead, searched for in the Search dialog and exported with the group option Only Membership, which specifies far more precisely which objects are actually exported. There is a Migrate button for Exchange Online export policies that converts a Recipient Type selection into a dynamic distribution group.

Exportable RecipientTypeDetails — not deprecated. A per-OU list of which recipient types are eligible for export at all. GALsync exports objects whose msExchRecipientTypeDetails / RecipientTypeDetails property holds one of the values on this list, or whose property is not set. This is still the current mechanism and is how you make remote mailboxes exportable.

So advice to stop using Recipient Type selection and advice to add Remote User Mailbox to Exportable RecipientTypeDetails are both correct. They are different settings doing different jobs, and they are frequently mixed up.

Making remote mailboxes exportable

In the export policy:

1. Go to the Directory tab.
2. Double-click the OU containing the remote mailbox users.
3. Select the Exportable RecipientTypeDetails tab.
4. Click Add/Remove RecipientTypeDetails.
5. Select Remote User Mailbox and click Add.
6. Save the changes.

Note that this is configured per organizational unit. If remote mailbox users are spread across several OUs in the export scope, each one needs the change.

A warning that comes with it

The manual is explicit about adding recipient types that are not on the default list: GALsync does not check whether they are present or useful in your environment. Verification is left to the administrator deliberately, so that as many scenarios as possible are supported. The disadvantage is that the list can be misconfigured and produce undesirable results.

So add the type only when you know the objects in question actually carry it, and confirm the exported object count afterwards rather than assuming.

# What recipient types do your objects actually have?
Get-Recipient -ResultSize Unlimited |
    Group-Object RecipientTypeDetails |
    Select-Object Name, Count |
    Sort-Object Count -Descending

Verify the change

1. Run the export manually and compare the object count against the previous run. The increase should roughly match the number of remote mailboxes you expected to add.
2. Check the log for the specific users that were missing.
3. Only then let the import run.

Confirming this is worth the extra step. A configuration change of this kind has been applied, reported as resolved, and found still not to have fixed the customer's problem — so treat the object count, not the change itself, as the evidence.

If users are still missing

Adding the recipient type is one cause of missing objects and not the only one. Work through the others:

• The search result cap. Objects selected through the Search dialog are limited by a maximum Results value that defaults to 500, and objects beyond it are silently excluded from the policy.
• The basic requirements. Users and groups need an SMTP proxy address; contacts need a target address.
• A static selection that has drifted since it was configured.

See Why Objects Are Missing from a GALsync Export for all of these in order.

Why this is worth catching early

Objects missing from an export are, to the import, objects deleted at the source — so the corresponding contacts are removed at the partner. During a migration, when mailboxes are moving to Exchange Online in batches, this can quietly remove contacts as each batch moves.

Set Minimum objects to transfer data file on the export policy before a migration starts, so an unexpectedly short file is held back rather than consumed. See How to Prevent GALsync Contact Deletion During Export Errors.

References

• GALsync 8.7 Manual p.150 and p.153 — Exportable RecipientTypeDetails; the Add/Remove control and the warning that added types are not validated.
• GALsync 8.7 Manual p.161 — Migrate (Exchange Online only); selection by Recipient Type deprecated, group membership with Only Membership recommended instead.
• GALsync 8.7 Upgrade Instructions p.42 — Recipient Type selection deprecated as of version 8.4.
• GALsync 8.7 Manual p.158 — the Search dialog and the maximum Results default of 500.
• The current GALsync manual is published by NETsec at netsec.de.