Assessing 2003 DNS infrastructure prior to Migration

Prior to migrating from Server 2003 to Server 2012 R2, you’ll need to figure out which servers in your organization are functioning as DNS servers. You’ll also have to figure out which DNS zones are hosted on your DNS servers and the nature of those zones.

An Active Directory Integrated zone is stored within Active Directory. A standard primary or secondary zone is stored in a file. Stub zones, which just host name server records, can also either be stored in Active Directory or within a file.

Windows Server 2003 DNS deployments generally take two forms, domain controllers as DNS server or stand alone DNS servers. Stand alone DNS servers will be configured to host either the standard primary or standard secondary version of a zone. While domain controllers can also host standard primary and standard secondary versions of a zone.

You can determine whether a zone is stored within Active Directory or as a file by using the following command on a DNS server:

1. Dnscmd /enumzones

You can also do it by checking the zones in the DNS Manager console. The advantage of using dnscmd is that you can use it to remotely query DNS servers.

You should also determine if any DNS forwarders are configured and if any Advanced options, such as round robin or netmask ordering, are configured in a way that differs from the defaults. In general, most organizations don’t change the defaults, but it’s a good idea to do a check during the assessment phase rather than figuring out that you missed an important bit of configuration information half way through your migration.

Bulk Migrate Office 365 Licenses

This is a follow-up post to Bulk Enable Office 365 License Options and reflects an unusually complex scenario where O365 licenses must be migrated to a different SKU.  Here is a real-world example…

Customer initially purchases E1 licenses and begins to provision and migrate accounts using the included service options (i.e. Exchange, SharePoint, and/or Lync).  Customer then realizes they require an expanded feature set and decides to purchases E3 licenses to replace the E1.  However, by this time many users already have a live Exchange mailbox under E1.  To complicate matters further, some users have now been enabled for SharePoint and/or Lync using the new E3 license while Exchange is still enabled under the original E1.  (Yes, this is possible as long as the same service is not enabled in both SKUs.)  Wow, what a mess!  So, how do we “flip” all the E1 licenses to E3 without data loss?  I’m glad you asked :-)

First, a couple key considerations:  (1) un-assigning an Exchange license for users which have already been enabled can result in the re-provisioning of an empty mailbox; (2) at no point can the same service be enabled under two different SKUs; (3) if Office Web Apps is to enabled under E3 then SharePoint must also be assigned under E3.  Scared yet?  Here we go…

We will definitely need some logging for this:

$LogFile = "c:\o365\SwitchLicense.log"; Get-Date | Out-File $LogFile

We already know that if the user does not have a mailbox under E1, we will not be enabling the Exchange option under E3.  So, let’s define that license option:

$NoExchange = New-MsolLicenseOptions -AccountSkuId "tenant:ENTERPRISEPACK" -DisabledPlans "EXCHANGE_S_ENTERPRISE"

Next, we’ll create a data set to run against.  As always, I prefer to use a CSV import when making bulk changes.  But, the task could be run against all accounts.  In either case, keep in mind that some users may have both E1 and E3 assigned.  So, we must query for each.  If the user is not licensed at all, then we’ll make note of that in the log file and move on:

