Not long ago, I received an e-mail from the owner of a business that I provide IT services to. It was forwarded from an intern at the company. Here is what it said:

From: [Intern]
Sent: Monday, March 01, 2010 12:06 PM
To: [Owner]
Cc: [Admin person]
Subject: Way to save money?

I was doing some research into this, and it may be a way for our company to cut some costs. Google has a more efficient and easy way to control email and calendars than Microsoft exchange server. It removes the need for servers, tapes, etc., for our email system and saves money as well. Granted I don’t know what we pay for the server and IT support, but they break down the costs on the website.

A great benefit: it allows employees to choose to use outlook or Gmail as the client (ie: don’t have to train people who are accustomed to outlook and don’t want to switch – not that Gmail is complicated). We keep all the same email addresses and such, however it allows EVERYONE to check their email and calendars from home, much easier than with the exchange server, and Google syncs the calendar, contacts and emails with outlook so everyone has the same information.
• Because chat is part of Google, quick answers can be received from within the office, rather than having to write up an email, yet it is stored as an email. Below is the link to information on the business premium version of Google apps.
• 25 GB storage per person is also a huge factor. I believe that may be larger than what we currently have with MS exchange.
• Email archiving of up to 10 years of retention
• Better spam controllers (we wouldn’t need our specialty spam software)
• Fully secure web server
http://www.google.com/apps/intl/en/business/index.html There are also some videos from some large business who use Google rather than Microsoft here.

This is the link to the cost savings calculator: http://www.google.com/apps/intl/en/business/messaging_value.html I find it really interesting the difference in costs. If we were able to save over $100,000 in a 3-year time period by switching, maybe it’s worth it?

Take a look and let me know what you think. I was trying to explain Google Wave to you both last week when we were discussing marketing, and how I think it is the start of what is to come in business communication, and I think Google apps is also in this realm. Personally, I know that I love Gmail and all the applications associated with it, and I think I can speak for [admin person] in that she agrees with me (we’ve both mentioned the “conversation” aspects of Gmail which are incredibly useful at helping organize your inbox).

Thanks,
[An intern at one of my clients]

 

Here is my response to the customer:

Summary: Switching to Google e-mail will increase your e-mail costs by 40 percent and complicate your infrastructure by decentralizing it.

Truth in advertising:
I think that large enterprises that have entirely different network and software licensing infrastructure from yours might be able to save some money with this. They have huge costs for servers and software that are dedicated to running their e-mail system and don’t have any other roles. Instead, small businesses have less costly servers ($3500) that perform multiple roles, one of which is e-mail.

Google’s figures assume that you’ll be buying two servers at $5,000 each JUST to run your e-mail, that you’ll somehow be paying $3,193 for a ten user license of Exchange, which is about twice the actual cost, assuming a standalone Exchange server that is not part of Small Business Server. The SBS edition combines the e-mail license as part of the overall license, further reducing the cost.

There is also an assumption that your IT admin will spend a bunch of hours specifically working on the e-mail system. That may be true for large businesses, but I’ve hardly touched your e-mail system in years.

The figures on the Google website are inflated, designed to catch your eye. They are not accurate figures for a company of your size and with your e-mail usage.

Also, outsourcing the e-mail to Google will not eliminate the need to have a server or backup system. You’ll still need that for your files, centralized control of user accounts, antivirus control, VPN access, accounting software, etc. So you’re only affecting one component – email. But you’re not eliminating it, you’re moving it further from your control. Also, someone in your company (or paid by your company) still has to manage it whether it’s at Google or in your office. The software licenses for it are tied in with your licenses for the other components of the server. You’ve already paid those licenses.
Your actual IT costs:
Nearly all of the money you have spent maintaining your network has been on things like printers, server OS and file backups, workstation issues, firewall, switch, etc. These other components of your infrastructure would still be needed to run your business and to access and work with your Google Mail. The only money you have spent on e-mail was a result of having more than one e-mail account on your computers, which was not related to hosting your own e-mail.

Your IT costs through BFTech from 3/24/2009 through today have been $3540. That’s just the labor. You’ve also purchased a server. Your total costs are probably more like $7500 – but that included replacing some equipment that was more than 5 years old. Looking through the descriptions of those costs, I see about $350 of that being related to e-mail – your home e-mail, NOT driftmier.com e-mail. You’re paying about $250 per year for the Postini anti-spam service, and a percentage of your antivirus cost is e-mail related. Those are the only ongoing costs that are specifically tied to your e-mail. Let’s call it $500/year combined.

When it is time to replace the Proliant server, which runs your files, printers, user logons and e-mail, that might cost you $10k if I gouge you mercilessly for labor costs and make you upgrade to SBS 2008– but the portion of that cost which will be related to e-mail will be about 15% – so that’s $1500 you’ll be spending on maintaining your e-mail. That happens about every 3-4 years, so that’s between $375 and $500 that can be attributed to e-mail. Let’s say for sake of argument that you replace your server every three years.

So how are you going to save $100,000 in three years when you’re only spending about $2000 in three years on your e-mail?

