Link to home
Start Free TrialLog in
Avatar of JasonDuncanworks
JasonDuncanworksFlag for United States of America

asked on

Upgrade Server 2008 R2

I have a Server,  2008 R2 that run SQL 2008 R2 and Exchange 2010 SP1.

We are looking to upgrade to Server 2012. I also need to to put Exchange on a VM and upgrade to 2013.

My plan is this.

1. Full Backup.
2. In-place upgrade Server 2008 R2 Operating System to 2012.
3. In-place upgrade SQL Server 2008 R2 to 2012.
4. Backup Exchange Database, Uninstall Exchange.
5. Install server 2012 on a VM and install Exchange 2013 and import mailbox's.

Anyone know of any gotcha's or have a better plan of attack?
ASKER CERTIFIED SOLUTION
Avatar of Seth Simmons
Seth Simmons
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of JasonDuncanworks

ASKER

Thanks for the heads up on Exchange, have about 80 mailboxes, so I will spin up the VM first then migrate users over to that.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Why are you doing an in-place upgrade?  It's always better to start clean.  With VMs, just install VMs and migrate services.  Less downtime and more stable.
I agree with Leew - a clean install is better and then migrate roles and user etc.
Clean install would take way too long. There are over 80 computers that would have to rejoin the domain.
I didn't say clean install of the domain - I said clean install of the servers.

DO NOT UPGRADE THE SERVERS.  MIGRATE THEM to clean installs.  Add a new server with 2012 as a DC, then demote the 2008 server and transfer other services to it.  This PRESERVES Active Directory and you don't need to do rejoin machines to the domain while have clean installs without the possibility of upgrade issues.
To Leew's point, an inplace upgrade is a one way trip,  not all trips work out the way they are planned.

Taking the time to do it right over days, weeks in my opinion is preferable versus a situation of an inplace upgrade failure for one reason or another and then one runs into a situation that a backup does not work and now one finds it a deep ..........

You could once server 2012 setup as a hyper-v host, virtualized the physical windows 2008 server as a VM for backup/functionality purposes .......
How about two VMs

1. New 2012 Server with SQL 2012, install apps and test.
2. New Exchange - Move one box and test, then move the rest.
3. Once new server apps show they are working, Transfer roles to new server, wait a few days, demote old server and just leave as host.
Hi Jason.

I think best way is this suggestion - cos better to have moved all domain to the new server before you move exhange mailboxes. Then you make a clean install of 2012 and migrate/move all from the 2008 server
If you want you can start with your sqlserver og wait .

Then...

1. Do the domainprep and forestprep commands to make sure the 2008 domain is prepared for migration.
2. Install your new server 2012- promote it to DC in same domain . "New DC for existing domain" etc.
3. Check Ad for users and groups to have been replicated to your new DC 2012 server.
4. Move FSMO AD roles til 2012 server. http://www.petri.co.il/transferring_fsmo_roles.htm
5. Exchange setup and move mailboxes .
6. Move data
7. for clients you need to setup DHCP on the new server as well.

If everything is working now you should be able to turn down the 2008 server host.
Hi Jason. 2 vms would be a good solution. I agree w others to start on a clean install. Its  not so scarry to move roles and migrate data. Users and groups will be replicated automaticly when u join the new 2012 to the domain. Then fsmo roles and exchange mailboxes. I would prefer to do it over the weekend when people don't work.
If you're not familiar about it you could make a demo vm of both systems just to get practice with the process.
Two VMs are fine.  You just need to plan/spec out the new server to handle the capacity/functionality.