Free/busy Exchange hybrid troubleshooting with Microsoft Edge

Those of you who have configured Exchange hybrid with Office 365 before know that free/busy functionality can be troublesome at times and not work correctly.

Instead of searching through Exchange logs I found that you can pin point the exact error message through Microsoft Edge to assist with troubleshooting.

To do so;

  1. Open Microsoft Edge and login to Office 365 OWA ( with an Office 365 account
  2. Create a new meeting request
  3. Press F12 to launch developer tools
  4. Conduct a free/busy lookup on a person with a mailbox on-premises
  5. Select the Network tab
  6. Select the entry with “GetUserAvailability”devtools-getuseravailability
  7. Select the body tab (on the right hand side)
  8. The MessageText element will display the exact error messagedevtools-messagetext

Delegate Mailbox Access using Groups in Exchange Online

A common misconception about granting mailbox access rights in Exchange Online is that you can only add access to the individual and not a group. You may have opened the Exchange Administrator Center (EAC), found the mailbox you wanted and looked at the delegated access tab. Only to be provided with a list of eligible user identity’s, but none of your on-premises security groups that have been created. Fear not, the on-premises groups just need a little remediation to the correct flavour to be seen in the picker and then applied.
The key settings of a group to assign mailbox access in Exchange Online are:
  1. Universal Security
  2. Mail Enabled
Things in your environment may have gotten this way over time as legacy on-premises Exchange Server versions weren’t as picky with your selection and would allow the permission to be granted to any kind of group you threw at it. Moving to Exchange Online has more sophisticated taste that needs to be catered for due to its Evergreen state with all the latest Exchange trends.
If you migrate on-premises mailboxes with these slightly incorrect permissions to Exchange Online they will be lost forever. So if you remedy the existing on-premises mailboxes before initiating a remote move request to Exchange Online, no further action will be required at completion.

The Process

Update the group to universal:
Get-Group $Name | Set-Group -Universal
Mail enable the group:
Enable-DistributionGroup -identity $Name
Finally, not compulsory but if you want the group to be hidden from your Exchange Address Book:
Get-DistributionGroup -identity $Name | Set-DistributionGroup -HiddenFromAddressListsEnabled:$True
Force a synchronisation of your group modifications with Azure Active Directory and you should find that the group will be available in the Office 365 Exhange Administrator Center. On the Azure AD Connect Server:
CD C:\Program Files\Microsoft Azure AD Sync\Bin\
.\DirectorySyncClientCmd.exe delta
So my final note that I would like to re-iterate is that if you tidy this stuff up before migrating to Office 365 you will have a lot less problems when the mailbox becomes active in Office 365. A mailbox that has been migrated with a faulty group type will have permissions assigned on the object, but will not resolve to an object and therefore only show SID information. Firstly the permissions fail, but secondly, it makes it very difficult to find out what the group was previously to add post migration. (see first permissions below)

 Hot Tip

Fix the issue with your groups before you start the synchronisation of the mailbox to Exchange Online and the permissions will be stamped correctly during the initial phases of the move request and once finalised, will work as expected.

Hybrid Exchange Migration: Mailbox to Mail-User Conversion Fails

Occasionally after migrating a mailbox from an on-premises Exchange server to Exchange Online the user is unable access their mailbox using Outlook, however the Office 365 Outlook Web Access (OWA) application is functional. Often (but not always) the migration batch report will contain users that have “Completed with Errors” or “Completed with Warnings”.

Commonly this is caused by the migration process failing to update the on-premises object and convert it into a mail-enabled user, often due to issues with inheritable permissions or unsupported characters. This critical step retains relevant information to populate the Global Address List, while clearing some attributes that block Outlook from performing an autodiscover operation to locate the mailbox on Office 365.

Additionally the process sets the targetAddress attribute to allow Exchange to correctly route mail to the Exchange Online mailbox. In this situation it’s likely that you will need to complete the conversion from mailbox to a mail enabled user manually. Microsoft has made the KB2745710 article available recommending a process for resolving the issue.

Unfortunately, running “Disable-Mailbox” will result in the user losing their proxy and X500 (LegacyExchangeDN) addresses which will likely create more problems. I have put the following simple script together that will convert an on-premises User Mailbox into a Remote Mailbox (mail-enabled user).

Note: Do not use the script ‘as is’ against any other mailbox type (shared, resource, etc)!

This script will set the following attributes to NULL:

  • homeMDB = NULL
  • homeMTA = NULL
  • msExchHomeServerName = NULL

and then sets the following attributes:

  • msExchVersion = “44220983382016” (this is relevant for mailboxes previously hosted on Exchange 2003)
  • msExchRecipientDisplayType = “-2147483642” (SyncedMailboxUser)
  • msExchRecipientTypeDetails = “2147483648” (RemoteUserMailbox)
  • msExchRemoteRecipientType = “4” (migrated)
  • targetAddress =

To run the script, save as a PowerShell ps1 file. The samAccountName of the affected mailbox is a required input as in the below example:

.\Complete_MailUser_Conversion -samAccountName smithj
# Global Variables & Constants

Import-Module activedirectory

$targetDomain = "*" #Update to match your own
$ProxyAddresses = (Get-AdUser $samAccountName -properties *).ProxyAddresses
$UPN = (Get-AdUser $samAccountName -properties *).UserPrincipalName
$target = $proxyaddresses -like $targetDomain -replace 'smtp:','SMTP:'

# Script START
if ($target -gt 0) {

    Get-ADUser -Filter 'UserPrincipalName -eq $upn' | `
    Set-ADUser -Clear homeMDB, homeMTA, msExchHomeServerName -Replace @{ msExchVersion="44220983382016";msExchRecipientDisplayType="-2147483642";msExchRecipientTypeDetails="2147483648";msExchRemoteRecipientType="4";targetAddress=$target }
# Script END

Hybrid Exchange Connectivity with Azure Traffic Manager

Does your exchange hybrid architecture need to have redundancy? How about an active/passive solution using Azure Traffic Manager elimating the need for a HLB device in your DMZ.

Currently there is a few topologies for configuring Hybrid Exchange with Office 365;

  1. Single Hybrid Server
  2. 2+ Hybrid Server behind a load balancer
  3. 2+ Hybrid Server with DNS round robin

A simple solution to make a redundant Hybrid Exchange design without using a HLB is to leverage Azure Traffic Manager to monitor and service the DNS namespace configured in on-premises Exchange and Office 365 configuration.

Traffic Manager offers:

  • It works at the DNS level, routing traffic between one or more hybrid public endpoints that sit behind the common DNS service name
  • Traffic management policy profiles like failover and performance metrics rather than DNS round robin and TTL.

In my scenario we will make the Primary Hybrid Server the responding IP until the event of a failure. We do this via pro-actively probing the health check page on a web services virtual directory on each Hybrid Server where NTLM challenge authentication is not required for the anonymous probe. If we think about all the services offered across exchange virtual directories that are exposed, Outlook Web Access with forms based authentication seems to be the standout. OWA has a health check page that can be used by load balancers to check for service outages and degredation.


If in the event that this service becomes unresponsive, Traffic Manager will start responding with the secondary server endpoint IP until services resume. We have comfort in knowing that if the OWA page is unresponsive we can be assured that the Exchange Web Services (EWS) virtual directory probably is aswell.

New-AzureTrafficManagerProfile -Name "HybridExchange" -DomainName "" -LoadBalancingMethod "Failover" -Ttl 30 -MonitorProtocol "Https" -MonitorPort 443 -MonitorRelativePath "/owa/healthcheck.htm" | Add-AzureTrafficManagerEndpoint -DomainName "" -Status "Enabled" -Type "Any" | Add-AzureTrafficManagerEndpoint -DomainName "" -Status "Enabled" -Type "Any" | Set-AzureTrafficManagerProfile

Create a CNAME for the hybrid namespace configured with Office 365 to For the example outlined in this blog, I would create a CNAME in my public DNS Zone for with ‘’ to ‘’.



In this solution you will know that the primary Exchange Hybrid Server will always respond to Office 365 web services requests until the event of a failure. This will include free/busy lookups and also mailbox migrations. The benefits of using an active/passive hybrid namespace rather than a HA pair is that the through put of mailbox migration is much higher as EWS requests maintain a persistent connection with the originating Hybrid Server and no load balancer is intercepting/redirecting the traffic. We also have control on the failover/failback timings versus true DNS load balancing with round robin which could take longer to resolve.

This is a simple solution using a cloud service for eliminating the need of any fancy layer 7 load balancing and improving on the simplicity of DNS round robin.

Hot Tip: If you have a Database Availability Group (DAG) on-premises with mailboxes being migrated to Exchange Online. It would be of benefit for your active Hybrid Server to be closer to the mailbox server with the active copy to reduce mailbox move traffic on your local network links during synchronisation.


AADSync – AD Service Account Delegated Permissions

Note: This applies to Azure AD Connect, previously referred to as AAD Sync or DirSync.

***UPDATED (04/07/2016): Includes Exchange Hybrid Object ‘msDS-ExternalDirectoryObjectID’ for Exchange 2016 environments. Thanks Dave Young.

***UPDATED (29/10/2015): Included two lines for Password Write-back as per Chris Lehr Comment

When you configure Azure AD Sync (AADSync), you need to provide credentials of an account that is used by AADSync’s AD DS Management Agent to connect to your on-premises Active Directory. In previous versions of DirSync this was achieved via running the configuration wizard as a ‘Enterprise Admin’ and thus allowing the installer to create a service account and apply permissions to the Directory on your behalf. The account could have any of these following permissions to your AD DS based on your choices for purpose of the sync:

  1. Write Access to User, Contact, Groups Attributes – Hybrid Exchange Deployment
  2. Password Changes – Password Synchronisation
  3. Write Access to Passwords – Password Write-back (AAD Premium)

There has been a lot of talk lately about new tools to help you configure synchronisation of your directory with ‘(this) many clicks’. While these new tools do some great pre-req checks and wrap everything into a nice shiny wizard that helps guide you through your experience, it currently puts the burden of creating this service account and applying AD DS permissions back on you. It is now your responsibility to raise a change with the Active Directory team, in which you will need explain how you are going to splatter permissions all over their directory.

So we should re-assure the Active Directory team that we can create a service account and appy LEAST permissions on the directory for this account using the following script(s).

Apply all that are appropriate to your scenario:

Exchange Hybrid Deployment:

For rich co-existence between your on-premises Exchange infrastructure and Office 365 you must allow the service account to write-back attributes to your on-premises environment. Please check the link for additions HERE.

Configure Hybrid Write-back:

import-module ActiveDirectory
$DN = "OU=Users,OU=Company,DC=mydomain,DC=com"
$Account = "mydomain\svc_aadsync"

###--------Bind to AD

$sc = (Get-ADRootDSE).SchemaNamingContext
$ob = "CN=ms-Exch-Schema-Version-Pt," + $sc
$ExchangeSchemaVersion = (Get-ADObject $ob -pr rangeUpper).rangeUpper


<# Switches used in cmds /I:S = Specifies the objects to which you are applying the permissions.'S' - The child objects only /G = Grants the permissions that you specify to the user or group WP = Write to a property Permission #>

###---Update Attributes

if ($ExchangeSchemaVersion -ge 15317)
    #Object type: user
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msDS-ExternalDirectoryObjectID;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchArchiveStatus;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchBlockedSendersHash;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchSafeRecipientsHash;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchSafeSendersHash;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchUCVoiceMailSettings;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchUserHoldPolicies;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;proxyAddresses;user'"
    Invoke-Expression $cmd

    #Object type: group
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;proxyAddresses;group'"
    Invoke-Expression $cmd
    #Object type: contact
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;proxyAddresses;contact'"
    Invoke-Expression $cmd
    #Object type: user
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchArchiveStatus;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchBlockedSendersHash;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchSafeRecipientsHash;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchSafeSendersHash;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchUCVoiceMailSettings;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchUserHoldPolicies;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;proxyAddresses;user'"
    Invoke-Expression $cmd

    #Object type: group
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;proxyAddresses;group'"
    Invoke-Expression $cmd
    #Object type: contact
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;proxyAddresses;contact'"
    Invoke-Expression $cmd



Use DSACLS to validate your settings
dsacls “\\OU=Users,OU=Company,DC=mydomain,DC=com”

Your output should resemble:

Inherited to user
 Allow BUILTIN\Pre-Windows 2000 Compatible Access
                                       SPECIAL ACCESS for Group Membership   <Inherited from parent>
                                       READ PROPERTY
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for msExchSafeSendersHash
                                       WRITE PROPERTY
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for msExchArchiveStatus
                                       WRITE PROPERTY
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for msExchUCVoiceMailSettings
                                       WRITE PROPERTY
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for msExchBlockedSendersHash
                                       WRITE PROPERTY
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for msExchSafeRecipientsHash
                                       WRITE PROPERTY
 Inherited to contact
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for proxyAddresses
                                       WRITE PROPERTY
 Inherited to user
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for proxyAddresses
                                       WRITE PROPERTY
 Inherited to group
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for proxyAddresses
                                       WRITE PROPERTY

Password Synchronisation:

For granting permissions to the service account for reading password hashes from your on-premises AD DS you must allow the special permission of Replicating Directory Changes & Replicating Directory Changes ALL.

Configure Password Synchronisation:

$Account = "mydomain\svc_aadsync"


&lt;# Switches used in cmds /G = Grants the permissions that you specify to the user or group CA = Control access If you do not specify {ObjectType | Property} to define the specific extended right for control access, this permission applies to all meaningful control accesses on the object; otherwise, it applies only to the specific extended right for that object. #&gt;

$RootDSE = [ADSI]"LDAP://RootDSE"
$DefaultNamingContext = $RootDse.defaultNamingContext
$ConfigurationNamingContext = $RootDse.configurationNamingContext

###---Update Attributes

#Object type: user
$cmd = "dsacls '$DefaultNamingContext' /G '`"$Account`":CA;`"Replicating Directory Changes`";'"
Invoke-Expression $cmd
$cmd = "dsacls '$DefaultNamingContext' /G '`"$Account`":CA;`"Replicating Directory Changes All`";'"
Invoke-Expression $cmd


The output of the cmdlet if completed successfully you will find:

Allow mydomain\svc_aadsync           Replicating Directory Changes


Password Write-back:

To grant the service account password write-back permission on the directory you must allow the special permissions of Reset Password & Change Password extended rights.

Configure Password Write-back

$DN = "OU=Users,OU=Company,DC=mydomain,DC=com"
$Account = "mydomain\svc_aadsync"


&lt;# Switches used in cmds /I:S = Specifies the objects to which you are applying the permissions.'S' - The child objects only /G = Grants the permissions that you specify to the user or group CA = Control access If you do not specify {ObjectType | Property} to define the specific extended right for control access, this permission applies to all meaningful control accesses on the object; otherwise, it applies only to the specific extended right for that object. #&gt;

###---Update Attributes

#Object type: user

$cmd = "dsacls '$DN' /I:S /G '`"$Account`":CA;`"Reset Password`";user'"
Invoke-Expression $cmd
$cmd = "dsacls '$DN' /I:S /G '`"$Account`":CA;`"Change Password`";user'"
Invoke-Expression $cmd
$cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;pwdLastSet;user'"
Invoke-Expression $cmd
$cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;lockoutTime;user'"
Invoke-Expression $cmd


Run dsacls “\\OU=Users,OU=Company,DC=mydomain,DC=com” once again to find your entry:

Allow mydomain\svc_aadsync           Reset Password

 Check your AD MA credentials

  1. Open the ‘Synchronization Service’
  2. Choose ‘Connectors’
  3. Select the Connector with Type ‘Active Directory Domain Services’
  4. Right-Click ‘Properties’
  5. Configure Directory Partitions
  6. Select the radio button below


Add your credentials for the service account



Azure Active Directory Synchronization Tool: Password Sync as Backup for AD FS Federated Domains

Kloud has helped many Australian businesses leverage Microsoft cloud services such as Office 365, Intune and Microsoft Azure and most have implemented Active Directory Federation Services (AD FS) to provide a highly available Single Sign-On (SSO) user experience. In mid-2013, the Windows Azure Active Directory Synchronization Tool was updated to support password synchronisation with Azure Active Directory, which provided an alternative way to leverage on-premises authored identities with Microsoft’s cloud services.

Password synchronisation is a feature of the Azure Active Directory Sync Tool that will synchronise the password hash from your on-premises Active Directory environment to the Azure Active Directory. In this scenario users are able to log into Office 365 using the same password as they use in the on-premises environment, similarly to when using AD FS, however unlike AD FS there is no automatic sign in capability so users will still be prompted to enter credentials on a domain joined device.

For those that have already deployed AD FS or indeed those that are intending to implement AD FS in the future, one of the least publicised feature improvements in the May 2014 update to Office 365 is support for using the password sync feature as a temporary fall-back option for the primary AD FS service and federated authentication.

Another scenario now supported is the ability to have some domains configured for Password Sync while others within the same tenant are enabled for Federated Authentication with AD FS.

Mixing Password Sync and Federated Authentication

It’s quite a common scenario across many Office 365 implementations that I’ve done for customers to have a primary brand and domain such as where the majority of users reside and is configured for federated authentication with AD FS. Contoso also owns a subsidiary called Fabrikam and there is no requirement for federated authentication or single sign on.

Previously this scenario would mean that for users with a primary SMTP address of would either have to maintain a separate password within the Office 365 tenant or have a sub-optimal login experience and be configured for sign in with a UserPrincipalName in the format.

The recent changes to Office 365 allow for the mixed use of federated and password sync enabled domains.

Password Sync as a Temporary Fall-Back for Active Directory Federation Services

A number of smaller organisations I’ve worked with have elected to use a single instance of AD FS, taking advantage of the Single Sign-On capabilities but not including any high availability or site resilience. The Azure Active Directory Synchronization Tool is already a core component of the AD FS infrastructure so enabling Password Sync to provide a backup solution for the Single Sign-On service makes a lot of sense – and it’s free!

If you haven’t already (and you really, really should), deploy the most recent version of the Dirsync tool and enable the Password Sync option when prompted in the Configuration Wizard. A good TechNet article describing the Password Synchronization feature and how to implement it can be found here.

How to Temporarily “Switch” from Federated Authentication to Synchronised Password

The fall-back option is not automatic and requires manual configuration. Federated authentication can be changed to synchronised password authentication on a per-domain basis in the event of an outage to the AD FS infrastructure.

Detailed steps are as follows:

  1. Run the Windows Azure Active Directory Module for Windows PowerShell as an Administrator
  2. Run the following commands from the primary AD FS server:
    1. $Cred = Get-Credential
      #Enter non-federated Office 365 administrator credentials when prompted
    2. Connect-MsolService –Credential $Cred
    3. Convert-MsolDomainToStandard –DomainName <federated domain name> -SkipUserConversion $true -PasswordFile C:\Temp\passwordfile.txt
  3. Once the outage is over use the following command to convert the domain back to federated:
    1. Convert-MsolDomainToFederated –DomainName <federated domain name> -SupportMultipleDomains

It is recommended that you do not change UserPrincipalNames or ImmutableIds after converting your domain to the managed state for users that have been switched to use synchronised passwords.

It is worth noting that switching between Federated Authentication and Synchronised Password Authenication for sign in to Office 365 is not instant and will likely interrupt service access. This may not be a factor in the initial activation (as it’s likely an outage scenario) however it is something to bear in mind when cutting services back to Federated Authentication.

Hybrid Exchange 2007/2013 and Lync EWS Integration

I came across an interesting issue recently with a client currently running Exchange 2007 and looking to migrate to Exchange Online. Since Update Rollup 10 for Exchange 2007 Service Pack 3, it has become possible to coexist Exchange 2oo7 and Exchange 2013.

After installing Exchange 2013 as the Hybrid server, this particular client ran into an issue with the Lync 2013 client losing EWS integration with any mailboxes that still reside on Exchange 2007. The net effect of this is that any users that hadn’t been migrated from Exchange 2007 to Exchange 2013 or Office 365 would have to rely on Outlook MAPI (and Outlook being open) for anything to do with the Personal Information Manager feature of Lync.

Microsoft have confirmed this is a known issue and there is no workaround or hotfix. It’s worth noting that the issue is isolated to a 2013 Hybrid configuration in coexistence with Exchange 2007 only, so a Hybrid Exchange 2010/2007 environment might be the more appropriate solution here.
Update: Microsoft have released a KB article stating that the workaround is to migrate the Exchange 2007 mailboxes to Exchange 2013


The Lync client will try to connect to Exchange but will prompt with the following:

Legacy versions of Exchange are unable to proxy requests to Exchange 2013, however Exchange 2013 can proxy to legacy versions. This means that a key step of a Hybrid implementation is pointing the Autodiscover service to Exchange 2013, which is when this issue manifested.

In the image below you can clearly see there is an error with the conversation icon and the alert in the bottom right corner is an EWS integration error. The Calendar icon is also missing from the top row.

In Lync “Configuration Information” you’ll notice that there is no server listed for the “Contact List Provider” and under “EWS Information” it shows the status as “EWS not deployed”

Delving into this a little further, looking at the IIS logs on the Exchange 2013 Hybrid server (or the Exchange 2013 server hosting the CAS role), you can see that there is a successful 200 response to the initial authentication request:

2014-03-26 00:36:48 POST /autodiscover/autodiscover.svc &CorrelationID=<empty>;&cafeReqId=680dcd6d-2d78-452c-acc2-7659fdc97343; 443 CONTOSO\test1 OC/15.0.4569.1503+(Microsoft+Lync) – 200 0 0 15

However when you get to the Autodiscover logs, you can see that the Autodiscover XML file is never actually downloaded by the Lync client due to the mailbox being on Exchange 2007.

2014-03-26T00:36:48.196Z,680dcd6d-2d78-452c-acc2-7659fdc97343,15,0,847,30,,Negotiate,True,,,OC/15.0.4569.1503 (Microsoft Lync),,EXCHANGE13,EXCHANGE13.CONTOSO.LOCAL,GetUserSettings,200,InvalidRequest,0,0,1,,,,,GlobalThrottlingPolicy_d74d65fa-cdb4-4e06-be99-6f259ea1158a,,,0,8,0,8,,0,15.63,ADSessionSettingsFromAddress=0;ADRecipientSessionFindBySid=15.63;;S:ServiceCommonMetadata.RequestSize=1527;S:WLM.Bal=300000;S:WLM.BT=Ews;S:BudgetMetadata.MaxConn=27;S:BudgetMetadata.MaxBurst=300000;S:BudgetMetadata.BeginBalance=300000;S:BudgetMetadata.Cutoff=3000000;S:BudgetMetadata.RechargeRate=900000;S:BudgetMetadata.IsServiceAct=False;S:BudgetMetadata.LiveTime=00:01:00.2078770;S:BudgetMetadata.EndBalance=300000;Dbl:WLM.TS=15.63;I32:ATE.C[DC01.CONTOSO.LOCAL]=1;F:ATE.AL[DC01.CONTOSO.LOCAL]=0;I32:ADS.C[DC01]=1;F:ADS.AL[DC01]=4.9612,,ErrorMessage=The SOAP-based AutoDiscover service is not available for mailboxes on Exchange 2007.;

Exchange 365 – Transport Rules & Distribution Groups

One of our customers is transitioning from on premise Exchange 2010 to a hybrid Exchange 365 (wave 15) environment and user management for Office 365 done through on premise Active Directory. Customer had quite a few transport rules setup up which needed to be migrated. This worked fine except for the rules using a “redirect the message to” action using a distribution group.

The error displayed in Exchange 365 generated is: The transport rule can’t be created because, the recipient to be added by a rule action, is a distribution group. Transport rules can’t add distribution groups to messages.

Checked with Microsoft Support and they confirmed that this is an issue.


There might be better ways of doing this but I wanted to make sure that no additional Office 365 licenses were required hence the use of shared mailboxes (which are free as long as you stay within a 5Gb size limit – which shouldn’t be a problem as the mailbox is purely used for forwarding). In the example workaround below I’m using the following (account) names:

  • as the Distribution group used in the original Exchange 2010 transport rule
  • as the account to be used in the Exchange 365 transport rule
  • Company:ENTERPRISEPACK as the Office 365 AccountSkuId
  1. Using the EMC create a normal user + mailbox: (Make sure name is meaningful and set a description for future reference.)
  2. On the properties General tab, select “Hide from Exchange address lists”
  3. Wait for DirSync to synchronise the account or manually kick off a sync.
  4. Assign an Office 365 license (this will only be temporary) to either using the EAC or the following PowerShell command:

    Set-MsolUserLicense -UserPrincipalName “” -AddLicenses “Company:ENTERPRISEPACK”

  5. From the EMC move the TR-Marketing mailbox to Exchange 365.
  6. Convert the ‘normal’ mailbox to a ‘shared’ shared mailbox using the following PowerShell command:

    Set-Mailbox -Identity “” -Type “Shared” -ProhibitSendReceiveQuota 5GB -ProhibitSendQuota 4.75GB -IssueWarningQuota 4.5GB

    As this shared mailbox is used as a forwarding address, I didn’t set any mailbox or recipient permissions.

  7. Remove the Office 365 license assigned previously assigned either using the EAC or PowerShell:

    Set-MsolUserLicense -UserPrincipalName -RemoveLicenses “Company:ENTERPRISEPACK”

  8. From either the EMC or EAC set the accounts forwarding address to Do NOT set Deliver message to both forwarding…..
  9. Assign to the “redirect the message to” action in the Exchange 365 transport rule.

Note: As user accounts are managed through on premise AD, do NOT delete the user created in Step 1.

As I said, there might be better or easier ways of doing this. Please comment if there are any.