Gokul's Blog

Leave a comment

BizTalk Jobs and BizTalk Databases



Handling the growing size of BizTalk database’s log db


BizTalk Message Viewer


Leave a comment

Renaming your BizTalk machine

Check this useful article from Saravana Kumar for BizTalk Machine rename.

Link to the article: http://blogs.digitaldeposit.net/saravana/post/2008/08/27/Renaming-your-BizTalk-machine.aspx

Copy of the post.

Anyone who been working on BizTalk server long enough will know renaming a BizTalk machine is not a trivial task. It always involves quite a bit of manual work, things like

  • Un-configure the existing setting either using the UI or ConfigFramework /U switch
  • Deleting the Databases manually,
  • Re-Configuring it, which will raise tons of errors.

It’s never been a smooth procedure. Recently I had to go through this painful process, because due to corporate policy changes, they renamed all of our developer workstations.

Here I’ll explain how we utilized the Disaster Recovery scripts available as part of BizTalk installation to help us rename the BizTalk machines smoothly (mainly without the pain of un-configure and re-configure). If everything goes smoothly you should be done in less than 10 minutes.

Disclaimer: Do this at your own risk, it worked for me.

Edit SampleUpdateInfo.xml file:

  • Navigate to the following folder C:\Program Files\Microsoft BizTalk Server 2006\Schema\Restore and open the file SampleUpdateInfo.xml file in your favourite editor.
  • Find and Replace all the "SourceServer" value with your original Server name
  • Find and Replace all the "DestinationServer" value with your new Server name.
  • Stuff related to Analysis, BAM, RuleEngine, HWS, and EDI are commented by default, if you are using them in your environment un-comment the required ones.
  • Save and Close the file.

Run the scripts to update database and registry:

Run the following command in the command prompt

cscript UpdateDatabase.vbs SampleUpdateInfo.xml

This script will update all the BizTalk databases with the correct server name. You need to run this script only once in a multi BizTalk server environment.

Run the following command in the command prompt

cscript UpdateRegistry.vbs SampleUpdateInfo.xml

This script will update the local registry with the correct server name. You need to run this script on each BizTalk server you have in the group.

Restart WMI Service:

Open the Service control manager (services.msc) and restart the "Windows Management Instrumentation" service. This step is required because most of the administration tasks you perform from the admin console depends on WMI.

Promote the new server as master secret server:

Follow the steps outlined in this link http://msdn.microsoft.com/en-us/library/aa559842.aspx to promote your new server as master secret server.

Configuring the BizTalk Administration Console:

Open the BizTalk administration console, click on the existing node (the one pointing to original server), right-click and remove.

Right click on the "BizTalk Server 2006 Administration" node and select "Connect to Existing Group…". Provide the new Server Name and select the BizTalkMgmtDb database.

Click Ok.

Update your Visual Studio project properties to point to new Server:

Most of your Visual Studio BizTalk projects will be still pointing to the old management db server. Trying to deploy your project will result in an error message like this "Login failed for the user ”. The user is not associated with a trusted SQL Server connection. "

Couple of Caveats:

At this point you should be able to see a working BizTalk Group. I experienced couple of problems,

1. When your try to expand the "Platform Settings\Adapters" and select any adapter from the list, you’ll see an error message like this "Unable to load adapter handler for XXXX adapter. (Microsoft.BizTalk.Administration.SnapIn) Access Denied (System.Management)"


The machine name in the error message is pointing to my old server name. I wrote a small console application utilizing the BizTalk WMI classes and they all worked fine. It shows clearly the wrong server name is stored somewhere and the admin console is trying to connect to the old server. BTW there won’t be anything in the event viewer to assist you 🙂

I opened the SQL Management studio and made the following changes in the BizTalk Management Database (BizTalkMgmtDb)

1. adm_group table, SSOServerName Column: This one had the original server name, I entered the new server name

2. adm_server table, Name column: Again this one had the original server name, I entered the new server name.

Restart all the BizTalk/SSO services.

NOTE: These procedures were performed on a Windows XP workstation (single BizTalk installation), SQL Server installed on the local machine. No named SQL instance. The procedure should work for Windows 2003 on a remote SQL Server with multiple BizTalk servers. I’m not sure about the SQL Named instance setup(example people using SQL Express, where the instance name will be for example ServerName\EXPRESS).



Leave a comment

Storing Configuration values with BizTalk

There are many ways by which we can store configuration, cross-reference information in BizTalk. I will try to discuss some of the ways which I have used before.

1. Using BTSNTSvc.Config’s appSettings to store the configuration information. This is similar to App.config in .Net. One more way to isolate the storage of appSettings values is to store in a different file and set the file attribute in the appsettings TAG to an External Filename.

E.x (In BTSNTSvc.config File)
<appSettings file="BizTalkAppConfig.config">

External File:
  <add key="ConnectionString" value="Integrated Security=SSPI;Data Source=localhost;Initial Catalog=BizTalkMsgBoxDb" />
  <add key="DEBUG_Mode" value="true"/>

2. Using SSO Configuration to store the information. Richard Seroter came up with a handy tool to store and retrieve values with SSOConfig db. The link I have added below has some added feature to it. http://geekswithblogs.net/paulp/archive/2008/05/16/122205.aspx

3. Incase if you are using a map, getting to these values or if the number of cross-reference values you store is more then the above design becomes a bit more complex option. Using the Xref set of tables and btsXrefimport option we can store configuration values and used by the MAP as well use the exposed API to get the application/common value. Link: xrefseed.zip
A good write up of some ways to store map data is here http://geekswithblogs.net/michaelstephenson/archive/2006/12/24/101995.aspx

There is a write up from Michael Stephenson regarding the same topic Click To View Entry

One more interesting article regarding storing custom configuration settings using Enterprise Library: http://geekswithblogs.net/paulp/archive/2008/06/11/122803.aspx

Leave a comment

BizTalk Assembly Extension (BtsAsmExt.dll)

regsvr32 "C:\Program Files\Microsoft BizTalk Server 2006\Developer Tools\BtsAsmExt.dll"
(where C:\Program files\Microsoft BizTalk Server 2006 is my BizTalk install location) and then take a look at Windows Explorer. There is an extra menu item called "BizTalk Server Assemblies."

Opening this menu item shows all deployed BizTalk assemblies. Opening any of these assemblies will show you all the BizTalk artifacts that are part of the assembly. You can double click on any of these (a schema, or an orchestration, for instance) to get an XML representation of the artifact.
Clicking View > Explorer Bar > BizTalk Server Search will open up a pretty good search tool for searching across all artifacts. The search results will also tell you what references the items displayed.

Taken from: http://aroder.blogspot.com/2008/05/biztalk-assembly-extension-btsasmextdll.html

Leave a comment

Restoring BizTalk ports and orchestrations after maintenance shutdown

Given a scenario where you have a maintenance window, and need to shut down one or more applications, you might find it challenging when you are going to start them up again.

If you are working with a large BizTalk solution, the Application Stop and Start functionality might not be useful. -If you had ports that where disabled, stopped or unenlisted before shutting the application down, these will also be started when starting up the application again. If these ports and orchestrations where disabled for a reason, this approach will not be acceptable.

Link to Article

Link to Console App