We have received a lot of questions about the deployment enhancements in BizTalk Server 2006.  Accordingly, I’ve decided to blog about it to help clear some things up but also to call attention to specific features which should be especially helpful to those working often with BizTalk.


In BizTalk Server 2006, application deployment has not changed dramatically under the covers, but many tools enhancements have been undertaken to ensure this process is much more intuitive and less error-prone.  These will be discussed each in turn within this article.


Application Concept


The first major enhancement in this area is the introduction of the application concept.  This is really just a logical container for application artifacts, allowing you to bucket related components.  However, this concept permeates well throughout the product.  The effect is a streamlining of many of your everyday tasks.  By being able to deploy, manage, start/stop, and troubleshoot all at the application level, there becomes less confusion and less risk of errors for users.


For example, a developer can specify an application to deploy to by editing the “Application Name” property of a Visual Studio project.  By doing so, their artifacts will be deployed to the said application.  This creates a common vocabulary between the developer and the IT Pro when they speak of “an application”.


For the IT Pro, they can use the Administrative MMC Console to configure and start an entire application.  Performing these tasks at the application level ensures that no stone is left unturned.  Once running, the application concept allows the IT Pro to manage and troubleshoot selectively at the application level.  In other words, they can ignore errors coming from a less important application while carefully debugging a more critical application.



This concept also assists greatly with the tasks related to Developer deployment as well as IT Pro deployment and staging, segueing into our next sections.


Developer Deployment


Developers typically deploy to their own local BizTalk server to sanity test the solution still in progress.  The developer deployment and re-deployment process been streamlined considerably since BizTalk Server 2004.


Firstoff, the aforementioned application concept allows different projects to deploy into logical application containers, bucketing like artifacts.  This allows users to easily enter the Administrative MMC Console after deploying from with VS and create ports and bindings for this application.


Once deployed, the developer typically tests, makes changes, and redeploys.  In BizTalk Server 2004 this required a lot of manually intervention on the part of the developer to stop and tear down the dependent components in the correct order, redeploy all of the artifacts, restart host instances, and re-create/start all of the dependent artifacts (e.g. ports, orchestration enlistments, etc.).  With BizTalk Server 2006, the developer experience is much more streamlined and less susceptible to user error.  After making changes to the project already deployed (say fixing an orchestration or editing a map) and with the Redeploy = True and Restart Host Instances = True properties for the project set, developers can simply Right-click Deploy the project or solution and voila!  This removes many formerly manual (and yes, painful) steps.



But application deployment does not just start and stop with the developer.  The next section explains more about the feature advances which will help the IT Pro.


Deployment and Staging


Deployment is the logistical distribution of application artifacts to ensure all necessary components are available to the systems that require them.  Staging, more specifically, refers to the moving of application artifacts from environment to environment, say from development to a test environment, or from staging to production.


Generally, deployment has been improved with the introduction of the application concept.  Since an application typically contains all of the necessary components that its parts depend on, this logical container can be leveraged to help roll-out artifacts to other machines added to the group or for staging (when transporting an application to another environment).


Naturally, the application container contains BizTalk assemblies which are deployed to it by the Visual Studio environment, as explained earlier.  Further, users can manually add BizTalk assemblies to the application, or move BizTalk assemblies from other applications.  Likewise, they can also add non-BizTalk assemblies to the application.  The application may also contain receive ports, receive locations, send ports, property tracking settings, and role links, to name a few.  Implicitly, the application also contains all of the bindings that are represented by their current settings.  And other BizTalk artifacts can also be added to applications, such as BRE (rules) policies.


But in an effort to create a more comprehensive application container, we also provide the ability for users to add additional (typically non-BizTalk) artifacts to the application under the Resources node.  Scripts are also a welcome type of resource which can be chosen to run during different application deployment operations.


Now that an application contains all of the necessary artifacts, the actual deployment process comes in.  BizTalk Server 2006 employs the help of MSIs to actually perform deployment and staging.  The following section covers this process.


Working with MSIs


