Because we’re all skilled computer professionals who have carefully considered a suitable computer naming convention before deploying any server into production, I can’t think of good reasons why anyone would ever want to rename an Exchange server. On the other hand, I can think of some pretty bad reasons for wanting to rename a server such as wishing to update all names following a corporate merger or as part of a rebranding exercise launched by the marketing department.
Of course, this kind of exercise cheerfully ignores the basic logic that few users care what their server is called and fewer probably know how to find out. Administrators do care because of the naming convention that is in use to identify servers and the role that they play within an organization. Some questions have recently been asked on the topic so I thought it worth discussing here.
If backed into a corner by the unreasonable demand to rename a server, the first ploy that should be adopted is the standard response “it’s unsupported by Microsoft.” In this case, it’s actually true and Microsoft support is most unlikely to be happy with you if you call in to report that things went horribly wrong when you attempted to rename a server. However, aside for the directive that you must not change the server name after installing an Edge server that’s buried in a TechNet article, there is little authoritative commentary on the topic, so here’s why you shouldn’t even consider a renaming exercise.
The first thing to realize is that Active Directory is liberally populated with references to an Exchange server name. Both the distinguished name (DN) and the visible server name can be found. The basic location to start looking is in the Servers container in the famous Exchange Administrative Group (FYDIBOHF23SPDLT) container (much beloved of those interested in playing Exchange trivial pursuit). You’ll need to navigate to Services, then Microsoft Exchange, and then the name of your organization within the configuration naming context to locate this container. This is the basic object that holds Active Directory configuration data about an Exchange server and has been used for this purpose ever since Exchange started to use Active Directory in Exchange 2000. In this case, we’re looking at a server called EXSERVER1. I guess the sheer unimaginative quality of this name is one reason why someone might consider a rename…
OK, let’s assume that it was possible to simply scan through Active Directory and do a search and replace for all instances of the old server name and replace it with the new and improved version. Seeing that we’re dealing with computers and it’s all just a mere matter of programming, it is conceivable that you could indeed write such a tool for this purpose. But that tool would have to be awfully careful when it did brain surgery on the Active Directory to ensure that it got all the places where a server name might be lurking.
For example, here’s an instance where the properties of a database that happens to be within a Database Availability Group (DAG) contains a reference to EXSERVER1, which happens to be the server where the database is currently mounted. It’s kind of important that things like this are picked up and that the configuration data for any technology that Exchange depends on (in this case, Windows Failover Clustering for the DAG) is also updated. Our tool will have to do some pretty complicated processing to ensure that everything that should be done is done and will probably have to insist that it can only be run on the server whose name is being changed.
Assuming that our brain surgery is successful and that every single instance of the old server name can be located and updated in Active Directory, we still have to deal with the system registry. It’s true that the vast bulk of Exchange configuration data is maintained in Active Directory but a quick scan of the registry on a server revealed that there are many instances where the server name pops up. The screen shot below reveals some information that Active Manager stores there about the databases in a DAG such as the name of the server that last mounted the database and the time when it was mounted. Now, we could decide that these registry entries are transient data and can be ignored but that doesn’t seem too sensible as we simply don’t know what will happen if a server name is updated in Active Directory and is then brought online with the old name loitering in the registry. Of course, we’d test the heck out of our tool before we’d ever use it on a production server but a) would you have a high level of confidence that the tool would catch every possible instance where a server name occurs and b) what would you say to Microsoft support when you called to report a brain-dead server?
And then there’s user PCs that contain profiles that point to Client Access Servers (CAS) or mailbox servers to be able to locate mailboxes using Outlook or through IMAP, POP, or whatever other access method you prefer. It’s simple to update a single client PC in a test environment but significantly more difficult and more expensive to update the several thousand PCs that might conceivably connect to a server.
If you’re pinned to the wall and forced to accept that senior management wants server names to change, the only solution is to remove Exchange from the server, check that all trace of the server has disappeared from the organization, change the server name from Windows, reboot, and then reinstall Exchange. This procedure will produce a nice clean renamed server at the expense of several hours work.
By the way, don’t fall to the temptation to use ADSIEDIT as a shortcut to blow away an Exchange server unless absolutely necessary, especially if it’s a member of a DAG. Go through the correct processes to remove the server from the organization by running Setup to deinstall all of the Exchange server roles from the computer. Before that, go through all the various steps to transition work to other servers. For example, if you are dealing with a mailbox server, you have to move any mailboxes that exist on the server including arbitration and search mailboxes. You might also have to take steps such as assigning another server to generate the OAB and moving public folder replicas. Servers that are part of a DAG are more complex because you have to first ensure that all of the database copies are removed and then remove the server out of the DAG. This step should clean up the underlying cluster by evicting the node from the cluster and adjusting the quorum.
Before anyone asks, the situation doesn't seem to be any better with Exchange 2013.
The bottom line is that renaming an Exchange server is not supported and shouldn’t be done. We don’t have the tools to search and replace old names with new and no one really wants to be on the bleeding edge of finding out the many interesting places where Exchange has squirreled away a server name. So if someone with power and influence (such as the person responsible for your annual performance review) comes to you with a request to change a server name be prepared with good arguments to prove that the request is unreasonable and impossible or, maybe even better, just say yes and do the work to remove, rename, and add the server back again. Isn’t that what weekends are for?
Follow Tony Redmond on Twitter @12Knocksinna
