This blog will talk about an issue with the version of Microsoft.BizTalk.Interop.SSOClient that ships with BizTalk 2016 and how I solved it.
Microsoft.BizTalk.Interop.SSOClient Migration Issue
After upgrading from BizTalk 2013 R2 to BizTalk 2016 we saw “A failure occurred when retrieving the SSO ticket” for messages sent to a FTP send ports. Trust me this error occurs because the version of the SSO assemblies is different between these two BizTalk versions. Firstly, before I tell you why let me tell all about SSO tickets.
Using SSO Affiliates
I use SSO Affiliate Applications to store credentials for Receive Locations and Send Ports to avoid either having the credentials in the Bindings (which is insecure) or having to re-enter the credentials after each release (which causes releases to take too long). I am following Coen Dijkgraaf here. Thus on each port we configure something like this.
The port looks up the SSO Affiliate at runtime and retrieves the password for the SSO database at runtime. An example of how we configure SSO Affiliates is shown below.
Send ports require an SSO ticket if you configure a SSO Affiliate. Thus, you must assign a SSO ticket for each message, on every send port that uses an SSO Affiliate Application. If you do not then you get a failure like “A failure occurred when retrieving the SSO ticket” that we see above. Receive locations do not require a SSO Affiliate. A SSO ticket is part of the context.
Assigning a SSO ticket
We use the BizTalk BRE Pipeline Component Framework to assign a unique ticket to each message. Please read some of my previous blog articles for more links to this amazing framework. One of the vocabularies does this for us easily in a business rule e.g.
Next assigning this execution policy to the pipeline adds a ticket to the message in BizTalk 2010.
In BizTalk 2013 R2 the ticket is not assigned unless you redirect the assembly version of Microsoft.BizTalk.Interop.SSOClient that the BRE Pipeline Component Framework uses. Thus, our BTSNTSvc.exe.config and BTSNTSvc64.exe.config contain the following customization.
The BRE pipeline component framework was built using version 5.0.1.0 of Microsoft.BizTalk.Interop.SSOClient. In order to use the 9.0.1000.0 version that ships with BizTalk 2013 R2 you need to redirect the binding reference in the app configuration file.
The issue
Finally, now that we understand SSO ticket error I can now begin to talk about why BizTalk 2016 is different. If we look the properties of the Microsoft.BizTalk.Interop.SSOClient dll that ships we see the following
I wrongly assumed that assembly version was 10.0.2205.0. The SSO ticket error does not disappear when the redirect version is 10.0.2205.0 and not 9.0.1000.0. Tracing of the BRE Pipeline Component framework shows that it is not binding to the SSOClient.
The Solution
Finally after much head scratching I decided to probe the troublesome assembly with gacutil -l and to my surprise I saw
Microsoft.BizTalk.Interop.SSOClient, Version=10.0.1000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL
Editing the app config file gave the desired result. The SSO error disappears.
Conclusion
I have learnt that you should not assume that the file or product version is the same as an assembly version. This makes a difference if you use assembly redirection.
