Wednesday, August 19, 2009

Exchange 2007 installed on Domain Controller

This is the first time I saw Exchange 2007 installed on Domain controller ( Not SBS) standard windows 2008 Server DC/GC/DNS , Exchange 2007 Server , Antivirus and SQL servers.

When body of mine needed help and asked me to take a look at the exchange server for companyX in DC, I was willingly to help and took me over 2 days to fix it (-:

This recent experience made me think, and decided to share the experience with you guys. As always I get pretty upset when I see Exchange is installed on a Domain controller, lets think for a sec and forget about SBS (-:

Domain controllers are already busy they authenticate users and deal with other services and also they deal with their distributed database called .DIT database.

Now when its comes to deploy domain controller , we always recommend fallowing best practices fro the RAID Level simply for redundancy and performance related concerns the most, and hence we say go with RAID 1+0 for OS and RAID 1+0 for Database and keep it mind the best practice is to keep .DIT and SysVOL together and place logs and .DIT on other spindals when it is all possible.

Now as you see DC is pretty busy already and do not install anything else except , other Domain controller functions & Roles if it is required or desired, such as DHCP, DNS, etc.

Remember best practice is to use AD Integrated DNS since DNS is part of .DIT database, and do not allow none secure updates. In  AD Multi Master Replication Model the DNS information will be replicating via replication with help & function of KCC.

Installing another application such as Exchange on the existing DC is always big NO, and I will tell you why in a second.

Now the network I helped to fired made me horrified, the Exchange was installed on the domain controller +, GC,DNS,DHCP, and on top of all these all FSMO roles were loaded on this server.

Seeing Exchange binaries on C drive ( 12 GIG) while other drive has 100 GIG is big NO (-:

Beside it is bad practice simply it is stupid to do to be honest. Now running DCpromo out and making it failed is another mistake in production this isn't a LAB network.

As far as I recall anyone who has some decent experience with AD and Exchange will tell you , build another server move mailboxes , decommission exchange meaning uninstall it and deal with the DC afterwards and DO NOT try to run DCPROMO (-:

You want more here it comes,

What happens when you have 4 DC ( windows 2003) and one of the DC wont talk to others over 60 days? Talking meaning KCC for what ever reason is not working and DC4 is not talking to other DC’s over 60 Days.





Well if you are the network guy and you have not woken up since 2007 (-:, I would say

you are not doing your job properly or don't know what you are doing.

Okay I think there are enough reasons why Exchange would not work properly, so how we deal with this situation? How do we make DC4 talk back to rest of the domain controllers?

The answer is going to be Metadata Clean up and it it is necessary promote the Death DC back as healthy domain controllers.

Part two I will explain why you need DCPROMO /ForceRemoval and NTDSUTIL & Metadata Cleanup

oz Casey Dedeal,

MVP (Exchange)
MCSE 2003, M+, S+, MCDST
Security+, Project +, Server +

Http:// (Blog)

Https:// (Blog)

Https:// (Blog)

No comments: