So, related to my last post, I got the SB piece I needed working on my dev server and then scripted it out to run on the replication database on the production servers. Then, a quick test to make sure everything works:

    DECLARE @msg XML
    --DECLARE @body nvarchar(1000)
    SET @msg = ''

    DECLARE @dialogHandle uniqueidentifier
    BEGIN DIALOG CONVERSATION @dialogHandle
        FROM SERVICE [InitiateReplicationRequestService]
        TO SERVICE 'ProcessReplicationRequestService'
        ON CONTRACT [ProcessReplicationRequestContract];
    SEND ON CONVERSATION @dialogHandle
        MESSAGE TYPE [ProcessReplicationRequestMessage]
            (@msg)
    END CONVERSATION @dialogHandle
print @dialogHandle

go

RECEIVE convert(nvarchar(max), message_body) FROM dbo.ProcessReplicationRequestQueue

And it didn't.

For a couple hours of hitting my head against the desktop and querying Google. Until I finally came up with the right question to ask which led to this site, where I found the tools to help me. Turns out, I've got a bit of a minor annoyance of a situation that was easily remediable, once I knew what the problem was, and it's one that has cropped up before.

Our SQL Servers are all set up for mixed authentication. They also all live on a domain different than the one I log into all day. But that's ok, my NT account has appropriate rights and I can use trusted connections. Occasionally, however, SQL Server doesn't know about those rights when I'm not logged in, and this is one of those cases. I'd set up all of the SB pieces as AUTHORIZATION [dbo], which was fine. But, as the dbo was my account from the domain that SQL wasn't a member of, it would throw errors:

An exception occurred while enqueueing a message in the target queue. Error: 15404, State: 19. Could not obtain information about Windows NT group/user 'domain\user', error code 0x5.

Change dbo to a SQL Authenticated account, and it all works well.

FWIW, the same problem occurs when I create jobs or maintenance plans.

Onward and upward