Microsoft Exchange and Remote Desktop Services Specialists


Microsoft Exchange Server and
Blackberry Enterprise Server news, views and fixes.

Hardware Configuration for Exchange 2003

Despite Exchange 200x being around for over seven years, the question of hardware configuration is still frequently asked and discussed on forums and message boards around the internet.

Exchange is a high transactional database, which means it is constantly writing to its hard disks. Therefore, when you are considering what hardware to purchase for Exchange, you need to remember that you get the best performance from Exchange by prioritising its storage needs.

From a processing power point of view, you can large numbers of users on low end hardware. A single processor with a 1 gb of RAM will support 100s of users on a dedicated machine.

If you have one eye on a possible Exchange 2007 deployment later on, then get the smallest number of RAM modules that you can afford, so that you can put more RAM in place later. Although remember that you cannot in place upgrade to Exchange 2007, so you will need another machine to do a swing migration.

Also remember that Exchange 2007 is 64 bit only, but Exchange 2003 doesn't install on to 64 bit. Therefore you could purchase a machine with a Windows 2003 64 bit license, but you would need a 32 bit media kit to install Windows for use with Exchange 2003.

The rules with hardware selection on Exchange 2007 will change anyway, as it is 64 bit and can make better use of more processing power and memory. Despite these advances in the use of the processor and memory, the storage configuration outlined here will still be valid with Exchange 2007.

Array Selection

At a minimum, even with a small number of users, you should be looking to use at least two arrays.

- A mirrored array of two disks for the OS, application files and logs.
- A RAID 5 array of at least three disks for the database.

If you have a machine that can take six disks, then another disk as a hot spare can ensure that the server is able to run at optimum levels most of the time.

Remember that hard disks will fail, it is just a matter of when.

Partitioning the Disks

Partition wise, the mirrored array would be split. Usually 20gb and then the rest. So if you have 72gb of space you would have a 52gb second partition.
The transaction logs would then go in to a folder on this partition.

The files go in to a folder on the partition rather writing to the root of the partition for a number of reasons.
- it makes it easy to keep track of what they are
- it ensures that the server keeps running - Windows doesn't like lots of files in its root.
- it allows you to put something else on to this partition. I often share it with the message tracking logs.

Why partition the drive?
Partitioning isn't done for performance reasons, but for data protection.
If something happens, for example a mail loop or some kind of attack, the transaction logs will grow very quickly, using all the space that is available.
By having a restriction on the drive, there will be a point where no more logs can be written. At that point Exchange will dismount the stores.
However, the machine will still be running, giving you access to troubleshoot the problem.
If the logs had been on the same partition as the OS, then you may have a crashed server as well to deal with. Windows doesn't like having no free hard disk space.

The other array for the database would be a single partition.

More Disks Means No Partitions

If you have the budget, then go for something that can take at least eight disks.

2x mirrored OS
2x mirrored transaction logs
3x RAID 5 database
Hot spare.

If you are on Enterprise edition, then you can further increase the performance by having multiple arrays - with each array housing a separate storage group or mailbox store. The bottleneck at that point would then be the drives housing the transaction logs. At that point you could even go as far as having two arrays for each storage group - one for the database and one for its logs. It all depends on what your budget is like.

What about disk space?

The disk space required for the OS and transaction logs isn't really an issue. The smallest drives you easily purchase now are 72gb, which will be fine for a combined OS/Logs array or for separate arrays for the OS and logs.

The database array provides much more scope and very much depends on which version of Exchange you are installing.

If you are installing Enterprise edition, which is theoretically unlimited in storage space, then you need to make a guess at how much space you will need. If you already have Exchange, look at your current store size, double it and add at least 30%. If you have the users mailbox sizes restricted, then your life is a little easier as you can ask HR for a predicated population growth. However you are still taking an educated guess.

If you are installing Standard edition of Exchange 2003, then things are much easier, as there is a hard limit.
Standard edition of Exchange 2003 with Service Pack 2 can support up to 75gb in the mailbox store and the public folder store. This gives you a maximum use of 150gb.
Allowing for the use of the recovery storage group, recovering a store at the maximum size you would need another 75gb.
While Public Folders cannot use the RSG you should probably allow enough space for them to be recovered as well, meaning a total capacity of around 300gb.
Therefore 3x 146gb drives would be enough (giving you about 250gb of space) or if available, three 300gb drives.


