Planning an Exchange Server deployment is seldom easy, regardless of company size, but smaller companies typically have a tougher time of it. In addition to the usual Exchange Server deployment challenges, smaller companies often have to deal with small budgets and an IT staff that is already stretched too thin.
Furthermore, much of the deployment-related documentation for Exchange Server assumes that Exchange Server will be deployed in a huge organization; it therefore stresses a distributed deployment with lots of individual servers. These distributed deployments just aren't an option for most small, resource-strapped companies.
But there are techniques small- and medium-sized businesses (SMBs) can use when deploying Exchange Server to improve cost effectiveness and availability.
Consider all your options
If you have a really small organization, one way of saving some money is to invest in Small Business Server (SBS) rather than purchasing Windows Server 2003 and Exchange Server separately.
I admit that I've never been a big fan of Small Business Server because it requires you to run all the Microsoft server products on the same box (you don't have to install any product that you aren't planning on using). Even so, Small Business Server is ideal for some organizations.
Before you invest in Small Business Server though, you need to be aware of its limitations. For starters, SBS is only appropriate for organizations with fewer than 75 users. Technically, it allows you to have as many user accounts as you want -- but you are limited to 75 concurrent connections.
Another serious limitation is in the hardware that Small Business Server can run on. An SBS server can have a maximum of two physical processors (or four logical processors).
A traditional Exchange Server deployment
Since Small Business Server is, more or less, a self-contained Exchange Server solution, I don't want to spend too much time talking about it. Instead, I want to spend the remainder of this article talking about some deployment strategies for organizations that opt for the Standard Edition or Enterprise Edition of Exchange Server 2003.
Exchange Server performs optimally when it is deployed in a distributed manner. However, large, distributed deployments are expensive from both a hardware and software standpoint. Besides, such large and complex deployments are usually overkill for smaller organizations.
That being the case, I want to start out by talking about the smallest possible Exchange Server deployment, and work my way up to something that is a little more practical, while still being relatively cost-effective.
A tiny Exchange Server deployment
If you want to perform an absolute minimal Exchange Server deployment, you can set up a single domain controller on your network, and install Exchange Server on it. This technique does work, but it's a bad idea.
The main reason why this type of deployment isn't recommended is because you're putting all your eggs in one basket. If that server fails, not only do you lose Microsoft Exchange, but you also lose your organization's only domain controller.
I also don't recommend this type of deployment, because it tends to perform poorly. If you are running Exchange Server on your organization's only domain controller, that domain controller will also be acting as a global catalog server -- and most likely as a DNS server as well. All of these services running simultaneously can place a real strain on the server and cause performance issues.
There are a million other reasons why I don't advise placing Exchange Server on a domain controller, but I'll just mention one more here: finances.
If you are going to place Exchange Server on a domain controller, you are probably just as well off buying Small Business Server. SBS is basically a domain controller that is set up to run Microsoft server products, such as Exchange Server, but at a lower licensing cost.
A more practical Exchange Server deployment
Of all of the problems involved in deploying Exchange Server on your organization's one and only domain controller, the most serious is the issue of having a single point of failure.
Unfortunately, there is no way of totally eliminating a single point of failure without purchasing an Exchange Server cluster or some other high-availability solution. However, you can greatly reduce your chances of catastrophe by using three servers instead of one.
I recommend you install Exchange Server on a member server, rather than a domain controller. I also suggest you configure the other two servers to act as domain controllers. If one domain controller fails, the other will still be available.
Global catalogs
Exchange Server is dependent on the global catalog server, as is Windows. If fact, if your workstations can't contact a global catalog server, your users may not even be able to log in.
By default, the first domain controller that you bring online will act as a global catalog server. However, if that domain controller fails, you'll have no global catalog servers on your network. Therefore, I think that it makes sense to designate the other domain controller to act as global catalog server too.
Please keep in mind that the recommendations I am making here are only appropriate for SMBs. If you have a larger organization with more than two domain controllers, you can designate each domain controller to act as a global catalog server -- but you can really hurt performance if you do.
Each global catalog server has a certain amount of replication traffic associated with it. Having at least one global catalog server is a requirement; having two is a good idea; having more than two global catalog servers in a single domain can hurt performance on slow or congested networks.
Designating a domain controller to act as a global catalog server is simple:
- Open the Active Directory Sites and Services container.
- Navigate through the console tree to Active Directory Sites and Services -> Sites -> Default-First-Site-Name -> Servers -> your server -> NTDS Settings.
- Right click on the NTDS Settings container and select Properties.
- Select the Global Catalog checkbox and click OK.
DNS
Active Directory requires at least one DNS server on your network. If you don't already have a DNS server, Windows will automatically install the DNS services on the first domain controller brought online.
Active Directory cannot function without DNS. Likewise, Exchange Server uses DNS to resolve addresses. Even end users utilize DNS every time they access the Internet or attempt to attach to a host on your network.
Because DNS is one of your network's most critical services, it doesn't make sense to isolate it to a single server. Just as it's a good idea to configure both domain controllers to act as global catalog servers, you should configure both domain controllers to act as DNS servers. Then, if one DNS server fails, the other can pick up the slack. (Again, this only applies to SMBs with two domain controllers.)
Unfortunately, configuring a second DNS server isn't quite as easy as designating a server to act as a global catalog server. Since the DNS services aren't installed by default (except for on the first domain controller in the domain), the first step in the process is to install the DNS services onto the domain controller that needs it:
- Go to Control Panel -> Add or Remove Programs.
- Click the Add/ Remove Windows Components button.
- Select the Networking Services option from the list of available components and click the Details button.
- Select the Domain Name System (DNS) checkbox and click OK.
- Click Next and Windows will begin copying the necessary files. You may be prompted to insert your Windows Server 2003 installation CD.
- When the file copy process completes, click Finish.
Now that the DNS services are installed, you must configure them to act as a secondary DNS server for your network:
- Go to Administrative Tools -> DNS.
- Right click on the listing for your server in the DNS management console and select the "Configure a DNS Server" command to launch the Configure a DNS Server Wizard.
- Click Next to see a screen asking what type of zone you would like to create.
- Select the option to create a forward lookup zone, and click Next.
- You will now see a screen that asks which DNS server maintains your primary zone. Select the option indicating that an ISP maintains the zone and that a read-only secondary copy resides on this server. Click Next to continue.
- You will now be prompted to enter the name of the zone. In a Windows Server environment, the name of the zone is usually the same as your domain name. You can check your primary DNS server to be sure.
- Click Next, and you will be prompted to enter the IP address for the DNS server from which you want to copy the zone information. Put in the IP address for your primary DNS server and click Next.
- You will now see a screen asking if the DNS server should forward queries. That way, if the DNS server is unable to resolve a query, it can forward the query to a DNS server that is more likely to be able to resolve the query. Typically the forward address is your ISP's DNS server, since your DNS server isn't likely to be able to resolve many Internet-based domain names on its own.
- Click Next, followed by Finish.
- Now wait a few minutes and look under the new DNS server's Forward Lookup Zones to make sure that zone information has been successfully copied from your other DNS server.
You have now created a redundant DNS server. One thing to keep in mind is that none of your computers will be able to use this DNS server until you tell them they can. You must configure your DHCP server (if you have one) so that it makes clients aware of the IP address of your secondary DNS server. If you have any hosts with static IP addresses, you will have to add the secondary DNS server's IP address to the machine's TCP/IP configuration manually.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
Do you have comments on this tip? Let us know.
Related information from SearchExchange.com:
Tip: Global catalog server best practices for Exchange Server
Tip: Free open-source SMTP/POP3 email for Windows
FAQ: Exchange and Small Business Server issues
Reference Center: DNS tips and resources for Exchange administrators
Please let others know how useful this tip was via the rating scale below. Do you have a useful Exchange Server or Microsoft Outlook tip, timesaver or workaround to share? Submit it to SearchExchange.com. If we publish it, we'll send you a nifty thank-you gift.
