“I need an Exchange Server,” - it’s not quite that simple.

A partner called me today, distraught that he couldn’t get a simple answer to his client’s question.  What was the question?  “What do I have to buy to build an Exchange system for 200 users.” The frustration stemmed from the conversations that my vendor friend that had with the client about things like server class, storage, and about a dozen other criteria he wanted to be sure of before quoting out the hardware and software necessary to get the job done.  From the research the client had done on their own, they believed it should be as simple as buying “a server” and “some disk” and doing the Exchange install.

This particular vendor knows I work for Double-Take Software, and that I am one of their Exchange SME’s, and so reached out to me to see if I could come up with an answer on the failover/availability portion of the question, since that was also going to be a requirement for this environment.  He was less than thrilled with my answer, which fell somewhere between “are you insane,’ and, “I’m not touching this with a 40 foot pole.”

Eventually I settled down, and started walking through all the things that were wrong here, and trying to find some way to get the questions simplified enough so that the client didn’t feel like they were being asked to… well… architect a complete Exchange solution for their environment. It was quite the process, let me tell you.

In order to help those who have never worked with Exchange Server before, let me spell out a few of the things you will need to know before you move forward.  For those who work with it every day, I hope you can use this as a plain English explanation of what’s involved so that you can explain it to those who may need to sign the checks, but don’t know the tech – should you ever run into that problem.

First things first. “Exchange Server” isn’t a server.  It’s a platform of software tools that all work together to provide email, collaboration services and shared data services to end users.  That means that you can’t just buy “an Exchange Server,” and in most cases it’s not one server at all, but two or more acting in concert.  To say “I need an Exchange Server for 200 people” is like asking a car dealer for “a car that can go 10 miles each day.”  Do you want a car that can hold 2 people, or 4?  Are you planning on only moving people or do you have pets?  How about cargo space, are you planning on carrying groceries for those 10 miles, or hauling bricks?  Oh, and do you want a car that can go 5 days between trips to the gas station, or do you want an SUV that’s going to suck up the whole tank during each 10 mile trip?

To beat that analogy up even further, Exchange is only the engine, not the car.  Much like other types of engines, it works better in some car chassis than others.

So, what do you plan to do for your 200 users?  Do they use a lot of email all day long, or is it just light email a few times a week?  What do they email, just regular text emails, or are they shipping multimedia presentations back and forth to each other and outside the firm? Are they all in one office, or spread out across multiple offices all over the place?  If they are spread out (or if they access mail from home, etc.) what level of security do you need to provide?  Are they doctors (HIPPA) or officers of a public company (SOX)?

Now let’s talk about some other things that may go on in your environment.  Do you need to be able to schedule conference rooms, company vehicles or other shared resources?  How about generic email boxes, like for users to request information, open support tickets or contact a salesperson or media contact?  In other words, is it 200 users that need 300 mailboxes all told, or is it 200 mailboxes?

How big were you planning on letting these mailboxes get?  Left to their own devices, users can accumulate gigabyte after gigabyte of data.  I know some sales folks who routinely have about 6-8GB of data in their email boxes.  And speaking of all that email, how long do you plan on keeping it?  Do you need to archive older mail (which you should do) or do you need to permanently delete things over a certain again (which you may need to do)?

As you can see, things are quite a lot more complicated than “get me an Exchange Server for 200 people,” and we’re not done yet.

Let’s talk Exchange Ecosystems.  That’s Microsoft’s term for all the servers and services that surround the Exchange Server in most environments.  Don’t think you need that?  You may want to think again.

Anti-Spam, Anti-Virus and other message hygiene tasks could be done on the Exchange Mailbox server, but typically for systems over about 100 users, they’re done by independent servers well before the email reaches the mailbox.  That means either creating servers dedicated to those jobs, or – more likely at this size – leasing services from a 3rd-Party provider of message hygiene solutions.  If so, do you want to host an appliance at your site, or outsource everything?

Speaking of outsourcing, 200 users is still well within the range of Exchange Hosted Services or other forms of Exchange Server Hosting.  Then you can just outsource everything and tell the vendor what features you want.  Can you do that in your industry and with the regulations/company policies you’ve got in place?

People rarely stand still for long.  I’m writing this blog posting on a train heading to Boston, but I have full access to my entire Exchange mailbox and other corporate resources through Outlook Web Access, Outlook Anywhere via my air card, and of course my Blackberry device.  Do your 200 users all need to be able to have that kind of access? If not, how many do and how many do not?  Do you need to configure Outlook Anywhere (the components of Exchange that enable many mobile devices like Windows Mobile and iPhones)?  Do your mobile folks like Blackberries instead?  If so, do you want to host your own Blackberry Enterprise Server, or outsource that too?