You’ll save $2 per mailbox per month ($2 x 10 users x 12 months = $250/yr) by not needing to have Postini. That means each month, you can buy an extra pizza and a couple of beers with your savings. Oh, but wait – you’re going to have to pay Google $3,302/year for the privilege of hosting your e-mail with them. So much for the pizza and beer.

In fact, let’s look at that a little more closely. Right now you’re spending about $2000/year in e-mail related costs. Google wants $3302/year for 10 users.

Aren’t numbers great? We can play with them all day and make them say different things.
Features:
Easy access from home/mobile – Right now, your users can check their e-mail from home by just going to [OWA URL]. The logon process for that is no more difficult than the logon process for Google. Their entire mailbox is in there, not just their Inbox, calendar, and contacts. If your users have a Windows Mobile smartphone, or an iPhone, or a Droid, or a Palm smartphone, or a Samsung smartphone, or any number of other mobile phones that support Microsoft ActiveSync, they can work with their e-mail, calendar, contacts, and tasks right from their mobile device.  This support is just as widespread as the Google mail thing – maybe more so at this point.

Chat -  that looks nifty – but if it stores as an e-mail, why not send an e-mail using a web browser, phone, or mail client? Microsoft used to have an IM component built into Exchange. They stopped including it because nobody was using it.

E-mail Conversations and organizing – Outlook has many different views and ways to organize your e-mail, including a Conversation view. This is not an Exchange vs. Google thing. It’s a feature of Outlook, and you can use it no matter what e-mail system you are using.

Storage capacity – 25 GB per user is definitely more than Exchange server supports at your current license level – but who needs that much? Your mailbox, that you have been building up for more than ten years, is 6.5 GB in size. [Intern’s] is 1.2 GB. If we needed more capacity, we could upgrade your Exchange licensing and expand to meet the need, and still come in below Google’s pricing in the medium to long term.

E-mail archiving – also nifty, and if at some point in the future you need it, we should evaluate the costs to implement it on your existing server or migrate to a service like Google mail that includes it.

Integrated anti-spam – that’s a good feature. I like that. See the comment above regarding pizza and beer.

Security – Has anyone hacked your Outlook Web Access server lately?
The bottom line:
You have to support a network infrastructure anyway, for reasons other than e-mail. E-mail is a relatively small portion of your IT costs. You are utilizing a very small percentage of what your Exchange server is capable of. It can be made to do much more.
Google is “the new hotness” – but is your Exchange system “old and busted”?
I don’t think so.

 

I also submitted this thread to some other consultants on an e-mail distribution list, and here are their responses:

-=-=-

Ellis:

The number one reason I’ve found to recommend an internal e-mail system over any hosted solution is how can a missing message be traced that the business is critically dependent on?  That is the kind of situation where the ability for us to be able to dive into the message tracking logs, filters and other connectivity systems to find out where the connection failed, and this can provide value that outweighs the cost of the entire e-mail system if the message is valuable enough.

-=-=-

Eugene:

By the way, I laughed when I saw the $100,000 in 3 years thing.  When has this customer ever spent $100,000 in 3 years on all their IT (let alone the email portion, as you point out)?  Most small to medium-small business don’t spend that kind of money, so it’s patently impossible for them to _save_ that kind of money.  And since savings are always a proper (obviously) fraction of spend that is well below unity (i.e. well below 100%) – because the new vendor damn well wants a piece of the pie to take to their own bank – they’d have to spend multiple times that – so, multiple hundreds of thousands per 3 years.  Doesn’t happen, as you point out – you set them up with $3,500 budget servers, reasonable compromise backups plans (i.e. no gold-plated tapes stored in nobel-gas-filled earthquake-proof offsite vaults), and only as much consulting as they need to make their email and OWA work in a normal fashion, and your customer’s costs are quite reasonable.

Regarding Intern’s mention of Google Wave: it is not a real thing at this time, and there’s no indication anytime soon that it will be.  Therefore it is a non-feature, with no importance to the client.
See http://www.theregister.co.uk/2010/01/18/google_wave_drowning/  – “Google Wave isn’t even close to being ready yet for the average user” (published 9 weeks ago)
-=-=-

Joe:

When it breaks, who do you call and what do you expect?  Notice that Wikipedia.com was offline today?  At this point it’s nice to have a bit of control.  You know what you have, you don’t have to worry about a failure outside of your control.  If something breaks, you can walk over, tap the person on the shoulder and ask what the issue is, and when things will be back up.  Who are you to Google?  How important is your business working to them?

Lets say you want to cut down on costs, what can you cut from Google?  You can have me come in less, do no upgrades, and for the most part things should continue to run at a minimal cost.

I’ll also toss in the large file between users – where it has to be uploaded to the server and then pulled down again (rather than staying on the LAN).  It’s not like the client gets to turn off a server by doing this.  All it’s doing is replacing part of a software package that’s already owned and implemented, to let’s change, and this is how many hours of billable work it is to change.  Change like this is expensive for no savings.

