SQL SERVER – Msg 32055 – sp_refresh_log_shipping_monitor – There Was an Error Configuring the Remote Monitor Server

Log shipping was deployed, every backup, copy and restore job was green, and the project still could not be signed off, because the monitor report was wrong. Refreshing the monitor by hand gave Msg 32055: there was an error configuring the remote monitor server. I fixed it at the time by giving a linked server the sa password. I would not do that today, and reading the procedure on SQL Server 2025 shows why the error told us so little.

The Situation

The log shipping itself was healthy. I checked the job history, and I compared the data file sizes on the primary and the secondary. The logs were being applied. What was broken was only the reporting: the transaction log shipping status report was stale and raising alerts that were simply wrong.

So I asked the secondary to refresh its monitor data by hand:

Msg 32055, Level 16, State 2, Procedure sp_refresh_log_shipping_monitor, Line 248
There was an error configuring the remote monitor server.

The documentation says only sysadmin members can run this procedure. We were already sysadmin. So that was not it.

Why the Message Says So Little

The procedure’s source is readable. On my SQL Server 2025 instance:

SELECT OBJECT_DEFINITION(OBJECT_ID('sys.sp_refresh_log_shipping_monitor'));

The part that matters, trimmed:

begin try
    exec @retcode = @linkcmd @mode = 2, ...
end try
begin catch
    select @retcode = 1
end catch
...
if (@retcode = 0)
    return 0
else
begin
    raiserror(32055, 16, 2)
    return 1
end

There it is. The procedure calls the monitor server through a linked server. If anything goes wrong, the CATCH block sets a return code of 1 and throws the real error away. Then 32055 is raised in its place.

So “there was an error configuring the remote monitor server” is not a diagnosis. It is a wrapper around a message you never get to see. Login failed, server not found, certificate not trusted: all of them come out as 32055.

Get the Real Error

Log shipping creates its own linked server to reach the monitor. Its name starts with LOGSHIPLINK:

SELECT name, data_source, provider
FROM   sys.servers
WHERE  name LIKE 'LOGSHIPLINK%';

Then test that linked server yourself, outside the procedure, so nothing catches the error:

EXEC sp_testlinkedserver N'LOGSHIPLINK_MONITORSRV_12345';

sp_testlinkedserver hands the real message straight back. I checked on my own instance that it does, with a name that does not exist:

Msg 7202
Could not find server 'NOSUCHLINK' in sys.servers.

Against a real LOGSHIPLINK server that is failing, this is where you will see the login failure or the network error that 32055 was hiding. In my client’s case the fix that worked points at the login. The linked server was reaching the monitor with a security context the monitor did not accept.

What I Did Then, and Why I Would Not Now

I opened the LOGSHIPLINK linked server in SSMS, went to Security, chose “Be made using this security context”, and typed in the monitor server’s sa login and password. The refresh worked. The project was signed off.

It also left the sa password stored in a linked server, used by anyone who could run a query through that link. That is a much bigger problem than a stale report. And it is a hand edit to a linked server that log shipping built for itself, so log shipping knows nothing about it. The next person to touch the configuration will not know it is there.

The Better Fix

Log shipping has its own settings for how it connects to the monitor. They are parameters on the procedures that configure it, and they are all present on SQL Server 2025. I listed them from the procedure definitions:

sp_change_log_shipping_primary_database
    @monitor_server_security_mode
    @monitor_server_login
    @monitor_server_password
    @monitor_connection_options

sp_change_log_shipping_secondary_primary
    @monitor_server_security_mode
    @monitor_server_login
    @monitor_server_password
    @monitor_connection_options

Security mode 1 means Windows authentication. That is my first choice, because there is no password to store at all. Give the Windows accounts that run SQL Server and SQL Server Agent on the primary and the secondary a login on the monitor, with only the access they need in msdb.

If you must use a SQL login, use mode 0 with a dedicated login made for this one job. Never sa.

The newer @monitor_connection_options parameter takes a connection string, and the procedure checks it before storing it. If your monitor server needs particular encryption settings, this is the place for them. I read that from the procedure definition. I do not have a log shipping setup here to test it end to end.

Worth Knowing

The monitor is optional. Log shipping works without it, and every job keeps its own history. The monitor only gathers the status into one place. So when the monitor breaks, the data is almost always fine, and the fix can wait for a calm hour rather than a panic.

That was true for my client too. Nothing was lost. The only thing waiting was a signature.

Msg 32055 is not the real error, it is the real error with its label torn off.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.