A quick blog post to document a tough lesson learnt by myself so others can hopefully avoid making the same mistake. Changing a BizTalk WCF send port’s send handler (i.e. the host instance it is associated with) will remove all passwords that are currently configured on the send port. This includes credentials to access the target service as well as the proxy server password if there is one. This appears to be the case with WCF-SQL receive locations as well, however a quick test with the File adapter showed that this behavior might not be consistent with non-WCF adapters so it’s best to try your change on a development environment first.
How can you tell if your password has been wiped? Normally when you access the send port, if you have previously entered a password then you will see the black circles indicating a masked password is present. If the password has been wiped then the field will be totally blank as below.
As a practice I would encourage others to avoid hardcoding passwords on send ports and to use the SSO’s credential mapping facilities instead (a blog post on how to achieve this using the BRE Pipeline Framework soon). This isn’t applicable for proxy server credentials but those can typically be set on the send handler level so you don’t have to worry about associating then with your send ports.
Moral of the story, if you’re changing your adapter handler on a port and there are passwords associated with the port then re-enter them.
I thought I would share a trick which might seem obvious to those who know it already, but should seem like an eureka moment to those who don’t.
How many of you have tried to use the Performance Monitor tool to try to track resource usage of a BizTalk application and have been stumped as to which Host Instances you are actually tracking? The problem with Performance Monitor is that for many of the counters (especially the generic non-BizTalk specific counters such as Process or Memory) the Host Instance names are not listed, but instead all you see are the service names (BTSNTSVC or BTSNTSVC64) with a counter based on how many instances of that specific service are currently running, as in the below screenshot.
You could be creative (you won’t believe the number of stories I’ve heard of how people work around this) and start your Host Instances one at a time and try to figure out which one relates to which Performance Monitor instance but there is a better way. The key is to add the performance counter called “ID Process” under Process for each of the different BizTalk Services as in the below screenshot.
Now that you’ve added the ID Process performance counters, you can click on any of the specific instances in Performance Monitor and if you take a look at the values in the Last/Average/Minimum/Maximum columns (they’ll all have the same value) you’ll find that they contain the value of the PID (Process ID) for a specific host instance which you can find under the Services tab of the Windows Task Manager as per the below screenshot. You have now built an association between the Performance Monitor Instance and the BizTalk Host Instance, and those associations will carry over to other Performance Monitor counters.
Something to keep in mind is that when you restart Host Instances they will get new PIDs, and if you restart all the Host Instances at the same time there is a possibility that the order of Instances in Performance Monitor might get swapped around. My recommendation is that if you are currently profiling your BizTalk environment using Performance Monitor and you want consistent results, you should either track your Data Collector Sets to separate output files each time you restart your Host Instances, or you should look into restarting your Host Instances one at a time to maximize (I’m not sure if this is a guarantee) the chance that the order will stay the same. Regardless which path you choose, it is important to take note of which Host Instance relates to which Performance Monitor instance, especially if you plan on studying the results in the future at which point it might no longer be possible to link the associations.
I’m pleased to announce that the White Paper titled “The A-Y of running BizTalk Server in Microsoft Azure” which I have been working on for the last two months is now available to download on the BizTalk 360 White Paper collection.
Writing this White Paper has been a momentous task, especially given that Microsoft Azure is an ever-changing entity (I’m pretty certain my synopsis on D-series VMs is already a bit dated since Microsoft have recently released new information stating that they sport faster CPUs, which I was previously unaware of, in addition to having SSDs) and I owe all the reviewers a big deal of thanks for their help.
This endeavour started out as a blog post (I just deleted the draft) and it quickly became apparent that the topic was well larger than anything I could cover within a single post and required a lot more attention to detail.
I hope the paper proves to be interesting and valuable to you, and as always welcome any feedback.
It will be nice to get back to blogging again 🙂