Category: Deployment



This continuation from the earlier post of the same name will take us through the second phase of the 2003 to 2010 Exchange migration I performed for a past student of mine.

Quick recap of what we’ve done up to now…

  • Prepared the environment for the new Exch 2010 server (prepareAD schema and domain)
  • Installed (2) VM’s. server names Ex10 & Ex11.company.com. Windows Server 2008 R2, patched the OS. Installed all Exch 2010 pre-req’s. Installed Exch 2010 into the new VM’s. Also installed the latest Roll-up.

So we have the platform ready, but all inbound and outbound mail is still routing through the old mailbox servers. Let’s start by getting all inbound mail into the new 2010 CAS role first. The company in question was using a “mail.company.com” hostname for the Exchange 2003 OWA environment which they planned on retaining. This is fine but the DNS configuration they were using would require us to get a new certificate for the new 2010 boxes (see Understanding Digital Certificates and SSL)

To cover all bases I recommended to get a new UCC / SAN certificate with the following names…

ex10.company.com

ex11.company.com

autodiscover.company.com

mail.company.com

ex10.company

ex11.company

autodiscover.company

mail.company

Why so many names?? well again, this particular environment had an external namespace with a normal DNS namespace (company.com) but their internal AD domain was a single label domain name (company). The certificate they purchased (Godaddy.com)  was a “multiple domains – UCC” type with up to 10 domains. this allowed us to have the luxury of having any and every name (single label or not) to be resolvable internally or externally. Some may argue this is overkill. This admin inherited this environment and was in the position to make changes to get it into Microsoft recommended shape prior to the upgrade, so this was the easiest solution for him.

Now that we have this new cert installed on both new boxes as well as the old cert from the old 2003 box imported into the new ex10 & ex11 machines we are ready to start moving mail through the new machine.

He made changes to his Sonic wall rules and had all port 25 SMTP, 80 HTTP and 443 HTTPS traffic get redirected to the new ex10 CAS 2010 box. All client MAPI/ RPC / OA / OWA and EAS connections will now hit this box first. he also created a new public autodiscover.company.com A record resolving to the old public IP he was using before. Last but not least he created another new A record for legacy.company.com pointing to a NEW public IP he had available. This is for co-existence OWA purposes.

At this point all mailboxes are still on the 2k3 side. Before we even thought of moving a single mailbox, let’s test mail flow both in and out with the new 2010 HUB roles being the point of entry and exit. We did some quick tests from internal and external mailboxes from and to internal and external mail organizations. Success. Next we created a new 2010 mailbox. We created one called “Jay Cutler” since this admin was a Chicago Bears fan. Since we installed 2010 into the 2003 organization it automatically created a connector between the 2003 routing group to the new 2010 based one. Let’s login to this new mailbox (via MAPI and OWA) and send mail messages back and forth. Success. This also confirms 2010 CAS is functioning correctly. 2010 CAS servers automatically register a SCP (Service connection point) in AD for this!

So transport internal and external is confirmed and even between 2003 and 2010. Let’s turn our focus to client access. We used the Microsoft Exchange remote connectivity analyzer 

image <— click me Smile

to aid us in this. Using some credentials from AD, we could simulate and tell which types of remote connectivity works! RPC over HTTPS (outlook anywhere), OWA and even Exchange Active Sync are all testable here. After some tweaks to his sonic wall this worked great. This tool is IMMENSELY helpful since it not only tells you when something isn’t working, but gives suggestion on possible resolutions.