Don't forget to purchase a good fast RAID card. If you have decided to make the investment in the storage, then ensure that the RAID card is up to the job. Don't put a small 64mb RAID card in and hope it will support your large database and high transactions. At least a 128mb RAID card and if your budget will take it, go for something even faster. You should aim to get the data to the disks as quickly as possible.


When faced with a choice between RAM/Processor and storage, storage wins every time. That is where the most can be gained from the investment on an Exchange server.

Why you shouldn't use a POP3 Connector

There are so many reasons why you shouldn't use a POP3 connector on an Exchange server that it is difficult to know where to start.
I don't simply mean the POP3 Connector supplied with Small Business Server, but any third party POP3 Connector. They all have the same issues.

With the correct choice of services and configuration, there is almost no reason why a POP3 connector should be used as part of the deployment of Exchange.

POP3 is a client to server protocol. Designed for pulling email from the server for storage in the client. Exchange is not a POP3 client. All that the POP3 connector does is pull the email down, then place it in to the SMTP queue for delivery to the end users.

With the SBS POP3 Connector, that is done at 15 minute intervals.

I have outlined the most common arguments for using the POP3 connector below and why they don't make a very good case.
Then I have outlined the major benefits of using SMTP delivery.

I may well update this article in the future, so if you are using the RSS feed and it comes up again, then that is why.

Common Arguments for using the POP3 Connector.

I don't have a static IP address.

Not having a static IP address is not a hurdle for hosting your own email.
Simply use one of the dynamic DNS services to map a dynamic DNS to your MX record host, or just use the dynamic DNS address host in your MX records.
You will need to put a tool on to the server to keep the dynamic DNS address active, but there are lots around.

My ISP blocks port 25.

If you are running Exchange on a "residential" connection, or the ISP wants you to upgrade to a business class connection that costs many times the normal amount for basically the same service, then you may find that port 25 is blocked.
For outbound email you can use an SMTP Connector.
For inbound email, simply subscribe to one of the mail hop services. These services provide you with hosts that you put in to your MX records and will receive email for you. They then forward the email to you on an alternative port that is not being blocked.
Furthermore, in the event of a failure of your server or internet connection, these services will queue the email for you, which also deals with the "protection" reason (see below).

It provides "protection" in case the server goes down.

One of the most common reasons that people want to use the POP3 connector is because of the protection that is provides for them in case the server goes down.
This is often the reason given by people who don't understand the way that email and SMTP delivery works on the internet.

You should have complete control over your email at all times.
In fact, you should have control over all aspects of your internet service.

What happens if your ISP goes bust? It happens. Not as often as it once did, but it does happen.
If you are using a dedicated web hosting company, then they are more likely to go bust than regular ISPs, because the hosting market is so competitive. (I can rent a dedicated server for UK£45 a month - on that I could get 100 web sites very easily).

You have an disagreement over a bill with your ISP. They cut off access to your email until you pay the bill - holding you to ransom. 

You should have the email delivered to your server at all times, using SMTP. That is what Exchange is designed to do.

However, many people will see that the Exchange server is a single point of failure for email delivery. Unless you pay out for additional services and applications, that will be a factor for most companies.
You also have the internet connection - that is often a single point of failure as well.

SMTP email has some protection built in. Most servers are configured to attempt to deliver email for 48 hours before giving up. If email is that critical to your business, then you will not wait 48 hours before getting some kind of email service. Where hardware is available, I can have a server back running in around four to six hours. It may not have the old information available to the users, but what most companies want is new email, the old content can wait a bit longer.

If hardware isn't available, then you can use an alternative email service, collect the email with POP3 and then import it back in to Outlook. That can be fixed up in around 30 minutes, with just clients to configure.

If you are in a larger site with multiple servers, then it probably doesn't apply as you will be able to make internal arrangements.

My mention of POP3 in the previous paragraphs doesn't mean using the ISPs POP3 service, or supports the use of the POP3 connector.

How can you protect yourself?

The biggest problem with making alternative arrangements is the DNS propagation time. It takes 48 hours for DNS changes to fully propagate round the Internet. Therefore if you were to rely on replacement DNS changes, you would loose email.

The trick that I like to use is to use a second MX record and a dynamic DNS service provider.
The dynamic DNS entry is pointed at your existing IP address - so you have two MX records pointing at the same location:

