Exchange and the LegacyExchangeDN Problem

KB ID 0001468

Problem

Why do we have the Exchange LegacyDN? It’s a throwback, from a time when we had our users, and our mail users in different databases. Below you can see the ExchangeLegacyDN for this Exchange on-premises user;

/O=First Organisation/OU=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn={something-user-specific}

Who cares? Well they are still important, if you send an internal email (to someone in the same Exchange Organisation). Exchange uses this address NOT the SMTP address which you would expect. Also Microsoft Outlook has a habit of caching this address and NOT the SMTP address. Normally this is not a problem, UNTILL you migrate your mail somewhere else, then the internal cached ExchangeLegacyDN addresses are now incorrect. (See error message below).

How Does Migrating To Office 365 Handle This?

If you do a Hybrid Exchange Migration with Azure AD sync, this is all ‘fixed’ in the background for you, When you first get your AD user ‘synced’ (i.e before you migrate the mailbox) you get an X500 address that’s just used in O365.

Then once the mailbox is migrated the users gets the ExchangeLegacyDN copied across as an additional X500 Address.

In fact if you repeat the command we did at the very start, you will see the on-prem user no longer has an ExchangeLegacyDN

Note: As pointed out, (below) you can run ‘Get-Remotemailbox “Pete Long” |  FL LegacyExchangeDN‘ to locate mailboxes not hosted on the mail server you are working on.

LegacyExchangeDN Problems

You will see problems ‘Post Migration‘ to another domain, to a newer version of Exchange, or if you use a third party tool, to migrate your users to Office 365, (which is just another domain to be honest).

If your users attempt to send an email to a ‘cached’ address, they will get an error that looks like this;

More Info for Email Admins
Status code: 550 5.1.11

The recipient email address is a LegacyExchangeDN address, which isn’t used by the Office 365 service. You might see this error if you’ve migrated your organization’s email from on-premises to the cloud, or if your organization has a hybrid configuration and you synchronize your on-premises directory with Office 365. If clearing the recipient Auto-Complete List from the user’s Outlook or Outlook on the web doesn’t solve the problem, try to clear the related LegacyExchangeDN address from your on-premises Active Directory. Then synchronize the directory again.

For more information, see Fix email delivery issues for error code 5.1.11 in Office 365.

Original Message Details

Created Date:     06/09/2018 15:37:37

Sender Address: pete@pnl.co.uk

Recipient Address:            IMCEAEX-_O=PNL_OU=First+20Administrative+20Group_cn=Recipients_cn=Bob+2EGSmith@GBRP265.PROD.OUTLOOK.COM

Subject: CRS Update

Error Details

Reported error:  550 5.1.11 RESOLVER.ADR.ExRecipNotFound; Recipient not found

You can either tell your users to run (within Outlook) File > Options > Mail > Send Messages > Empty Auto-Complete List.

Or try fighting with your users NK2 Files, (if you are on older versions of Outlook).

Outlook Autocomplete / Nickname / Nk2 file

Or you can export all the ExchangeLegacyDN addresses from your source domain, (in x400 format), convert them to x500 format and import them into your new domain as an additional ProxyAddress, that will get replicated to Office 365, or understood by your newer version of Exchange. (NOTE: If you are running AzureAD Sync you import them into the on-prem domain and let the changes synchronise to Office 365.)

Export LegacyExchangeDN Addresses (Source Domain)

On a DC or a machine that you have imported the Active Directory module;

[box]

Get-ADUser -SearchBase “DC=YOUR-DOMAIN,DC=COM” -Filter * -Properties SamAccountName,legacyExchangeDN | Select-Object SamAccountName,legacyExchangeDN | Export-CSV C:\Temp\Exported-LegacyDN.csv -NoTypeInformation

[/box]

Import LegacyExchangeDN Addresses (Target Domain)

Save the following as Import.ps1 then run the script;

[box]

Import-Module ActiveDirectory
$Input = Import-CSV C:\Temp\Exported-LegacyDN.csv
ForEach ($ADUser in $Input){
if ($ADUser.legacyExchangeDN){
Set-ADUser -Identity $ADUser.SamAccountName -add @{proxyAddresses=”X500:$($ADUser.legacyExchangeDN)”}
}
}

[/box]

Related Articles, References, Credits, or External Links

NA

Forward Mail From Exchange (On-Prem) To Office 365

KB ID 0001467

Problem

WARNING: Do not do this, if you are carrying out a Hybrid migration to Office 365!

I’ve been doing an On-Prem to Office 365 migration recently. It was a little unusual because the ‘on-prem’ Exchange was not in the clients domain. So rather than migrate all the mail to their domain, and them migrate it to Office 365  we chose to use a third party migration solution ODME (Quest On Demand Migration for Exchange). 

