Automating Azure ServiceBus Key Updates in BizTalk

Hooking BizTalk up to an Azure Service Bus is a straightforward enough process, thanks to the SB-Messaging adaptor. When creating Receive Locations and Send Ports that make use of this adapter, you specify the Service Bus endpoint that you want to connect to and give it the shared access policy name and authorisation key.

But what if you have a company policy that dictates that all access keys need to be rolled once a month?

Or even if you don’t have such a policy, but a situation arises where you need to roll the keys in order to prevent access by a third party?

You could manually open each SB-Messaging Send Port and Receive Location in the BizTalk Administration console and update all the keys. But what if you have 100 such entities? And then replicate that across other environments that may also need to be updated? This has now turned in to a very time-consuming undertaking, during which you may have non-functioning Receive Locations and Send Ports.

Fortunately, there is another way. By making use of WMI, the BizTalk ExplorerOM, and Azure PowerShell you can almost completely automate the process.

There are just a couple of caveats however:

• You do need to be able to query the Service Bus configuration to retrieve the keys,
• and you need to have Administrator access to BizTalk.

As long as that is the case, then the basic process flow is as follows:

1. Initialise the BizTalk.ExplorerOM.

 

2. Login to the Azure subscription hosting the Service Bus.

 

3. Query BizTalk for all the Send Ports that make use of the SB-Messaging adapter. For every SB-Messaging Send Port, get the name of the Service Bus and Queue it is connected to, and the Shared Access Policy name it is using. For the Send Ports, I had issues with updating the required configuration using the BizTalk.ExplorerOM, so here I am using WMI. The end result is the same.

 

4. Query the Azure Subscription for a matching Service Bus of that name. If one is found, then request the key for the Shared Access Policy name, within the Queue that we are connected to.

 

5. If we successfully retrieve one, then update the BizTalk configuration with the key that we have retrieved.

 

6. If the Send Port is in a Started state, then restart it to pick up the configuration changes.

 

7. Query BizTalk for all the Receive Locations that make use of the SB-Messaging adapter. This example uses the BizTalk.ExplorerOM to complete this task.

 

8. From here, the process is almost identical to updating the Send Port, except for how we commit the changes back to BizTalk due to the fact that we are using the BizTalk.ExplorerOM this time, and not WMI.



In addition to being used in the event of having to roll keys, this method of updating the Service Bus keys can also be incorporated into the process of deploying BizTalk applications, in conjunction with BizTalk Deployment Framework.

A custom target can be added to the BTDF so at deploy time the correct key is retrieved from the relevant Service Bus Queue. This can be a good alternative to storing sensitive configuration data in the BTDF settings spreadsheets.