Easy math = My Hourly Rate x Hours to Migrate all existing data into this new setup = more than you would save in 2-3 years time by changing.

-=-=-

Patty:

Agreed on all counts.  I don’t think g-mail tech support could be a replacement for a consultant or on-site help desk when problems arise.  That being said, I also think it would probably be the consultant dealing with that g-mail support and charging the client in turn for the time spent dealing with them rather than just solving the problem directly.  Thanks to Microsoft SBS, the e-mail portion of IT expense is small and would be extremely difficult for any outside vendor to compete with from a cost or functionality standpoint.

-=-=-

Ken:

I think you and others have nailed it on a number of counts, particularly with the point about flexible IT budgeting. Customers like being able to get lean when they have to and then ramp up quickly when they get busy.

-=-=-

Here’s a good account of what can go wrong with this type of service as well:
http://www.windowsitpro.com/article/cloud-computing2/Networking-Forecast-Cloudy-with-a-Chance-of-Indifference.aspx

Tags: Exchange, Google Mail

So how the heck do you check mailbox sizes in Exchange 2007? There’s no GUI for it (yet). Maybe that will come in Service Pack 3. Or maybe we have to wait for Exchange 2010.

You can do it in Exchange Management Shell though. here’s the command:

get-mailbox | get-mailboxstatistics | select-object DisplayName,ItemCount,TotalItemSize,LastLogonTime,LastLogoffTime,LastLoggedOnUserAccount | ft

You’ll want to make sure your window size is set nice and wide to accomodate all of that data. I guess with all of the widescreen monitors being forced on us by the people who decide what is sexy to sell to us, that shouldn’t be too hard. if widescreen doesn’t work for you, just replace the “ft” at the end with “fl” for list format instead of table format. Harder to take in at a glance, but it will be nice and vertical.

Want to make an icon to double-click for this? Copy/paste the command into a text file, rename the extension to .ps1, and call it from Powershell like so:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -PSConsoleFile “C:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1″ -noexit -command “. ‘d:\disks\exchstats.ps1′”

Tags: Exchange 2007, Powershell

I am a network consultant. I specialize in migration projects such as upgrading NT4 to Windows 2003/2008, migrating from Exchange 5.5 to 2003/2007, retiring domain controllers and promoting new ones, etc.   I also do my fair share of emptying temp folders, removing malware, and fiddling with backup systems. I tell you this so you will understand that the idea of performing migration projects and reconfiguring networks does not intimidate me. However, I also know that there are always more details and time-sinks involved in such an endeavor than you remember.

Not long ago, my business was running on an HP Proliant DL380 server with Small Business Server 2003 on it. My server was running fine. It was not a brand new server, but was not showing any signs of instability or failure either. I had spare hard disks available, ready to hot-swap, and I had reliable backups.

When I became familiar with virtualization, the idea of virtualizing my server entered my head and percolated there for a while. Virtualization is cool, I thought, but my current server is working fine. Why go to the trouble?

Then I advanced my thinking a couple of years ahead. Then my server would be long since out of warranty, parts would be difficult to find, and I might find myself at the mercy of used hard disk resellers on eBay. Worse than that, if I had to replace a motherboard or hard disk controller, I might find that my server was not so happy with that idea.

Backup software has been claiming for some time now to be able to do “bare metal”, “hardware-independent” restore operations – but if you’ve ever tried one of those, you find out quickly that if there aren’t lots of asterisks and disclaimers in those feature lists, there should be. It’s never as easy as they claim, and the more different the new hardware is, the less likely it is to succeed. If it does succeed, the result is usually somewhat slower, and prone to quirks for the rest of its life.

Then I thought about how a restore works for a virtualized server. The underlying hardware can be totally different, but the hypervisor presents the same hardware layer to the operating system of the VM – so in the event my server failed, I could load up the hypervisor on a completely new, different server (a much faster one), and restore without a hitch.

Failures aside, I also thought about what would happen if I wanted to continue using SBS2003 and do a planned migration from one server to another. I’d have to load up a fresh SBS2003 instance, use ADMT, or manually migrate my user accounts and workstations. Then I would need to install my LOB apps, and migrate databases, files, printers, etc. If I wasn’t using ADMT, or if for some reason ADMT failed on my workstations (you and I know how reliable ADMT is for workstation migration), I’d be manually migrating them. That’s always at least a full weekend worth of work, with another couple of weeks of minor adjustments – a little detail here, a missed setting there. That’s no fun.

With a virtual server, I’d just copy it from one server to the other and be done with it. Then I could spend the rest of my weekend with friends and family, riding my ATV in the woods.

Finally, I thought about upgrades of software on my server. The last upgrade of my accounting software was done with my heart in my throat. If it didn’t work, how well would my backups protect me? How much time and effort would I spend rolling back? The antivirus software upgrade was even more of a concern. You never know when that’s going to backfire on you, and what the cleanup will be like.

