A couple weeks ago one of my clients was experiencing constant “Cannot generate SSPI Context” errors in BizTalk. These are Kerberos errors and they are extremely annoying because they happen constantly whenever you are trying to use any database function with BizTalk. These would fill up the event logs on my client’s server and was a huge time waster because they would prevent me from doing just about anything with BizTalk. I would receive these errors when trying to start a host or change almost anything in the BizTalk admin console. I think the source of the problem is that something about the domain membership was different than some of the accounts on the server and this led to Kerberos authentication problems.
As a temporary fix I was able to restart the BizTalk server but the errors eventually came back again. The errors basically paralyze a BizTalk server and they are complicated to diagnose and sometimes you just do not have enough time to do diagnostics – like in a production environment. The fix provided next is similarly a workaround, it does not solve the root problem but at least provides another way to get the server working.
To attempt to resolve the problem, I tried a couple different things such as removing the server from the domain and adding it back in, but none of these things were successful at removing the problem completely. I did also try switching my Enterprise Single Sign On account and master key but this did not conclusively solve the problem. I was looking at the article at http://support.microsoft.com/kb/811889 and tried some of the suggestions but was not getting anywhere. Then I tried disabling TCP/IP for SQL connections and just use named pipes based on using SQL Configuration Manager or the SQL Network Configuration tool. TCP/IP seemed like such a fundamental protocol that I was not optimistic the problem would go away by switching protocols, but it worked for me. Many people also think that named pipes only works on a single server and functions like IPC but this is not exactly right.
My use of this workaround was on BizTalk 2010, W2K8 R2, with SQL 2K8 R2 when SQL is on a separate server than BizTalk.
The KB article above solely mentions this workaround in the context of SQL and Kerberos so I am blogging that this fix is working for me on my BizTalk server too. ‘
Thanks,
MS Innovations Blog 
Good finding Ben.Before reading your blog even I was also under impression that named pipes work on a single server.
Regards
Rohit Sharma
Thanks Rohit! I was pleasantly surprised it solved the problem. I was trying to identify why the confusion exists over named pipes and saw that the WCF named pipe binding is for on-machine communications: http://msdn.microsoft.com/en-us/library/ms731092.aspx. So I guess this is some of the confusion – “named pipes” has various implementations so it is not a consistent meaning.
Thanks,