Migrate from Exchange 2003 to By Gareth Gudger

92 

Loading....

Loading....

Loading....

Loading....

Loading....

Full text

(1)
(2)

Migrate from Exchange 2003 to 2010

By Gareth Gudger

(3)

Text copyright © 2014 Gareth Gudger All Rights Reserved

(4)
(5)

Table of Contents

Introduction

Step 1: The Prerequisites

Step 2: Sizing and building the multi-role server Step 3: Extending the Schema

Step 4: Exchange Server Setup Installing All Roles Step 5: Name space Design and Implementation

Step 6: Unified Communications Certificate (UCC / SAN) Step 7: Relocating the database and log files

Step 8: Configure Public Folder Replication Step 9: Moving test users to Exchange 2010

Step 10: Moving production users to Exchange 2010 Step 11: Offline Address Book

Step 12: Convert Address Lists & Email Address Policies Step 13: Redirect Mail Flow

Step 14: Remove the Public Folder Database Step 15: Uninstall Exchange 2003

(6)

Introduction

With Exchange 2003 end of life, I have had a

significant influx of migrations and migration-related questions.

For those that don’t know, Exchange 2003 reached end-of-life on April 8th, 2014.

What this means is that there will be no further patches or service packs for this product, nor, will you be able to receive any form of paid assistance from

Microsoft.

You may be able to find a consultant that can help with Exchange 2003 for years to come. Keep in mind that finding someone with that knowledge and skillset will diminish over time.

A couple years ago I helped a friend with a failed Exchange 5.5 box. Yes, that is not a typo. We were able to get it operational. The miracle is that I remembered a best kept secret from 5.5 to get it going. These were things I hadn’t thought about in 12 years!! It’s crazy what we remember.

The larger concern, however, is the complete lack of updates. If an exploit were to be found in the product, after April 8th, you are on your own.

Now, is the time to upgrade!

There are many great articles that have already covered this process. And while many have written fantastic articles I wanted to write my own book for a slightly different audience in mind.

That of the small business.

Specifically, seventy-five users and below.

“Seventy-five?” you might say, “Isn’t that the max number of users for Small

Business Server 2003?”

(7)

I will be focusing on a small company running Exchange 2003 Standard. While this will focus on the full version of the product, you can easily transpose this for Small Business Server.

We will focus on transitioning from a single server running Exchange 2003 to a single server running 2010. We will use a Cisco ASA 5505 as our firewall. Our network will look like this.

“Why not go directly to Exchange 2013?” you may ask. Well, simply put, you can’t.

Microsoft has not released an upgrade path to go from 2003 to 2013. If your final goal is to get to Exchange 2013, Microsoft recommends you go to 2007, or, 2010 first. Exchange 2003 and 2013 cannot co-exist in the same forest.

Now you can cheat, and use products like MigrationWiz, to perform what they call a cross-forest migration. And, it will get you directly to Exchange 2013. But

(8)

that is exactly what you will get. A brand new forest and a brand new domain. And that comes with its own set of challenges.

Don’t get me wrong, MigrationWiz is a fantastic product.

In fact, keep your eyes peeled for an article on supertekboy.com that covers transferring mailboxes from Lotus Notes to Exchange 2010 using MigrationWiz. But for now, let’s follow Microsoft best practice.

(9)

Step 1:

The Prerequisites

First things first. The prerequisites. We need to do this before we even consider putting in the Exchange DVD.

Before we can get started we need to do some checking in Active Directory and the current Exchange environment.

First, we need to check the Exchange Organization mode. We need to make sure it is Native. To do this:

1. Open Exchange System Manager.

2. Right click on the top-level item and select Properties from the context menu.

3. Check the field that says Operation Mode.

 If this box says Native Mode (no pre-Exchange 2000 servers) then you are all set. Proceed to Step 4.

(10)

 If this box says Mixed Mode (can support pre-Exchange 2000 Servers) click the Change Modebutton.

4. Click Ok.

Next we need to determine the domain functional level. We need to make sure this is a minimum of Server 2003.

(11)

Note: You can NOT do this if you have any Server 2000 (or older) domain controllers in the environment. Those will need to be upgraded or decommissioned first. To check and modify the domain functional level:

1. Open Active Directory Users and Computers 2. Right click on the name of your domain.

3. Select Raise Domain Functional Level from the context menu.

4. From the Select an available domain drop down box choose Windows Server 2003.

5. Click the Raise button.

6. You will be warned this action is irreversible. Click Ok.

7. You will receive a dialog determining whether or not this was successful. Click Ok.

8. To confirm this worked, right click on your domain and select Raise Domain Functional Level again. It should look like the screenshot below. Click Close

(12)

Next we need to determine the forest functional level. Like we did with the domain level, we need to make sure this is a minimum of Server 2003.

Note: If you have more than one domain in your forest, all domains must be at a Server 2003 domain functional level before the forest functional level can be raised. To check and modify the forest functional level:

1. Open Active Directory Domains and Trusts

2. Right click on the top level node, Active Directory Domains and Trusts, and select Raise Forest Functional Levelfrom the context menu.

3. From the Select an available forest drop down box choose Windows Server 2003.

4. Click the Raise button.

(13)

6. You will receive a dialog determining whether or not this was successful. Click Ok.

7. To confirm this worked, right click on the top-level node and select

Raise Forest Functional Level again. It should look like the screenshot below. Click Close.

Next we need to determine if the Domain Controllers themselves are at the minimum service pack level. If your domain controllers are all Server 2008 or newer then no problem. You are good to go. However, if you have any Server 2003, or, they are all 2003, then we need to check.

