BTSDEPLOY on a remote BiztalkMgmtDb database

Published on : May 15, 2006

Category : BizTalk Server

Saravana

Author

Do you think you can use BTSDeploy on a remote BiztalkMgmtDb database server? I thought it will after looking at its parameter list, it takes a database server name and managment database name and an XML port configuration file as arguments. So, it sounded very normal for me to take it for granted we can IMPORT/EXPORT stuff into remote Biztalk server (or groups) using the BTSDEPLOY command. Example: BTSDEPLOY EXPORT SERVER=ACCD12WS229 DATABASE=BiztalkMgmtDb BINDING=c:ports.xml UNBOUNDPORTS We architected everything based on this assumption.The idea of our project is to control multiple biztalk environments (groups) from a single web application. The project I’m working on is relatively of big scale where we have around 10 different Biztalk server groups each with 4 Biztalk servers + all those additional SQL servers, Clusters blau, blau. As a developer I was working on my workstation specifying my local workstation name as server and BiztalkMgmtDb as database parameter. For quite long time we didn’t hit any problems. Once in a while we connected to some other developer boxes remotely to do some testing and everything worked seamlessly. (Yes! it worked seamlessly connecting to a remote biztalk server). Hang on before you start cursing, why is this post then?!! All our problems started when we deployed our solution into the module testing environment. Suddenly we saw this error comming up Access Denied. Microsoft.Adapter..WSE.dll There are so many attributes which can go wrong and produce this error, some of them we considered. 1. It’s a ASP.NET web applicaiton, so some of the credentials may not be correct. (We used application pool running under specified Biztalk account). 2. You are accessing a remote Biztalk Database server, where some SSO bits involved. So, again some credentials may not be correct. 3. There could be some problem in MSDTC between the ASP.NET server and reomote DB server etc,etc…we can think of so many attributes because of the distributed nature of Biztalk itself and thing what we were trying to achive. Luckily, this error popped up on one of the developer box as well, where he was using one of our inbuild custom adapters. Then we came to a conclusion, this problem occurs only for biztalk servers(groups) where some custom adapters are deployed (BTW, WSE adapter is also an addon adapter on top of Biztalk base build). If you deploy the same adapter in the main server** and run the command against a remote server, it IMPORTED/EXPORTED successfully. Wow! so what’s going on underneath the scene. Here you go. Thanks to Microsoft folks Angus foreman and his upline MS staff at Redmond for making us understand what going on beneath the scene. When you EXPORT configuration from BiztalkMgmtDb, the result set comes as a big blob data to the main Biztalk Server** in an encrypted form. Then the main server** parse the result with the help of adapters deployed in the main server**, from where it gets all the design time parameters of the adapters from the registry and generates the output port configuration xml file. If the adapters are not present in the main server** but the data is present in the blob then there is a mismatch and BTSDEPLOY throws Access denied error. We wouldn’t have found out this error or the functionality behind if there were no custom adapters. Then, we did some work around to fix the problem, using web services and stuff. Huh! this post is already to long. **(from where the BTSDEPLOY command is executed)