So using their tool I could migrate the ‘DATA’ and then the plan is to use the Quest CPUU (Client Profile Update Utility) to repoint all the clients Outlook profiles to Office 365.

Thats fine but how to keep the mail ‘up to date’ in both locations while they are being migrated. I thought (incorrectly) that the Quest ODME would do this, but forwarding from on-prem Exchange deployments is not supported.

This is what I wanted to do;

Then I could migrate everyone, then move the mail flow to Office 365, by simply changing the DNS (MX) Records.

Solution

I’ve covered forwarding of mail before in this previous article (you might want to have a read though that one fist).

Microsoft Exchange – Forwarding Mail To External Email Addresses

So I know what the commands are, and I can supply the usernames and the email addresses to forward to, in a CSV file.

Firstly: You need to enable Forwarding to your office 365 email address*

[box]

New-RemoteDomain -Name YOUR-DOMAIN-O365 -DomainName your-domain.onmicrosoft.com
Get-RemoteDomain YOUR-DOMAIN-O365 | Select DomainName, AutoForwardEnabled

[/box]

*Note: I’m using the ‘onmicrosoft.com‘ tennant email as it is already publicly routable, and lets me still have my live mail feed pointed to the on-prem Exchange.

Now assuming you have all your on-prem usernames and their Office 365 email address sin a CSV file like so,

And you have saved the CSV file as C:\Temp\Office-365-Users.csv, use the following script.

[box]

Import-Csv -Path "C:\Temp\Office-365-Users.csv" | ForEach-Object {
	Set-Mailbox -Identity $_.'Source-User' -DeliverToMailboxAndForward $true -ForwardingSMTPAddress $_.'Target-Mailbox'
}

[/box]

To test it worked;

[box]

Get-Mailbox | Where {$_.ForwardingSMTPAddress -ne $null} | Select Name, UserPrincipalName, ForwardingAddress, ForwardingSMTPAddress, DeliverToMailboxAndForward

[/box]

To Remove it when you have finished;

[box]

Get-Mailbox | Set-Mailbox -DeliverToMailboxandforward $False -ForwardingSMTPAddress $Null -ForwardingAddress $Null

[/box]

Related Articles, References, Credits, or External Links

NA

Office 365: Grant a User Full Mailbox Access to all Mailboxes

KB ID 0001466

Problem

Obviously there are some security concerns about having a user with full mailbox access to all mailboxes! But that aside, I was using a third party Migration tool last week, and it needed to connect to every mailbox with full access rights to perform the migration.

So this is how I did it;

Solution

Firstly you need to connect to your Office 365 tenant with PowerShell;

Connect to Office 365 Exchange PowerShell

Now I could grant access to one user, but I’m going to create a ‘Group’, Exclude that group from the Global Address List, Put my user in that group. Then Finally grant the ‘group’ rights to all the mailboxes.

[box]

New-DistributionGroup -Name “365-Migration-Admins” -Type "Security"

Set-DistributionGroup "365-Migration-Admins" -HiddenFromAddressListsEnabled $True

Add-DistributionGroupMember -Identity "365-Migration-Admins" -Member "Pete@tenant.onmicrosoft.com"

Get-Mailbox -ResultSize unlimited -Filter {(RecipientTypeDetails -eq 'UserMailbox')} | Add-MailboxPermission -User 365-Migration-Admins@tenant.onmicrosoft.com -AccessRights FullAccess -InheritanceType all

[/box]

Related Articles, References, Credits, or External Links

NA

O365: Enable Application Impersonation

KB ID 0001449

Problem

While using a migration tool to do some ‘on-prem’ to Office 365 migrations I had to enable ‘Application Impersonation’ for my Office 365 user. The tool didn’t explain how to do that, so I had to work it out for myself 🙁

So to make things easier for everyone else, here’s how to do it.

Solution

From within the Office 365 portal > Admin > Exchange.

Dashboard > Permissions > Admin roles.

Give the role a name/description e.g. Application-Impersonation (I hate spaces!) > Then Add the ApplicationInspection role, (seems the developers at Microsoft also hate spaces!) > OK.

Scroll down to ‘Members‘ and add in the user you want to allocate this role to > OK > Save.

Related Articles, References, Credits, or External Links

NA

Migrating Mailboxes From On-Premises to Office 365

KB ID 0001419

Problem

This post continues from Part-One where we connected both our domain, and on-premises Exchange server to Office 365. Now we will add our public domain, and migrate our mailboxes.

Step 3 Adding Domains to Office 365

Before proceeding you will need administrative access to your public DNS records so you can create new records.

Log into Office 365 > Admin Console.

Add a domain.

Enter your public domain name > Next.

