Incorrect Email Address Applied after Mailbox migrated to Office 365

Introduction

By default, whenever you create a mailbox in your Exchange infrastructure, the primary email address for the mailbox is being assigned based on the email address policy applied to the user. Recently, I have been working with a customer for Exchange 2010 hybrid implementation with Office 365 and we ran into an issue of email address being changed after the mailbox is migrated to Office 365. Primary email address of mailboxes being migrated to Office 365 from on-premises Exchange 2010 had been changed. You will notice this issue in your hybrid implementation if you have more than one email address policy applied in your exchange organization.

Understanding Email Address Policy

From the behavior of email address, it was obvious it’s being done by email address policy but the question is which email address policy and why? As we are running infrastructure in a hybrid mode and our on-premises infrastructure is the source of authority so we need to look into Exchange 2010 email address policies to fix the issue.

If you have more than 1 email address policy in your Exchange organization than It’s recommended to review your email address policies before moving any mailbox to Office 365.

In my scenario, i had 2 email address policies configured on Exchange 2010 as shown below.

Incorrect Email Address Applied after Mailbox migrated to Office 365As you can see, We had two email address policies configured and the policy with the name of “Set Email Address” has highest priority.

For those of you who don’t know why we need to create another email address policy, In Exchange 2010,  you cannot modify the criteria and conditions of default email address policy that’s why organizations tend to create a new custom policy as per their requirements. Default email address policy assign an email address of firstnamelastname@domain.com with a scope of “All Recipient Types“.

Incorrect Email Address Applied after Mailbox migrated to Office 365The custom email address policy was configured to be applied on “Users with Exchange Mailboxes” and the primary email address was configured as first initial and last name (e.g. rjbutt@msexperttalk.com)

Incorrect Email Address Applied after Mailbox migrated to Office 365

Why Email Address was changed?

We understand the email address policy configuration, now whenever a mailbox is migrated to Exchange Online the Default Policy will be applied to the mailbox instead of the custom policy because the custom policy scope is set to only “User Mailbox” and when you move a mailbox to Office 365, it converts the mailbox to MEU and our custom policy was not applied to MEU. As a result, the default reply address is set to riaz@msexperttalk.com instead of what might have been originally intended.

How to Fix It?

Now, we understand the problem and it’s time to fix the issue. We have 2 options to fix this issue.

  • Modify the Custom Policy to apply to all Recipient Type
  • Modify your default email address policy to add additional SMTP address matching the custom policy and set the email address as primary address

Once you apply the fix, you need to wait for Azure AD connect sync to happen to replicate the changes to Office 365. Hope this article help you fix your issue with incorrect email address applied to user mailbox after the mailbox is migrated to Office 365.

Exchange 2013 Email Stuck in Draft

Recently I was troubleshooting an interesting mail flow issue where the users were not able to send or receive email. Apparently everything was working fine on Exchange server but users were not able to send or receive any email internally and externally. Customer did everything to troubleshoot the issue and even thought to setup a new exchange 2013 server and move services over to new server. You can imagine mail flow was broken for some reason. When i was being asked to troubleshoot the issue. I had a technical session with the customer to understand the problem in detail and i got a typical response.

Riaz whenever we had this issue, we restart exchange server 2 or 3 times and everything start working again.

Well, being a Consultant i was expecting such response. Anyhow, i asked the customer when they noticed this issue and they told me whenever we try to upgrade our Exchange server to latest CU, setup failed and we started to face this issue. I have discussed the issue of Exchange 2013 CU upgrade here.

When i started to troubleshoot the issue, i noticed that everything on Exchange server was working fine like services, ECP, EMS, OWA, Autodiscover, Outlookanywhere etc. I logged in to OWA as a normal user account and sent an email to internal and external recipient and email straight away went to Draft folder. This makes me think of why this email didn’t hit Exchange server. As you know in Exchange 2013 Mailbox Transport service and the Transport service work together to process messages sent by end users. Below diagram shows the process of mail flow in Exchange 2013.

Exchange 2013 Email Stuck in Draft

In Exchange, OWA automatically store a copy of message in Draft Folder when you compose an email. When you submit an email using OWA it’s being sent to Mailbox submit agent that process outbound message by giving it to Transport services running on mailbox server via SMTP connection. OWA keeps your message in Draft folder until it’s being successfully delivered.

