I have set up a new BizTalk group and am setting the following error in the SQL logs.
The EXECUTE permission was denied on the object 'MsgBoxPerfCounters_GetHostQueueLength_SendHost', database 'BizTalkMsgBoxDb', schema 'dbo'.
Tracing this shows the receive host process is trying to access the MsgBox perf counters for the send host.
I can give the receive host users explicit permissions to the send host objects, but why is the receive host user trying to access performance counters of the other hosts ?
This could be because of the way the performance counters are implemented for the send/receive hosts. A send host could be one-way or two way, and a receive host could be one-way or two-way, either way it is the same set of counters that are being written. So both the send/receive hosts need access to the entire set of performance counters. Also performance counters can be designed against categories/instances specific, etc (have a look at http://msdn.microsoft.com/en-us/library/system.diagnostics.performancecounter(v=vs.100).aspx which details the performance counter class). So even through, you have different instances (handlers) for send/receive portions of the adapter, the underlying performance counter category/group would be the same.
So you should ensure that on the BizTalk systems, the BizTalk Host/Isolated Host Users group are part of the builtin "Performance Counter Users" group.
We have the same application on our QA and dev environments though, and these do not experience the error.
The MSGBOX_PerfCounters sprocs on these environments are only called by their own host users.
I'm also seeing errors where the receive host user is trying to execute the PerfCounters SPROCs from our orchestration host.
How does the receive host know anything about the orchestration host sprocs ?
- Edited by ConfusedKris Monday, March 11, 2013 2:35 PM
Our QA environment uses different accounts, but we have a second production group that uses the same configuration as this new group, and experiences no errors. I've been through host and DB configuration and can see no differences between the group that is working, and the group that experiences the error.