[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 69
  • Last Modified:

Migrating from Exchange 2003 to Exchange 2013 in my sample environment

Here is the background on my environment.  Windows Server 2003 Standard functioning as a domain controller with Exchange 2003 server offering Exchange to clients in addition to Outlook Web Access using a go-daddy certificate.  It receives email from a Barracuda Anti-Spam appliance (smtp is port forwarded to the Barracuda from the firewall) on the private subnet.  I have installed a new VMware eSXi 5.5 server that will be hosting three VMs for my new environment.  The first VM is a Windows Server 2012R2 Standard server that is also a domain controller and is currently fully functional and talking well with the 2003 domain controller.  I have already transitioned the FSMO roles to the new 2012 DC.
My next step is to introduce an Exchange 2010 server to the environment so I can do a swing migration.  I installed Windows Server 2012R2 Standard to be the new Exchange server and then realized that you cannot install Exchange 2010 on this version of the operating system.  Some have said you CAN if you get Exchange 2010SP3 but details have been sketchy and I don't want any gotchas.

I am looking for advice as to which of my proposed scenarios would be the best for me.

1.  Spin up a Windows Server 2008R2 member server box and install Exchange 2010 to it per guides and whitepapers I have found.  Move mailboxes to it and run it this way for a few weeks and then decommission the Exchange 2003 server by uninstalling it from the Windows 2003 Server.  Spin up another Windows Server 2012R2 box (which will be the permanent home of Exchange) and install Exchange 2013 to that one and migrate from the 2008R2 Exchange 2010 box to that one.  Once that is complete, decommission the Exchange 2010 server and delete the 2008R2 box from the domain and dump the VM.

2. Spin up a Windows 2012R2 Standard member server VM and install Exchange 2010 to it (if this is possible ... I don't think it is but I am throwing it out there in case someone can confirm it IS possible) and migrate the mailboxes from Exchange 2003 to it.  Decommission the 2003 Exchange server.  Then, do an in-place upgrade from Exchange 2010 to Exchange 2013 on the Windows 2012R2 Standard box.  If it isn't possible, would it make sense to install Windows Server 2012 Standard (NOT R2), Exchange 2010 and then do an in-place upgrade later to Exchange 2013?

If #2 is possible, it would seem to be the least painful.
0
Steve Bantz
Asked:
Steve Bantz
  • 4
  • 4
  • 2
  • +2
4 Solutions
 
Seth SimmonsSr. Systems AdministratorCommented:
...and then realized that you cannot install Exchange 2010 on this version of the operating system

SP3 with update rollup 5 or later is supported; update rollup 8 is the latest

Exchange Server Supportability Matrix
https://technet.microsoft.com/en-us/library/ff728623(v=exchg.150).aspx

Update Rollup 8 v2 For Exchange 2010 SP3
http://www.microsoft.com/en-us/download/details.aspx?id=45225

...do an in-place upgrade from Exchange 2010 to Exchange 2013

in-place upgrade of exchange is not supported

Install Exchange 2013 in an Existing Exchange 2010 Organization
https://technet.microsoft.com/en-us/library/bb124350(v=exchg.150).aspx
0
 
Seth SimmonsSr. Systems AdministratorCommented:
i would go with #2 though your 2012 box should have exchange 2013 and migrate everything there from the 2010 server
0
 
Will SzymkowskiSenior Solution ArchitectCommented:
Number 2 is completely not possibly.

Spin up a Windows 2012R2 Standard member server VM and install Exchange 2010 to it
Exchange 2010 SP3 is not supported with Server 2012R2. See below link...
http://blogs.technet.com/b/rmilne/archive/2013/09/17/exchange-support-for-windows-server-2012-r2.aspx

Then, do an in-place upgrade from Exchange 2010 to Exchange 2013 on the Windows 2012R2 Standard box
In place upgrades are not supported with Exchange. See below link for additional details.

https://social.technet.microsoft.com/Forums/exchange/en-US/d0a521df-8b85-47d4-aad1-fd40140379ea/in-place-upgrade-error

Option 1 would be fine. 2008R2 will be smooth install and will be stable. You can just remove it when you are finished your migration to Exchange 2013.

Will.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
davorinCommented:
In place upgrade of Exchange server is not possible and also Exchange 2010 (even SP3) is not officially supported on windows 2012 R2, so I would not use that OS for Exch 2010.
0
 
Gareth GudgerCommented:
Option 1 is the way to go. For reasons Will stated.
0
 
Steve BantzIT ManagerAuthor Commented:
Thanks for all of the suggestions.  I ended up doing a lot of reading and prep work based on the links posted.  I ended up spinning up a Windows 2008R2 box on VMWare and putting Exchange Server 2010 on that.  Everything went quite well with the move but I did have to do a bit of monkeying with ADSIedit to rehome the Free/Busy public folder to the public folder store on 2010.  I still have a few Outlook 2003 clients in the enterprise so I had to get this working for meeting requests.  I have decided to let the system run for a month or so and then I will spin up the final destination for email, which will be a Windows 2012R2 server running Exchange 2013.  I have to get the rest of the Outlook 2003 clients upgraded first anyway.

I am a little apprehensive about decommissioning the old Exchange 2003 server.  I don't want there to be any legacy entries left in AD after the uninstall of Exchange server.  A friend told me he had to delete a bunch of stuff in adsiedit even after a seemingly successful uninstall.
0
 
Steve BantzIT ManagerAuthor Commented:
I should mention that the only real lingering problem so far is Outlook clients complaining about the certificate.  I bought it for mail.mycompanyname.com to use for OWA.  The internal name of the exchange server and the external names are different.  The cert is fine from the outside.  If I connect from an Outlook client from the inside network, it will complain of a certificate name mismatch since the cert I bought is for mail.mycompanyname.com and not srvex.root.mycompanyname.com.
0
 
Will SzymkowskiSenior Solution ArchitectCommented:
What are the virtual directory URLs set to for internal?

Will.
0
 
Steve BantzIT ManagerAuthor Commented:
If I issue a get-WebServicesVirtualDirectory I get https://srvex.root.mycompanyname.com/EWS

mail.mycompanyname.com resolves to the local server's IP internally so I should be able to change the internal URL so it matches the certificate name.  Do I have to do this for ALL 6 virtuals, i.e. autodiscover, ecp, EWS, etc?
0
 
Will SzymkowskiSenior Solution ArchitectCommented:
If you have a split DNS setup that having the external and internal set the same is recommended.

Will.
0
 
Steve BantzIT ManagerAuthor Commented:
Ok, I think that worked.

From the command shell I issued:
Set-WebServicesVirtualDirectory -Identity "SRVEX\EWS (Default Web Site)" -InternalUrl https://mail.mycompanyname.com/ews/exchange.asmx

I restarted my machine and entered Outlook and it didn't complain about the cert since the names match.


As a side note, to be able to use the cert with one name, I had to create a primary zone on the internal DNS server named mail.mycompany.com with an A record pointing to the private IP of the exchange server.  Kind of a pain, but split namespace requires a hacked solution if you want don't want to use a wildcard cert.  I also did this for autodiscover.mycompanyname.com and the others just in case.  

Thanks to all. I will divide points!
0
 
Will SzymkowskiSenior Solution ArchitectCommented:
Glad this is working now!

Will.
0

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

  • 4
  • 4
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now