With some encouragement and prodding from some of the other senior members of my team I finally spun up a BizTalk 2013 VM through the Azure Portal. I must say that I was very pleased with the experience and am very excited at the potential that hopefully will be unleashed by this and other such platforms.
Once I got my BizTalk 2013 VM all configured up, I did what I do on every single dev BizTalk machine that I setup…I changed the schedule for the TrackedMessages_Copy_BizTalkMsgBoxDb SQL Agent job such that it runs every 10 seconds instead of the default every one minute. This results in me wasting less time waiting to see tracked messages and removes the temptation for me to pull out what little hair I have left in frustration.
However after making the change I found that the SQL job was failing with the error “Could not find server ‘xxxxx’ in sys.servers”.
I followed the instructions on this lifesaver of a blog post by Christian Loris which suggested that the wrong server name might be registered in SQL Server. Sure enough this turned out to be the case, and I can only guess that this might be a byproduct of the way that Azure spins up a VM with the specified DNS name from a base image.
If anyone else has similar problems with their BizTalk 2013 VM then do the following (credit to the aforementioned blog post). First check that there is indeed a server name clash by running the below queries against the Master database and seeing whether they return anything other than the expected server name (the second query should return an unexpected value).
Once you’ve confirmed a naming issue you need to drop the unexpected server name and add the correct server name as below.
Once you have done this you will need to restart the SQL Server service and your TrackedMessages_Copy_BizTalkMsgBoxDb job should start working again.
Another alternative that was suggested to me by my colleagues who also encountered the same issue recently was to change the server name used in the SQL agent job step to the unexpected alias. They also mentioned that they encountered the problem immediately after their first reboot of the VM so it is quite likely that many if not most people spinning up a Biztalk 2013 Azure VM will encounter this problem.