With a virtual server, I would simply take a snapshot before beginning the upgrade, and when I was satisfied that it was working properly, remove the snapshot. If it went sideways on me, I’d just revert to the snapshot. If there was changed data after the snapshot, that’s not too difficult to back up and restore to the server after reverting. I’d certainly rather do that than sweat it out trying to repair the damage.

In the end, I decided to go ahead with virtualizing my SBS2003 server. I’m glad I did, and I haven’t looked back.

Tags: Why Virtualize?

 

Exchange 2007 Sizing with a Specific Server/Customer Example

 

I was asked to assess an Exchange 2007 server’s performance, after it had been built and put into production. The customer was asking about the server’s performance, as a result of logging into the console and not finding the server to be as responsive to them as they felt it should be, given the amount of money they had put into it.

 

Along with the general performance review, I was given a specific set of questions to investigate and give my best quick answers to, without spending days researching them.

 

Below is my assessment of the situation, with the names changed.

 

 

Executive Summary:

 

EXCHANGE1 needs more RAM. Beyond that, its configuration seems correct as compared against Microsoft’s published configuration examples and sizing recommendations.

If more RAM were added, I would support adding a DC role to EXCHANGE1.

The memory usage COULD be throttled by a registry key limiting the memory usage on the Exchange Information Store, but this is not recommended by either Microsoft or myself.

I do NOT recommend adding any utility applications to EXCHANGE1.

 

Regarding the perceived performance of EXCHANGE1: I agree that a brand new server with EXCHANGE1’s specifications “should” be snappy. However, I don’t believe its current responsiveness is abnormal. As noted below, servers are tuned for back-end performance for client access. When they have nothing loaded, they are very responsive to the console.

 

If you build up a server OS on a fresh box, it is usually snappy. It boots fast. It shuts down fast. Things come up quickly when you click on them. Then, you join it to a domain, add a few applications (or one big one), and somewhere along the line you realize your shiny new server is not snappy anymore. It’s the way of things.

 

 

Q&A Session:

 

1. Is it normal to see an exchange 2007 use the level of system resources that we are seeing at “Preferred Customer”?

Yes, it is normal to see Exchange 2007 use the amount of memory I am seeing in use, which is just below 8GB of memory. Since the server only has 6, extensive page file usage is occurring.

The CPU utilization seems relatively low as well.

 

2. For a small network like ours does Exchange need all these resources or has Microsoft just assumed we were using this in a large environment?

Microsoft seems always to assume a large environment. Their sizing recommendations are never, in my experience, tailored to a small business environment, no matter how much they say they want to cater to the SMB market.

That being said, the sizing recommendations I have found and listed below do seem to reflect the size of the business we’re talking about.

 

3. Is the reason for the system resource issue because we undersized the server?

At this point, my findings indicate that the server is moderately undersized in the category of Memory (RAM). This is a technicality, based on guidelines provided by Microsoft. In this case, it does seem to be supported by the results of the server’s performance monitor. However, we often see undersized Exchange server that the users are happy with.

 

4. Is the reason because we are loading all the exchange roles on one server?

This is difficult to answer. Microsoft provides many different ways to calculate requirements based on each role being on its own server. At the bottom of each table, there is often a section for “Multiple Roles on one server” with its corresponding recommendation.

The best answer I can give is that any time you load multiple roles of anything on a single server, each of those roles will not perform as well as it would on a dedicated server. How much performance loss we are seeing due to multiple Exchange roles is difficult to calculate.

 

5. Would some type of memory throttling affect the user email experience in a smaller environment like ours?

The short answer is “This is not recommended.” Really, I can only speculate. Since the server is “undersized” in the Memory category, but the users are happy with the performance at this point, I submit that throttling the memory would only potentially cause you trouble by slowing it down for the users. Store.exe on EXCHANGE1 is currently using about 3GB of memory. Of course, the total numbers listed in Task manager do not add up to the actual usage, they never do. There is a method of throttling the amount of memory that the Information Store uses. If the customer agrees to some experimentation, it might be worth trying, if the goal is to free up memory for the server to do other things.

The details of these steps are documented for server 2003 at the bottom of KB article http://support.microsoft.com/kb/815372. It is the same process for exchange 2007.

 

6. I know that Microsoft has at least 3 scenarios for installing 2007, did we pick the wrong scenario when we installed 2007?

Based on my research, this logical configuration is correct for this organization.

 

7. Will this memory resource issue keep getting worse?

Probably. If the company grows in size and more users are actively using the mail system, then store.exe will consume more memory, up to a certain point. In Exchange 2003, the memory usage seemed grow to meet the memory you put into the server, up to a certain point. I suspect that Exchange 2007 will also consume all available resources, until it has more than it knows what to do with.

 

8. If we added a domain controller role to the exchange server, what problems can we expect to run into?

Based on my findings, I suspect that adding a DC role to EXCHANGE1 will slow down the performance as perceived by anyone logging into its console to work directly on the server. Reboot speed will also be adversely affected. However, I do not think it will have a significant impact on client access. Servers are tuned to provide the performance to the users at the cost of local sessions. Terminal Servers are an exception to this rule.

 

9. Is there a way to mitigate this risk?

