Skip to content

Domain verification fails in Hybrid Configuration Wizard


Domain verification continually fails in Hybrid Configuration Wizard when using Exchange 2016 Server on-premises.


This is a known bug with Exchange 2016 CU7 Server

As a workaround, create a new text file called
C:\Program Files\Microsoft\Exchange Server\V15\Config\SystemConfigurationTasks.Overrides.ini on the Exchange 2017 CU7 Server with the following content:


Either the server is not working properly, or credentials are not available to manage and monitor it

Web Application Proxy is installed and configured on multiple servers in an NLB cluster

When attempting to view the Operations Status of a remote WAP Server from the other in Remote Access Management Console, the following warning is displayed in the Details pane:

Either the server is not working properly, or credentials are not available to manage and monitor it

Open Windows PowerShell as Administrator on all WAP Servers and run the following command:

Enable-PSRemoting –force

Now run the following Windows PowerShell command to list all TrustedHosts:

Get-Item WSMan:\localhost\Client\TrustedHosts

Each WAP Server should list all other WAP Servers as TrustedHosts. In my example, ADFSWAP01 does not list ADFSWAP02, and vice-versa.

Run the following Windows PowerShell command on ADFSWAP01 to add ADFSWAP02 as a TrustedHost:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'adfswap02' -Concatenate

The -Concatenate parameter appends to the existing list of TrustedHosts rather than replacing it.

Repeat on ADFSWAP02 and all remaining WAP Servers, modifying the TrustedHosts parameter accordingly:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'adfswap01' -Concatenate

Confirm the changes have been applied:

Get-Item WSMan:\localhost\Client\TrustedHosts

If you make a mistake, or want to remove your changes, then use the following command to Null the list of TrustedHosts:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value ''

Refresh Operations Status in Remote Access Management Console and hopefully all is now well. You may need to close and reopen Remote Access Management Console if a refresh doesn’t work:

How to force AAD Sync to perform full synchronization

This post relates to Azure Active Directory Sync Services (AAD Sync). For the original Directory Synchronization tool (DirSync), refer to the earlier posts How to force DirSync to perform full synchronization #1 and How to force DirSync to perform full synchronization #2.

AAD Sync only performs a full import automatically when run for the very first time. After that it always defaults to a delta synchronization.

There will be times when you need to force a full import. This is usually indicated by event ID 6127 in the Application log of your AAD Sync server:

Log Name:      Application
Source:        ADSync
Event ID:      6127
Task Category: Management Agent Run Profile
Level:         Warning
The management agent "{management_agent_name}" completed run profile "Delta Import" with a delta import or delta synchronization step type. The rules configuration has changed since the last full synchronization.
User Action
To ensure the updated rules are applied to all objects, a run with step type of full synchronization should be completed.

You typically need to force a full import after making changes to Synchronization Service Manager (miisclient.exe) on your AAD Sync server. This includes modifying any synchronization filters (such as User or OU filters).

To perform a full directory synchronization, open Windows PowerShell as Administrator and run the following commands:

cd \
cd "\Program Files\Microsoft Azure AD Sync\Bin\"
.\DirectorySyncClientCmd.exe Initial

Set-MsolAdfsContext authentication issues. Unable to enable Remote PowerShell on ADFS Server.

In order to convert MSOL domains between Managed and Federated using ‘Windows Azure Active Directory Module for Windows PowerShell’ on a machine other than the ADFS Server itself, you must first set the ADFS context. This is performed using the following command:

Set-MsolAdfsContext -Computer {ADFS server FQDN}

If you are prompted for credentials which continually fail to work, PowerShell will eventually display an authentication error. In order to resolve, you must enable Remote PowerShell on the ADFS Server. This is performed using the following command on the ADFS Server:

Enable-PSRemoting -Force

If the following PowerShell error is returned, ensure you are running PowerShell 2.0 on the ADFS Server:

PS C:\> Enable-PSRemoting -Force
The term 'Enable-PSRemoting' is not recognized as a cmdlet, function, operable program, or script file. Verify the term and try again.

Enable-PSRemoting is not supported on PowerShell 1.0. This issue may affect ADFS Servers running older operating systems, such as Windows 2008 SP2.

Set-MsolAdfsContext authentication issues

How to create email address policies based on group membership in Exchange 2010 and hybrid deployments

You cannot create email address policies in Exchange 2010 EMC that filter based on group membership. You can however create these policies via EMS:

New-EmailAddressPolicy "{policy name}" -RecipientFilter {((MemberOfGroup -eq "{distinguished name of group in Active Directory}") -and ((RecipientType -eq 'UserMailbox') -or (RecipientType -eq 'MailUser')))} -EnabledEmailAddressTemplates "SMTP:{primary email address template}","smtp:{proxy address template 1}","smtp:{proxy address template 2}" 

For example:

New-EmailAddressPolicy "HR Staff" -RecipientFilter {((MemberOfGroup -eq "CN=HR Staff,OU=Groups,OU=ExitCodeZero,DC=CONTOSO,DC=COM") -and ((RecipientType -eq 'UserMailbox') -or (RecipientType -eq 'MailUser')))} -EnabledEmailAddressTemplates "","","" 