1. Log onto your domain controller.

2. Go to Start, right click on My Computerand select Properties.

3. Under the General tab, in the System section, look for a Service Pack level. 4. Repeat this for all domain controllers.

(14)

We need to make sure our domain controllers are at a minimum Service Pack 2 (or, running Server 2003 R2). If not, then you need to run Windows Update. Technically, only the Domain Controllers hosting the Schema Master and Global Catalog roles need to be at Service Pack 2, but for the sake of simplicity, let’s get all our DCs patched up.

The next prerequisite is to make sure we Suppress Link State Updates. We do this from the registry of the Exchange 2003 server.

To do this, follow the steps in this Microsoft TechNet Article: http://technet.microsoft.com/en-us/library/aa996728.aspx

(15)

Step 2:

Sizing and building

the multi-role server

Exchange 2010 can only be installed on a 64 bit operating system. That operating system must be a minimum of Server 2008 Service Pack 2.

Technically with Exchange 2010 Service Pack 3, we could go to Server 2012. But for this scenario we will find the middle ground and go with Server 2008 Release 2 (Service Pack 1).

At the time of writing Exchange 2010 cannot be installed on Server 2012 Release 2. Will it be an option in the future? Probably not.

Server 2012 Release 2 can be used with Exchange 2013 SP1. For more information on compatibility check the Exchange Server Supportability Matrix:

http://technet.microsoft.com/en-us/library/ff728623(v=exchg.150).aspx

So let’s get the new Exchange Server going. I’ll let you choose whether to keep this box physical, or, go virtual. Microsoft supports all the major Hypervisors.

“But what about specs?”

Well because this will host all roles (CAS, HUB and MBX) Microsoft

recommends a minimum of 8GB of RAM. Then they recommend to add 3-30MB per mailbox. Let’s take the top end and go with 30MB. For our 75 user scenario that adds an additional 2.2GB. So, 10.2GB. But remember this is all minimum requirements. So let’s round that up to a nice 16GB.

“Ok, so what about the processor?”

As stated above Exchange has to be on a 64-bit processor. An Intel Xeon is what I always recommend. Minimum requirements state that it has to be a least a dual core processor. Generally, quad cores are the entry level point on all servers these days (if you can budget for a 6-core or an 8-core even better). For our 75-users a quad core is sufficient.

(16)

Understanding Memory Configurations and Exchange Performance: http://technet.microsoft.com/en-us/library/dd346700(v=exchg.141).aspx Understanding Processor Configurations and Exchange Performance: http://technet.microsoft.com/en-us/library/dd346699(v=exchg.141).aspx

“Ok, so what about the disk?”

If you can throw 15k RPM SAS drives at your Exchange Server. Go for it! It won’t be money wasted.

However, Microsoft boasts that with database improvements in Exchange 2010 you can run on JBOD (Just a Bunch of Disks).

Database I/O has been reduced by up to 90% compared to 2003. This means you could use entry-level 7.2k RPM SATA drives.

For our 75 users 7.2k RPM SATA drives would be fine. But we won’t be using JBOD. JBOD offers absolutely no redundancy. In our single server environment we have no DAG. We must rely on RAID.

With our small 75-user environment we can use a single RAID 5 array. Then segment these out into separate partitions in the operating system. We could get away with a minimum of three hard drives.

If you can throw more spindles at it; great! Dedicated mirror sets for the operating system, or, separate RAID 5 arrays for the database and logs are always good. It all comes down to price. Storage can easily become the largest expense of your server purchase.

For our scenario, I will recommend 3 x 600GB SAS drives in a RAID 5 configuration. We lose one drive immediately to parity and with some RAID overhead our usable space is going to be just above 1100GB.

(17)

Our disk layout will look like this:

“Why does the log drive need to be so big?”

When you are moving 75 mailboxes between servers it generates a lot of log files. These log files aren’t committed to the database until a Full Backup occurs.

If you were to do a Full Backup on Friday, move 75 users over a weekend, with your next backup not scheduled until Monday, you might run out of space on the log drive.

After the moves are complete you likely won’t need anything close to 100GB (unless you are having problems with your backup). So, you could shrink this drive later on.

If that is something you will likely do, then I recommend making the Log drive the last partition on your virtual disk. That way you can easily reallocate space as needed.

“Enough talking! Let’s get this server built!”

(18)

Now that we have everything spec’d out, let’s get it built. Get the OS installed, get it patched and, get it on the domain.

(19)

Step 3:

Extending the Schema

“What’s next?”

Well, quite possibly, more prerequisites.

We perform the Active Directory Schema updates from the SETUP program on the Exchange DVD. Because Exchange 2010 is 64 bit only, that means SETUP.EXE is 64-bit only. If you are running Small Business Server 2003, or, you only have 2008 RTM or older domain controllers, chances are you only have 32-bit domain

controllers.

One option could be to spin up a 64-bit domain controller but, that adds time to our project.

A second option is to install the Remote Server Administration Tools on the Exchange 2010 box. It doesn’t hurt to have them on there anyway.

This is also a good time to get .NET 3.5.1 installed. 1. Open Server Manager

2. Click Features in the left pane

3. Click the Add Featureslink in the right pane 4. Expand .NET Framework 3.5.1 Features 5. Click .NET Framework 3.5.1

(20)

6. Scroll down and expand Remote Server Administration Tools 7. Expand Role Administration Tools

8. Expand AD DS and AD LDS Tools 9. Expand AD DS Tools

(21)

11. Click Next 12. Click Install