Yes. If you put a DC role on EXCHANGE1 and it slows down significantly, to the point of user disturbance, you can simply demote it from its DC role and go back to the way things were. As long as you have not moved FSMO roles to EXCHANGE1, this process is straightforward.

NOTE: Since writing this article, I have revised my view on answer #9. In Windows 2003/II6, promoting/demoting a server to/from a DC role has the effect of TRASHING the IIS permissions. I strongly recommend promoting or demoting a server that is running IIS6 unless you are prepared to completely rebuild IIS. This often includes removing and reinstalling several versions of .Net Framework and any other web-related apps that are installed on that server. I don’t yet know whether this issue has been solved with IIS7. I know that positive steps have been made in the area of anonymous web user accounts and IIS worker processes, but do not know whether these steps will protect IIS through a DC role changing event.

 

 

10. If we had a choice between domain controller or Utility server types of applications would say it be all right to load Backup Exec or an Enterprise Virus scanning application on the Exchange server?

Presented with a choice, and the requirement to do one or the other, I would choose to add a DC role (See the note above). However, at this point I do not recommend adding any roles to EXCHANGE1 server until its memory is increased. Once that has been done, adding a DC role would be my next recommendation based on the customer’s current configuration. I recommend against installing any utility functions on EXCHANGE1. They will consume more resources with a higher combined effect, and increase the likelihood of rebooting the server for troubleshooting, maintenance, and upgrades. Instead, I recommend adding a lightweight inexpensive server for DC or utility functions.

 

 

 

Exchange 2007 Configuration and Hardware Planning

 

There are many resources available for planning and right-sizing an Exchange 2007 server. So many resources exist, and so much is said about the topic that it is daunting to try to find your target configuration among the vastness of the data. However, I have summarized them below. I copied and pasted sections of information relevant to a medium-sized business with more than one server, more than 50 or so users, but less than 5 physical sites and less than 1000 users. This constitutes a “scale” or range within which you can narrow down your requirements based on the information below.

 

 

Planning for a Simple Exchange Organization

 

Simple Exchange Organizations with a Single Server

Of the four defined organization models for Microsoft Exchange Server 2007, the simple Exchange organization represents the most basic topology into which Exchange 2007 can be deployed. The simple Exchange organization contains either:

 

·         A single Exchange server that provides all Exchange services and stores all Exchange data for the entire organization.

·         Multiple Exchange servers in a topology that includes redundant directory servers and an Edge Transport server in a perimeter network.

 

A simple Exchange organization with a single server consists of the 64-bit, retail version of Exchange 2007 running on a computer that has been configured as an Active Directory directory service server. A simple Exchange organization can also consist of a single computer running the version of Exchange that is included with the retail version of Microsoft Windows Small Business Server 2003 (Windows SBS) server software.

 

·         We recommend that you deploy the single-server simple Exchange organization only when using Windows SBS.

·         We recommend that you deploy the multiple-server simple Exchange organization only when using Centro (on Windows 2008).

 

Planning for a Standard Exchange Organization

 

Of the four defined organizational models for Microsoft Exchange Server 2007, the standard Exchange organization represents the most common topology into which Exchange 2007 is deployed. As messaging service needs grow beyond the resource limits of a single computer, separation of Exchange 2007 services onto multiple computers becomes the next topological division: the standard Exchange organization. The standard Exchange organization builds upon the simple Exchange organization by deploying multiple computers running Exchange.

 

Unlike the simple Exchange organization, in which all Exchange services, except for the Edge Transport server, are installed on a single computer, the distinguishing characteristic of the standard Exchange organization is that Exchange services are installed on multiple computers. In this topology, Exchange Server is not installed on a directory server, and it may be installed on multiple member servers. In this case, adequate directory service resources must be available to meet the needs of the messaging system.

 

Other distinguishing characteristics of the standard Exchange organization include:

·          The Service Delivery Location (SDL) and Client Service Location (CSL) reside on the same local area network (LAN).

·          There are more than 1,000 mailboxes in the organization.

·          There are fewer than five routing groups, and between one and five Active Directory directory service sites. Multiple locations and Active Directory sites introduce the multi-site routing protocol and role discovery algorithms, as well as a requirement to use IP site links.

 

 

Hardware Requirements

 

Processor

 

Processor Configurations

Exchange 2007 server role	Minimum	Recommended	Maximum
Multiple server roles (combinations of Hub Transport, Client Access, Unified Messaging, and Mailbox server roles)	1 x processor core	4 x processor cores	4 x processor cores

 

Knowledge worker profiles for Outlook users

User type (usage profile)	Send/receive per day approximately 50-kilobyte (KB) message size
Light	5 sent/20 received
Average	10 sent/40 received
Heavy	20 sent/80 received
Very heavy	30 sent/120 received

 

[Note: Here I must interject a comment: What planet do the people who wrote this table live on, where sending 30 e-mails per day and receiving 120 is considered “Very heavy”? Using this scale, I know quite a lot of Exchange users who would fall into the “Staggering” row (not featured in this table).]

 