Why Exchange 2013 email stuck in Draft? Well, there are few reasons that can cause this particular behavior with your exchange server. Few of those reasons are as below.

  • Transport or Mailbox transport service isn’t running on mailbox server hosting user mailbox
  • Problem with transport pipeline that prevents outbound message
  • Issue with DNS
  • Transport Service is in maintenance mode

When i started the troubleshooting of this issue, I did the basic Transport troubleshooting steps to verify transport services are running on exchange server and we don’t have any space issue or back pressure on transport queue that can cause this issue. Next step was to verify name resolution is working fine. To do so, we need to make sure that you have appropriate internal and external DNS binding is configured for your Exchange server. To verify your DNS binding, login to Exchange Admin Center and navigate to EAC>Servers>Select Server and click on Edit and go to DNS.

Exchange 2013 Email Stuck in Draft

You can also check your internal and external DNS server by running the EMS cmdlet. If you notice that external DNS is setup then make sure you can resolve names using external DNS. In my case, DNS was working fine.

Get-TransportServer | fl InternalDNSServers, ExternalDNSServers, Identity

2

Once you’ve verified that your DNS is setup properly. Next step is to verify that your Exchange transport services is working fine. Apparently if you look at your transport services in services.msc console you will see the services are running. To verify it’s not in maintenance mode, run the cmdlet Get-ServerComponentState and verify that all components are in “Active” state. If your components are “Inactive” then run the following cmdlet to bring them in active state. In my case, servercomponentstate was InActive.

5

Set-ServerComponentState -Identity “ServerName” -Component ServerWideOffline -State Active -Requester Maintenance

4

Rerun the cmdlet Get-ServerComponentState -Identity “ServerName” to verify all components are in Active State.

3

In my case, removing the transport service from Maintenance mode fixed the issue and all emails in Draft folder were being sent successfully. The reason why transport services were in maintenance mode because customer did an attempt to perform Exchange 2013 CU12 upgrade and whenever you perform your Exchange upgrade, it set the services in maintenance mode to avoid any interruption.

 

Azure AD Sync “Permissions-Issue” Error Code-8344

Azure AD Sync “Permissions-Issue”

Today i have been working on troubleshooting Azure AD Sync tool for one of my customer where they were having issues with the tool. MIIS client was reporting export errors for all the users in the organization and the error was “Permissions-Issue”. It was one of the interesting errors to work on and it took me a day to resolve the issue and i thought to share the remedy with all of you so that you should be able to resolve this issue within an hour.

Azure AD Sync Export Error

Whenever AAD Sync perform synchronization with office 365, evertime we were getting the error message on “Export”. If we look at the error message it says “Permissions-issue” and we verified that our on prem service account and Office 365 service account has all the required permission for AAD Sync tool. At one stage we thought it’s a false error but No it’s not a false error and it does have a solution. Below is the screenshot of error message that we were getting.

Azure AD Sync error When you click on permission-issue you’ll see the following screenshot which is giving us the details of error message along with error code.

AAD Sync permission error details

Let’s get started to resolve this error and below are the steps that we need to perform to resolve this issue.

Resolve AAD Sync Export Error

If you click on Permission-Issue to see the detail you’ll see that Connected date source error code is 8344. To resolve this issue, perform the following steps

1. Run Active Directory Inheritance script to get a list of users on which inheritance is blocked. Once you’ve the list pls make sure that you allow inheritance on those users/groups.

To allow inheritance, Make sure Advance Features are enabled in View then go to user properties –> Security –> Advanced –> Select the check box “to include inheritable permissions from this object’s parent”

2. Make sure you’ve the required on prem permissions assigned to Azure AD Sync tool service account. You can assign the appropriate permissions to Azure AD Sync tool by following this article.

3. Once you’ve check the inheritance and required permissions. Make sure that the service account is a part of AAD Sync security group in active directory. The name of security group is MSOL_AD_Sync_RichCoexistence. After you add the service account to the group, re-run the full synchronization and you will see that all permission-issue errors are gone.

In my case, customer was using AAD Sync along with password sync and they had Exchange 2010 SP3 hybrid configured.

Hope this article will help you resolve your issue with Azure AD Sync tool. Please feel free to ask us in case you have other issues. Thanks.