LSASS process can get into a spin with too many MSMQ messages
There's a new KB article out (although the hotfix was produced last year):
The following is taken from the KB:
SYMPTOMS
Consider the following scenario. You are running Microsoft Message Queuing on a local Windows Server 2003-based domain controller with global catalog (GC). Too many messages are sent to a public queue of Message Queuing. In this scenario, the Lsass.exe process may use a high percentage of CPU resources.CAUSE
This problem occurs because sending messages to the public queue involves a GC query. For ordinary domain controller connections, the result of the DsGetDCName function is cached. However, for GC connections, the result is not cached. Therefore, all serverless calls that connect to a domain controller over the GC port incur the expense of the DsGetDCName function. This behavior causes high CPU utilization in the lsass.exe process.
So I had to look up what serverless meant. Apparantly:
"A serverless bind string is one that does not contain the name or IP address of the target server. Serverless binds are used to locate the best domain controller to handle the request."
This is for convenience when some application needs to locate a domain controller occasionally. Unfortunately it doesn't work too well with performance-centric systems like MSMQ where minimising DC location activity is important. So the solution is to do a "server bind" if the domain controller is also a GC and then fall back to a "serverless bind" upon failure.