Multiple Server Roles

The guidance for a computer with multiple server roles installed is similar to the Mailbox server role. To accommodate the Client Access and Hub Transport server roles on the same server as the Mailbox server role, reduce the 1,000 mailboxes per core calculation based on the average client profile by 20 percent (800 mailboxes per core) when performing sizing. The maximum recommended processor core configuration is listed at 4 x processor cores for the multiple server roles configuration to indirectly provide guidance on the maximum number of users that should be hosted on a multiple role server. <snip> For this reason, the recommended maximum processor core configuration for the multiple server roles configuration is listed at four. Although this configuration can use up to eight processor cores, we do not recommend this configuration due to availability concerns.

 

Sizing used primarily for budgeting purposes can be accomplished by assuming that 1,000 average mailboxes will require a 1 x processor core. (For example, a 4,000-mailbox server with an average usage profile requires 4 x processor cores). A heavy usage profile effectively doubles the required processor cycles (or halves the number of users per processor core to 500 mailboxes per processor core). A 2,000-mailbox server with an average profile requires a 2 x processor core server. The maximum number of processor cores efficiently used by the Mailbox server role is eight. Deploying mailboxes on servers with more than eight cores will not provide significant scalability improvements.

 

 

 

Memory

 

Memory configurations for Exchange 2007 servers based on installed server roles

Exchange 2007 server role	Minimum per server	Recommended	Maximum per server
Multiple roles (combinations of Hub Transport, Client Access, Unified Messaging, and Mailbox server roles)	4 GB; also depends on number of storage groups (For information, see later in this topic.)	8 GB plus from 2 MB to 5 MB per mailbox. This is variable based on user profile. For more details, see “Mailbox Server Role” later in this topic.	32 GB

 

 

 

Storage

 

This topic provides guidelines for selecting a storage configuration that provides good performance and a strong platform for Exchange 2007. Capacity and performance are often at odds with each other when it comes to selecting a storage solution, and both must be considered before making a purchase. Generally, the decision involves the following factors:

·          Making sure there will be enough space to store all of the data. Determining your capacity needs is a relatively straightforward process.

·          Making sure the solution provides acceptable disk latency and a responsive user experience. This is determined by measuring or predicting transactional input/output (I/O) delivered by the solution.

·          Making sure that non-transactional I/O has both enough time to complete and enough disk throughput to meet your service level agreements (SLAs).

The goal is to find a balance of these factors so that you can design the actual hardware solution for your servers.

 

Planning Disk Storage for Exchange

Disk subsystem bottlenecks cause more performance problems than server-side CPU or RAM deficiencies. A poorly designed disk subsystem can leave your organization vulnerable to hardware malfunctions. Specifically, your disk subsystem is considered to be performing poorly if it is experiencing:

·         Average read and write latencies greater than 20 milliseconds.

·         Latency spikes greater than 50 milliseconds that last for more than a few seconds.

 

High disk latency is synonymous with slow performance. To reduce costly disk latency issues, at a minimum, you should:

 

·         Invest in high performance disks and spindles   It is better to have smaller capacity disks that utilize each spindle’s performance than to use fewer spindles with large capacity. Fast storage with a sufficient amount of spindles is one of the most important investments you can make in your messaging infrastructure.

 

·         Consider performance before capacity   Relying on capacity as the primary metric for storage sizing often results in poor performance for your disk subsystem. For example, most administrators who select a RAID-5 solution do so to maximize storage usage. However, in many cases, properly sizing the performance of your spindles requires you to use more physical disks for RAID-5 than you would use in a RAID-1+0 configuration.

 

·         Align your disks Use the Diskpart.exe tool to verify that your disk tracks are sector-aligned. By using Diskpart to create aligned partitions (as compared with non-aligned partitions that are created with the Disk Management snap-in or Windows Explorer), you can increase disk performance by as much as 20 percent. Note that Diskpart can only be used with basic disks. Diskpart cannot be used with dynamic disks. Diskpart is part of the Windows Server 2003 Service Pack 1 Support Tools. Diskpart supersedes the functionality found in Diskpar, a Windows 2000 Server Resource Kit tool.

 

 

Role Ratios

 

After you have determined your optimal processor, memory, and disk configurations, you should determine how many server roles of each type are required for your deployment. Every environment is different, so consider these recommendations as starting points that can be tailored to your environment.

 

Active Directory Server and Mailbox Server Ratios

The recommended number of Active Directory directory servers in each site containing Exchange 2007 Mailbox servers or users depends on the number of processor cores in each computer running the Exchange 2007 Mailbox server role and the hardware platform on which Active Directory is running. Specifically, consider the following scenarios:

 

If Active Directory is running on the x86 platform (32-bit), the recommended ratio of Active Directory directory server processor cores to Exchange 2007 Mailbox server processor cores is 1:4.

 

In the above ratios, it is important to note that this is a ratio of processor cores and not processors. Thus, a dual-core processor counts as 2 when calculating the ratio.

