Sep 192007

With the 2006 deployment paradigm shift, I have been kind of left behind.

I have lately been thinking a lot about how to make things better/easier/lazier for me, and it got me looking at the new automatic features in the creation of the MSI.

One of the things is the ability to deploy BAM definitions automatically. Let’s review how this is done:

  1. On the development server, you still need to manually deploy the BAM definition.
    bm deploy-all
  2. You then want to add the BAM definition file to your application as a resource. Some things to keep in mind, you need to make sure you define a destination, otherwise the BAM definition file does not exist on your next environment. I am using variables that are accessible from the BTSTask.
    BAM Resources
    Doing this will ensure a successful installation of your BAM definition on your new environment, congratulations! However the issue is that if you undeploy the BizTalk application, the BAM definition still exists and is not removed. I asked Keith Lim if this was a feature or flaw. He informed me that this was by design. “I checked with our feature team and this is indeed by design.  The reason is that, for BAM activity deployment, there could already be user data in the database tables and we don’t want to risk having user data deleted implicitly.” — Well, for me, most times I don’t want to have to manually go to an environment that I normally don’t have access to anyway and undeploy BAM definitions if I need to redeploy code, because 90% of the time I will want to start all over with BAM than keep working with the old data. I want a way to automatically undeploy the BAM definition! Here is how:
  3. Now you will need to add a script that will actually remove the BAM Definition. Let’s first create the script (uninstall.bat) and then add it. The code below does the following, determines that it is undeploying and then undeploys the BAM definition
    set LogFile=c:\%BTAD_ApplicationName%_Undeploy.log
    REM ### Uninstall part of the script called for an existing application
    if “%BTAD_ChangeRequestAction%”==”Delete” (
      if “%BTAD_InstallMode%”==”Uninstall” (
        if “%BTAD_HostClass%”==”BizTalkHostInstance” (
            echo “c:\Program Files\Microsoft BizTalk Server 2006\Tracking\bm.exe” remove-all -DefinitionFile:”%BTAD_InstallDir%\%1″ >> “%LogFile%”
            “c:\Program Files\Microsoft BizTalk Server 2006\Tracking\bm.exe” remove-all -DefinitionFile:”%BTAD_InstallDir%\%1″ >> “%LogFile%”
            echo “Pre uninstall part of the script called for %BTAD_ApplicationName%” >> “%LogFile%”

    Now you might ask yourself, “why don’t you determine the path of the install directory right from within the batch file” like this:

    for /f “skip=2 tokens=2,*” %%f in (‘reg query “HKLM\SOFTWARE\Microsoft\BizTalk Server\3.0” /v “InstallPath”‘) do SET BTSbm=”%%~gTracking\bm.exe remove-all -DefinitionFile:”
    echo “%BTSbm%%BTAD_InstallDir%\%1” >> “%LogFile%”

    I tried for quite a while, but for some reason the logic will not resolve to the install path. If anyone knows why, I would be happy to add how to get it to work, in the meantime, go ahead and hard code the install path.

  4. Now you would think that you would simply add the batch file as a PostProcessingScript like this
    however there is no way to add an argument to the calling of this batch file (remember “%BTAD_InstallDir%\%1” ?) So we need to manually add it. We also need to make sure it is a PostProcessingScript, as the documentation states here: “During uninstallation, all scripts run in the opposite order that they run during installation. Therefore, post-processing scripts run at the beginning of uninstallation and pre-processing scripts at the end of uninstallation.” – We don’t want to delete the BAMDefinition.xml before the undeploy process gets to it do you?
  5. I need to add the batch script with an argument (the BAMDefinition.xml). I need to follow the instructions as documented here.
      Import PostProcessing Script
  6. Let’s go back and see the script has been added correctly (click to enlarge)
  7. Let’s create the MSI and don’t extract the Global Parties (since we don’t care about them anyway)
     Create MSI Part 1
  8. Save the file
     Create MSI Part 4
  9. Now you can install it in your new environment. Having done that, just to make sure, lets take a look at the install directory to make sure the two files are there:
     Installed Files
  10. Also the BAM Views are there:
    BAM Views
  11. So lets undeploy the code and see if the magic happens! (Of course it would, or this blog entry would be a total sham!)
  12. And finally the log that we created in the batch script

Congratulations, you now have a MSI that will deploy a BAM solution to the environment you need and will also undeploy the definition when you uninstall the application!


Wouldn’t it be nice to have a dialog box during the uninstallation of a BizTalk application where there is a BAM component asking if we want to undeploy instead of these hoops?

My personal lessons learned:

  • Don’t have spaces in the application name or the BAM Definition file: the BTSTask variables behave oddly and when passing variables into the batch file is almost impossible to troubleshoot
  • Even though I could run a batch file manually that would resolve the installation path of BizTalk, the resolving always came back as null
  • If it is a PreProcessingScript, it will delete the folder in the Program Files directory (and all subsequent files stored there) before executing the script
  • Even though it warns “You should always write scripts intended for production systems in silent mode. This is because a script waiting for user input will cause the BizTalk databases to become locked and inaccessible until the input is received.” I had to test it, I put a pause in the batch file and I ended up rebooting the machine because the installation script was waiting for me to press a key on a DOS prompt that wasn’t available!