13. Click Close

Now that we have AD DS Tools installed, let’s insert your Exchange 2010 DVD and get those schema updates loaded.

(22)

Be sure that the account you are running these commands from is a members of the Domain Admins, Enterprise Admins and Schema Admins groups. Otherwise, this will fail.

From a command prompt switch to the DVD drive letter. Run the following commands in order.

Note: If you have UAC turned on, run command prompt as an Administrator.

Setup.com /PrepareLegacyExchangePermissions

This command allows Recipient Update Policies (Exchange 2003) and Email Address Policies (Exchange 2010) to coexist.

(23)

Setup.com /PrepareSchema

This command extends the Active Directory Schema to handle Exchange 2010.

Setup.com /PrepareAD

This command prepares the Exchange Organization to accept Exchange 2010. It adds an additional Administrative Group called Exchange Administrative Group (FYDIBOHF23SPDLT). You can confirm this was created by checking Exchange System Manager from your Exchange 2003 box.

(24)

Setup.com /PrepareDomain

This is the final command in extending the schema. This command creates a new root OU in your domain called Microsoft Exchange Security Groups. Under this OU are more than a dozen Exchange Security Groups. Do not alter this OU or these groups.

(25)

Step 4:

Exchange Server Setup

Installing All Roles

First, we will need to install the Microsoft Office 2010 Filter Pack.

This install is just a series of Next button clicks and you are done. There is nothing to configure.

The Filter Pack can be downloaded from here:

http://www.microsoft.com/en-us/download/details.aspx?id=17062

Now let’s go to our Exchange DVD. If it doesn’t auto-run, click double click SETUP.EXE on the DVD.

1. Steps 1 & 2 should already be complete. Click Step 3to expand it.

2. Select Install all languages from the language bundle. (You can also pick Install Only Languages from the DVD. Whichever one you pick determines how many language options your users will have when they use tools such as

Outlook Web App. If you are an international company I recommend the former option.)

(26)

3. Select Download the latest language pack bundle from the Internetand click Next.

(27)

4. Click Finish.

(28)

6. Click Next.

(29)

8. Choose whether or not to send error reports to Microsoft. Click Next. 9. Pick Typical Installation(this installs all roles).

10. Based on the planning from Step 2 we are going to put the Exchange Install on the D: drive. Click the Browse button and change the path to the D: drive. In our example, our file path becomes:

D:\PROGRAM FILES\MICROSOFT\EXCHANGE SERVER\V14

11. Select Automatically install Windows Server roles and features required for Exchange Server. This completes A LOT of busy work for us!

(30)

13. Check The Client Access Server role will be Internet-facing.

14. Enter the FQDN you plan to use for Exchange Web Services. EWS includes services such as Outlook Web App, ActiveSync and Outlook Anywhere. It doesn’t matter if this is the same URL you currently use for Exchange 2003. We will discuss namespaces a little later. In our example our external namespace is: mail.daleksofskaro.com

15. Click Next.

16. Choose whether you want to join the Customer Experience Improvement Program and click Next.

17. The Exchange Installation will then perform readiness checks. This determines whether or not all prerequisites and requirements have been met. If everything is good, click Install.

(31)

18. The installation will take some time. Now is a good time to refill that coffee cup! If everything completes successfully, click Finish.

(32)
(33)

Step 5:

Name space Design

and Implementation

While we are waiting for our server to reboot let’s discuss name space.

Name space is very important in Exchange 2010. Not only does name space govern services like Outlook Web App, or, ActiveSync, but it also governs items such as the distribution of the Offline Address Book, or, the Autodiscover service. A correct namespace design is key.

Currently, our Exchange 2003 box is providing Outlook Web Access, ActiveSync and RPC over HTTPS. It uses a name space of mail.daleksofskaro.com.

It is our plan that Exchange 2010 will use that same namespace. We will also have a period of coexistence.

“How can both servers use the same name?”

Well, they can’t.

We will change the name space (and certificate) on the Exchange 2003 server to legacy.daleksofskaro.com.

We will need a new host record for our Autodiscover service. This will be autodiscover.daleksofskaro.com.

We also need to examine our internal name space. During the install process, setup made all our internal URLs the name of our internal server. In our example this is

EXCHANGE.SKARO.LOCAL.

Due to recent restrictions, 3rd-party certificate providers can no longer put internal names on certificates. This is actually a good thing! Otherwise, you are exposing the internal host names of your servers to the internet.

However, if our certificate does not match our internal server name it will give our internal users security warnings.

(34)

Simple. We make our internal URLs match our external URLs.

Then we use split-brain DNS. So mail.daleksofskaro.com matches the internal IP of exchange.skaro.local. That keeps all the traffic on the local LAN. Without the split-brain DNS all local traffic would try to go out the firewall only to try and come back in later. Most firewalls will block this kind of behavior.

Server rebooted?

Okay, let’s change those Internal URLs. 1. Open the Exchange Management Console.

2. Expand Microsoft Exchange On-Premises (server name) 3. Expand Server Configuration

4. Select Client Access

5. In the lower-right pane, under the Outlook Web Apptab, double click OWA (Default Web Site).

6. Under the General tab, copy the contents of the External URLand paste over the content in the Internal URL field.

(35)

7. Click Ok.

8. Repeat steps 6 and 7 for the Exchange Control Panel, Exchange ActiveSync and Offline Address Book Distributiontabs.

9. Now is a good time to enable Outlook Anywhere. While still on the Server Configuration >> Client Access, right click on name of the server and select Enable Outlook Anywherefrom the context menu

