Removing Exchange 2010 on a Domain Controller

OK let's not get into the why so much as I've spent hours on the phone with Microsoft, and others.  The conclusion is that the Domain Controller that Exchange resides on (not recommended for precisely this reason), is corrupt beyond repair. I can't remove the DC role as exchange still exists.  I'm going on 3 months limping along, and even the Exchange install still has legacy x400 public folders and crap we don't want/need. Even if I could somehow patch it back together I think a fresh start may be the better option here.

So this isn't so much a question, as it is a request for validation of my steps.

1. Dismount the mailboxes, and be sure they go down Clean. Backup the EDB files.
2. Uninstall Exchange via add/remove. Since AD replication is not happening I will likely have to manually remove from the other DC using the below steps.

3. Right Click on ADSIEdit and Click Connect to

4. Connect to “Default Naming Context”

5. Navigate to the following objects and Delete them.

DC=Domain,DC=Com -> OU=Microsoft Exchange Security Groups 

DC=Domain,DC=Com -> CN=Microsoft Exchange System Objects

6. Right Click on ADSIEdit and Click Connect to

7. Connect to “Configuration”

8. Navigate to the following objects and Delete them.

CN=Configuration,DC=Domain,DC=Com -> CN=Services -> CN=Microsoft Exchange

CN=Configuration,DC=Domain,DC=Com -> CN=Services -> CN=Microsoft Exchange Autodiscover

Open in new window

3. Once I verify that exchange is truly gone. Remove the AD role as well. Again probably won't go away cleanly so I'll follow in the event it doesnt.

Once both the DC and exchange are no longer in the domain. I'll start the rebuild.

1. Install new exchange server. It is going into a new VM, and I planned to put all the roles on one. We won't be doing a DAG ever as in the next 6 months I will be moving people to a hosted solution probably Office365.  One question here is there any reason not to give the new box the same IP and name as the old one? If I've verified by ADSI edit that it is truly gone. This will just save some work on apps that use SMTP to send email either by name or address.

2. Once installed create an empty mailbox for all the users that had one before.

3. Setup OWA, and reissue certs, and set up internal relays for other app servers.

4. Mount EDB's that were backed up during uninstall as Recovery DB and restore.

5. Finally get a full night's sleep.

Does anyone see any glaring issues here?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

On your point 1 question.  Exchange is so tightly coupled with Active Directory that you may not be able to use the same name as the old server (that is unless, you are 100% absolutely certain that the old entries are all gone).  The IP I don't really believe will matter as you just remove the old DNS entries for the old server name, flush and re-register dns.

Now just to put a little fly on your wall, it may be possible to stand-up a new VM with the old server name if you reinstall Exchange in disasterrecovery (using setup.exe /M:RecoverServer) mode.  Also you wont have to fuss with modifying the AD database.

A few things to consider before you go jumping for joy.

1.  You won't use your plan with regards to the clean-up of AD.  You will just make your old server unavailable (disconnected from the network, etc.)
2.  The version of Exchange on the new server must match the old version *excactly* (you can't decide to install Exchange 2013, or if you were using Exchange 2007 Standard, move it to Exchange 2007 Enterprise).
3.  The version of the OS must match the old server OS, you guessed it, *exactly*
4.  This only works if there is an Active Directory replica on the domain (another DC that contains, at a minimum, the AD records associated with the old Exchange server).

So if your interest is piqued enough to try it:
How to recover an exchange server using the RecoverServer switch

Might gain you a few more moments of shut-eye.  ;)

bhiebAuthor Commented:
I had seen this, and considered it. But the same admin that put it on the DC also left some stuff like legacy x400 addresses, free/busy public crap, and god knows what else (this server has never had a perfectly clean event viewer). So if I recover it won't some of those other "legacy stuff" stick around?

I meet all those requirements, I'm just not sure if "polishing a turd" is worth it, my way I get a truly fresh start. There is only 150 users so scripting out the mailbox creation and recoveries should be minimal work especially since i have all that data.