One of the big headaches many admins will have is the OWA co-existence. The new 2010 CAS cannot provide a 2003 OWA experience if the target mailbox is still on a 2003 back-end server. So during this phase it has to refer the OWA request back to the 2003 Front-end “legacy” server. See what we did there? this is the legacy A DNS record we made earlier. This new public IP address goes directly to the IP address internally of the old 2003 Exchange server. So the process works like this. You hit the new OWA 2010 login page using the old URL (Http://mail.companyname.com/exchange) you are automatically redirected to the actual URL of (Http://mail.company.com/OWA). The user enters their credentials. If the lookup shows the target mailbox is still on the 2003 box it’s redirected to a URL we set earlier using the Exchange Management Shell. (Http://legacy.company.com/exchange) Now to support this some settings had to be modified on the front end server and a patch had to be installed to support this new change.

Once this was working well and EAS was also hitting the 2003 server correctly we moved a few mailboxes both guinea pig and fake dummy mailboxes.

In part 3 I’ll cover the mailbox moves, DAG configuration and how to handle failover if one of the servers becomes unavailable.

 


So near the end of January I was lucky enough to escaped the void of the classroom and get back to hands-on work. I was able to act as a consultant for my training firm and go on-site to an old student of mine’s place of business. Our task seemed simple. Migrate a single exchange 2003 server to a mailbox redundant 2010 solution.

Just drop down a few new 2010 boxes and call it a day right? Not so much. Any migration can have hiccups and issues along the way. We had originally chipped out four days to complete the process. Due to some SAN issues we lost our first day and then had to get everything ready in just 3. One box and about 350 mailboxes it should be easy right? We planned for extra time thank goodness. If we originally planned on 3 and now only got 2 we’d be very hard pressed to have that done. We did in fact get the major steps done in 3 days. let’s review all that happened.

For security purposes let’s not give out our clients domain name and such, let’s focus on what we know and what was learned over the 3 days. Here is where we started.

Single domain forest. All DC’s and GC’s were at the Exchange 2010 minimum of 2003 SP1 or higher. Domain functional level was 2003 as was the forest functional level. Permissions on the accounts to be used for installation were in place, so let’s get started. All inbound mail via his MX record was going into his SonicWall and then being placed into his Cisco IronPort device for scrubbing before being delivered to the 2003 Exchange server.

We began with bringing up the OS of the first Exchange 2010 box in a VMWare virtual environment. The OS was to be 2008 R2 Enterprise edition. Why enterprise? Well we planned on using a DAG (Database Availability Group). This HA (High Availability) feature requires the failover clustering component within Server 2008. That was still in standard edition back in the 2003 Server days, but has been removed in 2008 RTM and higher. So now that R2 server is ready and fully patched / updated, let’s get the Exchange pre-req’s on there for the Exchange bits install. To speed things up we used a pre-made script that automates all the installation of required items as they pertain to Exchange role requirements. You too can download it HERE. It was created by Exchange MVP Dejan Foro. You can hit his whole site here – www.exchangemaster.net.

Think your ready for Exchange install time? Not so fast son. There are four KB document fixes that will need to get put on 2008 R2 before anything else is started.

Before you start contemplating putting that Exchange 2010 media in or mounting that ISO. Check your DNS and active directory to ensure it’s solid and stable before continuing. Also make sure that you have your 2003 / AD settings all up to snuff.

  • Ensure your 2003 address policies are not split between authoritative and non-authoritative. This may require you to modify or even rebuild them.
  • Check your Recipient update services in that they are pointing to a valid DC that still exists Smile
  • Ensure any external or manually created trusts are working and verifiable.
  • Is your domain a SLD? (Single label domain – “Consoso”, not “contoso.com” when you have ADUC open).
  • Ensure IPv6 and the windows firewall is enabled. Either of these could kill your install of Exchange.

OK, NOW you can begin your installation of Exchange. I recommend copying the source files locally to a new folder called “C:\source” or something like that. Now download the latest rollup (RU) for the version of Exchange (RTM vs. SP1) and placing it in the \updates folder. This will slipstream the updates during the installation and save you steps later!

Step 1.) Preparation of AD

This went very easy as we had a single domain and all the rights necessary. Wasn’t a fast process but experienced no errors when we ran setup.com with the following switches..

/preparelegacypermissions – this is ONLY needed if you have 2003 exchange. Skip if you have 2007

/PrepareAD – do you know your organization name? you can find it in the ESM.

Step 2.) Install Exchange on your first server. Have a plan here. Don’t just rip off a “typical” install (core 3 roles – CAS/HUB/MBox) if  you’re unsure, use the Exchange Deployment assistant.

We knew we were only going to have 2 servers with all three roles on them. We chose to do the “typical” install. We also set the “External” address for his CAS role to the same thing as his existing 2003 OWA URL (I.E. – “Http://mail.contoso.com”)

Now we have a fully functional Exchange 2010 server with nothing coming into it, and not hosting any mailboxes.

 

This is a great starting post and will continue to cover hiccups we hit in a future post. (ran out of time Smile )


Quick poll of the blog readers..

Which image deployment method do you use at the office? If you use more than one style – select all that you use!