Why this happens

SQL Server stores the name it was installed under in two places that can drift apart after a clone or a Windows-level rename:

  • The Windows machine name — controlled entirely by Windows, and whatever you set it to during or after sysprep/rename.
  • SQL Server's internal server name — captured in the master.sys.servers table at install time and surfaced through @@SERVERNAME. This value does not update automatically when Windows is renamed.

Once those two diverge, anything that relies on @@SERVERNAME — replication, some Availability Group health checks, certain SSRS and SSAS operations, and any custom code that queries the instance's own name — starts referencing a host that no longer exists.

Step 1 — Confirm the mismatch

Before changing anything, confirm there actually is a mismatch. Connect to the instance and run:

SELECT @@SERVERNAME                           -- SQL Server's internal record
SELECT SERVERPROPERTY('ServerName')           -- what SQL Server currently reports
SELECT SERVERPROPERTY('MachineName')          -- the actual Windows machine name

If @@SERVERNAME still shows the old hostname while MachineName shows the new one, you have the classic post-clone mismatch and the fix below applies.

Before you change anything

Take a full backup first. This procedure touches system metadata in master. On a production instance, back up master (and ideally take a full instance backup) before proceeding, and run the change in a maintenance window — the fix itself requires a service restart.

Step 2 — Update the internal server name

For a standalone (non-clustered) default instance, drop the stale name and register the new one using the built-in system stored procedures:

-- Remove the old, stale server name entry
EXEC sp_dropserver 'OLD-SERVER-NAME';
GO

-- Register the current name, keeping it as a local server
EXEC sp_addserver 'NEW-SERVER-NAME', local;
GO

Step 3 — Restart the SQL Server services

The change doesn't take effect until the Database Engine service is restarted. Restart, in order:

  1. SQL Server (MSSQLSERVER, or the named instance service)
  2. SQL Server Agent
  3. Any dependent services you stopped for the maintenance window (SSRS, SSAS, SSIS if co-located)

Step 4 — Verify the change

SELECT @@SERVERNAME                    -- should now show the new name
SELECT SERVERPROPERTY('ServerName')    -- should match @@SERVERNAME

Named instances

For a named instance, @@SERVERNAME returns COMPUTERNAME\INSTANCENAME, so both the drop and add steps need the full name.

Step 5 — Fix downstream dependencies

  • Replication — publications and subscriptions store the server name in their metadata and typically need to be dropped and reconfigured.
  • Reporting Services (SSRS) — re-run the Reporting Services Configuration Manager and be prepared to restore the encryption keys.
  • Analysis Services (SSAS) — update deployment targets, connection strings and scheduled processing jobs.
  • Linked servers on other instances — update any definition pointing at the old name.
  • Kerberos SPNs — register new SPNs for the new hostname and remove the stale ones.
  • Application & ETL connection strings, DNS records and monitoring configuration.

A note on clustered instances & Availability Groups

This procedure applies to a standalone instance. For a Failover Cluster Instance the client-facing name is the cluster network name resource, not the Windows node name. For Always On Availability Groups clients usually connect via the listener, so a node rename has different impact — validate AG health after any change.