PREVIOUS: Migrating Exchange 2003 to 2010 – Part I
In our previous article, we discussed how to check and raise the domain, forest, and Exchange functional levels. We also looked at the minimum service pack requirements for our domain controllers.
In this article, we will look at extending our Active Directory Schema and begin installing our multi-role Exchange server.
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).
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 adding 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 core’s 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.
“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).
The 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 are 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.
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!”
Okay, so this is what we ended up with.
Now is a good time to get the OS installed, get it patched and, get it on the domain.
Step 3: Extending the Schema
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.
- Open Server Manager
- Click Features in the left pane
- Click the Add Features link in the right pane
- Expand .NET Framework 3.5.1 Features
- Click .NET Framework 3.5.1
- Scroll down and expand Remote Server Administration Tools
- Expand Role Administration Tools
- Expand AD DS and AD LDS Tools
- Expand AD DS Tools
- Check AD DS Snap-Ins and Command-Line Tools
- Click Next
- Click Install
- Click Close
Now that we have AD DS Tools installed, lets insert your Exchange 2010 DVD and get those schema updates loaded.
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 and run the following commands in order.
C:\> Setup.com /PrepareLegacyExchangePermissions
This command allows Recipient Update Policies (Ex 2003) and Email Address Policies (Ex 2010) to coexist.
C:\> Setup.com /PrepareSchema
This command extends the Active Directory Schema to handle Exchange 2010. You can confirm this worked with ADSIEDIT. For more info on how to do this, check this article out.
C:\> 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.
C:\> 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.
That’s it for Part II. In our next article, we will get all the roles installed on our Exchange Server and run through some additional configuration.