How to create Remote User Mailbox hybrid objects for mailboxes previously migrated via a staged migration

Mailboxes migrated using a staged migration remain in the on-premises Exchange Organization as User or Legacy Mailboxes. Mailboxes migrated using a hybrid migration are replaced by Remote User Mailboxes in Exchange on-premises. If you switch from a staged to a hybrid migration then it is wise to replace all on-premises staged entities with Remote User Mailboxes. This ensures consistency.

Use the following steps to replace previously migrated on-premises mailboxes with Remote User Mailbox objects:

  1. Open Exchange Management Shell (EMS)
  2. Run the following command in EMS:

    Disable-Mailbox -Identity {identity} -Confirm:$False
    Enable-RemoteMailbox -Identity {User_Name} -Alias {Alias_Name} -RemoteRoutingAddress {Alias_Name}@{Remote_Routing_Domain}

    For example:

    Disable-Mailbox -Identity 365test01 -Confirm:$False
    Enable-RemoteMailbox -Identity 365test01 -Alias 365test01 -RemoteRoutingAddress
  3. Run directory synchronization

Important notes

  • Outlook profiles may need recreating, although I’ve only tested in a mixed Exchange 2003/2010 hybrid environment where transform files had previously been used.
  • All email addresses are completely reset using the Exchange on-premises email address policy
  • X500 addresses will change so there may be issues replying to existing internal emails. The autocomplete name cache will no longer be valid, but this may not be an issue if Outlook profiles are recreated.
  • Mailboxes migrated using a staged migration remain in the on-premises Exchange Organization. Beware if you need to roll-back from Exchange Online. You must also ensure that staged clients connect directly to Exchange Online rather than Exchange on-premises as Exchange on-premises will attempt to connect users to their obsolete, migrated mailboxes.
  • I’ve not yet tested rolling back, via a hybrid remote move request, a staged user converted to a remote user mailbox.
  • After implementing a hybrid deployment into an existing staged deployment, the primary email address of all staged Exchange Online mailboxes changed from @{vanity_domain} to @{tenant_name} Users retained all existing email addresses but their primary (reply) address was changed. External recipients received email sent from converted users from the senders onmicrosoft address rather than the corporate (‘vanity domain’) addresses. Email address policies wouldn’t update this. Each user’s primary email address (for Exchange 2003 mailboxes) had to be manually switched using Active Directory Users & Computers and then waiting for dirsync to update the Exchange Online mailboxes.
  • Cross-premises email routing is performed by the targetaddress attribute on the on-premises Active Directory user account. The address space for staged mailboxes is @{tenant_name} rather than the hybrid namesapce @{tenant_name}, so staged mail-flow uses the default SMTP connector rather than a dedicated send connector. This means that the existing on-premises Exchange (2003) Server doesn’t require TLS and can use a smart host for outbound delivery. If you implement a hybrid deployment when on-premises and online mailboxes are currently coexisting through a staged migration, any issues with the new hybrid Exchange Server accessing EOP directly over port 25 will cause cross-premises mail-flow to break.


You can script the conversion of mailboxes using an import script:

  1. Create an import CSV file called c:\temp\userlist.csv on the Exchange 2010 on-premises server
  2. Populate the first line with two columns:

  3. Populate each additional line with the UPN and Exchange Alias of every staged user to be converted, one per line. For example:,365test01,365test02,365test03
  4. c:\temp\userlist.csv should now look like this:

  5. Run the following commands in Exchange on-premises EMS, ensuring that ‘tenantname‘ in line 3 is changed accordingly:

    $UserList = Import-Csv c:\temp\userlist.csv
    $UserList | foreach {Disable-Mailbox -Identity $_.userprincipalname -Confirm:$False}
    $UserList | foreach {Enable-RemoteMailbox -Identity $_.userprincipalname -RemoteRoutingAddress ($_.alias+'')}

Also refer to this forum thread.

Synchronized mailboxes don’t appear in Exchange Online

On-premises mailboxes for synchronized users in a hybrid environment should appear under Exchange Online EAC as Contacts. They should also appear as Mail Users when targeting Exchange Online through the on-premises EMC. If this isn’t the case then delete the affected MSOL accounts as follows and allow directory synchronization to recreate them correctly at the next synchronization:

Remove-msoluser –userprincipalname –force
Remove-msoluser –userprincipalname –force -RemovefromRecyclebin

Address List management in Exchange Online

If you want to create Address Lists or Address Book Policies in Exchange Online then you need to assign yourself the ‘Address Lists’ role. This isn’t assigned to anyone by default, including Global Admins or members of Organization Management.

DirSync notifications not being received

Directory synchronization notifications are delivered to the Technical Contact Email defined in your MSOL subscription. This can be viewed and edited in the Microsoft Online Portal.

If dirsync notifications aren’t being received by the technical contact, then change the Technical Contact Email address to that of a user assigned the Global Administrator role in MSOL.

New remote move request option is not available in EMC


Occasionally, when you right-click a user mailbox in EMC, the Remote Move Request action is not available for selection. This sometimes occurs after a previous failed mailbox move.


Open ADSIEDIT.MSC, drill down to the problem user and clear the ‘msExchMailboxMoveRemoteHostName’ attribute.