For Exchange 2007, we recommend that you deploy one 32-bit global catalog (GC) server processor core for every four Exchange 2007 Mailbox server processor cores. Although other server roles will influence the number of GC processor cores required, the Mailbox servers that are deployed influences the deployment of each of the other roles, so basing the number of GC processor cores on Mailbox server processor cores will suffice.

 

Recommended server role ratios based on processor core

Server role ratio	Recommended processor core ratio
Mailbox Server Role : Hub Transport Server Role	7:1 (no antivirus scanning on Hub) 5:1 (with antivirus scanning on Hub)
Mailbox Server Role : Client Access Server Role	4:1

 

[Note: This table was initially very confusing to me. I think it means you should have five processor cores dedicated to mailbox servers per one processor core dedicated to hub transport servers, and so on.]

 

When considering these recommendations, be aware of the following:

·          The preceding ratios are a general rule, and they may not be valid for every topology. A general rule means that the ratios are not a requirement for support or a definitive rule.

·          Ratios can change dramatically based on user profiles. A user that creates a larger than expected load against the Mailbox server role than the Hub Transport server role will increase the Mailbox:Hub ratio, and vice versa.

·          These recommendations are derived from the internal deployment of Mailbox servers at Microsoft, which is based on approximately 500 heavy users per processor core.

·          These ratios assume that Mailbox servers are at greater than 60 percent processor utilization during peak periods, with corresponding processor utilization on Hub Transport or Client Access servers.

 

 

 

References:

 

TechNet Library: Microsoft Exchange Server 2007

http://technet.microsoft.com/en-us/library/bb124558(EXCHG.80).aspx

 

Planning for a Simple Exchange Organization

http://technet.microsoft.com/en-us/library/bb124367(EXCHG.80).aspx

 

Planning for a Standard Exchange Organization

http://technet.microsoft.com/en-us/library/bb124367(EXCHG.80).aspx

 

Planning Processor Configurations

http://technet.microsoft.com/en-us/library/aa998874(EXCHG.80).aspx

 

Planning Memory Configurations

http://technet.microsoft.com/en-us/library/bb738124(EXCHG.80).aspx

 

Planning Storage Configurations

http://technet.microsoft.com/en-us/library/bb124518(EXCHG.80).aspx

 

Planning Server Role Ratios

http://technet.microsoft.com/en-us/library/bb738159(EXCHG.80).aspx

 

 

 

Tags: Exchange 2007, Right-sizing

Exchange 2007: Use Roles When Right-sizing Server Hardware

Date: June 12, 2007

Exchange Server 2007 represents a complete re-envisioning of enterprise e-messaging for the Microsoft platform. Server roles play a central part. Use these guidelines to right-size server hardware and plan enterprise deployment.

One Actor, Five Roles

Exchange Server 2007 parses core messaging functions into five roles. Begin by understanding the roles and their functions.

·         Client Access Server. This role answers all non-MAPI access requests such as those made via Outlook Web Access, Exchange ActiveSync, POP3, and IMAP. The Exchange ActiveSync Direct Push feature automatically synchronizes data to mobile devices (forwarding e-mail, for example), but will only work with cellular devices, not over Wi-Fi. When implemented in a redundant architecture, the Client Access Server role can also perform load-balancing.

o    Do not confuse this role with the front-end server for Exchange 2003. The Client Access Server off-loads significant processing tasks from the Mailbox Server including Exchange ActiveSync policies and Outlook Web Access (OWA) segmentation.

·         Edge Transport Server. Residing in a DMZ with only limited access to the organization’s Active Directory (AD), this server directs mail flow, enforces policies and compliance, and performs anti-virus/anti-spam functions before passing mail to the Hub Transport Server.

o    The Edge Transport Server’s Address Rewriting feature allows an organization to modify all out-going messages to present the same, corporate e-mail domain name. Conversely, address rewriting can be used to modify incoming e-mail messages to route them to specific domain-names. This will be most useful to enterprises comprised of multiple subsidiaries.

·         Hub Transport Server. The Hub Transport Server role directs mail flow within the organization and enforces transport rules and journal rules (which allow e-mail to be recorded by the enterprise). Multiple Hub Transport Server roles can be implemented in a redundant architecture for load-balancing.

·         Mailbox Server. This role stores all mail, interacts with all other roles to fulfill retrieval requests, handles MAPI-based Outlook requests, and manages Contacts, Public Folders, and Distribution Groups.

·         Unified Messaging Server. Voice and fax messaging are integrated into the user’s inbox. The Unified Messaging Server role can answer the telephones, route VoIP traffic, receive faxes, and interoperate with third party fax server software to send faxes.

At a minimum, enterprises will want to use three servers:

1. An Edge Transport server in a DMZ.
2. A standalone Unified Messaging server.
3. A combined Client Access, Hub Transport, and Mailbox Server.

See the recommendations below for how many Mailbox Servers the enterprise will require. Larger enterprises will also add additional Client Access and Hub Transport Servers to perform load-balancing.

Recommendations

Microsoft offers plenty of material to help shops size the servers and suggest possible architectures based on messaging load. Here are the highlights:

