Sometimes Microsoft products can be misleading. To install one, or so it seems, all you need to do is run the setup program and press “Next” until the whole thing is over. However, there are a few considerations that should be taken into account when setting up the first Exchange server. There are IP addresses, naming schemes; there is that Active directory part, hardware considerations, Anti-virus protection and more. With a few pointers you can install your own Exchange server and rely on phone support for special issues that should not occur if you plan and execute well.
As you might have heard by now, Exchange relies on Active Directory. This means that users, groups and even the Exchange configuration itself is stored in Active Directory.
The server holding Active Directory is appropriately called a Domain Controller. Exchange can be installed on a domain controller. However, for redundancy, you might consider installing two domain controllers, separate from Exchange. Domain controllers require a reboot from time to time, so when you have two of them, separate from Exchange, you can do so without interrupting service to clients.
So, what is a Active Directory? Basically it’s a database, just like Exchange, actually built on the same technology. Some small businesses will start using Active Directory for the first time when they implement Exchange. Previously, they had been working in a “Workgroup” where each computer has it’s own security mechanism. Once Active Directory is implemented in order to make way for Exchange, all computers start using a central authentication system. This means that when you login to your Windows, you enter a username and password that is stored on the Active Directory domain controller. Active Directory can also store all kinds of information about you, and you can setup groups to implement permissions on files, database and other objects.
Once Exchange is installed, more attributes are added to Active Directory. This is referred to as “Extending the schema”. This means that Exchange attributes can now be assigned to a user such as e-mail addresses, location of a user’s mailbox, etc.
As an Exchange admin you should always worry about Active Directory. A lot of Exchange problems are a direct result of domain controller errors. Exchange actually uses only domain controllers that are global catalog servers for some functions. You should make sure that all the domain controllers are global catalog servers. Otherwise you might find that a problem with your first domain controller which is a global catalog server by default will cause Exchange not to service users anymore.
Global Catalog Server
By default, the first domain controller becomes a global catalog server. To set more global catalog servers:
- Click Start, click Administrative Tools, and then click Active Directory Sites and Services.
- Double-click Sites, expand Servers, and then select your domain controller.
- Double-click the domain controller to expand the server contents.
- Below the server, an NTDS Settings object is displayed. Right-click the object, and then click Properties.
- On the General tab, make sure that the Global Catalog check box is selected (this is the default setting).
Though a restart is not a requirement anymore with Windows 2003, it is my recommendation that you still perform a reboot of the domain controller.
Beware that sometimes Exchange information replicates slowly from one domain controller to another so when setting up a mailbox for a user or change a group member you need to wait for replication to occur or replicate it yourself.
Computers on the Internet (or hosts as they are called) use DNS servers to locate servers. If you, for example, want to locate www.msexchange.org because you want to browse it’s web server, you will approach your Internet provider’s DNS server and it will search for this server by either using its cache or by querying a root server for the “org” domains list and from there to the server responsible for the “msexchange.org” domain which hosts the “www” server, or several servers that answer collectively as “www”.
Microsoft decided to use this technology with Active Directory. In an Active Directory domain clients will have to use local DNS servers instead of the ISP servers to resolve local server names. Active Directory also hosts special records called “SRV records” for finding various services such as Global Catalog servers.
The best configuration is that you setup an Active Directory-integrated DNS and have clients DNS list point to the first, then the second domain controller, and then perhaps as a last resort, the ISP DNS. This means that a failure of a single domain controller will still allow you to use Exchange services, and a failure of two domain controllers will allow you to browse the Internet.
A domain controller should have a DNS client list as follows: Itself, the other domain controller and the ISP DNS.
To complicate matters further, you can have a separate Internet domain (msexchage.org) and an internal one (msexchange.local). This is actually the recommended configuration as it simplifies name resolution issues when you have some servers, such as your web server hosted outside your internal network. Make sure that your internal domain name is not one that is used on the Internet. Every few years new domain suffixes are added (.biz, for example), so using “[domain name].local” is considered a safe bet for a local Active Directory domain name.
At this point you should decide on an IP addressing scheme. Most businesses these days use a separate internal and external IP addressing. The Internet provider assigns you an external, public Internet IP address. Internally, however, you will use one the private IP schemes.
The most common internal IP range for small companies is 192.168.0.0/16. You can use subnet mask 255.255.255.0 if you require less than 254 IP addresses or 255.255.0.0 if you need more in a single network. All these IP addresses will be translated on the Internet to one IP address, the one assigned to you by your Internet provider.
You should assign a range for servers, for example, 192.168.0.0-192.168.0.10 that will not be used by DHCP (which automatically assigns IP Addresses) or by manually assigned workstations.
You might require one more public IP address to represent your Exchange server on the Internet. The router or Firewall (shown below) will translate your public IP address to the internal one and forward communications from the internet to your Exchange server.
Alternatively you can have your router or Firewall redirect all incoming mail traffic (port 25) and possibly Outlook Web Access traffic (port 443) to your internal Exchange server. This means that the Internet DNS servers will point you to the router IP address and it will forward all relevant queries to the internal Exchange server which will no longer require an external IP address.
A typical Exchange server with no port re-direction implemented will answer to an internal IP address (such as 192.168.0.2) and externally to a valid Internet IP address (such as 184.108.40.206).
Some organizations might choose to implement a “mail relay” which accepts incoming mail and scans it for viruses, spam, etc. This server will also face all kinds of Internet attacks. This is a very good option for medium to large organizations but for small offices I would recommend using a good Firewall to fend Internet attacks, perhaps even weed out viruses and spam and not install a separate server.
In case you do implement a mail relay, Exchange will still need a public IP address if you intend to publish Outlook Web Access on the Internet, unless you implement an Exchange front-end server which answers HTTPS calls and forwards them to your internal Exchange server.
Again, for small organizations, implementing a front-end server could be a waste of money and time that could otherwise be invested in other solutions that can improve your security such as a better Firewall.
Externally, you can call your mail server whatever you like, though “mail” is quite common. The internal name does not need to have any resemblance to the external one. The external name, after all is resolved by Internet DNS servers and the internal one is resolved by the internal DNS servers.
Some “security experts” recommend a vague name for your Exchange server such as a color (“Red”), a planet (“Venus”) or a complex name (“b2xxxrl3”). This supposedly meant to disguise the true nature of your server so that attackers will not find right away that your server is a domain controller or an Exchange server. However, most hackers and even viruses or Trojan horses will typically scan your machine for ports rather than look at its name.
My recommendation is to keep names simple and obvious. Remember that that you will need to configure a few Outlook servers and enter you Exchange name a few hundred times during your Exchange admin career. Worse, sometimes users will need to enter their own configurations, so the simpler the better. Names like “Exchange”, “Mail”, “DC1” and “DC2” are preferred.
Exchange 2003 basically requires a server with at least 512MB though 1GB or more is recommended.
CPU is always an issue, but most servers and even workstations have enough CPU horsepower for Exchange if you’re not loading your server with anything else that is CPU intensive. Exchange supports hyperthreading feature available with Pentium 4 and other CPUs. If you need more CPU power you can use Intel Xeon which can offer you more cache and multiple CPU support.
Today, 64-Bit support is available in some CPUs but is Not supported by Exchange 2003 and will only be available with the next version of Exchange, E12.
Disk configuration is a complex issue and is covered in my article:
To make a long story short, today, you can choose either SATA disks for lower end Exchange servers or SCSI disks if you can afford it. SATA disks can give you more disk space for less money but are generally slower though by far better than ATA (IDE) disks. You will need some form of disk redundancy (RAID) so disk failure will not bring you down. Hardware based RAID is recommended in most cases.
When planning for disk space it is best to leave room for a bit more than double the disk space expected for the Exchange databases. 32GB or more for the Exchange database partition is recommended for Exchange Standard edition.
Backup, Viruses, SPAM
You cannot have an Exchange server without some extra components that you might need to purchase separately. Windows 2003 has its own backup utility that can backup Exchange 2003 and IMF can be freely installed on Exchange 2003 to prevent junk e-mail (SPAM) but you will definitely need to purchase some sort of an Exchange-specific anti-virus even if you have some sort of perimeter level anti-virus protection, because some viruses might come from within.
Make sure that your Exchange server is backed up daily and that your backup tapes are placed in a fireproof safe. You should also buy new tapes on a regular basis so that your tapes are not worn to a degree that makes them unusable.
IMF is not the most advanced junk e-mail filter though it is going to be improved in upcoming service packs and Exchange versions. You can buy a commercial product but make sure that it lets users manage their own filtering options so users don’t have to turn to you every time an e-mail is quarantined because your junk e-mail filter found it to be suspect.
A solid anti-virus package doesn’t hog your CPU and allows you to filter file types by extension which is typically less CPU intensive than going over virus signatures for every attachment. It should be updated on a daily basis or more since virus outbreaks can sometimes be violent and quick. Some anti-virus packages now have a way to determine whether an e-mail item contains an unknown virus.
It is difficult to test an anti-virus package for Exchange in a lab, so your best bet is to ask around or search the Internet for recommendations before getting one.
The information presented in this article is just the tip of the iceberg when it comes to the different aspects of Exchange. It does give the big picture, and MSExchange.org is frequently updated with in-depth articles for every aspect of Exchange.
As the article shows, planning for an implementation of a single Exchange server is not that difficult once you separate fact from myth and understand the basic architecture.