Rename a SQL Server Failover Cluster Instance
When a SQL Server instance is part of a failover cluster, the process of renaming the virtual server differs from that of renaming a stand-alone instance. For more information, see Rename a Computer that Hosts a Stand-Alone Instance of SQL Server.
The name of the virtual server is always the same as the name of the SQL Network Name (the SQL Virtual Server Network Name). Although you can change the name of the virtual server, you cannot change the instance name. For example, you can change a virtual server named VS1\instance1 to some other name, such as SQL35\instance1, but the instance portion of the name, instance1, will remain unchanged.
Before you begin the renaming process, review the items below.
SQL Server does not support renaming servers involved in replication, except in the case of using log shipping with replication. The secondary server in log shipping can be renamed if the primary server is permanently lost. For more information, see Log Shipping and Replication (SQL Server).
When renaming a virtual server that is configured to use database mirroring, you must turn off database mirroring before the renaming operation, and then re-establish database mirroring with the new virtual server name. Metadata for database mirroring will not be updated automatically to reflect the new virtual server name.
To rename a virtual server
Using Cluster Administrator, change the SQL Network Name to the new name.
Take the network name resource offline. This takes the SQL Server resource and other dependent resources offline as well.
Bring the SQL Server resource back online.
After a virtual server has been renamed, any connections that used the old name must now connect using the new name.
To verify that the renaming operation has completed, select information from either @@servername or sys.servers. The @@servername function will return the new virtual server name, and the sys.servers table will show the new virtual server name. To verify that the failover process is working correctly with the new name, the user should also try to fail the SQL Server resource over to the other nodes.
For connections from any node in the cluster, the new name can be used almost immediately. However, for connections using the new name from a client computer, the new name cannot be used to connect to the server until the new name is visible to that client computer. The length of time required for the new name to be propagated across a network can be a few seconds, or as long as 3 to 5 minutes, depending on the network configuration; additional time may be required before the old virtual server name is no longer visible on the network.
To minimize network propagation delay of a virtual server renaming operation, use the following steps:
To minimize network propagation delay
Issue the following commands from a command prompt on the server node:
ipconfig /flushdns ipconfig /registerdns nbtstat –RR
After we rename the network name of SQL Server 2012 failover cluster we need to verify and perform the below suggested additional instructions to get all scenarios in SQL Server Agent and Analysis Services working.
Analysis Services: After you change the network name of a SQL Server 2012 Analysis Services (SSAS) failover cluster instance using Windows Cluster Administrator tool, the future upgrade or uninstall operation might fail. To resolve this issue update the ClusterName registry entry following the instructions in the resolution section of this (http://go.microsoft.com/fwlink/?LinkId=244002) knowledge base article.
SQL Server Agent Service: Verify and perform the below additional actions for SQL Server Agent Service:
Fix the registry settings if SQL Agent is configured for event forwarding. For more information, see Designate an Events Forwarding Server (SQL Server Management Studio).
Fix the master server (MSX) and target servers (TSX) instance names when machines / cluster network name is renamed. For more information, see the following topics:
Reconfigure the Log Shipping so that updated server name is used to backup and restore logs. For more information, see the following topics:
Update the Jobsteps that depend on server name. For more information, see Manage Job Steps.