MX value: 10
MX value: 50 Type: A Value: Type A: Value

Note that two hosts have been used, not a alias to the original host.
While this does break the official best practises for MX records in having two records pointing at the same host (which will be flagged if you use for example), in operation it has no effect.

In the event of a failure, the original lowest value MX record is no longer responding. The sending servers will try the higher value MX record - which at the point of failure also isn't responding.

Simply change the IP ADDRESS on the dynamic DNS record to point to your alternative server or internet connection. No other changes are required, and email will begin to flow very shortly afterwards.
You haven't got to wait for DNS changes to propagate, because they are already there. The dynamic DNS services have setup their service so that host changes are reflected around the internet very quickly.

Once the original server has been fixed, change the entry back again and email to the alternative server or IP address will very quickly dry up.

Why not use a Backup MX Service?

You may have seen advertised backup MX services. This is where another server is configured in your MX records to accept email for your domain - using similar values to my example above.

The reason not to use backup MX services is quite simple.
In most cases it is only spammers who will use the second (higher value) MX record to send email. The theory being that the backup record is not so heavily protected against spam.

One of the most effective ways to deal with bandwidth use by spam and virus carrying messages is to simply refuse delivery for users who are unknown on your server.
This feature works by rejecting the message at the SMTP stage, before the message has been delivered. In a small site it is very effective.

If you are using a backup MX server, then you will probably be unable to use that feature, because the backup server has already accepted the message. Attempting to refuse delivery of the message will cause the messages to queue on the ISPs server as they are trying to bounce the message back to the "sender". In most cases the sender of the spam is spoofed and doesn't exist.

My ISP / Web Host doesn't provide an SMTP feed.
That excuse is one that is regularly heard. You don't need an SMTP feed to host your own email. That excuse often comes from the ISP / host, who just want control over everything. They recognise that you could be using your own email server, and want to ensure that you have a level of reliance on their service. They may even be charging you on a per mailbox basis, and don't want to see their revenue stream removed.

To have email delivered to your email server, all you need to do is get your MX records configured to point at your server instead of theirs. If they will not change the MX records, then transfer the domain to a domain name registrar where you have complete control. You can continue to use the ISP/host for hosting the web site (despite what they may say).

I have users who need to collect email from outside by POP3.
If you have any kind of permanent connection to the Internet, then they should be collecting email from the Exchange server. Configuring a domain and Exchange server to share a domain with another email server is problematic and an administrative overhead you could probably do without. It can be done, and is documented on the MS KB but I wouldn't advise it.

If you are on Windows 2003/Exchange 2003 or SBS 2003 then remote users should be configured to use RPC over HTTPS. This gives the user the Exchange feature set, without requiring a VPN. It just needs an Internet connection.

I don't have a permanent internet connection.
Of the main reasons for using a POP3 connector, this one is probably the only reason for using it for some sites. It is probably the ONLY reason I would deploy the POP3 connector, and that would be only after all other alternatives have been investigated an found not to be available.
However you still don't have to use the POP3 connector.
Use an ISP that supports ETRN collection. This is effectively "SMTP on Demand". The Exchange server connects to the Internet and then sends the ETRN server a command to say that it is ready to receive email, and the ETRN server then delivers it. You get most of the benefits of the SMTP type delivery, but without the hassles of POP3 collection.

The CEO wants to import his personal email in to his Exchange mailbox.
This reason has started to become more frequent with the increasing amount of space available in web mail services. There is no technical reason why this is a bad idea. Depending on the relationship you have with the staff member who requests it, you may not have any other choice.

However the best counter-argument for this reason is the loss of privacy. It is personal email. Once it has been imported in to Exchange, it becomes business content. It will be backed up and could be read by anyone else once the staff member has left the company.

Does that email have a place going through company systems?

I am also very suspicious of someone using personal email for business purposes. Why would they want to mix personal and business email up. The main reason is so that they can remain in touch once the business email is no longer available. Or perhaps they don't trust business email or are hiding something.

Benefits of SMTP Email Delivery

If you are currently on a POP3 connector, then why should you switch to SMTP delivery?

It is How Exchange is designed to work.
Exchange was built around the SMTP protocol, and is designed to work with SMTP.

Almost Instant Email Delivery
Most POP3 connectors will only collect email at most every minute, and the SBS POP3 Connector at 15 minute intervals.

