Tuesday, November 11, 2008

Why we should not install Exchange on Domain Controllers

This post below is from TechNet and to me it is very interesting and has a great value. It seems to be the case for installing Exchange on a domain controllers happening time to time and making me say all the times

No, No, No (- :, same way around I most often get upset to see another application on the domain controllers and yes I do know Microsoft gives you everything and tell you install it Small business servers makes me always say

no no no, please (-: don't do it.

The point is for those of you work in enterprise environment will know the best practice is to dedicate separate resources for any server and off course it cost more $$$$.

Anyways, some of the basic troubleshooting skill and knowing some the trash holds for exchange and outlook is the key to identify the bottlenecks and performance related issues which is addressed in this article

Here is the situation:

The domain controller was configured by somebody else, w2k3 with all Sp's. I had to install exchange 2003 on that server.

The installation went fine, and exchange is working perfect ....BUT The webmail is working fine, but the communication between exchange and

Outlook is a problem. When I configure outlook to use exchange, and when I click on 'check name',

the DNS resolving is already slow, but it resolves .... . Then, when I want to start outlook it says (on all clients) that there is no communication possible with the Exchange server and outlook shuts down


Thomas, this is going to be third time you will hear the same thing (-: installing exchange on a domain controller is *** no, no, no for many reasons, obvious one is the performance and unhappy clients and more work for you. Complicating scenarios in such will make clients and business suffer in my opinion.

Anyway the way Exchange application is build by design, will consume all memory resources for instance ( Store.exe) and will let even your OS ( windows 2003) or your DC's Lsas.exe not being so happy up front may cause replication problems and lookup problems and performance problem soon or later.

For future references please do not install exchange on a domain controller "Since domain controllers busy they authenticate users, they deal with (.dit) database and they don't like sharing their resources with any other applications as well as exchange.

In your case they even do more, they are GCs, WINS and who knows if you have other services turned on.

Now for your outlook slowness problem let's focus on the statement you made

"Communication between exchange and Outlook is a problem."

When you configure exchange for a client from outlook for the name of your exchange servers and client name window on the setup, you can put there the name of your domain controller instead of your exchange server.

This will trigger quick look up for the user mailbox location process the request will go to AD database and locate the user object, and the attribute called "ExchangeHomeDB" will be located and the name of the exchange server will be placed into the outlook setup quickly.

Before I speculate more the problem can you please post some of the event logs from your exchange server (application logs) if there is anything interesting.

General questions I would ask

Does outlook client closes up on all the workstations? Try multiple workstations and make sure this is not client side issue as wrong link speed on the NIC, or bad switch etc.

Open outlook from one of the client with outlook /RPCdiag and observe the window to see where outlook application is trying to connect?

As it was suggested before since you have the exchange and DC/GC on the same box this will generate stress on the DC and exchange lookup ups might be the problem, poor performance from DC/GC to the exchange will cause slowness.

Are you seeing any errors " Outlook is retrieving data from exchange server" the famous Christmas Balloon

Check this article it might give you an idea how outlook works



The server that Outlook queries for this information is either a "Microsoft Exchange Server" or "Global catalog server" which is same box in your case

If the server name appears as a NetBIOS name, the data is being retrieved from an Exchange Server computer. If the server name appears as a fully qualified domain name (FQDN), the data is being retrieved from a global catalog server.

You may have to turn on some of the performance counter on the exchange server to indentify the bottleneck

On the bottom of this article

Troubleshoot performance issues

Physical disk (all instance)

  • Avg Disk Sec/Read
  • Avg Disk Sec/Write
  • Current Disk Queue Length


  • MSExchangeIS
  • RPC Averaged Latency
  • RPC Requests
  • RPC Operations/Sec


Typically, it is a good idea for the RPC Requests counter to be lower than 10.

If it is higher than 25, this is an indicator of a resource bottleneck.

Only 100 requests can be handled at the same time.

If the RPC Requests reach 100, the client will experience refused connections

The recommended values for the Avg Disk Sec/Read counter and for the Avg Disk Sec/Write disk counter are as follows:

  • Good < 20 msec
  • Fair < 30 msec
  • Poor < 40 msec
  • Cache/Exec < 1 msec
  • Cache/Good < 2 msec
  • Cache/Fair < 4 msec

You need to spent time to identify all these and come up with conclusion

Good luck


Oz ozugurluMVP (Exchange)


MCSE (M+,S+) MCDST, Security+, Server +,Project+

Blog: http://www.smtp25.blogspot.com/

1 comment:

Anonymous said...

thanks I was searching for that