BizTalk Server: Could not store transport type data for Receive Location to config store. Access denied.

Welcome back to another blog post on the BizTalk Serve saga of Errors and Warnings, Causes, and Solutions. Last week, while I was trying to help a client recreate their developing environment into a brand new BizTalk Server 2020 development environment, and when I was trying to export the binding files, I got the following error:

TITLE: Export Bindings
——————————
Failed to update binding information. (mscorlib)
——————————
ADDITIONAL INFORMATION:
Could not store transport type data for Receive Location ‘receive-location-name’ to config store. Access denied. See the event log (on computer ‘computer-name’) for more details.
 (Microsoft.BizTalk.ExplorerOM)

For those unaware, binding creates a mapping between a logical endpoint, such as an orchestration port or a role link, and a physical endpoint, such as a send, a receive port, or a party. This enables communication between different components of a BizTalk business solution. You can create bindings by using the BizTalk Server Administration console.

A binding file, on the other hand, is a .xml file that contains binding information for each BizTalk orchestration, pipeline, map, or schema in the scope of a BizTalk assembly, application, or group. The binding file describes what host each orchestration is bound to and its trust level, as well as the settings for each send port, send port group, receive port, receive location, and party that has been configured. You can generate binding files and then apply the bindings they contain to an assembly, application, or group to avoid needing to manually configure bindings in different deployment environments.

Cause

Usually, this error may occur if:

  • The Enterprise Single Sign-On Service is stopped.
    • This was not the case since I could access and browse in the administrative console.
  • Or the current user who is trying to export the binding file is not a member of the SSO Administrators group.

In fact, this last option was my problem.

Solution

The solution to this problem is quite simple. You can authenticate with a user who is a member of both the BizTalk Server Administration and SSO Administrators groups or add your user to the SSO Administrators group.

To add the user to the SSO Administrators’ group, assuming that we are using local groups and this is a standalone environment, you need to:

  • Access Local users and groups by:
    • Click Start > Run.
    • Enter lusrmgr.msc in the box and click OK.
    • Alternatively, you can use Windows Search to search for Local Users and Groups.
  • Click on Groups and do.
  • Right-click on the SSO Administrators group and select the option Add to Group…
  • On the SSO Administrators Properties window, click on Add…
  • On the Select Users window, set your user and click OK.
  • Click OK.

Alternatively, they can add the BizTalk Administrators group as a member of this group. So all BizTalk administrators will automatically be part of this group also.

I hope you find this helpful! If you liked the content or found it useful and want to help me write more, you can buy (or help me buy) my son a Star Wars Lego! 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.

Leave a Reply

Your email address will not be published. Required fields are marked *

turbo360

Back to Top