While we’re on the subject of people talking to each other, do your users need to share more than email?  Do they routinely cooperate on documents, lists, wikis and other things too?

At this point, you may be ready to throw your hands up, throw the idea of creating an Exchange Server out the window, and go home.  Don’t give up yet, because here’s where we tie it all together:

Exchange Server 2010 is the currently shipping version of the Exchange Server Messaging and Communications Platform.  It contains the ability to set up mailboxes, message hygiene and routing for email, communication with mobile devices and connections to other tools.  It’s available in two “flavors” – Standard and Enterprise.  With 200 users, you’re almost definitely looking at the Enterprise version, which is good, because it can help a lot with the high availability questions.  Most clients will also need additional availability solutions (see disclaimer below, I’m biased) and backup solutions as well.

Also, you’ll need Client Access Licenses for each user/mailbox.  There are two types, Standard and Enterprise.  Enterprise CAL’s allow you to do things like grant mobile access and get archiving and cross-mailbox search, so you will most likely need those for at least some of your users.

Next, what kind of hardware will you be needed?  Well, if the 200 users don’t do a lot of email work, you can get away with a lower-class machine than most.  You may even be able to squeeze everything on to one server, though putting the front-end systems (called Hub/Transport and Client Access Services) on their own server isn’t a bad idea.  You’re right on the edge of needing to split everything out anyway, and if you’re planning on growing (which hopefully you will) then you’re going to need to do it sooner rather than later.

As for what those servers will look like, there’s a lot of debate on that topic, so for this article I’ll use the official specs from Microsoft.  You can find them (and a lot more info) on the Microsoft TechNet site on Exchange Performance and Sizing.

Your front-end server should have between 4 and 12 cores, which you can get by using 1 to 3 quad-core processors, which are the standard these days.  The Mailbox server needs more horsepower, so you’re looking for from 4 to 24 cores there.  RAM-wise, front-end servers should be getting about 4GB-8GB each.  At this level you’ll probably only have one front-end server though.  Mailbox servers need 4GB to start, and then need 3MB/mailbox if your users are light email users.  If most of your users are heave emailers, with lots of attachments, huge contact lists and tons of calendar appointments, you should be looking more toward 30MB per user mailbox.

Disk space is another concern.  Microsoft has made Exchange 2010 much more efficient with disk than its predecessors, and so you can use a lot of different types of disk options.  You will need to be able to hold all the information not being archived or deleted, so think in terms of 200% of what you’re allowing your users.  So if each user can store up to 3GB of data in their mailbox, you should be allocating 1.2TB (3GB x 200 users x2) of storage space for them.  This will allow you to allocate space for Exchange’s transaction logs (internal log files used to track what Exchange is writing to the databases), the databases themselves, and the necessary queuing systems that shuttle mail back and forth, with a little room to grow.  These days you can get that with just internal disk, but many clients choose to go with external arrays so they can scale over time.  Definitely check the TechNet website for recommendations on what RAID to use and other disk settings; as this is just how much disk you need, not how you should create or allocate it.

Exchange 2010 also comes with native archiving and compliance search features built in.  This will, of course, require more hardware, so have a look at the overview of these tools on the TechNet site and plan accordingly.  Keep in mind that if you use native or 3rd-Party backup/availability tools, you’ll also need another server and appropriate disk space to hold the backup copies of the data.

External to the Exchange Server itself, but just as important, are the Ecosystem servers.  SharePoint Server allows your teams to share documents, calendars and projects easier than the native tools in Exchange Server could alone.  SharePoint is a whole other server platform, but one that you should look into if your users tend to share stuff on a daily basis.

Blackberry and Good Technologies are two common tools that work side-by-side with the native Outlook Anywhere (formerly known as ActiveSync) systems in Exchange.  If you have Enterprise CAL’s, your users can access email via Outlook, Outlook Web Access, or a host of mobile devices like iPhones just by using Exchange Server.  If you want to add extra security and sync features, then you use Good.  If you want your users to have access to the popular Blackberry mobile devices – and centrally control and manage them, then you’ll need Blackberry Enterprise Server (BES).  Good can often by installed to the Exchange Mailbox Server, but it’s a better idea to give it its own server so it doesn’t bog down the mailboxes.  BES can either be provisioned on its own server at your site, or you can lease space on a hosted BES service provider’s server.  If you host your own, then of course you will need a server to put it on.

