One of our Exchange Servers is permanently down and I'm trying to remove it from our site. After right-clicking the failed server and selecting All Tasks > Remove Server, I get an error that says it can't be removed because people are using mailbox stores on it, even though all end users already moved to a different server. How can I fix this?
While it's possible to pull out a "bigger hammer" and manually remove the remnants of your Exchange Server from Active Directory (ADSI Edit, for example), I would suggest considering a few alternatives.
It's possible that the error you're getting could be resolved by searching for mailboxes that were created -- but that end users never actually logged on to -- and then removing the Exchange attributes. This is a common cause of the symptom you're having. In Exchange 2000/2003, search user objects with Active Directory Users and Computers (ADUC) to find the "Exchange Home Server" attribute for the failed server. In Exchange 2007 and higher, use the Get-Mailbox cmdlet to find any mailboxes on a server or database you may have missed. If you're in a multi-domain forest, don't forget to add the IgnoreDefaultScope parameter so mailboxes from all domains are also displayed.
Even if this eliminates the error you're seeing, I'd caution against manually removing the server. In addition to protecting data on the server (although it sounds like you were able to do so), the services the server was responsible for could include mail flow, client access and system-level functionality. Manually removing the server could cause significant problems if you don't fully transfer all functionality to another server.
The good news is that since the release of Exchange Server 2000, every Exchange Server's configuration information is stored in Active Directory. The configuration data is replicated to every domain controller (DC) in the forest. This centralized and hopefully redundant data set (two or more DCs required) effectively commoditizes the actual Exchange Server hardware. Setup provides a recovery option, which can be used to install Exchange on new hardware while still maintaining the existing server name and services associated with the failed server.
|Exchange 2007 and 2010||Setup /m:RecoverServer||http://technet.microsoft.com/en-us/library/aa998656(v=EXCHG.80).aspx|
|Exchange 2013||Setup /m:RecoverServer||http://technet.microsoft.com/en-us/library/dd876880(v=exchg.150).aspx|
The mailbox databases on the failed server would need to be recovered from backup if the storage subsystem went down with it. You could use Recovery databases, Dial tone portability and database portability to minimize recovery time.
The following table is a reference for where information is stored in AD that would need to be manually removed if you had to do so.
|AD Configuration||CN=Configuration [domain] -> CN=Services -> CN=Microsoft Exchange -> CN=[organization] -> CN=Administrative Groups -> CN=Servers -> [failedserver]|
|Mailbox Databases||CN=Configuration [domain] → CN=Services → CN=Microsoft Exchange → CN=[organization] → CN=Administrative Groups → CN=Databases [failedserver_databases]|
|Security Group membership||
About the author:
Richard Luckett is a consultant and instructor specializing in messaging and unified communications. He's been a certified professional with Microsoft since 1996 and has 20 years of experience in the public and private sectors. He's a Microsoft Certified Trainer with more than 15 years of training experience with the Microsoft product line and received the Exchange MVP award in 2006, 2007 and 2008. He's also an expert in deploying and integrating Exchange Server and Lync Server. He leads the Microsoft training and consulting practice at LITSG
Dig deeper on Microsoft Exchange Server Performance
Related Q&A from Richard Luckett
When you're stumped on how to track email items following a central mailbox move, fix the dilemma by knowing what happens to items in mailboxes when ...continue reading
There are a number of actions to take to implement OWA security, including obvious ones like creating strong password policies. Admins should also ...continue reading
Our resident Microsoft Lync expert explains where to find IP phones that are compatible with Microsoft Lync Server.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.