SP with xp_cmdshell gives an error in the MessageQueue, but executes successfully in SSMS.

Question

Hi All,
I have a SP, which calls xp_cmdshell in it. This SP is being used in a MessageQueue. 
The SQL server and Agent services are configured using a Domain service account, and this service account has a login under the sysadmin server role as well.
When the MessageQueue is invoked, the SP returns the following exception :
The xp_cmdshell proxy account information cannot be retrieved or is invalid. Verify that the '##xp_cmdshell_proxy_account##' credential exists and contains valid information.
But when I execute the SP in SSSMS, under the service account login (which is a sysadmin), it successfully executes.
I even created the ##xp_cmdshell_proxy_account## credential, but the Message Queue never stops giving this error.
This is how the queue looks like :
CREATE QUEUE [dbo].[TestxmCmdshellQueue]
WITH STATUS = ON ,
RETENTION = OFF ,
ACTIVATION (      STATUS = ON ,
                        PROCEDURE_NAME = [dbo].[SpWithxp_cmdshell_Init] ,
                        MAX_QUEUE_READERS = 5 ,
                        EXECUTE AS N'dbo'  ),
POISON_MESSAGE_HANDLING (STATUS = OFF) 
The Service account is configured as a Local Administrator in the Local Server as well.
I am running SQL Server 2008 R2 Sp2 on a Windows Server 2008 R2 Enterprise Machine. 
Please let me know what I am missing here.

Answer 1

I Made TRUSTWORTHY = ON in the database and the SP executed without any problem by the Message Queue.
No, that is not the solution.
Yes, it works. And it is a lot simpler than the solution I pointed you to. But it opens a big security hole. Or, well, depending how things you are on your server, it may be entirely uncontroversial. But as long as I don't know anything, I will have
to assume that it is a security hole. And even if there is no one today on the server who is db_owner in the database but who should not be sysadmin, that could happen in the future.
So, to anyone else who is reading this: don't set your databases to be trustworthy, unless you fully understand the implication. The correction solution is to use certificate signing. I describe this in detail in my article, and this article also explains
the dangers with TRUSTWORTHY.
http://www.sommarskog.se/grantperm.html
Erland Sommarskog, SQL Server MVP, [email protected]