Summing up, we’ve gone from “I need an Exchange Server for 200 people,” to, “I need several servers of different sizes to host all the components of Exchange Server for my organization.”  If you have never touched Exchange Server before, this can be bewildering, frustrating and expensive – especailly seeing as you’ll probably goof up at least once (we all do).  The good news is that there are two options if you just can’t wrap your brain around all of this.

One is to get help.  There are a huge number of service providers who can assist you in planning, procuring and implementing all these moving parts.  Many can also train your team to maintain what they built, and to build out new stuff when needed.  If you plan on hosting everything yourself, this is the much better course of action to take, as going it alone quickly gets more expensive as you fix mix-ups than the consulting costs would have been.

Alternately, you can talk to Microsoft and their partners about having someone else host and administer your Exchange solution.  Hosted Exchange Services is the product offered directly by Microsoft, and many partners also host Exchange services on their own.  Take a look an article or two before this one in this blog for some details on that.  Up to 500 users/mailboxes, it is quite suitable to go the hosting route, and even up to 1000 users it can make a lot of sense.  It’s still Exchange Server, you still get Outlook, Outlook Web Access and Outlook Anywhere – and you may be able to get Good and BES too.  You’re trading management and hardware costs for a monthly cost per user and/or per amount of storage space they use.

So, what does it boil down to?  The short answer is that there is no valid short answer here.  You need to take a look at your users and your datacenter facility.  You need to know what they want to do with their messaging systems before you can even begin to install Exchange Server components.  Exchange Server is no longer something you can just buy “off the rack” and toss into your environment.  Plan, implement and manage it correctly, or it will be nothing but a nightmare until you eventually do the planning and rebuild it right – which always costs a lot more.

Confusion over “2003 AD” and “2008 AD” with Exchange Installs.

One of my colleagues ran into this one last week, so I thought I’d share the issue here, and detail the fix.  When you go to install various versions of Exchange Server (2003 and up) and/or try to activate certain Exchange functionality, you may find that your Active Directory (AD) domains are not at the correct functional level, even though they appear to be.  Here’s a case in point:

I checked, and my domain is at a 2003 domain level, but Exchange Server 2010 says that it isn’t…

At first glance, this is an infuriating problem, because my colleague definitely confirmed that the Domain Functional Level was “2003” and the installer just wouldn’t work. The issue is a matter of one word versus another – specifically “Mixed” versus “Native.”

Mixed mode domains are designed to allow earlier versions of Windows AD Servers to operate properly in an environment that is being upgraded to a new AD platform.  Today, it is not uncommon to see 2003, 2008 and 2008 R2 Domain Controllers (DC’s) in a single environment, and the Mixed mode of each of those AD versions can allow for interoperability.  Exchange Server 2010, however, cannot operate if there are components of AD/Domain Services from Server 2000 or NT.  As such, it requires that only Server 2003 or higher AD controllers exist.  This means that you must be in 2003 Native mode (or higher) to install Exchange Server 2010.

Native mode ensures that no DC’s of any version prior to the functional level can communicate with AD in this domain.  This allows software packages like Exchange Server to not have to worry about passing commands that might be incompatible with earlier versions of AD.  Additionally, some features of Exchange Server 2010 go one step further and require either 2008 Native mode or 2008 R2 Native mode to function properly, so you may be on 2003 Native and still get errors if you are attempting to enable those services.

If you get the error during the pre-flight check on the installer (or later when adding features), make sure that your AD systems are in the appropriate Native mode, instead of Mixed, and you should be just fine. Note: you will often see these modes referred to as “Legacy” and “2008 Only” or similar language.  Legacy, as the name implies, allows for earlier AD controllers to communicate.  2008 Only or 2008 R2 Only limit the DC’s to those levels and higher.

Sometimes, when it comes to Exchange Server, one word can really make all the difference.

Official versus 3rd-Party Exchange Hosting

Clients have been asking me lately about if Exchange Hosted Services (EHS) is a generic term that anyone who hosts Exchange 2007 and 2010 servers can use, or if it is specific to Microsoft?  The answer is that it could be either, but for the most part the term Exchange Hosted Services – spelled out as such – is a Microsoft product that they sell, host and maintain.

EHS is a relatively new product line from Microsoft Online Services (MOS), which has been offering workspace hosting for the rest of the Office platform for a while. You can store and share Word, Excel and other documents online and control them either personally or via a company controlled platform.  You can also rent Dynamics components and other products through the MOS program, but email was something that didn’t immediately become available.