Microsoft Installer (MSI) technology is used to assist with application deployment tasks.  Why use an MSI?  MSIs are a standard way for applications to be installed onto Microsoft Operating Systems.  They create registration entries in the Add/Remove Programs, accelerate deployment by automating deployment of artifacts and their dependencies in the correct order, and also have many additional capabilities which will be described below.


With BizTalk Server 2006, users have the option of exporting an application to an MSI file, which serializes all of the application artifacts into this package.  Thereafter, several operations can be done with this MSI, explained below.


  • (1) IMPORT – This is a group level deploy.
    This operation will import bindings resident in the MSI package, deploy all BizTalk assemblies to the Management Database for the group, run scripts specified to run at import time, et cetera.  This is done by opening an MMC and doing an import operation of the MSI (or via an import operation from the BTSTASK command line).

  • (2) INSTALLATION – This is a per box deploy. 
    This GAC’s all BizTalk assemblies and dependency assemblies so that this machine has all of the binaries it needs for runtime. This operation can also roll out related web services which might be part of the solution (e.g. orchestrations published as web services).  Further, this operation can be used to apply machine-specific changes, such as pre-creating MSMQ queues, creating FILE drop folder structures and permissions, et cetera, which can be done with the help of scripts.  This operation is done by double-clicking on the MSI file itself.  Instead of being done once per group, it must be done on each BizTalk machine that is a member of the group.


Depending on what type of roll-out you are doing, you may have to do one or both of the above operations. 



Scenario A would be adding an additional server to the BizTalk group.  You may want to use MSIs to help with this.  Exporting the application as an MSI and installing it on the new machine would probably be sufficient to prepare this machine for runtime, at least with respect to the application.


However, Scenario B might be setting up a brand new environment with the solution, in which case the application and its contents must not only be installed on all runtime machines in the new group, but also registered with the Management Database for the group so that the application is created, the bindings are applied, the BizTalk assemblies are deployed, et cetera.  This would necessitate running the MSI installation (double-clicking the package) on all n servers, but also importing the MSI once for the group.


Using Scripts with MSIs


Scripts can be helpful when customization to the machine (installation operation) or to the group (import operation) becomes necessary.


The documentation article entitled, “Using Pre- and Post-processing Scripts to Customize Application Deployment” in our core documentation, explains how scripts can be added as resources and how (and when) they are called by the MSI.


The long story short is that you can add scripts to run as pre-processing or post-processing scripts.  However, you will have to include logic in your scripts to check environment variables to determine which context the script is executing in (an import, installation, or uninstallation) and process accordingly.


Advanced Staging


There are some additional features in BizTalk Server 2006 which can better facilitate staging.  Obviously, exporting applications as MSIs can help greatly with this.  But even beyond this, we have added some new capabilities which make transporting solutions from environment to environment even easier.


For example, every application contains a Resources node which is a general catch-all for additional application components.  One of the Resource types is called “BiztalkBinding”.  This allows users to add additional bindings files to an MSI.  For each bindings file that is added, the user must specify the environment name (text field) which the bindings should be applied to.  Then on import, the user will be asked to choose the environment name to which they are presently importing.  If these are matching, then the bindings file is applied to the target group.  Users can also choose to specify no environment name which will cause the bindings file to be applied to all environments unconditionally. 



As explained earlier, the application implicitly has a bindings set by default, since ports and locations exist and the transport properties are already configured.  These settings will be serialized into an XML file, included in the MSI file, and tagged as belonging to the “Default” environment.  This environment can be chosen by the user or circumvented by selecting another.


Often times transports, URIs, or endpoints can change from environment to environment, and this feature allows an IT Pro, or developer, to create one package which contains all of the transport properties for all environments which it require testing in.  One monolithic package can then be distributed around to service them all.


More Information


Yes, there are even more new deployment features in BizTalk Server 2006.  For more information, please consult the core BizTalk documentation included with the product and updated online at MSDN.


Doug Girard

Note: This posting is provided “AS IS” with no warranties, and confers no rights.