I do have a good PDC that has all the roles. Question tho, if I choose this. I still have the domain expecting an DC @ the old name. So how do I get that out of the domain? Do I clean it up after exchange is back up, or do I do it first. I'd assume not first as then i couldn't do the recovery.
All things considered, performing a reinstall of the original OS, rejoining it to the domain, standing it back up as a DC, reinstalling Exchange in /M:DisasterRecovery, recovering your DB's and then performing an Exchange migration to a new server may seem like "polishing a turd", but may actually provide a cleaner slate to work from than going through the manual process of gutting and cleaning AD.  

I say this because, in the process of promoting the server to a DC, you may get a clean-up of the DC related entries in AD.  Once this is completed and you recover Exchange, yes everything associated with the old one will (e.g. - legacy stuff) still be there but so will the other things that may not be considered (Transport Rules, Anti-Spam rules, etc.)  It will, also, allow for a cleaner removal of Exchange and the AD roles associated with the server when you stand up your new VM that you migrate to.

Ultimately though, it is a double-edged sword either way you go.  Both scenarios do offer pitfall's and celebratory moments.  It just come's down to which method will be the most time and cost effective for not only the present but also for the future.

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

bhiebAuthor Commented:
Correct me if I'm wrong but if I do the recovery, I'm standing it back up as a DC too. So I'd have to go through another migration to another VM later in order to finally cleanly remove the server and dc. That definitely seems like the approved way of doing it, but after the restore I'm still not in the state I want to be in.

Hmm. Like you said both have pluses and minuses. I'll have to sleep on it. Good thing is (i suppose) this has been dragging on long enough that my users aren't going to be upset at the downtime (especially over a weekend), as the flaky up and down nature that we've been living with has soften them up a bit. An (un)fortuante side effect of living in an unstable environment long enough, is that the price for stability becomes an easier pill to swallow.
bhiebAuthor Commented:
I'm still a little perplexed on the DC role. Assuming a recover install.

1. Shutdown clean the old server, make sure edb's are dismounted cleanly. Make copies.
2. Reset computer object in AD on PDC.
3. Install new VM, join to the domain with same name.
4. Activate DC role? This is the step confusing me won't it expect it already there, and iirc I can't add it before I join???
5. install exchange prereq.
6. run recovery install
7. put edb's in the same path on new vm
8. mount db's
9. Redo owa cert im sure, double check other settings like internal relays...

At this point I'd assume all the Outlook profiles would need to be rebuilt, or would that pick up fine?
You are correct, you would stand it back up as a DC.  But in your plan you had stated that you ultimately plan to move it to a VM.  So doing the migration seems like a more appropriate (perhaps?) course of action.

If your ultimate goal is to clean out garbage from AD, then removing those entries via the recommended methods (e.g. - removing exchange via setup, removing AD roles via DCPROMO, etc.) seems cleaner and less likely to produce orphaned entries (hey no one is perfect, there will probably still be orphans to consider).

I feel both your pain and aprehension.  I'm not trying to be the voice of dissidence, I'm trying to be the voice of reason.

bhiebAuthor Commented:
To clarify it is a VM now, and will be restored as one as well.
See if this answers your previous questions:


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
bhiebAuthor Commented:
Actually I tried that, but I forget what error it was. Essentially since the 2 DC's aren't talking correctly moving it while the DC's aren't replicating cause issues. So I backed off of trying that, as the what-ifs were stacking up beyond safe levels. :)

I think I'm gonna try the recover, but to address my question on #4 above. After I join it to the domain, I put the DC role on it? The "standing it back up as a DC" part is my only concern at this point. Since the primary working DC thinks it is a DC, when i join it without the DC role is that gonna be an issue to put the DC role on after joining.
bhiebAuthor Commented:
Oh never mind actually that link looks to be exactly what I want to do. Bring it up on a new member, manually clean out the old DC. Good find.

Thanks for all your insight and help. Good to have someone to bounce ideas off of. If this fails I can always use my nuclear option :)
In the link that I posted above, the auther took a crashed DC, cleaned the AD role related metadata and rejoined a new computer with the same name, made it a member of the domain and reinstalled Exchange (without re-adding the DC roles).

Scalpel vs Hatchet, eh. ;)

Glad I could be of assistance.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.