1. General Guidance.
   • Hardware. Provide 2 processor cores and 2GB of RAM on each Exchange Server 2007 role server. Allocate at least 1 GB of RAM for each additional processor core (except Mailbox Server, which has heavier requirements).
   • Network Architecture. Install the Client Access Server first. The Hub Transport Server, Mailbox Server, and Unified Messaging Server must be installed in this order. The Edge Transport Server can be installed anytime after the Client Access Server.
   • Combining Roles. When two roles are combined (e.g. Client Access and Hub Transport) into one physical server, plan for a 20% reduction in capacity.
   • Virtualization. Exchange 2007 roles can be virtualized. Currently, Microsoft’s Virtual Server 2005 R2 does not support the 64-bit guest systems required. For more information refer to “Exchange 2007 facing integration issues with other Microsoft software,” from Network World and further comment in Azaleos’ corporate blog.

For full details refer to, “Planning Processor and Memory Configurations,” “Best Practices for Deploying a New Exchange Organization,” and “Best Practices for Transitioning an Exchange Organization” from Microsoft TechNet.

1. Client Access Server.
   • Hardware. Microsoft recommends provisioning this server with 4 processor cores and 4GB RAM. Ensure at least a 100Mbps connection to the Mailbox Server. Enterprises with fewer than 3,000 mailboxes seeing average traffic or fewer than 1,000 mailboxes that see heavy traffic may consider using only 2 processor cores and 2 GB RAM. (In Microsoft parlance, “average” refers to an e-mail usage of 10 outbound/40 inbound messages a day. “Heavy” usage refers to 20 outbound/80 inbound messages a day. “Very heavy” usage describes workloads of 30 outbound/120 inbound messages a day.)
   • Network Architecture. Client Access Server is the first role that should be deployed and configured within the network topology. Each AD site that will also contain a Mailbox Server requires at least one Client Access Server. Proxies can be used to configure multiple Client Access Servers to present a single external address for OWA or ActiveSync access.

For detailed sizing information including Microsoft’s in-house experiences refer to, “Planning for Client Access Servers” and “Sizing Client Access Servers” from Microsoft TechNet.

1. Edge Transport Server.
   • Hardware. Microsoft recommends provisioning this server with 2 processor cores and 2GB of RAM. Monitor to determine if the volume and size of messages warrant adjustment.
   • Network Architecture. This role can be deployed at any time during the deployment. Also, Edge Transport Server can be deployed to an existing Exchange network without upgrading the other Exchange servers.

For full details refer to, “Planning for Edge Transport Servers,” “Planning for Edge Transport Features,” and “Planning for Address Rewriting” from Microsoft TechNet.

1. Hub Transport Server.
   • Hardware. Microsoft recommends 4 processor cores and 4GB of RAM. Using anti-virus/anti-spam on the Hub Transport Server may warrant an 8 core, 8GB RAM configuration.
   • Network Architecture. This role should be installed before the Mailbox Server or Unified Messaging Server roles, as those roles depend on the Hub Transport Server for mail delivery. Each AD site that also contains a Mailbox Server must contain at least one Hub Transport Server.

When contemplating e-mail flow in the Exchange infrastructure, be sure to review “Planning for Compliance,” “Overview of Compliance Features,” and “Planning for Domain Security” from Microsoft TechNet.

1. Mailbox Server.
   • Hardware. Microsoft recommends planning one processor core per 1000 average mailboxes. Double this for each higher level of usage. In other words, plan 2 processor cores for 1000 heavily used mailboxes; plan 4 processor cores for 1000 very heavily used mailboxes. Provision 3GB to 5GB of RAM per core (more for higher usage levels). Conversely, plan memory by allocating 2GB for every 4 Exchange Storage Groups on the server.
   • Network Architecture. The Mailbox Server role is strongly tied to Exchange storage choices and may be part of a Cluster Continuous Replication (CCR) or Local Continuous Replication (LCR) cluster (after Exchange 2007 SP1 launches, Standby Continuous Replication also becomes possible).

For additional information refer to, “Planning for Mailbox Servers,” “Planning Disk Storage,” “Planning for Local Continuous Replication,” and “Planning for Cluster Continuous Replication” from Microsoft TechNet.

1. Unified Messaging Server.
   • Hardware. Microsoft recommends 4 processor cores and 4GB of RAM. Converting WAV files to WMA files drives the hardware requirements for the Unified Messaging Server. Enterprises with minimal Unified Messaging Server activity may consider 2 cores with 2GB of RAM.
   • Network Architecture. Unified Messaging Server is the last server role to be installed into the Exchange network.

For full details refer to, “Planning for Unified Messaging Servers,” “Supported IP/VoIP Gateways,” and “IP/PBX and PBX Support” from Microsoft TechNet.

Bottom Line

Microsoft Exchange Server 2007 compartmentalizes e-messaging delivery workloads through a role-based architecture. Follow these recommendations to right-size server hardware for Exchange Server 2007 roles.

Tags: Exchange 2007, Right-sizing