10. In the External host name field we will enter mail.daleksofskaro.com. 11. Keep Basic Authentication checked.

(36)

12. Click Enable.

(37)

We also need to change two additional namespaces. Autodiscover and Exchange Web Services (EWS). These are not in the GUI. For this, open the Exchange Management Shelland issue the following commands.

Note: Be sure to change EXCHANGE on both these commands to the host name of your internal server.

Set-WebServicesVirtualDirectory -Identity “EXCHANGE\EWS (Default Web Site)” -InternalUrl

https://mail.daleksofskaro.com/EWS/Exchange.asmx -BasicAuthentication:$true

To confirm the change.

Get-WebServicesVirtualDirectory | fl Identity,internalurl,ExternalURL

And now for Autodiscover.

Set-ClientAccessServer -Identity EXCHANGE – AutoDiscoverServiceInternalUri

https://autodiscover.daleksofskaro.com/Autodiscover/Autodiscover.x ml

To confirm this change.

(38)

Split-Brain DNS

Alright, let’s get our split-brain DNS configured next. Our DNS Servers will hold non-authoritative zones for our external name space. This will only be used by our internal users.

1. On your DNS server open DNS Manager.

2. Right click on Forward Lookup Zoneand select New Zone…from the context menu.

3. Click Next.

(39)

5. Keep all the default settings. Click Next.