Now you need to create a ‘Text Record” in you public domain, the TTL does not really matter but the TXT value must match exactly.

As below, once created click (Verify).

Ill manage my own DNS records > Next.

We are only concerned with Exchange > Next.

STOP: These are the DNS records you need to create if you want everything to point to Office 365, DO NOT CREATE THEM if you want your mail to still get routed to your on-premises, and you want your Autodiscover to point there. I leave everything pointing to my on-premises server!

So I DON’T create the records (below) unless I’m about to decommission an on-premises Exchange server.

If you DID want all mail and auto discover to route to Office 365 that’s fine BUT change the SPF record that Microsoft gives you to include the public IP of your on-premises server of you may start getting mail blocked.

i.e.

Microsoft Suggests: “v=spf1 mx include:servers.mcsv.net ?all”

Use: “v=spf1 ip4:123.123.123.123 mx include:servers.mcsv.net ?all”

Finish.

Test Mail Flow

If you have made any public DNS changes, then before you do anything else, make sure mail continues to flow in and out of your on-premises Exchange organisation as it did before!

Step 4 Mailbox Migration

Log into Office 365 and locate a user to perform a test migration on, then allocate them an office 365 licence.

Then from the Office365 Admin Center > Recipients > Migration > Add > Migrate to Exchange Online > Remote move migration > Next.

Add in your ‘Test user’ > Next.

Supply your Exchange administrative credentials > Next.

Put in your MRS proxy FQDN > Next

Note: You may see the following error

MRS Proxy Error ‘The connection to the server could not be completed’

Give the batch a name > Next.

Select an email address to be sent a migration report, Note: For the test migration I’m leaving it on ‘Manual Complete’ once Im happy I would select ‘Automatically Complete’ > New.

You can view a ‘hight level’ progress, or click the download link;

To view a more detailed report.

Note: You can connect to O365 PowerShell online, and view the migrations from command line like we normally do with an on-premises mailbox migration. See the following link;

Connect to Office 365 Exchange PowerShell

When finished complete the migration.

Migration completed.

Viewing the same thing from PowerShell;

Now test mallow in/out from on-premises and from Office365, then make sure mail also flows between on-premises and Office 365 (both ways).

Make sure calendar sharing scheduling also works between on-premises and Office 365 mailboxes.

Once you are happy, you can migrate the rest of the mailboxes.

 

Related Articles, References, Credits, or External Links

NA

Office 365: Migrating To Exchange Online

KB ID 0001418

Problem

This is Part-One of a migration from ‘on-premise’ Microsoft Exchange, to Office 365 (Exchange Online). I’m using my spare ‘test domain’ (.co.uk). And I’m using the 5 user E3 Office 365 subscription that the good folk at Microsoft let me have, as part of my MVP benefits.

Note: I’m using Exchange 2016, with a ‘full-hybrid’ migration into Office 365.

Step 1: Pre-Requisites

DNS: You will need access to the DNS records for your public domain, both to ‘prove’ it is your domain, and to divert mail flow, and client requests to Exchange online, rather than your on premise Exchange.

Licenses/Subscription: You need an office 365 subscription, and available licences for all the users you want to migrate. At time of writing the minimum subscription level that includes Exchange Online is E3. (Note that’s not strictly true, you do get Exchange online with E1, but you dont get any office products, so I’ve never seen an E1 licensed migration). You’ll need to have access to Office 365 with a ‘global administrator‘ account.

Backups: Not really a pre-requisite, but how are you going to backup your cloud mailboxes? As far as Microsoft is concerned, your online email gets deleted after its retention period, (amount of time after a user deletes it, i.e. up to 100 days). If your business continuity plan, requires you to keep mail ‘x‘ years, then you will need to think about Azure Backup, or a third party backup solution.

Existing Exchange: Unless you are going to use a third party migration tool, then your on premise Exchange needs to be at Exchange 2010. So if you’re still at Exchange 2007/2003/2000, then you need to either; 1) Upgrade your on-prem Exchange, 2) Do another on-prem migration before you start, or 3) Purchase a third part migration tool. Note: With Exchange 2007 you can add one Exchange 2010 Exchange server, then migrate.

Certificates: You MUST HAVE a certificate on your Exchange that is publicly singed by a third party certificate vendor. There’s no excuse to use self signed certificates these days, (for Exchange). For this exercise I bought a certificate for a year and it cost me less than ten dollars, thats half the price of a one users monthly licence for Office 365? WARNING even with a correctly setup PKI environment with publicly published CRLs etc, your own certificates wont work, and you wont find out what’s wrong, until you have migrated users, and carnage/downtime will ensue! BUY A CERTIFICATE: I’d recommend a wildcard cert for your public mail domain.

 

