Exchange Server 2007 Setup

Question

I'm working on a upgrade to Exchange 2007 and I wanted to get some advise on hardware choices. We currently have an Exchange 2003 STD server with 400 users split between 6 AD Sites, that is housed on a single server. We need to move to a redundant, fault tolerant system to support our users.

I'm planning on installing 2 Dell 1950 servers with W2k8-std to act as CAS and Hub servers, with NLB to allow abstraction of the actual server name to the users. There won't be an edge system since we have a Barracuda box already that will handle in/out spam/virus filtering.

Backend I'm planning on 2 mailbox servers which will be Dell 2950s with 16GB RAM, 2 either dual-core or quad-core CPUs and 6 300GB SAS drives in some RAID config. These systems will be clustered using W2k8 Ent clustering and running CCR in Exchange.

My questions are as follows:

1. Is 16GB enough RAM for serving that many mailboxes along with the windows clustering and ccr?

2. I'm trying to figure out disk layouts and I'm unsure of whether to use all local disk or some local and some SAN, via an OpenFiler iSCSI server. The SAN would be a Dell 2850 with 6 - 300GB SCSI drives and a PERC controller to slice as I want, with 8GB RAM.

   Option 1: 2 drives, RAID 1 - OS 2 drives, RAID 1 - Logs 2 drives, RAID 1 - Mail stores

   Option 2: 2 drives, RAID 1 - OS and logs 4 drives, RAID 5 - Mail Stores and scratch space for eseutil.

   Option 3: 2 drives, RAID 1 - OS 2 drives, RAID 1 - Logs 2 drives, RAID 0 - scratch space ~300GB iSCSI volume for mail stores

   Option 4: 2 drives, RAID 1 - OS 4 drives, RAID 5 - scratch space ~300GB iSCSI volume for mail stores ~300GB iSCSI volume for logs

3. I have 2 sockets for CPUs and need to chose between dual and quad cores. The dual core have faster clocks but less cache and I'm thinking older architecture. Am I better off with more cores and cache while sacraficing clock speed?

I am planning on adding the new E2K7 cluster to the E2K3 server and then move each mailbox over, all at once, then remove the old server. This seems more complicated than simply getting rid of the 2003 server and then adding the 2007 cluster and restoring the mailboxes using PowerControls or exmerge. The migration option lets me do this on my time, where a cutover means it all needs to work at once.

If I go with the cutover method, how can I prebuild the servers and add them to the domain right after removing the 2003 server, or can't I? I think the answer is no and the migration is my only real option if I want to prebuild.

I need to also migrate about 30GB of Public Folders. Is there anything special about this, other than specifying in the E2K7 install that I want older Outlook clients and PF's setup? I guess I could even keep the E2K3 server to host just the PFs?

Lastly, if I have a mix of Outlook 200, 2003 and 2007 what do I need to do to make sure they all have access to the GAL and OAB? At time of cutover, we'll be at like 90% 2007, but we will have some older stuff around. My plan is to use Outlook Anywhere on laptops that are used outside the physical network. Are there any gotchas involved in that? I'm even thinking about using is for all Outlook clients, does anyone do that? The reason I'm considering it is that our WAN is really VPN tunnels over internet connections, so not a fully messhed, stable WAN.

Thank you all very much for the assistance in advance and I look forward to discussion of these points!

Regards...Michael

Answer 1

As for RAM, we have between 4000 to 4500 users and both of our mailbox servers are at 8GB of RAM. We're working. Since you have an order of magnitude less users you should be just fine with less memory.

Getting 2007 in the system We set up our full 2007 environment in parallel to our 2003 environment before we moved any real users over to the 2007 servers. This allowed us to get the 2007 servers into the 2003's routing group so mail would correctly deliver between the two environments. Next, I believe we cut over OWA to the 2007 servers; users on 2003 would still get the 2003 OWA and when we moved them over to 2007 would automatically get the 2007 version of OWA.

Then you need to make sure your 'autodiscover' stuff is in place for 2007. I can't remember exactly what this is off the top of my head, but there is some DNS stuff that needs doing.

Replicate your Public Folders over to the 2007 servers. That'll get 'em on there.

Migrating users We did it in batches over about a week. The users didn't even notice. When they move they get the new OWA. If they're already on Outlook 2007 some features will start working that weren't working before.

Clean up There are some gotchas in removing the 2003 servers from your environment. Be careful about this. We missed a step, and I still don't know what step that was, that made things like delegates stop working and Entourage users start griping. It all started when we removed the 2003 routing group. So, read up on that and don't be like us. Otherwise, you and the LegacyExchangeDN will become dear friends.

Answer 2

Sounds like fun! Here are some thoughts:

Disks:

• I'd skip the iSCSI and go with DASD if it's cheaper. Since you don't need shared storage for CCR I'm not sure that I see an advantage to iSCSI unless it gets you more / better disk cheaper.

• Disk option 1 seems like underkill, but I don't know how much mail data you have.

• Disk option 2 will offend some people w/ the OS and pagefile being on the same spindle as the transaction logs, but I'd predict that you'll have so little IO contention there as to render that point moot. With that kind of RAM I can't imagine you'll be paging frequently.

• Disk options 3 and 4 make sense if you're going to use iSCSI, though in either case you might consider using the excess disks in the server computer as a RAID-1 volume with a storage group for, say, public folders on them. I think that an iSCSI volume for the transaction logs might be a bad idea, depending on the throughput of your iSCSI gear.

CPU and RAM:

Microsoft seems to think that you want more cores, as opposed to higher clock speeds. I tend to agree, but I can't base that on anything other than anecdotal observation of performance. Exchange has always done a great job of taking advantage of multiple CPUs, and I can't imagine that E2K7 is an exception.

Your RAM configuration ought to be plenty, per Microsoft's planning guide's formula (http://technet.microsoft.com/en-us/library/bb738142.aspx), but more accurate planning could be had by working up some sizing based on your existing E2K3 install.

Migration:

A move-mailbox migration is your friend, and it's not complicated at all. You can stage everything while the E2K3 server computers are in production and migrate away from them as time allows. Your routing group topology sounds pretty straightforward (>smile<) so it won't be a big deal to mail routing going as you bring E2K7 online.

There is no option to "pre-build" if you're going to go the "cutover" route. You can't have both an E2K3 and an E2K7 organization freestanding in the same AD forest.

Public Folders:

Keeping your old E2K3 machines to host public folders is certainly a possibility. If not, replicate the public folders to the new public stores you create and, as you've said, specify the default public store for each private store.

Clients:

Supporting Outlook 2007 and Outlook 2003 simultaneously isn't a problem. Technically Outlook 2000 isn't "supported" by Microsoft. I've never tried it and I've never heard from someone who has. I'd be wary of expecting that it would work and I'd test it. Supposedly as long as there's a public store available Outlook 2000 will work.

Outlook Anywhere works fine in E2K7. I don't know what to say about using Outlook Anywhere company-wide. I'm not aware of a comparison of bandwidth usage between MAPI on the wire versus MAPI inside of HTTP, and I think that would give you the answer. You could certainly mock it up and benchmark it with something like Wireshark. (Gee... another one of those "maybe I should do that sometime" ideas. I've been getting a lot of those since I've started posting on here...)

Answer 3

Hmmm. Well I could give you the anecdotal comment about loading that I'm running > 2000 users on a box with 24Gb with no issues, so 16Gb ought to cope with 400 users. Or I could point you to Microsoft's exchange sizing tool so you can use the scientific method for working out your needs.

Answer 4

Our exchange server has 1GB of memory and we have 373 fully active heavy usage email accounts. Unless you are trying to give each user unlimited amount of storage 16GB memory is overkill.

I wanted to edit that those are full time employee email accounts, we have a couple hundred of which we call light to almost inactive accounts. Less than 2MB which is nothing these days, its like they arent even using the accounts.

Answer 5

IIRC, Microsoft's best practice when it comes to Exchange (and SQL) is:

• RAID1 OS
• RAID1 Logs
• RAID5 Data (RAID10 would obviously perform better, but it's also much more expensive)

I have no idea how Exchange will perform against iSCSI, but with FC you could in reality run all of those on a SAN (with separate drive spindles).

Answer 6

I'd agree almost entirely with Evan's response. I'd have a couple different takes on some things. I'd differ about outlook 2000. I'd make sure those were upgraded before I moved those users over to 2007. I'd differ when it comes to public folders. You didn't mention what was stored in the public folders. Depending on what's being stored there you should consider moving it to sharepoint. Here is a guidance post on what to and not to move to sharepoint right off the bat. Even though the guidance says "no need to move" alot, I'd still consider it an option because

a. if you continue with public folders users will usually try to get more created- then you're back to the "new to pf" column, and, generally speaking of course, sharepoint is usually your best option.

b. It's likely you either have, or will have, a sharepoint server, in which case you'll likely be maintaining the same type of information in 2 disparate systems, which from a business process standpoint is not exactly optimal.

the key quote from the article is this:

"There are many advantages with moving to SharePoint for your collaboration, content management and business process needs. In contrast, not all Public Folder usage scenarios are best served by SharePoint. Consider the strengths of each server, and the factors listed above, when making this decision. A very realistic option for moving to SharePoint, is to deploy SharePoint in your organization today. Begin integrating it into your organizations workflow, and slowly reduce your reliance on Exchange Public Folders."