Linked Mailbox users will not sync in Azure AD with AAD Connect

You may find that some on-premises user accounts will not synchronize with Azure Active Directory using AAD Connect, no matter what you try. Once you rule out the obvious (OU filtering, object filtering, security permissions, etc.) check to see if the problem user has a linked mailbox in Exchange.

According to the article, Azure AD Connect sync: Understanding Users and Contacts:

"An account with a linked mailbox will never be used for userPrincipalName and sourceAnchor. It is assumed that an active account will be found later."

I can't tell you what that last sentence is supposed to mean, but I can tell you that a linked mailbox cannot be soft-matched or hard-matched, and it will never provision itself in Azure AD. You will not see any warnings or errors in Synchronization Service Manager or the event logs indicating there's a problem -- the user just never gets provisioned in AAD, as if they are being filtered.

If you're handy with Synchronization Service Manager ("C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe"), you'll see that the on-prem user was pulled into the metaverse, but the Connectors tab only shows the on-prem AD connector. It does not show the corresponding tenant connector, as it should.

A linked mailbox is a special type of mailbox that is accessed by a user in a separate, trusted forest. I don't normally see orgs using linked mailboxes except during specific cross-forest migration scenarios. For example, during a merger or acquisition when both forests need to access the same mailbox. I have, however, seen occasions when a normal user mailbox is somehow converted to a linked mailbox during an Exchange upgrade. This usually happens because the source mailbox has some funky* permissions set on it, and by moving the mailbox to the new Exchange Server infrastructure the mailbox is converted from a user to a linked mailbox for some reason.  * Funky is a technical term.

If your environment is a single forest with no trusts or resource forests there's virtually no reason that any mailbox should be a linked mailbox. As a matter of fact, Exchange won't even let you create a linked mailbox unless there's a configured trusted forest in existence.

It is normally safe to convert a linked mailbox to a user mailbox with no ill effects. You cannot use the Exchange Admin Center to convert a linked mailbox to a user mailbox. You must use the Exchange Management Shell.

Use the following EMS command to convert a single linked mailbox to a user mailbox:

Set-User -Identity kljohnson@contoso.com -LinkedMasterAccount $null

Or you can use the following EMS command to convert all linked mailboxes to user mailboxes:

Get-Mailbox -ResultSize unlimited -Filter {(RecipientTypeDetails -eq 'LinkedMailbox')} | Set-User -LinkedMasterAccount $null

Once a linked mailbox has been converted to a user mailbox you can run a delta sync of AAD Connect using the following command and the user object(s) will now be provisioned correctly in Azure Active Directory.

Start-ADSyncSyncCycle -PolicyType Delta

I usually do this twice in a row to make sure both on-prem AD and Azure AD objects are completely up to date.

Read more ...

How to Schedule and Force Sync Updates with AAD Connect 1.1.x

Microsoft has made some significant changes to AAD Connect in version 1.1.x. New features include:

• Automatic upgrade feature for Express settings customers
• Support for the global admin using MFA and PIM in the installation wizard
• Allow changing the user's sign-in method after initial install
• Allow Domain and OU filtering in the installation wizard. This also allows connecting to forests where not all domains are available.
• Scheduler is built-in to the sync engine and the default schedule is now 30 minutes
• Plus there's MOAR!

You can download the latest version of AAD Connect here.

Note that the new Automatic Upgrade feature is not enabled unless you install AAD Connect with Express settings. Customized settings require more configuration, so automatic upgrade is not possible in these scenarios (yet).

They also changed the way you manage AAD Connect synchronization schedules and manual syncs (again). I swear sometimes these guys are psychotic.

Scheduling Synchronization

In previous versions, the synchronization schedule was implemented as a scheduled task in Windows. Now it's part of the sync engine and is configured via a PowerShell cmdlet. Previous versions synchronized every 3 hours, now it's every 30 minutes! Run the new Get-ADSyncScheduler cmdlet to view the current synchronization schedule:

Default synchronization schedule in AAD Connect 1.1.105

If you want to adjust the default schedule run the Set-ADSyncScheduler cmdlet. Note that you cannot set the scheduler less than the AllowedSyncCycleInterval of 30 minutes, but you can set it higher. If you try to use a value less than 30 minutes, you will get an error:

Cannot change AAD Connect sync frequency less than 30 minutes

If you DO find a way to adjust the schedule lower, understand that this is not supported by Microsoft.

Set-ADSyncScheduler accepts the following parameters:

