@@SERVERNAME is NULL or empty

What this check looks for

An instance where @@SERVERNAME returns NULL or an empty string.

@@SERVERNAME is not read from the operating system. It comes from the local server entry in sys.servers, the row with server_id 0. When that row is missing, the function returns NULL. The finding names the value it saw and shows SERVERPROPERTY('ServerName'), which is the name the instance is really running under.

Why it matters

Plenty of code trusts @@SERVERNAME and never checks it. When it is NULL, that code does not always fail loudly. It often keeps going and records the wrong thing.

The places that depend on it:

  • Replication compares the publisher and distributor names to the local name, and setup or the agents fail when they do not match.
  • 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 end up with NULL in every row.

It is a Low severity check because the instance itself keeps running. The damage shows up later, in the feature that needed the name.

The usual causes:

  • The computer was renamed. SQL Server does not follow the rename. The old name stays in sys.servers until someone updates it, and if the old entry was dropped on the way, the local entry is gone entirely.
  • Someone ran sp_dropserver on the local entry and did not add it back.
  • An image or restore of master brought in a sys.servers that does not include a local row.

How to confirm it yourself

Compare what the instance thinks its name is with what it is really running as:

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

If AtAtServerName is NULL, this check is correct. If it has a value that differs from ActualServerName, you have the neighboring problem of a stale name after a rename, which the same fix covers.

Look at the local entry directly:

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

No row means the local entry is missing.

How to fix it

Add the local entry back using the name SERVERPROPERTY('ServerName') returned, then restart the SQL Server service. The new name is not used until the restart.

-- the name to use: SERVERPROPERTY('ServerName'), for example
-- SQLPROD01 for a default instance or SQLPROD01\INST2 for a named one
EXEC sp_addserver @server = N'SQLPROD01', @local = 'local';

Then restart the service and confirm:

SELECT @@SERVERNAME;

If the finding showed a stale name rather than NULL, the old local entry has to go first:

EXEC sp_dropserver @server = N'OLDNAME';
EXEC sp_addserver  @server = N'NEWNAME', @local = 'local';

A few things to know before you do it:

  1. The restart is part of the fix. Plan it as you would any service restart. Until it happens, @@SERVERNAME still returns the old value.
  2. Use the exact name from SERVERPROPERTY('ServerName'), including the instance name for a named instance.
  3. Do not rename a clustered instance or an Availability Group replica this way. Those names come from the cluster and are changed there.
  4. After the restart, look at anything that recorded the wrong name. Replication publications, log shipping configuration and multi server jobs may need to be checked or recreated.

How long it takes

About half an hour, most of it waiting for a restart window. The change itself is one statement.

Report Why you would go there
Linked Servers Whether any entry in sys.servers still points 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
Linked server points to the current instance A loopback linked server, often created after a rename to get the old name working.
Linked Server With No Data Access Another configuration problem in sys.servers.

Frequently asked questions

The server was renamed months ago and nothing broke. Nothing needed the name yet. Replication, log shipping and multi server jobs are the common ones that do, and they tend to be set up well after the rename.

Does sp_addserver need the instance name for a named instance? Yes. Use the full value of SERVERPROPERTY('ServerName'), such as SQLPROD01\INST2.

Can I avoid the restart? No. @@SERVERNAME reads the local entry when the service starts, so the change takes effect at the next restart and not before.

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