As a consultant, one of the easiest ways for me to look good is to ditch the POP3 connector and switch the client to SMTP. The users see an immediate benefit as email is delivered shortly after it is sent - not when the server decides to collect it.

Add and Remove Users easily
You can simply add and remove users, email accounts, distribution lists to the server without having to worry about the configuration of the POP3 account. If you have named mailboxes with the ISP, then you don't need to configure those either.
If you are using a "Catch All" type mailbox, then you have bigger problems which can be solved by using SMTP delivery

The most effective anti spam measures are based on SMTP delivery
If you want to effectively deal with spam, then you need to block it at the point of delivery. With a POP3 connector you cannot do that, as it has already been "delivered" - to your ISPs server. If you attempt to block the message after that point your ISP will probably make you stop and insist that you download all the email that is waiting for you.

If you are using a "catch all" email account, which POP3 connectors, do, you will be bringing down spam messages with your legitimate email. As the sender of the spam messages is more often than not spoofed, your server will be unable to bounce the message and the messages will either queue or have to be dropped. This is a waste of bandwidth.

The two most effective methods of dealing with the major of spam messages are filtering unknown users ( and grey listing ( .
Both of those require the email to be delivered directly so that the messages can be blocked.
Those measures are also effective against many of the email virus threats.

Remote Sites Know the Message Has Been Delivered
When you have your email delivered directly, remote sites can check their logs to see that the message has been correctly delivered to your server.

Experiences with Grey Listing

I have heard from many sources that grey listing can be an effective weapon for fighting spam, yet hadn't had an opportunity to try it out.

However one of my clients was being hammered hard with spam, with 700+ messages a day being filtered by Intelligent Message Filter, and lots of messages getting past "I Hate Spam" from Sunbelt Software. Therefore I thought they would be a good site to test the method with.

I installed Vamsoft's ORF ( on to the gateway machine and left it to get on with it, enabling just the grey listing and the automatic white list* feature.

* The automatic white list is built by watching outbound email and recording the email address used. When the external recipient replies, the message comes straight back in as the server then knows that the email address is legitimate.

The effect was immediate and noticeable. I watched the logs of the application very carefully to ensure that no legitimate email was being blocked. The amount of spam that was blocked by the application was considerable. After a running a week, the application reported that over 85% of all email that was being received was spam.

That doesn't count messages that were dropped by the filter on unknown users (

The process isn't 100% effective, IMF was still catching some messages - but this was down to 20 or 30 a day, a massive reduction in the pre-grey listing number.
Users were also reporting that a few items were reaching their inboxes, but nothing like the level they had been receiving.

I have since deployed the application on four other sites, including my own Exchange server and seen similar significant drops in the number of spam messages being received.

As with user filtering, this technique also saves the bandwidth, as the messages are not even delivered to your server, so don't have to be processed.

The Vamsoft product works with any IIS SMTP mail server, so if you have Exchange 2000 then you can use it as well. It also features Active Directory filtering, which Exchange 2003 has built in, allowing users of the older version of Exchange to benefit.

How Does It Work?

Grey Listing is very simple idea.

A server attempts to deliver the message to the server. If the server hasn't received an email from that sender before, then it rejects the message with a temporary failure.

The systems that spammers use don't care about failure messages. They aren't interested in the failure and will therefore not try again. Spammers want to drop and run, before any system blocks the IP address that they are sending their email messages from.

However a legitimate email server will try again. Most email servers will try again for up to 48 hours, so you will get the email message eventually.

Are there any risks?

Any anti spam technique comes with risks. Unless you have a human looking at every message, you are relying on the computer making the decision whether the message is spam or not.

This technique will introduce a delay for new email messages - I have seen the delay as short as 90 seconds up to 20 minutes or more. If your business cannot tolerate any delay in email message delivery then this technique is not for you.

I have also seen a few email messages fail to be delivered from some sites that generate large amounts of email - such as eBay and a few ISPs. This is because each message appears to come from a different IP address in their server cluster.
With eBay, white listing their domain isn't advised as that will also allow in phishing emails.


While spammers don't comply with the RFC on SMTP email delivery and try just the once to deliver their email messages, this technique will be an effective first strike weapon in the war on spam. It shouldn't be considered the only weapon, but combined with other techniques can make spam more manageable.

Disappearing Blog

If you have visited this site in the last couple of days, you may have received odd HTTP error messages. This blog "disappeared".
On Wednesday (23rd) afternoon, the server that hosted this blog, along with the amset web sites suffered a hardware failure. It was the worst kind of failure for a web server - the hard disk.
The hosting company replaced the machine quickly and I was able to get the amset web sites running around six hours later.
Unfortunately the blog had to wait as it required more work, including configuring Community Server to operate in the way that I liked.
I have now completed the configuration and am in the process of populating the blog with my old articles.
I kept a copy of the articles offline on my home system, along with original publishing dates so I can easily restore the content.
I also took the opportunity to update the server to the latest release of Community Server.
For those of you reading this through RSS, I apologise for the number of "new" articles that you have seen popup. That was me repopulating the blog and couldn't be helped.

Internet Service Separation

One of the tactics I have been using with my clients for many years is something I call internet service separation.
This is where I use different providers for different aspects of the internet service that the client needs. 
This doesn't go down well with many internet companies (whether this is Internet service providers, web hosts etc). They like to have control over everything, get you to use their service for everything etc.
This isn't for your benefit despite what they may say in their sales brochures. It is for their benefit as it makes it much more difficult to leave them. You have to juggle all of the services being disconnected at the same time. For many people, especially those who don't understand how the internet works, they will not want the hassle. It is that reluctance to move that allows companies to get away with poor service.
You should have different companies for the following tasks:

  • Domain Registration.
    Use a specialist such as here in the UK, or Go Daddy or in the US. Don't use them for anything else (despite what they might tempt you with).
    Use a big provider, which limits the chances of them going down. Although most of the domain name registrars are actually using the services of one of the others, so in the event of a failure you may be able to rescue the domain name. 
  • Internet connection.
    This should come from a service provider who gives you the best deal. Unless you are on a managed service, use your own kit. Routers etc, so that you have control.
    The only thing they should be giving you is IP addresses. Everything else should come from other suppliers
  • Web Hosting.
    This should be with a dedicated host. The web hosting market is so competitive that the choice is endless.
    Try to steer clear from free web hosts - the old adage of "get what you pay for".
    However you don't have to pay over the odds for hosting - especially if the site is a simple static brochure type site. 
  • Email.
    Ideally you should be using your own email server. I am an Exchange specialist and this posting is from an Exchange server point of view. 
    Although, if you have more than five or six staff, you are getting to the point where you can justify your own server. This doesn't have to be Exchange - there are many low end options that will provide you with in-house email services without the complexity of Exchange.  

Your Domain Name
The thing that internet service companies all want is to get control of domain name. Preferably transferred to their own domain name registrar, or in to the master account at their pet domain name registrar if they aren't one already.
As that is your company identity, you don't want to loose it. Once they have control over the domain name, they can effectively hold you to ransom.
Resisting attempts to gain control over your domain name is very difficult, and trying to get hosting companies to comply with something else can be a challenge. They can do it - they just don't want to - as there is nothing in it for them.
I have even had companies say that they cannot do what I need them to do - which is a outright lie. Very shortly afterwards they will usually lose the business. For one UK ISP this meant a loss of over £20k in annual revenue as I took a large number of home user accounts, a leased line and other services away as well - I actually had an account manager on the phone begging to be given another chance and crying when they found out.

Despite what any web hosting company, ISP or whoever states - you do NOT have to transfer your domain name to them to use their service.

A domain name transfer is just a way of getting control and also earning themselves some more money from the transfer fee. 
All you need to do is ask them for their name servers, ask them to put your domain name in to their name servers, then enter the name servers in to the relevant option at the domain name registrar.
You have maintain complete control. In the event that you want to move your web site to another host, then you just need to change the name servers. The hosting company doesn't need to know anything about it. I have changed hosts many times, and the first the old company knows about it is when I ask to terminate their service. At that point I am not using them for anything, so if they cut me off immediately, it doesn't impact my web sites in any way.
If you do change the name servers, then you need to use the web hosting company to manage your DNS. Make sure that you have the correct entries in place first.

A better option is not even use their name servers.

Ask for the IP address of the web site and enter that in to your DNS at your domain name registrar. This is often a good idea when you are hosting your own email, as it is not uncommon for web hosts or ISPs to "reset" their DNS records which set the MX records back to their email servers rather than yours.
Protect the domain name like you would any other asset of the company. Make sure that you do whatever it takes to ensure that it remains under your control at all times.