BROKEN EXCHANGE SERVER? DON’T DELETE IT WITH ADSIEDIT — HERE’S WHY

When recovering an Exchange server, admins typically want to take the fastest route. But when they do, they often hit roadblocks on their journey. Many users and IT staff on the Microsoft TechNet forums run into endless issues when they want to upgrade or remove a server or simply do the normal tasks they need to do. They often get errors that reference a server or servers that were removed by previous admins. Or people just shut down a server and delete it from Active Directory with a “we don’ need it anymore” kind of attitude. The other Exchange servers then continuously log that they cannot communicate with server X and they are stuck because of an orphaned server. The other challenge is that something goes wrong with an Exchange server and admins find it easier to just remove the server using ADSIEdit.

Easy fix? Not really

While it seems easy to say, “I solved the issue as I removed the server from ADSIEdit or Active Directory,” you did not remove the entire footprint of Exchange in ADSIEdit and from Active Directory. You now have a broken database availability group (DAG), a broken hub transport server, an Exchange server that had mailboxes that you thought were not needed even though you need to keep the data for compliance.

The damage keeps growing. When you as the IT admin leave the organization, perhaps they hire someone who might be less skilled than you or is still learning. They have this big hole to fill. Think about your actions. Even though it seems easy to do, doing a quick fix now may create problems later. Spend the time to complete the job properly. Ask yourself the question, would you like somebody to do a sloppy repair job and hand it over to you to fix and you waste endless hours trying to figure out what was done?

Using ADSIEdit

OK, let’s take a look at ADSIEdit now that you see where I am going. ADSIEdit is a very powerful tool you can access from a domain controller. It gives you the ability to connect to each partition and look at the data.

There are times when you log a call with Microsoft and a senior support engineer will have to use it to do something or you need to change an attribute on an object. This is OK but it shouldn't be used at a tool to just delete stuff. The reason behind this is that if you delete the wrong information, you can cripple your environment completely and the Active Directory recycle bin is not going to rescue you on this one.

I have used ADSIEdit a few times. OK, so you say, “You use it but you tell us not to?” Here’s when to use it: Let’s say you have completed migrations that you cannot see to remove from Exchange when you run the command. Here you can go into the correct section and delete them but I would advise having your Active Directory backups in place, always a good plan. Why would you remove migrations? Because you cannot uninstall Exchange from a server if they are still present.

Now let’s move over to recover a server. Public folders are a problem in this area as many IT admins just blow it away vs. doing a move from a legacy version to the newer versions and letting it replicate.

Right, it is going to take you an extra day to build a new virtual machine and get all its prerequisites done and the server patched. Once that is done you can then move on to install Exchange with the recovery switch and then all its rollups (if on legacy versions of Exchange) and cumulative updates (if on newer versions of Exchange, 2013 and higher). Then you have the ability to uninstall Exchange.

OK, that is a lot to take in. So, you say, “You want me to spend time doing all that?” Yes! By doing it this way, you can then go and cleanly remove Exchange from that server. After you remove Exchange you can then reboot and after that take the machine off the domain.

Time well spent

Yes, you have “wasted” a day or two days doing this but you have saved yourself further headaches down the road. Recovering a server, if it can be recovered that is, is the cleanest way of doing things.

Rather than just shutting down your virtual machine or physical server, take the time to move your arbitration mailboxes and clear out move requests and migrations. And once all that is done and nothing is left to move or remove, then head over to the control panel and uninstall Exchange from the start. You will then not have to worry about having legacy issues in the environments or struggling with upgrades and when you leave the company one day, you hand over a clean environment to the next person.

Now you can go and remove the server from your inventory list and remove its IP address from DNS and do a cleanup. Please think before you just take the easy way out. ADSIEdit can be your best friend but it can also be your worst enemy when things don’ work out as planned.

If you are not sure how to do a recovery or feel you don’ have the time, ask the company to bring in a consultant to assist you and help you with the uninstalls.