User UPN’s: I’ve already covered this before in the past, things will be a lot easier, if you change all your users UPN’s to match their Email addresses.

 

For more information, see the following article;

Changing Domain Users’ ‘User Logon Names’ and UPN’s

Step 2: Onsite Preparation

Fail to prepare – prepare to fail.

What most people fail to do is make sure both their AD domain, and existing Exchange is healthy, (just because everything appears to be working, doesn’t mean everything is healthy). Install the latest cumulative update for your on-premise Exchange server ,and dig into the logs to make sure everything is as it should be!

Mailbox Replication Proxy Service

MRS Proxy is at the same solution we use for ‘cross-forest’ mailbox migrations, and your on-prem Exchange will act as the MRS proxy for your mailbox migration. To enable MRS Proxy: Exchange Admin Center > Servers > Virtual Directories > EWS > Edit.

General > Enable MRS Proxy Endpoint > Save

You can also check the service is running, (Windows Key +R > Services.msc {Enter}).

Exchange 2010 Note: If you’re running Exchange 2010, you can enable MRS Proxy with the following PowerShell command;

[box]Set-WebServicesVirtualDirectory -Identity “EWS (Default Web Site)” -MRSProxyEnabled $true -MRSProxyConnections 50[/box]

Azure Active Directory Connector

You can download the Azure AD connector from Microsoft, it can be installed on any member server. It will replicate your users and groups etc, into Office 365. Download and execute the installer > Tick ‘I agree….’ >  Continue.

Use Express Settings.

Note: You would only NOT use Express settings if you only wanted to replicate certain groups or sub domains, or if you wanted to use ADFS, (for example because you already had Azure secured services).

Provide your office 365 logon details > Next.

Provide logon details for your on-premise domain > Next.

You will probably only see your local domain, and it will be flagged ‘Not Added’ that’s fine, below you can see my public domain because it’s already been added to office 365, (I’ll cover that later) > Next.

Tick ‘Exchange hybrid deployment’ > Install.

Read and act on any warnings > Exit.

Note: If, (as above) it asks you to enable the ‘AD Recycle bin’, see the following post;

Windows Server 2016: Active Directory Recycle Bin

It will take a while, (depending on the size of your AD,) to replicate.

After a while you will start to see all your users appear in your office 365 portal, as they are replicated across.

Enable Exchange Hybrid Deployment

Back in Exchange admin Center > Hybrid > Configure > Sign into Office 365.

Once authenticated, notice the URL changes to Exchange online! > Configure.

Click here > Install.

Run.

Next.

I only have one on-premise Exchange server, so that’s selected,( if you had multiple servers, choose the one you want to use) > Next.

Sign in.

Once authenticated > Next.

Full Hybrid > Next.

Enable.

You need to create a ‘text’ record in your public DNS to proceed.

So I’ve jumped on my public DNS host management portal, and created the text record required.

Tick ‘I have created…..’ > Verify > Next.

I dont have any ‘Edge Transport Servers’ > Next.

Again I only have one, if you have multiple CAS servers, select the one you want > Next.

And again for the ‘Send Connector’ select the CAS server that will connect to Office 365 > Next.

Select your certificate. MAKE SURE it has selected a publicly signed one, NOT a self signed one! > Next.

Enter the correct public FQDN for your on-prem Exchange > Next.

Note: This must match either the CN on your certificate, or if it’s a wildcard certificate, the domain must be the same.

Update

Close

So far so good, in Part Two, I’ll add my public domain to my Office 365 account and start migrating some users.

 

Related Articles, References, Credits, or External Links

NA

Connect to Office 365 Exchange PowerShell

KB ID 0001410

Problem

If there’s one thing thats grown on me it’s PowerShell, After the last few versions of Exchange you can’t really escape it. So now we have so many clients with their Exchange in Office 365. The ability to connect to that, and use all your usual Exchange commandlets is a bonus!

WARNING: This process may end up with you getting an “Access is denied” error, if you are using modern authenticiction, or MFA. If so use this article instead.

Solution

If you haven’t already done so, you need to ‘slacken‘ your signing policy, (a little) before proceeding;

[box]Set-ExecutionPolicy RemoteSigned[/box]

Now to access Exchange online you need to be able to authenticate to it, the best way to do that is to ‘cache’ your logon credentials. (Unless you have ADFS Federation then you can skip this step). To enter your O365 creds execute the following command;

[box]$UserCredential = Get-Credential[/box]

Then create the settings for your remote session;

[box]$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection[/box]

Then to open the session;

[box]Import-PSSession $Session[/box]

DON’T FORGET: When you are finished, to disconnect the session with the following command;

[box]Remove-PSSession $Session[/box]

Related Articles, References, Credits, or External Links

NA