Import-Csv "c:\o365\ImportFile.csv" | ForEach {

#Get-MsolUser -All | ForEach {

$Upn = $_.UserPrincipalName; $Licensed = $_.IsLicensed

$UserLicense0 = (Get-MsolUser -User $Upn).Licenses[0]

$UserLicense1 = (Get-MsolUser -User $Upn).Licenses[1]

If ($Licensed -eq $False) { "SKIP: No license currently assigned [$Upn]" | Out-File $LogFile -Append }

If the user is currently licensed for only E3, then there is nothing to “flip”.  We’ll make note of that in the log and continue:

If ($UserLicense0.AccountSkuId -eq "tenant:ENTERPRISEPACK" -and $UserLicense1 -eq $null)

{ "SKIP: Only E3 license currently assigned [$Upn]" | Out-File $LogFile -Append }

If the user is only licensed for E1, then we can easily flip to E3.  However, we don’t necessarily want to enable options under E3 that were not enabled under E1.  For now, let’s assume all options under E1 are disabled.  We will query the assigned E1 license to determine which options are actually enabled and write the result to the log file:

If ($UserLicense0.AccountSkuId -eq "tenant:STANDARDPACK" -and $UserLicense1 -eq $null) {

$Lync = "Disabled"; SharePoint = "Disabled"; $Exchange = "Disabled"

(Get-MsolUser -User $Upn).Licenses[0].ServiceStatus | ForEach {

If ($_.ServicePlan.ServiceName -eq "MCOSTANDARD" -and $_.ProvisioningStatus -ne "Disabled") { $Lync = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "SHAREPOINTSTANDARD" -and $_.ProvisioningStatus -ne "Disabled") { $SharePoint = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "EXCHANGE_S_STANDARD" -and $_.ProvisioningStatus -ne "Disabled") { $Exchange = "Enabled" } }

"SCAN: Only E1 license currently assigned [$Upn] Lync:$Lync, SharePoint:$SharePoint, Exchange:$Exchange" | Out-File $LogFile -Append

If the E1 user does not have Exchange assigned, we can safely flip to E3 with Exchange disabled.  However, if the E1 userdoes have Exchange assigned, then we must transition to E3 by removing the old license and assigning the new license in a single command.  In both cases, we will write the results to the log file:

If ($Exchange -eq "Disabled") { Set-MsolUserLicense -User $Upn -RemoveLicenses "tenant:STANDARDPACK" -AddLicenses "tenant:ENTERPRISEPACK" -LicenseOptions $NoExchange }

Else { Set-MsolUserLicense -User $Upn -RemoveLicenses "tenant:STANDARDPACK" -AddLicenses "tenant:ENTERPRISEPACK" }

"MOVE: E1 license moved to E3 [$Upn] Office:Enabled, Lync:Enabled, SharePoint:Enabled, WebApps:Enabled, Exchange:$Exchange" | Out-File $LogFile -Append }

This is where it gets tricky.  If the user has both E1 and E3 assigned, we must determine under which license Exchange is enabled.  Once again, we’ll assume all options are disabled, query both licenses to identify which options are actually enabled, and write the results to the log file:

If ($UserLicense0.AccountSkuId -eq "tenant:ENTERPRISEPACK" -and $UserLicense1.AccountSkuId -eq "tenant:STANDARDPACK") {

$Office = "Disabled"; $Lync = "Disabled"; $WebApps = "Disabled"; $SharePoint = "Disabled"; $Exchange0 = "Disabled"

(Get-MsolUser -User $Upn).Licenses[0].ServiceStatus | ForEach {

If ($_.ServicePlan.ServiceName -eq "OFFICESUBSCRIPTION" -and $_.ProvisioningStatus -ne "Disabled") { $Office = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "MCOSTANDARD" -and $_.ProvisioningStatus -ne "Disabled") { $Lync = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "SHAREPOINTWAC" -and $_.ProvisioningStatus -ne "Disabled") { $WebApps = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "SHAREPOINTENTERPRISE" -and $_.ProvisioningStatus -ne "Disabled") { $SharePoint = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "EXCHANGE_S_ENTERPRISE" -and $_.ProvisioningStatus -ne "Disabled") { $Exchange0 = "Enabled" } }

"SCAN: E3 license currently split [$Upn] Office:$Office, Lync:$Lync, WebApps:$WebApps, SharePoint:$SharePoint, Exchange:$Exchange0" | Out-File $LogFile -Append   

$Lync = "Disabled"; $SharePoint = "Disabled"; $Exchange1 = "Disabled"

(Get-MsolUser -User $Upn).Licenses[1].ServiceStatus | ForEach {

If ($_.ServicePlan.ServiceName -eq "MCOSTANDARD" -and $_.ProvisioningStatus -ne "Disabled") { $Lync = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "SHAREPOINTSTANDARD" -and $_.ProvisioningStatus -ne "Disabled") { $SharePoint = "Enabled" }

If ($_.ServicePlan.ServiceName -eq "EXCHANGE_S_STANDARD" -and $_.ProvisioningStatus -ne "Disabled") { $Exchange1 = "Enabled" } }

"SCAN: E1 license currently split [$Upn] Lync:$Lync, SharePoint:$SharePoint, Exchange:$Exchange1" | Out-File $LogFile –Append

We’re getting close.  If Exchange is enabled under E3 in a “split license” scenario, we can safely remove E1 and enable any previously assigned options under E3.  Remember, Exchange is already enabled under E3:

If ($Exchange0 -eq "Enabled" -and $Exchange1 -eq "Disabled") {

$Exchange = "Enabled"

Set-MsolUserLicense -User $Upn -RemoveLicenses "tenant:STANDARDPACK"

Set-MsolUserLicense -User $Upn -AddLicenses "tenant:ENTERPRISEPACK" }

However, if Exchange is enabled under E1 we must first remove E3 and then flip the entire E1 license (Exchange included) in a single command:

If ($Exchange0 -eq "Disabled" -and $Exchange1 -eq "Enabled") {

$Exchange = "Enabled"

Set-MsolUserLicense -User $Upn -RemoveLicenses "tenant:ENTERPRISEPACK"

Set-MsolUserLicense -User $Upn -RemoveLicenses "tenant:STANDARDPACK" -AddLicenses "tenant:ENTERPRISEPACK }

The last possible scenario would be that Exchange is not enabled under either license.  So, we will simply remove both licenses and reassign E3 without Exchange:

If ($Exchange0 -eq "Disabled" -and $Exchange1 -eq "Disabled") {

$Exchange = "Disabled"

Set-MsolUserLicense -User $Upn -RemoveLicenses "tenant:ENTERPRISEPACK"

Set-MsolUserLicense -User $Upn -RemoveLicenses "tenant:STANDARDPACK"

Set-MsolUserLicense -UserPrincipalName $Upn -AddLicenses "tenant:ENTERPRISEPACK" -LicenseOptions $NoExchange }

Of course, we will write the results of all this license manipulation to the log file:

"JOIN: E1 license merged into E3 [$Upn] Office:Enabled, Lync:Enabled, SharePoint:Enabled, WebApps:Enabled, Exchange:$Exchange" | Out-File $LogFile –Append } }

Problem solved!  This scenario reflects an incredibly complex scenario that I hope you won’t encounter.  But, if you find yourself facing similar circumstance, I trust some of these concepts will prove useful.  It obviously goes without saying that you must thoroughly test this solution on sample accounts or a test tenant before running it against your production environment.

Multi-Forest Migrations to Exchange Online

Over the past few years, I've migrated many mailboxes into Exchange Online. I've talked to customers with every possible set of requirements, and I've been able to accommodate most of them. Until recently, there has been one category of migration requirements that I haven't been able to accommodate: multi-forest migrations. For customers with two or more separate Active Directory (AD) forests, each with their own Exchange deployment, the supported solutions for moving to a single Office 365 tenant were very limited. They could either consolidate their on-premises AD forests into a single forest, or they could contact Microsoft Consulting Services (MCS) and develop a custom solution using Forefront Identity Manager. 

With the recent release of the cumbersomely named Windows Azure Active Directory Sync Services (AAD Sync) and a change in the supported use of DirSync filtering, four new multi-forest Exchange Online migration scenarios are supported, without having to involve MCS or consolidate the on-premises AD forests. The four scenarios are separate topologies, full mesh, account and resource forest, and multi-tenant. After I describe these scenarios, I'll discuss the scenarios' migration requirements and explain how to use AAD Sync to successfully complete the migrations. 

Scenario 1: Separate Topologies

The separate topologies scenario refers to an organization with multiple AD forests (each with its own Exchange deployment) with no trusts or federation setup. In this scenario, all AD forests are completely separate. This situation often results from a merger or acquisition. It can also result from an organization having multiple separate business units that historically have kept their IT infrastructures completely independent of each other. 

With AAD Sync, migrating mailboxes from the separate Exchange deployments into Exchange Online is easy. There are two tasks you should perform before installing AAD Sync:

1. Make sure that each user appears in only one AD forest.
2. Run Microsoft's IdFix tool against all AD forests, and fix any problems discovered.

After you perform these tasks, you simply install AAD Sync in each forest (which I explain how to do in the "Setting Up AAD Sync" section) and proceed with two hybrid Exchange deployments to a single tenant. 

It's important to note that there are some limitations with this configuration, which are best illustrated by an example. Suppose that a user named Mary has an on-premises mailbox in forest A. Mary won't have any users from forest B listed in her Global Address List (GAL). Her GAL will contain only users with on-premises mailboxes in her own forest, users who were created as on-premises mailboxes in her forest and migrated into Office 365, and users who were created as remote mailboxes in her on-premises forest. The same holds true for users with on-premises mailboxes in forest B through Z. To confuse the matter more, once Mary's mailbox is moved into Office 365, she will see everyone listed in her GAL. This happens because mail contacts are created in Exchange Online for every mailbox, but those mail contacts will never be synchronized with the on-premises AD forests. Maybe Microsoft will add a GAL synchronization solution into AAD Sync at some point, but I don't expect it to happen anytime soon. 

Scenario 2: Full Mesh

The full mesh scenario refers to an organization with multiple AD forests (each with its own Exchange deployment) with trusts and federation setup. In this scenario, the organization might have a GAL synchronization solution set up to provide a unified GAL across all, or some, of the Exchange deployments. 

In the full mesh scenario, you migrate mailboxes to Exchange Online the same way you migrate them in the separate topologies scenario, except you might have a GAL synchronization solution to set up. The GAL synchronization solution could be Forefront Identity Manager or a third-party solution. The GAL synchronization solution needs to be separate from AAD Sync because AAD Sync doesn't provide the capability to perform GAL synchronization between on-premises Exchange deployments. How you deploy the GAL synchronization solution depends on the solution chosen, so it's beyond the scope of this discussion. 

Scenario 3: Account and Resource Forest

The third supported scenario is the account and resource forest configuration. In this scenario, the organization has a single resource forest that contains all the Exchange servers in addition to one or more account forests that contain the user accounts. All users will have active accounts in their respective accounts forests and disabled accounts in the resource forest. 

The unified GAL problem found in the previous two scenarios isn't a problem in the account and resource forest scenario because the organization has only one on-premises Exchange deployment and one Office 365 tenant. Therefore, every user is going to see every other user in the GAL. 

The hard part of this deployment is ensuring that AAD Sync properly recognizes the disabled accounts in the resource forest and properly associates them with the active accounts in the accounts forest. To ensure proper account associations, you need to carefully consider the configuration options used for their AAD Sync deployment. These options are discussed in the "Setting Up AAD Sync" section. 

Scenario 4: Multi-Tenant

In the multi-tenant scenario, the organization has a single on-premises AD forest with a single Exchange deployment and wants to connect it to multiple Office 365 tenants. This scenario will most likely come into play for international organizations that want to move to Office 365, but their users must stay in Office 365 data centers within their own regions. 

AAD Sync isn't needed in this scenario. You can migrate mailboxes to Exchange Online using DirSync with some filtering setup. After you deploy one DirSync server in each region, you set up DirSync filtering to ensure that out-of-region users are excluded from their respective tenants. In addition, email address policies need to be configured so that users and contacts in each region are assigned the proper service routing addresses. This solution is easy to deploy, but I suspect that some organizations will have difficulty maintaining the necessary configurations. 

Setting Up AAD Sync

The most important part of the AAD Sync deployment is ensuring that each user has only one account in one of the forests being connected to the Office 365 tenant (except in the case of the account and resource forest scenario, in which case you need to ensure all users have disabled accounts in the resource forest). 

The requirements for installing AAD Sync are:

• A computer running Windows Server 2008 or later.
• Microsoft .NET Framework 4.5.
• A full installation of SQL Server for large AD forests. By default, AAD Sync uses an internal SQL Server Express database. SQL Server Express databases are limited to 10GB in size, so AAD Sync can manage only about 100,000 objects by default.

In addition, at least two accounts are required to complete the AAD Sync installation: one on-premises account that needs read access to AD (default permissions assigned to all user accounts) and one global admin account for your Office 365 tenant. 

After you download AAD Sync, open the MicrosoftAzureADConnectionTool.exe file, which will start the wizard. On the Welcome page, you need to specify the install location of the AAD Sync files. 

Figure 1: Specifying the Location to Install the AAD Sync Files

On the Azure AD Credentials page, you need to enter the global admin account for your Office 365 tenant, as Figure 2 shows. 

Figure 2: Entering the Global Admin Account

On the AD DS Credentials page, you need to enter the Active Directory Domain Services (AD DS) account for your AD forest, as shown in Figure 3. 

Figure 3: Entering the AD DS Account

The User Matching page presents you with the synchronization options. As Figure 4 shows, this page has two sections to complete. 

Figure 4: Selecting the Synchronization Options

In the Matching across forests section, you're presented with the choice between the Your users are only represented once across all forests option and the Match using option. The option selected will determine how AAD Sync will match accounts from separate forests. If your users have only one account across all forests, the choice is easy. You select the former option. If your users are represented in multiple forests, you need to select the latter option, in which case you need to specify the criteria on which to match. Table 1 shows the possible matching criteria and their most common usage. 

Table 1: Matching Criteria

In the Matching with Azure AD section, you select the attributes you want to use as the source anchor and user principal name (UPN). The attribute chosen for the source anchor must never change for the lifetime of the object, including if this object is migrated between domains or across forests. This immutable attribute is used for identity federation. The default selection is the objectGUID attribute, but an organization can choose to use another attribute if that one isn't guaranteed to be unique and unchanging across all forests. Similarly, the selection for which attribute to use for the UPN defaults to the userPrincipalName attribute, but it can be changed if necessary. 

As Figure 5 shows, on the Optional Features page, you can select three optional features:

• Exchange hybrid deployment. If you select this option, you can have a limited set of attributes written back to the on-premises AD forest, allowing hybrid Exchange features.
• Password write-back. The password write-back feature requires an Azure AD Premium subscription. It allows users to change their passwords on an Azure website and have those changes written back to an on-premises AD forest.
• Azure AD app and attribute filtering. This advanced feature allows administrators to choose what attributes are synced into Azure Active Directory based on what applications they intend to use in Office 365. For instance, if your organization does not plan on using SharePoint in Office 365 you may choose to exclude syncing of all SharePoint related attributes to Azure Active Directory. 

Figure 5: Selecting Optional Features

On the Configure page, the wizard confirms your selections, as shown in Figure 6. Afterward, it starts the configuration. 

Figure 6: Confirming Your Selections

After AAD Sync is installed, you need to repeat this process to install it in each forest you're connecting to your Office 365 tenant. 

Conclusion

AAD Sync is a new tool from Microsoft that allows a number of new multi-forest migration scenarios to Office 365 to be accomplished fairly easily. With a little bit of planning, you should be able to accomplish these new migration types without any major problems.

SEM (Staged Exchange Migration) From MS Exchange 2007 to Office 365

SEM (Staged Exchange Migration) From MS Exchange 2007 to Office 365

Step#1: Prepare for Staged Migration

This is the primary and first step that require Global Admin rights in Office 365 portal. Using office 365 portal login through Global Admin and do the following

1       Register the domain you configured for MS Exchange (on-Prem) 2007/2003. It contains following 3 steps

a.       Domain On-line Verification.

b.      Creating online users or leaving it for later attempt if SEM is the process.

c.       Domain confirmation with services to use license. After successful completion of this step you have added an Accepted Domain in Exchange Online.

Important: make that domain default if that is your on-prem messaging domain.

d.      Initiate Windows Azure Active Directory Synchronization.

e.      Download latest DirSyncTool from the site.

f.        Create a user (service Account) for Dir-Syncing and assign permission of EntAdmin, SchemaAdmin(optional) etc.

g.       Add that created Admin user to the local Admin group of the computer where you are going to install DirSyncTool.

h.      Install it on a separate server that is prepared for DirSyncTool located on prem with Admin Privillages.

i.         Now, during configuration of DirSyncTool provide Admin user credentials for both of the sides (On-prem and Office 365).

j.        Test Microsoft Outlook Anywhere whether its functional or not using Remote Exchange Connectivity Analyzer.

k.       The on-premises user account that you use to connect to your on-premises Exchange organization (also called the migration administrator) must have the necessary permissions to access and modify the on-premises mailboxes that you want to migrate to Exchange Online. This user account is used to create a migration endpoint to your on-premises organization.

l.         Either of the Following permission must be granted to migration administrator user

                                                               i.      Domain Admins group in Active Directory in the on-premises organization.

                                                             ii.      FullAccess permission for each on-premises mailbox AND the WriteProperty permission to modify the TargetAddress property on the on-premises user account.

                                                            iii.      Receive As permission on the on-premises mailbox database that stores the user mailboxes AND the WriteProperty permission to modify the TargetAddress property on the on-premises user account.

2       Step#2 Create a CSV with the following compulsory attributes (3 attributes are compulsory).

a.       Email Address

b.      Password

c.       ForcePasswordChange

It’s example is given below

EmailAddress,Password,ForceChangePassword

pilarp@tailspintoys.com,Pa$$w0rd,False

tobyn@tailspintoys.com,Pa$$w0rd,False

briant@tailspintoys.com,Pa$$w0rd,False

Note: before uploading CSV, it is important to create Endpoint on Exchange online or you can create these endpoints later after uploading CSV.

Create Staged Migration Batch

To create a migration batch, you have to submit a CSV file that contains the information about the mailboxes you want to migrate. You can create and start a maximum of 100 migration batches at a time.

1       In the EAC, navigate to Recipients > Migration.

2       Click New Add Icon and then click Migrate to Exchange Online.

3       On the Select a migration type page, click Staged migration, and then click Next.

4       On the Select the users page, click Browse to specify the CSV file to use for this migration batch.

After you select a CSV file, Exchange Online checks the CSV file to make sure that:

1.       It isn't empty.

2.       It uses comma-separated formatting.

3.       It doesn't contain more than 2,000 rows.

4.       It includes the required EmailAddress column in the header row.

5.       It contains rows with the same number of columns as the header row.

If any one of these checks fails, you'll get an error that describes the reason for the failure.

5.     Click Next.

6.  Depending on whether any Outlook Anywhere migration endpoints have been created for your Exchange Online organization, do one of the following:

No migration endpoints have been created: On the Enter on-premises account credentials page, type the user name and password for an account that has the necessary administrative privileges in the on-premises Exchange organization that hosts the mailboxes you're migrating. Use the domain\user name format for the name of the administrator account. Click Next. Exchange Online will use the email address of the user in the first row of the CSV file, the administrative account, and the Autodiscover service to detect the connection settings to your on-premises Exchange organization. If the connection settings are successfully discovered, the fully qualified domain name (FQDN) of your on-premises Exchange server and RPC proxy server are displayed on the Confirm the migration endpoint page. Verify the settings and then click Next. If the test connection to the source server isn't successful, you’re prompted to manually specify the FQDN of your on-premises Exchange server and RPC proxy server. You have to successfully connect to the source server to continue.

Exchange Online creates a new migration endpoint using the connection settings that were successfully discovered or that you provided manually. By default, this migration endpoint is configured to support 20 maximum concurrent migrations.

5.       On the Move configuration page, type the name of the migration batch, and then click Next. This name will be displayed in the list of migration batches on the Migration page after you create the migration batch. Batch names can’t contain spaces or special characters.

6.       On the Start the batch page, do the following:

·         Click Browse to send a copy of the migration reports to other users. By default, migration reports are sent to the administrator who creates the migration batch. You can also access the migration reports from the properties page of the migration batch.

·         Specify one of the following options to start the migration batch after it's created:

·         Automatically start the batch   The migration batch is started as soon as you save the new migration batch. The batch is first marked with a status of Created; the batch is changed to a status of Syncing after it's been started.

·         Manually start the batch later   The migration batch is created but it's not started. The status of the batch is set to Created. To start a migration batch, select it on the migration dashboard and then click Start Start Icon

7.       Click New to create the migration batch.

The new migration batch is displayed on the migration dashboard.

Step#3 Start the Migration Batch

1.       In the EAC, navigate to Recipients > Migration.

2.       On the migration dashboard, select the batch, and then click Start Start Icon.

Step#4 Convert On-Premise Mailbox to Mail enabled users

After a migration batch has finished running and you’ve verified that all mailboxes in the batch are successfully migrated and the initial synchronization of mailbox items to Exchange Online is complete, it’s recommended that you convert the on-premises mailboxes in the migration batch to mail-enabled users. Why? After a staged Exchange migration, a user has an on-premises mailbox and an Exchange Online mailbox. Because mail sent to the user’s on-premises mailbox is forwarded to their Exchange Online mailbox after migration, users need to connect to their Exchange Online mailboxes to access their email. But if a person uses Outlook to open their mailbox, the Autodiscover service still tries to connect to the on-premises mailbox. After you convert on-premises mailboxes to mail-enabled users, the Autodiscover service uses a mail-enabled user to connect Outlook to the Exchange Online mailbox after the user creates a new Outlook profile.

Another important reason to convert on-premises mailboxes to mail-enabled users is to retain proxy addresses from the Exchange Online mailboxes by copying proxy addresses to the mail-enabled users. This lets you manage cloud-based users from your on-premises organization by using Active Directory. Also, if you decide to decommission your on-premises Exchange organization after all mailboxes are migrated to Exchange Online, the proxy addresses you’ve copied to the mail-enabled users will remain in your on-premises Active Directory.

Step#5 Delete Staged Migration Batch

After all mailboxes in a migration batch have been successfully migrated and you’ve converted the on-premises mailboxes in the batch to mail-enabled users, you're ready to delete a staged migration batch. Be sure to verify that mail is being forwarded to the Exchange Online mailboxes in the migration batch. When you delete a staged migration batch, the migration service cleans up any records related to the migration batch and deletes the migration batch. The batch is removed from the list of migration batches on the migration dashboard.

1.       In the EAC, navigate to Recipients > Migration.

2.       On the migration dashboard, select the batch, and then click Delete Delete icon.

Step#6 Complete Post Migration Tasks

1.       Assign licenses to Office 365 users. 

2.       Create an Autodiscover DNS record. 

a.       Alias   autodiscover

b.      Target   autodiscover.outlook.com

c.       Configure your MX record to point to your Office 365 organization. 

3.       Decommission on-premises Exchange servers. 

Exchange administrative tools and Active Directory: Not as close as they once were

When Exchange became the first front-line server application to embrace Active Directory with the release of Exchange 2000, Microsoft provided the functionality to allow administrators to work with the Exchange-specific attributes for mail-enabled objects through the then brand-new AD Users and Computers console. When the Exchange management tools are installed on a server, three tabs are added to AD Users and Computers to display attributes grouped under Exchange General, Exchange Advanced, and Exchange Features. The integration eased the movement from the older Exchange 5.5 administration model and hid some of the perceived complexity of dealing with Active Directory.

Up to and including Exchange 2003, you were able to create, modify, or delete Exchange mailboxes, distribution groups, and contacts from AD Users and Computers because the installation of the Exchange management tools adds the components such asmaildsmx.dll to the system to enable the display specifiers that expose the Exchange attributes and tasks in the console. It was also possible to make the Exchange tabs available to AD Users and Computers without installing the full set of the Exchange management tools.

Microsoft removed the ability to manage Exchange recipients in AD Users and Computers in Exchange 2007, largely because of the advent of PowerShell and the decision to consolidate Exchange business logic in the set of PowerShell cmdlets that are called by the Exchange management tools. AD Users and Computers doesn’t use PowerShell, so it made sense to remove its ability to create or delete recipients, even if this decision infuriated many administrators at the time because they now needed to use two tools to work with mail-enabled objects.

The demand to support a clear separation between Active Directory management and Exchange management is another reason why Exchange disappeared from AD Users and Computers. Small deployments probably have one or two people who do everything and the notion of separating responsibilities for managing Active Directory and Exchange doesn’t have much value. Things are more complex in large enterprises and that’s why Microsoft supports a split permissions model in Exchange 2010 and Exchange 2013 that is, in turn, based on Role Based Access Control (RBAC). A split permissions model is relatively uncommon but is extraordinarily useful to those who need to use it.

Apart from the last lingering vestige in the form of the much-reduced Exchange Toolbox, Exchange 2013 does not use MMC. Instead, the browser-based Exchange Administration Center (EAC) takes center stage for both on-premises and Exchange Online deployments.

Given the influence of cloud services over much of software engineering today, a transition to browser-based tools was inevitable. I didn’t like EAC very much when I first started to use it but now consider it to be as good as EMC in most respects and better in some. Sure, EAC still misses out some of my favorite EMC features like the PowerShell learning tools, but you don’t need to install any software to use EAC as it runs on just about any browser-capable device that can support a modern version of IE, Chrome, Firefox, or Safari. EAC is also quicker at dealing with large numbers of mailboxes and other objects than EMC ever was and includes new useful functionality like Administrator Alerts.