I had an interesting gotcha today.
I recently deployed a BTS App and then decided to clean it up and move it to more
appropriately named Hosts/Host Instances.
All appeared to work well I even reinstalled a new MSI AND updated the BTS App bindings
I have a Dynamic Send Port that I decided to stop for a last change
(before telling the business to commence testing) – 10 mins I thought. How wrong
BTS Admin console reported back an error with ultimately the BizTalk.ExplorerOM =
grief.
There’s a hotfix for BTS2006 – http://support.microsoft.com/kb/932700 for
this exact error.
How happy was I that I found thisshame I was working on BTS2009! I downloaded and
try to apply the fix on my box, and the hotfix was smart enough to detect I wasnt
on bts2006 x86 🙁
Roll up the sleeves time.
Digging further in the event viewer I noticed 2 entries talking about not being able
to connect to the MsgBoxDB and the other not being able to find a stored proc
The following stored procedure call failed: " { call [dbo].[bts_AdminOperatorsStartAndStopService_BTSHOSTNOTTHERE]( ?, ?, ?, ?)}". SQL Server returned error string: "Could not find stored procedure 'dbo.bts_AdminOperatorsStartAndStopService_BTSHOSTNOTTHERE'.".
NOTE: BTSHOSTNOTTHERE = a previous host that was used and was deleted
as part of the ’cleanup’. You’d think that if they were lingering references I shouldn’t
have been able to delete this guy.
I tried many things in the admin console and WMI to try and remove this guy but no
go.
After a little digging I went to the BizTalk Management DB and found
a table called bts_dynamicport_subids which held the stale info I
needed to change.
Here’s the magic I executed these queries against the Management
DB, restarted the BTS Admin Console and we’re back in the game 🙂
SELECT * FROM bts_dynamicport_subids where nvcHostName=’BTSHOSTNOTTHERE’ UPDATE bts_dynamicport_subids SET nvcHostName = 'BizTalkServerApplication’ Where nvcHostname=’BTSHOSTNOTTHERE’
Now to reclaim that lost time
Have a great day!