Your Tech Business | Technologies for a more efficient and productive business

server-web-mail-technologyYes you can install Exchange on a domain controller (DC). If you somehow found your way here from a google search while halfway through an installation and need an answer right now, then your answer is “It isn’t ideal but yes you can”.

If you were hoping for something a little more in-depth then read on …

First of all, the most obvious comment: this is indeed a Microsoft supported scenario, and in fact something they do themselves if you purchase the Small Business Server product and go with the defaults. There are countless people out there right now using Exchange installed on a Domain Controller who will never be aware of this discussion never mind how many websites it has been covered on.

Small Business Server has a couple of important considerations however, that make it an ‘edge case’ for server setups.

SBS is a compromise product. I don’t mean that in any kind of derogatory manner, but simply to say that the whole basic premise of the product is that it is providing a broad range of services to a limited amount of users.

Exchange on SBS is essentially the standard edition of Exchange, with all the limits that implies, which has an effect of rate-limiting the amount of growth and resources it can do. Microsoft’s deployment tools for SBS are written with all this in mind.

Installing Exchange and your cloud-based phone system onto a DC can be seen as a cost cutting exercise, because it obviously reduces the amount of servers you need to buy. Again, very true and correct. However, there are some considerations that you should consider when totaling up the overall cost of this choice.

Installing Exchange onto a DC introduces a number of problems, that are not apparent on a server that is lightly loaded, but which can choke a server that is heavily loaded; therefore a reasonable decision taken in the early days of a network implementation can come back to bite you later.

Both Exchange and Active Directory are based on resource hungry databases, and are serving users in time critical functions. Both systems can use large amounts of RAM; disk capacity and bandwidth; and processor time. If these processes have to compete for those resources then poor performance is your most likely outcome, and when it effects the CEO’s login times and email client behaviour, saving a bit of money might not seem as important as it used to.

You can of course attempt to over-specify your server to take this into account. The problems with this are two-fold.

I assume you hope your business will grow with your phone system – so now you’ve got to specify head room for growth in AD size, growth in Exchange size, AND extra free room for them to share resources.

The reasons for sharing a server we mentioned earlier were pretty much based on the cost of buying two servers. Remind me again how buying one big server for £8000 to share the two jobs is cheaper than buying two £2,500 servers to keep the jobs separated.

Another problem is security (you knew I’d get to that, right?)

If you want to use Exchange as a OWA or OMA web-mail server, then you’ve not only got to expose an Exchange server to the Internet, but now you’ve also got to expose a Domain Controller. Yes of course you can firewall it all off, but this simple cheap solution is suddenly getting less simple, and unless your time is worth nothing, that means it isn’t that cheap either.

Any outages that effect one service will have an impact on the other… want to patch Exchange and need to reboot? Ooops, now nobody can authenticate to anything because the DC is offline too. Want to patch your DC? I hope nobody was working on an important and lengthy email because they just lost it when you rebooted your DC.

Problems with applications that work with one service can affect the stability of the other service. For example, a faulty Exchange virus scanner would now also be in a position to upset basic network operations.

Just to drive a final nail in the coffin – lets look at operational concerns.

Sharing a server means that more services are suddenly interacting with each other. Now all of a sudden you’ve got servers that take forever to reboot.

If you ever have to do a disaster recovery of your Domain controller then guess what – your Exchange recovery skills better be up to scratch too! Hate recovering Exchange servers after a disaster? Well guess what – now you need to recovery a domain controller too – at the same time! The issue here is not that the recovery is impossible, but rather the cost of recovering one of these critical and sensitive services is compounded by having to also recover the other one at the same time.

Any DC that runs Exchange needs to be a Global Catalogue server.

Exchange server functions that would normally fail over to using different domain controllers if their preferred DC is not available will not work as expected.

So obviously, I’m pretty much against the idea. In a small business scenario with only one or two servers, it is acceptable if your choices are either to do this or go without Exchange entirely, but as an overall solution, it simply doesn’t scale.

· · ·

technology-email-systemI’m sure a few people have seen this happen: A small business starts and decides it needs an Internet presence, and contracts with an ISP to provide a basic connection to the Internet, some space for a webpage, and a few accounts for employees held on the ISP’s email system.

One day, this business will hopefully expand to the point where it needs more sophisticated messaging than this sort of setup offers, so what do you do if this happens to you?

Firstly, what exactly are your email/messaging needs? You need to consider several things when picking where to go next, probably including some of the things on the list below.

  • Do you need to exchange a lot of internal mail?
  • Do you want sales and customer services people to be able to record email exchanges with customers?
  • Do you have a statutory requirement to record communications with customers or even a statutory requirement for controlling the storage and disposal of these emails?
  • Do your staff need to access emails both in the office and “on the road”?
  • Do you need to integrate other things such as calendars and contact management into your work?

We’re using Exchange which offers all the above features very nicely (along with several others). However, it only makes sense to go for a sophisticated product like this or Lotus Notes if you intend to use these “extended” features that such a product offers.

I know a few places using this server very happily. There is a large number of open source mail email server type things out there that all work pretty good. Open Exchange looks like fun if you’ve got the time to spend on it.

So we’ll assume you’ve chosen an email server product, and set it up on a computer on your local network. Now you need to decide how email reaches you from the outside world. You can have your ISP “Store and Forward” email for you, or you can connect an email “gateway” to the internet directly and let this talk to servers on the internet.

The main advantage of the “store and forward” approach is that it works for a company that doesn’t want to have a permanent connection, and the main advantage of the direct connection is simplicity.

In either case, and in the interests of keeping this post to a manageable length, lets assume you can get the email from the internet onto your server.

Next you have to consider how your users will connect to their email on this server.

  • Use a POP3 client, transferring the emails off the server and onto the client’s account area. (I’m not a fan of this approach for any kind of business to be honest)
  • Use an IMAP system (or MAPI of course if you go for Exchange) that keeps email on the server
  • Use a webmail client
  • Combine option “2” with option “3” for a flexible email system that lets users manage their email with a full and powerful system when at work, and still be able to check messages and do bits and pieces when elsewhere.

POP Clients

POP3 clients are simple, and are what most people who might already have used the Internet at home or in a very small business will be used to. POP3 clients typically pull email down from the server and store it on the user’s computer (or user’s network drive or whatever), which makes managing email retention, logging and disposal a nightmare, but is very simple to set up and ensures you don’t need to spend a lot of money on the email server.

IMAP (and MAPI) Clients

IMAP clients leave email on the server and provide a view to the server to allow users to work with their email. As the email is actually stored on the server, it is easy to monitor and manage how emails are used and stored. As such, this approach is one I would describe as mandatory for a business with statutory requirements of any kind in this area.

Many of the more sophisticated servers of this kind also allow you to save space on message storage using a method that Microsoft refer to as Single Instance Storage, but which I’ve also seen other products using.

Webmail Clients

As you can imagine, webmail very much relies on leaving the email on the server, and all the “server-side” advantages that I mentioned before for the IMAP/MAPI approach also benefit here.

Webmail also has the benefits of very easy client deployment and setup (every OS comes with a web browser these days right?) and of allowing anyone with an Internet connection to get their mail from anywhere in the world.

Webmail suffers from underpowered clients. A web browser is not a good application interface, and any webmail client will typically be less capable, or at least slower and much more clumsy, than any “real” email application.

IMAP and Webmail

The power and advantages of a “real” email application in the office. The ease of getting your email from anywhere in the world you can find the Internet that webmail brings.

· · ·

<< Latest posts