6. In the Zone Namefield enter your public domain name (in our example

(40)

7. Keep all the default settings. Click Next.

8. Click Finish.

9. Expand Forward Lookup Zones.

10. In the left pane, right-click on daleksofskaro.com zone and select New Host (A or AAAA) from the context menu.

(41)

11. In the Namefield type mail. In the IP addressfield type the internal IP of your Exchange 2010 Server. (In our example it is 10.15.1.49).

12. Click Add Host

13. Repeat Steps 10-12 for autodiscover and legacy. However, with regard to

(42)

14. The end result should look like this.

Note: You will also need to repeat Steps 10-12 for any resources you have on the Internet. For example, if your website is www.daleksofskaro.com, you will need to create a www host A record and point it to the public IP address of your hosting provider.

Now this takes care of our internal name space but we still need to do some more work on the external name space.

First though we need to open some ports on our firewall. For coexistence we will need two public IPs.

Our first public IP will continue to point to our Exchange 2003 server. Our second public IP will point to our Exchange 2010 server.

We need to open ports 80 (HTTP) and 443 (HTTPS) to our Exchange 2010 server. This process will vary based on the firewall you have.

(43)

Step 6:

Unified Communications

Certificate (UCC / SAN)

Before we cut over our external DNS records to the second public IP we should get our new certificate in order first. It takes time for a certificate request to be

processed by a 3rd-party. That time can vary greatly. I have seen some take an hour. I have seen some take days.

One of the greatest improvements in Exchange 2010 was the brand new Certificate Generation Request wizard in the EMC.

This wizard takes all the guess work out of what kind of certificate you will need to purchase. Let’s get started.

1. Open the Exchange Management Console.

2. Expand Microsoft Exchange On-Premises (server name) 3. Select Server Configuration

4. In the far right Action pane, click the link for New Certificate Request… 5. In the Enter a friendly namefield enter you certificate name. In our example

(44)

6. Do NOT check wildcard. Leave this unchecked and click Next.

7. This next page will help us determine all the name spaces we need on our new certificate.

8. Expand Client Access Server (Outlook Web App). 1. Check Outlook Web App is on the intranet. 2. Check Outlook Web App is on the internet.

3. Make sure our external URL is the only address in both Domain namefields. In our case mail.daleksofskaro.com

9. Expand Client Access Server (Exchange ActiveSync). 1. Check Exchange Active Sync is enabled.

2. Make sure our external URL is the only address in the Domain namefield. In our case mail.daleksofskaro.com.

(45)

10. Expand Client Access Server (Web Services, Outlook Anywhere, and Autodiscover):

1. Check Exchange Web Services is enabled. 2. Check Outlook Anywhere is enabled.

3. Make sure our external URL is the only address in the External host name field. In our case mail.daleksofskaro.com.

4. Check Autodiscover used on the Internet

5. Check Long URL (Example: autodiscover.contoso.com)

6. Make sure our autodiscover URL is the only address in the Autodiscover URL to use field. In our case autodiscover.daleksofskaro.com.

11. Expand Legacy Exchange Server 1. Check Use legacy domains

2. Make sure our legacy URL is the only address in the Domain namefield. In our case only legacy.daleksofskaro.com.

(46)

12. Click Next.

13. You should see three Certificate Domains. Make sure mail.daleksofskaro.com is Set as the common name (in bold).

(47)

14. Click Next

15. Fill out your Organization and Locationinformation.

16. Click the Browse button and save the Certificate Request file to the Desktop.

17. Click Next 18. Click New

(48)

19. Before you click Finish, review the three steps. You will notice in Step 1, it has identified you need a UC certificate. This is also known as a SAN certificate. Click Finish.

(49)

This should have created a certificate request file on your desktop. Open this file with Notepad and copy the entire contents, including the BEGIN and END lines. Now you will need to purchase a UC / SAN certificate from a 3rd party source. There are many out there. But for the best price and quickest turnaround I highly recommendDigicert.com.

Once the certificate has been processed (and you have downloaded and unpacked your ZIP file from Digicert.com we need to complete the certificate request. 1. In the lower-right pane, right click on the name of our certificate

(mail.daleksofskaro.com) and select Complete Pending Requestfrom the context menu.

(50)

3. Click Complete.

Exchange Web Services are still assigned to the self-signed certificate. Let’s get these switched over to the 3rd-party certificate.

1. In the lower-right pane, right click on the name of our certificate

(mail.daleksofskaro.com) and select Assign Services to Certificate from the context menu.

(51)

3. Click Assign 4. Click Finish

Also, be sure to import this certificate on the Exchange 2003 server as well. You do this in IIS Manager. Go to the Properties of the Default Web Site. Then from the Directory Security tab click Server Certificate and do an Import (.pfx) from the wizard.

Now that we have our certificate installed, we need to test to make sure it is working properly.

The easiest way to check is to enter your external URLs (mail.daleksofskaro.com and legacy.daleksofskaro.com) into the web browser of an internal PC.

Make sure you can get to OWA on both servers and that there are no certificate errors.

Also, check from an external source as well, using the public IP address of the 2010 server (for example, http://321.321.321.321/owa). This will generate a certificate error but you should have access.

(52)

If all looks good then now is a good time to cut over the external DNS records. Remember that:

mail.daleksofskaro.com will point to the public IP of our 2010 server.

autodiscover.daleksofskaro.com will point to the public IP of our 2010 server.

legacy.daleksofskaro.com will point to the public IP of our 2003 server.

Note: DNS changes can take anywhere from 24-72 hours to propagate through the internet. I always recommend making DNS changes over a weekend, or, during times of low service usage.

Now that we have made these DNS changes we need to set up a forward for Outlook Web App. During coexistence we will have users on both mailbox

servers. The DNS changes will direct everyone to the 2010 OWA login page. What this forward does is redirect users still on the 2003 mailbox to

legacy.daleksofskaro.com instead.

To execute this forward open the Exchange Management Shell and issue the following command. Replace EXCHANGE with the internal name of your 2010 server.

SetOWAVirtualDirectory –Identity “EXCHANGE\OWA (Default Web Site)” -ExternalURL https://mail.daleksofskaro.com/OWA -Exchange2003URL https://legacy.daleksofskaro.com/exchange

Once the DNS propagation completes, retest OWA from a browser using an external source. Use the external URL rather than the public IP this time. Make sure you don’t get any certificate errors.

I highly recommend testing with the Exchange Remote Connectivity Analyzer. https://testconnectivity.microsoft.com/

(53)

Step 7:

Relocating the

database and log files

In our Step 2 we discussed configuring a dedicated disk structure that would place our database on drive M and our log files on drive L.

Let’s take care of this now.

1. Open the Exchange Management Console.

2. Expand Microsoft Exchange On-Premises (server name). 3. Expand Organization Configuration.

4. Select Mailbox.

5. In the top-right pane select the Database Managementtab.

6. Right click on the database and select Move Database Path…from the context menu.

(54)

7. In the Database File Pathfield, specify the M: drive. In our example:

M:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database\

8. In the Log Folder Pathfield, specify the L: drive. In our example:

L:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database\

9. Click the Move button.

(55)

11. Click the Yes button to confirm dismounting the database

12. The database will now move. Repeat steps 6 through 11 for the Public Folder Database.

(56)

Step 8:

Configure

Public Folder Replication

Now that we have our databases moved, let’s configure Public Folder replication. We need to set up replication so our Public Folder content is copied to our

Exchange 2010 server. We configure this through the Exchange System Manager on the 2003 Server.

Let’s replicate the Offline Address Book and Schedule+ Free/Busy information first.

To do this:

1. Open Exchange System Manager from the Exchange 2003 server. 2. Expand Administrative Groups.

3. Expand the name of your administrative group (most likely First Administrative Group).

4. Expand Folders.

5. Expand Public Folders.

6. Right click on Public Foldersand select View System Foldersfrom the context menu.

7. Expand Offline Address Book.

8. Right click on an address book and select Properties from the context menu. 9. Select the Replication tab.

10. Click the Add button.

11. Add the Exchange 2010 server.

12. Change the Public folder replication interval drop down to Always Run. 13. Change the Replication Message Priority drop down to Urgent.

(57)

14. Click Apply and Ok.

15. Repeat steps 8 through 14 for the remaining Address Books and Schedule+ Free/Busy Folders.

16. Repeat steps 8 through 14 for your Public Folder content. To get back to the Public Folders, right click the Public Foldersnode (step 6) and select View Public Foldersfrom the context menu.

Replication can take a very long time. Changing the schedule and priority should help speed things along.

(58)

Step 9:

Moving test users

to Exchange 2010

While we are waiting for replication, let’s move a test user from Exchange 2003 to 2010.

If you don’t have a test user, create one real quick in Active Directory. Give it a mailbox on 2003. Confirm you can log in using OWA (mail.daleksofskaro.com will automatically redirect the user to the legacy 2003 login page). Send and receive a test message to initialize the mailbox.

To move a test user:

1. Open the Exchange Management Console.

2. Expand Microsoft Exchange On-Premises (server name). 3. Expand Recipient Configuration.

4. Select Mailbox.

5. In the right pane, find the test user we wish to move. Right-click the user and select New Local Move Request…from the context menu.

(59)

7. Select a database on the Exchange 2010 server and click Ok

(60)

9. Leave the default Skip the mailboxand click Next.

(61)

11. Click Finish.

Problems?

If you have any errors during the Move Request the two most common causes are either corrupt messages, or, insufficient permissions.

For the first problem, one option is to ignore corrupted items. Instead of setting to Skip Mailbox in Step 9, you can Skip the corrupted messages instead. Then specify a threshold of how many messages you will skip.

(62)

For the second problem, I have found two different causes and solutions:

Local Move Request from Exchange 2003 to 2010 fails with database offline http://supertekboy.com/2013/12/10/1101/

Moving Mailboxes from Exchange 2003 to 2010 fails with Access Denied http://supertekboy.com/2013/10/16/moving-mailboxes-from-exchange-2003-to-2010-fails-with-access-denied/

Now that we have a test user successfully moved, let’s make sure everything is working.

Log into webmail. In our example, this is https://mail.daleksofskaro.com/owa. Our test user should see a brand new OWA interface.

(63)

Let’s run a few tests.

From OWA, have the test user send a test message:  To themselves.

 To a user on the Exchange 2003 server.  To an external mailbox (Gmail, etc.).

And in return, send a test message:

 From a user on Exchange 2003 to our test user.

 From an external mailbox (Gmail, etc.) to our test user. Did everything go through?

Great!

If not, let’s examine our Exchange environment a little more closely.

Right now everything is routing through the Exchange 2003 server. When SETUP ran it automatically created a routing group connector between 2003 and 2010. To check, launch the Exchange Management Shell. Then issue the following command:

(64)

Get-RoutingGroupConnector

The output should look similar to this.

If all looks correct here, then review the message queues. If the problem was sending from the 2010 side then check the 2010 queues.

To do this:

1. Open the Exchange Management Console.

2. Expand Microsoft Exchange On-Premises (server name). 3. Select Toolbox.

4. Under Mail Flow Tools, double-click Queue Viewer

5. Find the stuck message. Examine the error in the Last Error column. This error message is key to troubleshooting the problem.

(65)

(I don’t have any problems at the moment!)

This article describes one possible error code and how to fix it. 451 5.7.3 Cannot achieve Exchange Server authentication

http://supertekboy.com/2013/10/12/451-5-7-3-cannot-achieve-exchange-server-authentication/

(66)

Step 10:

Moving production users

to Exchange 2010

Before we do this we need to take a step back.

Backups.

This supporting process is often overlooked during the planning stage for any type of migration. Not just Exchange.

You need to make sure your current backup technology supports Exchange 2010. And, if 2010 is just a quick stepping stone to 2013, then this is even more

important.

I use Symantec Backup Exec to accomplish this.

Backup Exec 2012 fully supports Microsoft Exchange 2010.

Not only does it support the backing up and restoring of databases but, it also supports the granular recovery of individual mailbox items. These items are things like messages, calendar items, and contacts. Furthermore, you don’t need a

recovery database to perform a restore. Restoring is just a few simple clicks. Note: Backup Exec Media Server must be installed on a 64-bit operating system to back up Exchange 2010.

Restore. Restore. Restore.

You’d be surprised how many “successful” backups I have seen, that won’t

actually restore. Just because your backup software indicates it succeeded, doesn’t necessarily mean it did.

(67)

This is a great time to attempt a test restore. Not only could you attempt a test restore of the mailbox database but, you can also perform a test of individual items. Everything restoring as it should?

Awesome!

One other thing to check is antivirus.

If you have an antivirus client on your Exchange Server make sure you exclude all the Exchange locations.

This includes numerous locations. For a complete list check here:

http://technet.microsoft.com/en-us/library/bb332342(v=exchg.150).aspx

Let’s move some users!

Now that we have everything backing up, let’s move a pilot group of users. This should just be a small percentage of your overall user base. For our 75 user environment, let’s move 7 or 8 users. That’s 10% of our base.

When you move users from 2003 their mailboxes will become unavailable. You will want to specify a maintenance window when your users are offline.

How long these take to move can depend on a lot of things. Such as; hardware, network congestion and size of mailbox.

If our pilot users are all under 1 GB then a single evening should suffice. If these users each have a 30 GB mailbox, you may wish to schedule this for a weekend. To move these users, refer back to the procedure in Step 9: Moving test users to Exchange 2010.

The point of the pilot group is to determine if there are any problems before you move the bulk of your users.

(68)

 Their Outlook clients reconfigure automatically to the new server.  They can send and receive mail.

 They can use Outlook outside of the office.  They can use Outlook Web App.

 Any mobile devices still work.

 Any collaboration functions, such as calendar sharing (especially with users still on 2003)

Once you are comfortable that your pilot group is a success then you can move the rest of your users.

An easy way to keep track of who is on what server is to check the Recipient Type Details column. Any mailbox listed as Legacy Mailbox is still on the 2003 server. Any listed as User Mailboxis on the 2010 server.

Keep an eye on the free space on your log drive. Move requests will generate a lot of log files. These won’t be cleaned up until your next Exchange backup.

(69)

Step 11:

Offline Address Book

Before we decommission our 2003 server, we need to change which server

generates our Offline Address Book. This is a very simple process. To do this:

1. Open the Exchange Management Console.

2. Expand Microsoft Exchange On-Premises (server name). 3. Expand Organization Configuration.

4. Select Mailbox.

5. Select the Offline Address Book tab.

6. Right click on the Default Offline Address Bookand select Move from the context menu.

7. On the Move Offline Address Book wizard, click Browse. 8. Select the Exchange 2010 server and click Ok.

(70)

10. Click Finish.

Once the wizard closes, check the Generation Servercolumn. This should have updated to the 2010 server.

This is also a good time to change the distribution methods for the Offline Address Book. Exchange now has the option to distribute through EWS.

To change this:

1. Right click on the Default Offline Address Bookand select Properties from the context menu.

2. Select the Distribution tab.

(71)

4. Click the Add…button.

(72)

6. Click Ok.

If all your Outlook clients are 2007 or newer, you can actually uncheck Public Folder Distribution. You can also uncheck the Version 2 and Version 3 address books under Client Support.

(73)
(74)

Step 12:

Convert Address Lists

& Email Address Policies

If you try to edit the Address Lists in the Exchange Management Console you will receive an error that the Address Lists were created in a legacy version of

Exchange and need to be upgraded.

“The specified address list could not be edited. Address lists created by using legacy versions of Microsoft Exchange must be upgraded by using the

“ForceUpgrade” parameter of the “Set-AddressList” cmdlet.”

To update the Address Lists, open the Exchange Management Shell and issue the following commands.

WARNING: These scripts are very simplistic! They are only designed to convert the default ‘out-of-the-box’ Address Lists. If you have made any customizations to these Address Lists do not use these scripts. If you have created additional Address Lists you will need to update these as well. Be sure to test in a lab setting first!

Set-AddressList “All Users” –IncludedRecipients MailboxUsers

This command updates the “All Users” Address List. The filter adds all users in your environment that have a mailbox to that Address List. You will be prompted to confirm the change.

Set-AddressList “All Groups” –IncludedRecipients Mailgroups

This command updates the “All Groups” Address List. This filter includes all Distribution Groups.

(75)

Set-AddressList “All Contacts” –IncludedRecipients MailContacts

This list is for any mail contacts you may have created. Typically, a mail contact is an object that contains an external SMTP address that your Exchange server is not authoritative for.

Set-AddressList “Public Folders” -RecipientFilter { RecipientType -eq ‘PublicFolder’ }

This one updates your Public Folders address list. It adds any email addresses from mail-enabled folders in the Public Folders database.

Set-GlobalAddressList “Default Global Address List” -RecipientFilter {(Alias -ne $null and (ObjectClass eq ‘user’ or ObjectClass eq ‘contact’ or ObjectClass -eq ‘msExchSystemMailbox’ -or ObjectClass --eq

‘msExchDynamicDistributionList’ or ObjectClass eq ‘group’ or ObjectClass -eq ‘publicFolder’))}

This last command updates the Global Address List.

Once converted, the Address Lists allow you to open them from the Exchange Management Console. There is one exception. The Global Address List cannot be opened from the Exchange Management Console.

If you double-click nothing will happen. If you right-click you will only see “Help” from the context menu. Any further modifications to the Global Address List has to be conducted through the Exchange Management Shell.

Once converted these Address Lists can no longer be managed from 2003. Next on our task list will be to upgrade our Recipient Update Policy.

Similar to the Address Lists, when you try to edit the Email Address Policies in the Exchange Management Console you would receive an error that the policy was created in a legacy version of Exchange and needs to be upgraded.

(76)

“The specified e-mail address policy couldn’t be edited. E-mail address policies created with legacy versions of Exchange must be upgraded using the ‘Set-EmailAddressPolicy’ task, with the Exchange 2010 Recipient Filter specified.” To update the Email Address Policy open Exchange Management Shell and issue the command below. This command finds all the current legacy Email Address Policies (Recipient Update Policies) and pipes those findings directly into the Set-EmailAddressPolicy cmdlet. This cmdlet converts those Recipient Update Policies into Email Address Policies. You will be prompted to confirm.

WARNING: This script is very simplistic! It is only designed to convert the default ‘out-of-the-box’ Recipient Update Policy. If you have made any

customizations to the Recipient Update Policy do not use this script. If you have created additional Recipient Update Policies you will need to update these as well. Be sure to test in a lab setting first!

Get-EmailAddressPolicy | where {$_.RecipientFilterType –eq “Legacy”} | Set-EmailAddressPolicy –IncludedRecipients AllRecipients

Once you confirm you will then be able to open and edit these policies in the Exchange 2010 Management Console. You will no longer be able to modify these policies in 2003. However, in a coexisting environment Recipient Update Services will still be able to distribute these policies to mailboxes on the 2003 server.

(77)

Step 13:

Redirect Mail Flow

Before we can cut over mail flow, we need to create a Send Connector. This will allow our 2010 server to send mail directly to the internet.

Let’s get this created.

1. Open the Exchange Management Console.

2. Expand Microsoft Exchange On-Premises (server name). 3. Expand Organization Configuration.

4. Select Hub Transport.

5. Select the Send Connectors tab.

6. Right click in the right pane and select New Send Connector… 7. Give the New Send Connectora Name. In our example, Default.

(78)

.

9. Click Next. 10. Click Add.

11. Type * in the Address spacefield. Click Ok

(79)

13. Choose whether to use domain name system (DNS), or, smart host to route messages to the internet. In our example, we select Use domain name system (DNS). Click Next.

(80)

14. Click Next. 15. Click New. 16. Click Finish.

We also need to make sure our Receive Connector is ready to receive messages. To do this:

1. Open the Exchange Management Console.

2. Expand Microsoft Exchange On-Premises (server name). 3. Expand Server Configuration.

4. Select Hub Transport.

5. Under Receive Connectors, right click Default <server name> and select Properties from the context menu.

(81)

6. Select the Permissions Groupstab. 7. Check Anonymous Usersand click Ok.

(82)

These are the 4 most common scenarios I see.

1. Change the translation at the firewall. The original public IP is maintained, but TCP 25 is port translated to the internal IP of the 2010 server. DNS is not altered. (Make sure ports 80/443 still point to the 2003 server if you still have users housed there.).

2. Change the DNS MX record to point to the new public IP of the 2010 server. Be sure to open TCP port 25 on your firewall to the new server.

3. If an anti-spam appliance is in the mix, update the next mail hop with the 2010 server’s IP.

4. If an anti-spam cloud provider is in use, then you can either maintain the

original IP (and do the port translation mentioned in option 1), or, change to the new public IP of the 2010 server (and make sure TCP port 25 is open as

mentioned in option 2)

For our example, we will pick option 2. We will modify the MX record to use the public IP of the 2010 server. We will open up TCP port 25 on our firewall for the 2010 server.

We have to allow for DNS propagation of the MX record (up to 48 hours) Once DNS is propagated - test mail flow.

Send a message from an external account to one of your users and vice versa. Then, from an Outlook Client, review the message header. Make sure you only see references to the 2010 server. If your 2003 server is listed, mail is still routing through 2003. Correct this. Then proceed.

Note: If you have any applications or devices that send mail now is a good time to update them with the IP address of the 2010 server. This change process varies greatly. Consult their administrative guides for more information.

(83)

Step 14:

Remove the

Public Folder Database

In a previous step we moved all mailboxes to the 2010 server. We also configured replication of the Public Folders. With all users now on 2010, let’s decommission our 2003 Public Folder Database.

We need to move all replicas to the 2010 server.

Note: The replica move requires a mailbox database be present on the 2003 server. Without it, you will get a strange error regarding a “missing profile”. If you have deleted the mailbox database, no biggie. Just create a brand new one. Wait about 10 minutes and then attempt your move again.

Let’s get started.

1. Open Exchange System Manager from the Exchange 2003 server. 2. Expand Administrative Groups.

3. Expand the name of your administrative group (most likely First Administrative Group).

4. Expand Servers.

5. Expand your 2003 server.

6. Expand your storage group (most likely First Storage Group).

7. Right click on the Public Folder Databaseand select Move All Replicasfrom the context menu.

(84)

8. From the Select the serverdrop down, pick the 2010 server. Click Ok.

9. You will receive a warning that this may take quite some time (and it definitely can – don’t be surprised if it takes 24 hours!). Click Ok.

To monitor the progress of the Replica move: 1. Expand the Public Folder Database. 2. Select Public Folder Instances. 3. Press F5 to refresh as needed.

(85)

Once empty, all replicas have been moved off the 2003 server. Public Folder Hierarchy.

Next, we need to move the public folder hierarchy. To do this:

1. While still in Exchange System Manager right click on Exchange

Administrative Group (FYDIBOHF23SPDLT) and select New >> Public Folder Containerfrom the context menu.

(86)

2. Expand both the 2003 and 2010 Administrative Groups. These are most likely First Administrative Groupand Exchange Administrative Group

(FYDIBOHF23SPDLT).

3. Expand Folders under the 2003 administrative group.

4. Select Public Foldersand drag it to the corresponding Folders node under Exchange Administrative Group (FYDIBOHF23SPDLT).

At this point you can delete the Public Folder Database.

Right-click on the Public Folder Store and select Delete from the context menu. Click Yes to confirm. You will be notified that this will not remove the actual files themselves. This is fine.

Note: You will be notified if there is anything

preventing deletion, such as replicas still existing on that server. If that is the case, review the Public Folder Instances node to see if it is empty.

If this succeeds, you can then delete your Mailbox Database. Right-click on the

(87)

Right-click on the Mailbox Database a second time and select Delete from the context menu. Click Yes to confirm. You will be notified that this will not remove the actual files themselves. This is fine.

With both databases gone and mail flow redirected there is no need for the Routing Group Connectors anymore.

From the Exchange Management Shell issue the following command.

Get-RoutingGroupConnector | Remove-RoutingGroupConnector

This command finds all Routing Group Connectors in the environment and removes them. Don’t worry. Exchange 2010 doesn’t need them.

(88)

Step 15:

Uninstall Exchange 2003

Next, we need to remove the Recipient Update Policies.

To do this:

1. Open Exchange System Manager from the Exchange 2003 server. 2. Expand Recipients.

3. Right click the Recipient Update Service <domain name> and select Delete from the context menu. (In our example, Recipient Update Service (Skaro))

4. Click Yes to confirm.

To delete the Recipient Update Policy (Enterprise) we need to use ADSI Edit. To do this let’s switch to our 2008 R2 server. ADSI Edit comes preinstalled on 2008 R2. Alternatively, you can download ADSI Edit for older operating systems.

(89)

To use ADSI Edit:

1. From Start Menu >> Administrative Toolsopen ADSI Edit.

2. Right click on ADSI Edit and select Connect to…from the context menu.

3. From the Select a well-known naming contextdrop-down select Configuration.

4. Click Ok.

(90)

6. Expand CN=Configuration. 7. Expand CN=Services.

8. Expand CN=Microsoft Exchange.

9. Expand CN=<name>. (In our example CN=KHAN.) 10. Expand CN=Address List Container.

11. Select CN=Recipient Update Services.

12. Right click on Recipient Update Services (Enterprise)and select Delete from the context menu.

(91)

14. Close ADSI Edit.

The time has come! Let’s uninstall 2003.

Navigate to the Add/Remove Programs and uninstall Exchange 2003. Select Remove on all components and click Next.

You will be prompted for the Exchange CD during the uninstall so, be sure to have that handy.

When complete, reboot the server.

Note: The uninstall process for SBS 2003 is a little different. From Add/Remove

Programs select the Change button next to Small Business Server 2003. Follow

the on-screen prompts.

We are done!

(92)

Figure

Updating...

Related subjects :