@@SERVERNAME does not match the actual server name

What this check looks for

An instance where @@SERVERNAME and SERVERPROPERTY('ServerName') return different names. The comparison ignores case and surrounding spaces.

The two values come from different places:

  • @@SERVERNAME is read from the local entry in sys.servers (server_id 0). It is set at install time and only changes when sp_dropserver and sp_addserver are run.
  • SERVERPROPERTY('ServerName') is worked out from the current Windows or cluster network name every time it is read.

They drift apart when the machine, the cluster network name, or an availability group listener is renamed and sys.servers is not updated to match. The finding shows both values.

If @@SERVERNAME is NULL rather than a stale name, that is a separate check, because the local entry is missing and not merely out of date.

Why it matters

The instance keeps running under its new name while a lot of code still believes it has the old one.

The things that rely on @@SERVERNAME:

  • Replication compares publisher and distributor names to the local name.
  • Log shipping records the primary and secondary server names.
  • Linked servers and SQL Agent multi server jobs use the local name to decide what is local and what is remote.
  • Maintenance scripts and monitoring tools that write @@SERVERNAME into a table record the old name, so history is filed under a server that no longer exists.

It is Low severity because nothing stops. The cost shows up later, in whichever feature needed the right name, and the symptom rarely mentions the name.

The usual cause is a computer rename, which SQL Server does not follow on its own. A cluster network name change and an availability group listener rename do the same.

How to confirm it yourself

Put the two values side by side:

SELECT @@SERVERNAME                  AS AtAtServerName,
       SERVERPROPERTY('ServerName')  AS ActualServerName,
       SERVERPROPERTY('MachineName') AS MachineName;

Look at the local entry in sys.servers:

SELECT server_id, name, data_source
FROM sys.servers
WHERE server_id = 0;

The name there is what @@SERVERNAME returns. If it is the old name, the rename was never carried through.

How to fix it

Replace the local entry with the new name, then restart the SQL Server service. The new name is not used until the restart.

-- OLDNAME is the value @@SERVERNAME returned.
-- NEWNAME is the value SERVERPROPERTY('ServerName') returned, including the
-- instance name for a named instance, for example SQLPROD01\INST2.
EXEC sp_dropserver @server = N'OLDNAME';
EXEC sp_addserver  @server = N'NEWNAME', @local = 'local';

Restart the service, then confirm:

SELECT @@SERVERNAME, SERVERPROPERTY('ServerName');

Both should now match. Before you do it:

  1. Plan the restart. Until it happens, @@SERVERNAME still returns the old value.
  2. Use the exact name from SERVERPROPERTY('ServerName').
  3. Do not use this for a clustered instance or an Availability Group replica’s own name. Those names come from the cluster, and the mismatch there needs the cluster side checked first.
  4. Check what recorded the old name. Replication publications, log shipping configuration, multi server jobs and any linked server that pointed at the old name may need to be reviewed.

How long it takes

About half an hour, mostly waiting for a restart window. The change is two statements.

Report Why you would go there
Linked Servers Entries that still point at the old name.
Replication Publications and agents that depend on the local server name.
Log Shipping Primary and secondary names recorded for each database.
Configuration Values The rest of the instance configuration, for context.
Check
@@SERVERNAME is NULL or empty The local entry is missing altogether rather than out of date.
Linked server points to the current instance A loopback link, sometimes left behind to keep old names working.

Frequently asked questions

The computer was renamed and nothing seems wrong. That is common. Nothing needed the name yet. Replication, log shipping and multi server jobs are the usual ones that do, and they tend to be set up after the rename.

Why does SERVERPROPERTY('ServerName') already show the new name? Because it is read from the network name each time. @@SERVERNAME is stored, so it only changes when you change it.

Can I skip the restart? No. The local entry is read when the service starts, so the new name takes effect at the next restart and not before.

Why is this only Low? The instance runs fine. The cost is the feature that quietly records the wrong server, which is why it is worth half an hour.