Last year, Microsoft rolled out the ability to create an Exchange infrastructure, hosted in the cloud and based on Exchange 2010 technology.  This meant 25GB mailboxes, multiple-site resiliency for server failure events and the ability to allow centralized administrative control via the MOS consoles.  The concept has been around for quite a while, of course, but now there is a significant difference.

While any Microsoft Partner in the hosting business can host Exchange servers along with anything else, they cannot offer EHS by that name.  EHS is entirely controlled by Microsoft directly.  They own the datacenter space, control the servers, client management, billing and everything else.  Since Microsoft owns the overall experience, they have a very tight control over what features are offered, but also provide direct support for each of those features. So the trade-off is that you may get more feature sets from a 3rd-Party vendor, but not direct support via Microsoft Support Services.

3rd-Party partners cannot call their solution “Exchange Hosted Services,” at least not in those exact words.  Many partners will call their systems Hosted Exchange platforms or something along that vein, in order to differentiate.  You will probably be able to get the same level of service and redundancy, but be sure to always read the fine print.

When in doubt, ask the sales rep if the systems are hosted in Microsoft Datacenters or in independent, 3rd-Party datacenter facilities.  Only EHS is hosted in Microsoft Datacenters, and so this is an easy way to determine if you’re dealing with Microsoft’s EHS or a 3rd-Party.

Addendum:

A mea culpa is in order.  This article is not meant to give the impression that EHS is superior to 3rd-Party Hosted Exchange Servers.  Each has significant benefits and also at least some limitations, and you should explore all options before deciding which you will use for your email solutions provider.  For example, EHS is supported and managed by Microsoft, but does not give you any direct control over your Exchange Server, as you are instead leasing Exchange Services on Microsoft’s servers.

I’m a strong believer in the fact that no single solution can provide the right fit for every organization.  3rd-Party vendors (including the one I work for – see the disclaimer at the end of the blog) provide strong solutions with multiple options and feature sets.  Many also work in conjunction with Microsoft’s own products and services, so you might not have to give up one to use the other.

I’m glad this blog is part of your investigations, and I’m glad I can be part of your search for a solutions provider that includes multiple sources for reviews, features and functionality.  Always do your homework; only then can you make the best choice based on the needs of your company and the features of the various providers.

Offline Address Book Generation/Update

The OAB is used for Cached/Offline mode clients to perform lookups of contacts and other information. It is periodically updated from the Exchange Server to Outlook clients. A complete overview of how the OAB works in various versions of Exchange can be found on Microsoft TechNet by searching the sections for your specific version of Exchange.

In earlier versions of Exchange Server, a Public Folder was used to house the OAB data and distribute it. In 2007 and 2010, a web-based distribution system was put in place, with the ability to also maintain a Public Folder version in the event you have legacy Outlook (2003 SP1 or earlier) clients. While distribution of the OAB to any Outlook client is fairly automatic, the generation of the OAB for the first time may not fit into your time tables.

Usually, the OAB will update as part of the Online Maintenance Routines that occur by default every day from 1am to 3am server local time. This means that the OAB will not be generated at all until that first maintenance window, and will not be updated with new users until the first maintenance window after they are added to AD. There are several reasons why this may not work for you, but some common ones are:

- You’ve added a VIP to the AD system and management doesn’t want to wait 24 hours for the OAB to update.

- You have created a test system, and either don’t want to leave the system running overnight, or need to perform testing within the first 24 hours of the build.

- You add a large number of users to AD, and want to propagate the information to Outlook clients as quickly as possible.

In these, and other cases, you could force the Online Maintenance to occur, but that would take a significant amount of time, especially if all you want to do is update the OAB. In a production environment, performing maintenance routines during peak hours of operations can also have an impact on user experience, and so should be avoided.

To perform an immediate update of the just the OAB in Exchange Server 2007 or 2010, you can open a PowerShell command window and execute the following:

Update-OfflineAddressBook –id “Name of OAB” –verbose

Where “Name of OAB” is the name of the Offline Address Book you wish to update. Be sure to enclose it in quotes, especially if the name contains spaces. The default OAB for a new installation of Exchange is – oddly enough – “Default Offline Address Book” and you can use that name to perform the initial update on a brand new server.

If you maintain more than one OAB, or if you changed the default name, you must run the command for each OAB in your organization, replacing the name with the appropriate string each time.

The next time Outlook clients look for OAB information, they will see that the OAB has been updated, and download the appropriate changes to their local OAB copy.

Got an Exchange-related question that Mike can try to get you an answer for? Follow Mike Talon on Twitter (@TalonNYC) and send an @ mention with your question.