How to Rename a Computer That Hosts SQL Server

Renaming a Windows machine is a two minute job. Renaming a Windows machine that happens to be running SQL Server is not, because SQL Server records the server name in its own metadata at install time and does not notice when the operating system changes underneath it.

The result is an instance where SERVERPROPERTY('ServerName') reports the new name and @@SERVERNAME still reports the old one. Most things keep working, which is what makes it dangerous, and then something that reads @@SERVERNAME fails weeks later with an error that points nowhere near the rename.

This usually comes up when SQL Server was installed before the machine was named properly. The fix is short. The checks before it are the part worth doing carefully.

---

Check Whether You Have The Problem

Run this on the instance. It compares what SQL Server has stored against what it can see:

SELECT
    @@SERVERNAME                                  AS StoredName,
    CONVERT(sysname, SERVERPROPERTY('ServerName')) AS ActualName,
    CONVERT(sysname, SERVERPROPERTY('MachineName')) AS MachineName,
    CONVERT(sysname, SERVERPROPERTY('InstanceName')) AS InstanceName,
    SERVERPROPERTY('IsClustered')                  AS IsClustered;

If StoredName and ActualName differ, the metadata needs updating. As a one-line check for a script:

IF CONVERT(sysname, SERVERPROPERTY('ServerName')) <> CONVERT(sysname, @@SERVERNAME)
    SELECT 'MISMATCH - metadata needs updating' AS Status,
           @@SERVERNAME AS StoredName,
           CONVERT(sysname, SERVERPROPERTY('ServerName')) AS ActualName;
ELSE
    SELECT 'MATCH - nothing to do' AS Status, @@SERVERNAME AS Name;

The difference between the two is the whole issue. SERVERPROPERTY('ServerName') is derived from the machine at runtime and follows a rename immediately. @@SERVERNAME reads from sys.servers where server_id = 0, which was written at install and stays written until you change it.

---

Stop Here If Any Of These Are True

Run this before going any further. It is read only and it takes a second:

SELECT SERVERPROPERTY('IsClustered')   AS IsClustered,
       SERVERPROPERTY('IsHadrEnabled') AS IsHadrEnabled;

SELECT COUNT(*) AS ReplicationDbs
FROM sys.databases
WHERE is_published = 1 OR is_subscribed = 1 OR is_distributor = 1;

SELECT COUNT(*) AS MirroredDbs FROM sys.database_mirroring WHERE mirroring_guid IS NOT NULL;
SELECT COUNT(*) AS AvailabilityGroups FROM sys.availability_groups;
SELECT COUNT(*) AS LinkedServers FROM sys.servers WHERE is_linked = 1;

The clustered and replication cases are the two that turn a ten minute change into an outage. Check them rather than assuming.

---

The Rename

Step 1: Rename The Machine In Windows

Do this first, before touching SQL Server at all. Through the GUI it is System Properties, Change, but PowerShell is quicker and scriptable:

# local machine
Rename-Computer -NewName "NEWNAME" -Restart

# domain-joined, where the account running the shell cannot rename it
Rename-Computer -NewName "NEWNAME" -DomainCredential DOMAIN\admin -Restart -Force

-Restart reboots immediately, which is required for the rename to take effect. If you leave it off, the machine keeps answering to the old name until it is restarted and the SQL Server side of this will look like it did nothing.

Stop the SQL Server service cleanly before the reboot if the instance is doing anything that matters.

Step 2: Update The SQL Server Metadata

Once the machine is back up under the new name, run this against the instance. 'local' is what tells SQL Server this is the local server entry rather than a linked server.

Default instance:

-- old name, exactly as @@SERVERNAME currently reports it
EXEC sp_dropserver 'OLDNAME';
GO
EXEC sp_addserver 'NEWNAME', 'local';
GO

Named instance: use the full machine\instance form on both lines.

EXEC sp_dropserver 'OLDNAME\SQL2022';
GO
EXEC sp_addserver 'NEWNAME\SQL2022', 'local';
GO

Step 3: Restart The SQL Server Service

The change does not take effect until you do, and @@SERVERNAME will keep reporting the old value until the restart happens. This catches people out constantly: the procedures succeed, the value does not change, and it looks like the fix did not work.

After the restart, run the check query again. StoredName and ActualName should now match.

There is also an older way to read the machine’s real name from inside SQL Server, which turns up in scripts written before SERVERPROPERTY covered it:

EXEC master..xp_getnetname;   -- returns 'Server Net Name'

It still works, verified on SQL Server 2025, but it is an undocumented extended procedure. SERVERPROPERTY('MachineName') returns the same thing, is documented, and can be used inline in a query, so prefer that in anything you are keeping.

---

What To Check Afterwards

The metadata is only the first piece. These are the things that hold the old name somewhere else.

SQL Agent jobs. Every job in msdb.dbo.sysjobs carries an originating_server_id. Jobs generally keep running, but multi-server administration and any job step that references the server by name will not. Check the job list and any step that builds a connection string.

Linked servers on other instances. A linked server pointing at the old name will fail at the next call. Find them with:

SELECT name, data_source FROM sys.servers WHERE is_linked = 1;

Run that on the other servers, not this one, and look for the old name in data_source. Drop and recreate any that match. Generate Linked Server Script will script out the existing definitions before you drop them.

Kerberos SPNs. The service principal name registered in Active Directory still refers to the old host. If Windows authentication starts falling back to NTLM, or you get an SSPI error, this is why. The SPN needs deleting and re-registering against the new name, and the difference between the two authentication paths is covered in Kerberos vs NTLM in SQL Server.

Connection strings and DNS. Applications, ODBC DSNs, monitoring agents, backup software. A CNAME pointing at the old name is the usual quiet survivor here.

Database Mail and alerts. Operator email addresses and mail profile references are fine, but anything that writes the server name into an alert body will now be reporting the new one, which is worth telling whoever reads those alerts.

Reporting Services and other SQL features. These are configured separately and are not covered by sp_addserver. If SSRS is installed, its configuration needs updating through its own configuration manager.

---

A Note On Doing It The Other Way

There is a temptation to skip the Windows rename and just update the SQL metadata, or to update sys.servers directly with an UPDATE statement. Do not do the second one. sys.servers is a system view, direct modification is unsupported, and sp_dropserver and sp_addserver exist precisely because there is more to it than one row.

If the goal is only that applications can connect by a different name, an alias or a DNS CNAME is a far lighter answer than renaming anything. Renaming the host is the right call when the machine genuinely has the wrong name, not when you want a second name for it.

---

Frequently Asked Questions

---

Summary

SQL Server stores its own server name and does not follow a Windows rename. Detect it by comparing @@SERVERNAME with SERVERPROPERTY('ServerName'). Fix it with sp_dropserver for the old name, sp_addserver with 'local' for the new one, and a service restart, which is the step people miss.

Before any of that, check for a clustered instance, replication, mirroring or availability groups. Those change the procedure completely, and finding out afterwards is a much worse day than checking first.

---