• CustomizedSyncCycleInterval <timespan> -- Used to set the custom sync cycle interval. Must be higher that the Allowed Sync Cycle Interval.
• SyncCycleEnabled <bool> -- Enables or disables scheduled synchronization.
• NextSyncCyclePolicyType <SynchronizationPolicyType> {Unspecified | Delta | Initial} -- Specifies how the next synchronization will work. Delta only syncs changes since the last sync. Initial will perform a full resynchronization.
• PurgeRunHistoryInterval] <timespan> -- The interval when AAD Connect will purge the operation logs for past sync jobs. The default is keep them for 7 days.
• MaintenanceEnabled] <bool> -- Enables maintenance mode to enable you to update the certificates/keys and purge the operations log.
• Force -- Makes the setting changes without warnings or confirmation. It does NOT force AAD Connect to accept a custom sync schedule that it is lower than the Allowed Sync Cycle Interval.

Forcing Synchronization

If you want to run a sync sooner than the next scheduled run, you can do it manually using the new Start-ADSyncSyncCycle cmdlet. For example:

Start-ADSyncSyncCycle -PolicyType Delta

This will force a delta sync immediately, as long as a scheduled sync is not running. Use PolicyType Initial to force a full sync.

Read more ...

Important Information about Group Expansion for In-Place Holds

Exchange 2013, Exchange 2016, and Exchange Online in Office 365 all support In-Place Hold. In-Place Hold allows compliance administrators to retain specific data in Exchange for eDiscovery in an immutable fashion.

In-Place Hold differs from Litigation Hold in a few key ways. Litigation Hold allows you to hold all contents of one or more mailboxes. In-Place Hold allows you to define what data to hold (keywords, specific senders/recipients, and start/end dates, and the types of data, such as emails or calendar items). Both In-Place and Litigation Hold allow you to specify how long to hold this data.

When you configure a new In-Place Hold you have the option to place a group on hold. You need to be aware that group membership is expanded at the time the In-Place Hold is created, and the sources of the In-Place Hold do not automatically adjust if the group membership changes.

For example, I'll create an In-Place Hold for the members of Keith's Group.

Creating a new In-Place Hold for members of Keith's Group

I configure the search parameters, enable the In-Place Hold, and click Finish. Exchange then displays the following warning:

To enable In-Place Hold for the mailbox search, the distribution groups specified in the "Source mailboxes" field must be expanded. The task can expand the group members and save the expanded mailboxes as the source mailboxes of the mailbox search. Do you want to expand the group?

You have to click OK to continue. If you click Cancel it will not save the In-Place Hold.

Warning about group expansion

If you edit the new In-Place hold you will see that Keith's Group has been replaced with the members of the group at the time the In-Place hold was created.

Expanded group

There is no longer any link between Keith's Group and the new In-Place Hold sources. If the group membership changes, you will need to edit the mailbox sources for the In Place Hold manually.

Note that this expansion behavior is the same, whether you use distribution groups, mail-enabled security groups, or dynamic distribution groups.

Read more ...

The Importance of the @ record for Autodiscover

Ever since Outlook 2007, Outlook has used the Autodiscover web service to automatically configure itself for Exchange access. Outlook does this by trying to connect to Autodiscover externally using several methods that are hard coded into the product in this order:

1. HTTPS root domain query (e.g. https://contoso.com/Autodiscover/Autodiscover.xml)
2. HTTPS Autodiscover domain query (e.g. https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml)
3. Local XML file
4. HTTP redirect method (e.g. http://autodiscover.contoso.com/Autodiscover/Autodiscover.xml, expecting a redirect to an HTTPS URL)
5. SRV DNS record query (e.g looking for an SRV record called _autodiscover._tcp.contoso.com)
6. Cached URL in the Outlook profile (if a previous Autodiscover URL was found and cached)

It's rather unfortunate that Outlook uses the HTTPS root domain query first. I mean, really, how many companies publish Autodiscover off their root domain?!? I can count how many times I've come across this on NO fingers. Even so, this can cause some real problems, especially when your external DNS is hosted by a third-party service that hosts many many other DNS domains.

If you're having issues with Autodiscover taking several minutes to run and long delays when viewing free/busy information in Outlook, it might be because you don't have a special A record in DNS that redirects the root domain to your company website. Most third-party DNS hosters do not handle this redirection automatically. You can fix this yourself by adding an A record for @ that points to the same IP address used for by your company website (e.g. www.contoso.com).

For example, let's say you ping your root domain (contoso.com) and it resolves to 69.42.215.253, which happens to be the IP address of your DNS hosting provider.

Now you ping your company website (www.contoso.com) and it resolves to 75.25.134.99.

Create an A record in DNS for the host @ that resolves to the IP address of your company website. For example:

Now when users (or Outlook) use contoso.com it will redirect to your company website (www.contoso.com). Outlook will be much happier (it will not take 2 minutes to timeout) and the browser experience will be more consistent. It's a win-win.

Read more ...