I wanted to create a Node.js cloud application for Windows Azure platform. Current support is limited to PowerShell based user experience for creating and publishing a Node.js cloud app to Windows Azure. See the Node.js application creation tutorial.

I ran into the issue where the publish PowerShell command-let, Get-AzureSettings, failed. I already had 10 management certificates for my Windows Azure subscription and it appears that the command-let tries to create a new certificate for generating the publishsettings file. This is weird since I already have a management certificate for uploading packages via Visual Studio. 

I didn’t have any unneeded certificates that I could delete. So, this was clearly a blocker for me and pushed me to look for a Visual Studio based solution. Visual Studio already supports cloud apps creation and publishing (without requiring creation of additional certificates). It seemed that there should be an easy hookup for supporting Node.js. Apparently, it was not super easy and straightforward, however after jumping through a few hoops, I managed to get Visual Studio create the Node.js application package. I was able to test the application package in DevFabric as well as publish the app to the Cloud. I hope you find this information useful.

Issues addressed

1. Get-AzurePublishSettings creates 1 management certificate for each of my subscriptions, even though I may deploy the application to the first subscription only. It probably does that to provide support for deploying the package to any of the subscriptions. It is a crappy assumption since all my subscriptions now have a certificate that is essentially useless for reuse elsewhere (Visual Studio).
2. Get-AzurePublishSettings command-let fails if I already have 10 certificates in my subscription. The error is:
   1. “You have reached your quota of 10 management certificates and cannot add any more. Visit the Management Portal to delete any unneeded certificates.”
   2. What do I do if I don’t have any unneeded certificates to delete!!
3. There is no way for me to use an existing management certificate with Publish-AzureService command-let.

Pre-requisites

Ensure that you have the following prerequisites installed on the computer:

1. Windows Azure SDK for .NET – download link
2. Windows Azure SDK for Node.js – download link

Environment

I used the following development environment:

1. Windows Server 2008 R2 SP1
2. Visual Studio 2010 Professional SP1

Initial setup

1. Open a Node.js PowerShell command prompt via start > All Programs > Windows Azure SDK for Node.js – November 2011 > Windows Azure PowerShell for Node.js > Right click > Run as Administrator
2. Start Visual Studio. File > New Project … .New Project dialog box pops up
3. Select Visual C # > Cloud in Recent Templates pane on the left. Select Windows Azure Project template in the middle pane, click OK.
4. New Windows Azure Project dialog box pops up.
5. Select ASP.NET Web Role and click on right arrow button. Click OK.
6. Visual Studio may prompt to install Visual Studio extension NuGet. Click OK to install the extension.
7. Delete Account, App_Data, Scripts, Styles, *.aspx, Global.asax, Site.Master, Web.config (Web.Debug.config, Web.Release.config), WebRole.cs files and folders from WebRole1 project. What you have is an empty webrole to which we will add Node.js capabilities in the next section.
8. Assume that the project name is WindowsAzureProject1, WebRole name is WebRole1 [Replace these names with the actual names from your project].

The conversion

1. In the Node.js PowerShell command prompt, run commands
   1. cd c:\temp
   2. New-AzureService tempService
   3. Copy tempService\*.* <project folder>\WindowsAzureProject1\WebRole1
   4. Add-AzureNodeWebRole WebRole1
   5. npm install azure
   6. xcopy /chedi .\WebRole1\. <project folder\WindowsAzureProject1\WebRole1\.
2. In Visual Studio, add server.js, Web.cloud.config, Web.config files to the WebRole1 project
3. Add a reference to c:\windows\assembly\GAC_64\1.6.0.0__31bf3856ad364e35\msshrtmi.dll. Set Copy local property to True.
4. Manually add the following to <project folder>\WindowsAzureProject\WebRole1\WebRole1.csproj file. For all these binaries, set Copy Local to False.

   <ItemGroup>
     <Content Include="bin\node.exe" />
     <Content Include="bin\vcredist_x64.exe" />
     <Content Include="bin\iisnode.msi" />
     <Content Include="bin\setup_web.cmd" />
   </ItemGroup>

5. Now you are ready to build, package, deploy, debug the <project folder>\WindowsAzureProject1 as a regular cloud app in Visual Studio. 
6. And did I mention that you won’t be required to create a new management certificate for all your subscriptions for packaging and publishing the application to Windows Azure. You can use the existing management certificate that you have imported for use with Visual Studio publishing.

Copyright (C) 2011 Vikas Tyagi. All rights reserved.

Issue/symptoms:
1. An unhandled exception ('System.Runtime.InteropServices.COMException') occurred in setup.exe [3668]
2. Setup.exe crashes and watson dump shows the following: System.Runtime.InteropServices.COMException (0x800B0100): No signature was present in the subject. (Exception from HRESULT: 0x800B0100

Potential resolution: The registry entries under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\ may be corrupt. The System Update Readiness Tool (KB947821) would fix some of these corrupt package entries but not all. However, it would list all entries which it could not fix, in CheckSUR.log. Manually remove those entries from registry as per this article: http://www.raymond.cc/blog/archives/2009/03/06/fix-blank-or-empty-list-in-vista-turn-windows-features-on-or-off-optionalfeaturesexe/

Issue/Symptoms:

Setup is disabled or is not enabled devices associated with service failed to start
Setup Microsoft.ApplicationServer.Setup.Core.SetupException: it is disabled or is not enabled devices associated with service failed to start
Microsoft.ApplicationServer.Setup.Installer.WusaProxy.GenerateAndThrowSetupException (Int32 exitCode, LogEventSource logEventSource)
Microsoft.ApplicationServer.Setup.Installer.WusaProxy.Invoke (LogEventSource logEventSource, String packageName)
Microsoft.ApplicationServer.Setup.Installer.CbsInstaller.InvokeWusa (InstallMode installMode)
Microsoft.ApplicationServer.Setup.Installer.CbsInstaller.Install ()
Microsoft.ApplicationServer.Setup.Client.SetupWorkflow.StartActionPhase ()
Microsoft.ApplicationServer.Setup.Client.ProgressPage.StartAction ()

Potential resolution: Check if the Windows Update server is stopped/disabled. This service needs to be running to install Windows Server AppFabric.

There are situations where TPE doesn't behave as expected. The product documentation provides all factual details but does little justice to resolving common issues. This post is directed at resolving common BAM cases that center around TPE. The cases listed are the ones that customers run into most often. If there is one that you are battling with and would like see the same appear here, let me know.

The case of multiple rows in the activity table with holes/null for values when a single message is processed by BTS solution.

Presence of multiple rows in the activity table when you expect a single row containing all the BAM data suggests that you have mapped the business data of interest correctly, however, your continuations are setup incorrectly. If you track BAM data from multiple BizTalk schedules, e.g., ports and orchestrations, then you would need to setup continuations between these schedules. See product documentation on how to do this. See my blog post on TPE and multiple continuations.

The case of orphaned Tracking profiles

Tracking profiles are associated with an activity. If an activity is undeployed, the associated tracking profiles can become orphaned, which means they are no longer associated with an activity. In such a situation, if you pump a message through your solution, you will notice an error in the event log saying that TDDS ran into some problem (or something to that effect). So, the tracking profile exists but there is no associated activity definition deployed. There is no way to persist the BAM data. This is a well documented scenario. See product documentation on how to remedy this common ill.

The error message are

<Event log entry>

Event Type: Error
Event Source: BAM EventBus Service
Event Category: None
Event ID: 6
Date:  **/**/****
Time:  *:**:** **
User:  N/A
Computer: **********
Description:
Execute event error. Error(s) occurred while executing events, see TDDS_FailedTrackingData table for more details.  SQLServer: **********, Database: BAMPrimaryImport.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

</Event log entry>

<TDDS_FailedTrackingData table entries>

Could not find stored procedure 'dbo.bam_********_PrimaryImport'.
TDDS failed to execute event. Could not find stored procedure 'dbo.bam_********_AddRelationship'.
TDDS failed to execute event. Could not find stored procedure 'dbo.bam_********_EnableContinuation'.
TDDS failed to execute event. Could not find stored procedure 'dbo.bam_********_PrimaryImport'.
TDDS failed to execute event. Parameter is not valid.

</TDDS_FailedTrackingData table entries>

The case of dangling records and uncompleted activity when interchangeID is used for continuations

InterchangeID is available from two sources. One is the message context property bag and other is the system context property bag. You work with the first one through "select event source"->"select messaging property" menu and the other via "select event source"->"select context property" menu->BTS.InterchangeID. Although the values that you will get from either source is the same, the way they are extracted are different.

Regardless of which one you use, you must be consistent in your usage. Stick to one source only.

For most part now, it seems that creating single continuation [say, between two orchestrations] is a breeze for most developers. The part where TPE is not explicitly clear is the case of multiple continuations. The situation is typical as a BAM activity spans multiple receive ports, orchestrations and send ports. In order to collect the Business Activity Monitoring (BAM) data in one record, one has to setup continuations between all the BizTalk schedules. This turns out to be non trivial through the TPE UI, hence this posting to illustrate the case of multiple continuations.

Let's discuss some special cases. Let me lay out the general terms first. The case of one port OR one orchestration is a special case of many port and many orchestrations scenario. Lets deal with the ramifications of many port and many orchestration scenario. The different ways in which a message can be received and processed by orchestrations presents some interesting challenges and solutions. The scenario consists of a number of receive ports (R), orchestrations (O) and send ports (S). We use interchangeID context property as the glue to bind the continuations. You can, of course, use any other context property, activityID or anything else in place of interchangeID. The choice is immaterial to the problem at hand. I exclude the discussion on the data item/milestone/context-property-value being tracked from these ports and orchestrations. You would do that part of the mapping as per your business logic. Our target is to capture all BAM data from all the ports and orchestrations in a single row in the completed activity table .

A message arrives at exactly one of the R receive ports and gets processed by exactly one of O orchestrations. In this case, you will create a continuation folder on the Left Hand Side (LHS) activity tree view and map the interchangeID context property from the context property schema via "select event source"->"select context property" menu item. Next you will right click on the newly created interchangeID node on the LHS and select the ports to map from. In the select ports dialog box that comes up, select all N receive ports. Next you will create a continuationID folder on the LHS. You will open all O orchestrations, one at a time, and map the interchangeID context property from a shape in the orchestration. The mapping will look something like this:

- OrderProcess
    |- start_milestone
    |- end_milestone
    |- order_amount
    |- order_number
    |- order_item_number
    |- continuationR2O          [the continuation folder]
        |- interchangeID        [port mapping includes all R receive ports]
    |- continuationR2O          [the continuationID folder]
        |- interchangeID        [from O1]
        |- interchangeID        [from O2]
        .    .
        .    .
        |- interchangeID        [from Oo]
           

A message arrives at exactly one of the R receive ports and gets processed by each and every one of O orchestrations. This happens as the message is simultaneously and parallely sent to each of the O orchestrations. In this case, we would need O continuations. The mapping will look something like this:

- OrderProcess
    |- start_milestone
    |- end_milestone
    |- order_amount
    |- order_number
    |- order_item_number
    |- continuationR2O1         [the continuation folder]
        |- interchangeID        [port mapping includes all R receive ports]
    |- continuationR2O1         [the continuationID folder]
        |- interchangeID        [from O1]
    |- continuationR2O2         [the continuation folder]
        |- interchangeID        [port mapping includes all R receive ports]
    |- continuationR2O2         [the continuationID folder]
        |- interchangeID        [from O2]
    .   .     .
    .   .     .
    |- continuationR2Oo         [the continuation folder]
        |- interchangeID        [port mapping includes all R receive ports]
    |- continuationR2Oo         [the continuationID folder]
        |- interchangeID        [from Oo]

Now, let's discuss a CBR scenario. A message arrives at exactly one of the R receive ports and gets sent to exactly one of S send ports. This routing happens based on a context property value in the message. In this case, we would need one continuation. The mapping will look something like this:

- OrderProcess
    |- start_milestone
    |- end_milestone
    |- order_amount
    |- order_number
    |- order_item_number
    |- continuationR2S          [the continuation folder]
        |- interchangeID        [port mapping includes all R receive ports]
    |- continuationR2S          [the continuationID folder]
        |- interchangeID        [port mapping includes all S send ports]

The above mapping will also hold true in the following case. A message arrives at exactly one of the R receive ports and gets sent to all of the S send ports.

A message is processed by exactly one of O orchestrations (we don't know which one will execute at runtime) and is then sent by that orchestration to all the S send ports. In this case, we would need one continuation. The mapping will look something like this:

- OrderProcess
    |- start_milestone
    |- end_milestone
    |- order_amount
    |- order_number
    |- order_item_number
    |- continuationO1S          [the continuation folder]
        |- interchangeID        [from O1]
        |- interchangeID        [from O2]
        .    .
        .    .
        |- interchangeID        [from Oo]
    |- continuationO1S          [the continuationID folder]
        |- interchangeID        [port mapping includes all S receive ports]

A message gets processed by all O orchestrations in sequence, one by one. The mapping will look something like this:

- OrderProcess
    |- start_milestone
    |- end_milestone
    |- order_amount
    |- order_number
    |- order_item_number
    |- continuationO12          [the continuation folder]
        |- interchangeID        [from O1]
    |- continuationO12          [the continuationID folder]
        |- interchangeID        [from O2]
    |- continuationO23          [the continuation folder]
        |- interchangeID        [from O2]
    |- continuationO23          [the continuationID folder]
        |- interchangeID        [from O3]
    .   .     .
    .   .     .
    |- continuationOxO          [the continuation folder]
        |- interchangeID        [from On]
    |- continuationOxO          [the continuationID folder]
        |- interchangeID        [from Oo]

There are a few tracking scenarios that need explaination as far as tracking options for messages that arrive wrapped in an interchange or batch are concerned.  The choice is completely up to the user on how to construct the tracking profile for each of these scenarios.  The reasons are:

1. Different activities for different port-schema pairs (or just port-no schema) scenario. Multiple activities are configured for the same port but for different schemas.
   
2. A single activity scenario. For different milestones and data items in the activity, map different XPaths from different schemas. Furthermore:
   
   • If you choose the activity start point as the port start point and you want to track meta-data from the interchange and some payload data from the other created messages, then you will end up using change history table if the change history is turned on for the activity.
     
   • If you choose the activity start after the port start, then, as the interchange is broken up into individual messages, you are will have multiple rows in the activity table. Each row will correspond to one message.
     
3. A single activity scenario. For different milestones and data items in the activity, map different XPaths from the same schema. In this case, there will be one row in the activity table. If a schema use is repeated and if change history is turned on for this activity, the change history tables will be populated.
   

Copyright (C) 2006 Vikas Tyagi. All rights reserved.

THIS CODE AND INFORMATION ARE PROVIDED "AS IS" WITHOUT 
WARRANTY OF ANY KIND, WHETHER EXPRESSED OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.

TPE is the provisioning tool for BAM instrumentation of hte runtime. As such, it is intended for use by someone expert in the implementation of the BizTalk solution. This would typically be the developer, Eddie, himself.

Eddie has been given a BAM Activity Definition file and is asked to develop a tracking profile to provision it. Eddie, given his understanding of the details of the solution, analyzes the BAM Activity Definition and makes a list of assemblies (contents: orchestrations, schemas/context properties, etc.) that he will need to configure in order to complete this task. He then

1. Launches TPE to edit existing or create new tracking profile.
2. Selects a management database source pointing to
   • Directly - assemblies and their constituent parts which are the event sources.
   • Indirectly - the BAM primary import table database and any deployed BAM Activity Definitions, which are the mapping targets.
3. Selects any artifact, in some cases by assembly (messaging properties being the exception) from which to map (orchestrations/ports).
4. Imports the BAM Activity Definition.
5. Drags and drops shapes or message-payload/context-property data items from RHS to the milestones and data items on the LHS.
   • Orchestrations
   • Schemas: payload-message/context-properties
6. Deploys and tests the tracking profile.
7. Saves the tracking profile and checks it into source safe with his notes.

Copyright (C) 2006 Vikas Tyagi. All rights reserved.

THIS CODE AND INFORMATION ARE PROVIDED "AS IS" WITHOUT 
WARRANTY OF ANY KIND, WHETHER EXPRESSED OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.

Note: This information applies to Tracking Profile Editor in BizTalk Server 2006

You may face situations where Tracking Profile Editor does not work as expected or behaves in unknown ways. The help that ships with TPE is at times not descriptive enough to list each and every quirk associated with TPE. As I played around and experimented with TPE, I found it useful to list all the helpful hints that proved immensely useful to me later on. They are all listed here in no particular order of importance.

• Multiple instances of TPE can exist simultaneously. You can work on the same tracking profile in two different instances of TPE. While saving the tracking profile, the TPE instance that save the profile last will overwrite the previous changes, if any. Same is true while applying a tracking profile. It is recommended to work with one tracking profile in one instance of TPE to prevent accidental data loss.
• The management database setting specified via TPE is retained across sessions.
• While specifying the management database server, do not leave any spaces around the comma port separator when specifying a SQL port. For example, "foo,1234" (quotes not included)  is correct while "foo , 1234" (quotes not included) is not. Specifically, any connection string format that is acceptable to SQL server can be specified here. So, a . (dot) will be equivalent to localhost and will be perfectly acceptable to TPE.
• Original activity items, except for related activity names, can't be deleted in TPE.
• Mapping a data item to ActivityID folder is not mandatory. If nothing is mapped to ActivityID, then a GUID is generated and assigned to ActivityID by default. Interpreting GUIDs with a human eye is always a challenge. If the messages that are tracked by TPE contain a field that has a unique value, SSN in our case, then it becomes meaningful and convenient to map such unique valued fields (SSN) to ActivityID folder.
• Document Reference URLs folders can be used to track almost anything and not just document URLs. The only advantage that these folders offer that they appear on the BAM Portal. A single click on the BAM Portal link will take you to the document. Mapping anything other than the document URL is not very useful as, although visible as a link, it will take you nowhere in BAM Portal. The intent is to allow custom user interface developers to gain access to associated document information so that they can present it to the end user.
• If a continuation doesn't have a matching continuationID or vice-versa, TPE will warn you but not prevent you from applying the tracking profile. This is due to the fact that continuations can be established and populated using BAM APIs as well. In fact, one can mix TPE with BAM APIs freely. This is recommended for special situations where TPE alone can't fulfil the purpose. The whole purpose for using TPE is to avoid writing code as much as possible.
• You may define and map to any related activity but only those related activities will be visible on the BAM Portal that are under the same view. The same view restriction is forced by BAM Portal and not TPE.
• When you import an activity definition to start work on a brand new tracking profile, TPE shows the activities in the same view as related activity folders by default. TPE doesn't enforce this. You can add any activity as a related activity and map to it. TPE will allow this.
• If a tracking profile is modified and then re-applied, BizTalk will store the new version of the tracking profile along with the older versions. Older versions are not deleted or overwritten. This is because a long running orchestration might be using the older version. Any new instance of an orchestration will pick up the latest version of the tracking profile. A removal, results in the removal of all the versions of the tracking profile for that particular activity.
• There is no direct way to get a list of tracking profiles currently applied. The list of tracking profiles is stored in the BizTalkMgmtDb database in the bam_TrackingProfiles table. You can create a custom query to get that information.
• When tracking orchestration shapes, the end time for the shape's execution is reported by the engine as the milestone value.
• TPE lets you map multiple sources to the same item in an activity. In such a situation, the last artifact that was encountered during the BAM processing is the one whose value persists in the database and is viewable in the BAM portal.
• Not all message properties are available at design time. An example of this is when the listen shape is the first shape in a orchestration. When message properties are mapped from this shape, only the following properties have values: InstanceID, ServiceID and ServiceClassID. (MessageID is not in scope at this point and has a null value). MessageID will be guaranteed available for a send/receive shape. If your orchestration doesn't have a send/receive shape, you may not be able to track its value.
• Properties and message payload data items can be mapped to milestones. The value is evaluated at run time only. The date time values must be in a format that is acceptable to SQL server. Any casting problems will show up as an event log error.
• Message payload data, context properties and message properties can be tracked from both orchestrations and ports. The menu items and the final presentation is quite similar for both and is cause for confusion. The differentiating factor is the place from where they are chosen. For orchestrations, right click on an orchestration shape and select from the appropriate menu items. Stuff tracked there after will be in the orchestration context and there is no need to specify any ports. For ports, always go through the "Select Event Source" button menu items. The following sub menus: Select Messaging Payload, Select Context Property and Select Messaging Property track data from ports and would require a port mapping specified after creating a mapping. After mapping the item, right click the mapped node on LHS and you will see "Set Port Mappings" menu item. Choose this menu item to select the ports from which to track the data. If this menu item is disabled/unavailable, then you most likely ended up here from an orchestration shape and that may not be your intention. If you see this context menu item disabled, and would like to see this to be enabled so as to specify the port, delete this mapping and load your event sources via the "Select Event Source" button menu items.
• Pass through pipelines present a special challenge with respect to continuations. This is because pass through pipelines, by definition, are not aware of any XML message schema. Consequently, no data is tracked by engine including system properties like SessionID. The alternatives are to either remove all message payload tracking from a pass through pipeline or use an XML pipeline.
• Mime pipelines are not supported on 64 bit platforms and consequently can't be tracked by TPE. The workaround is to run a host instance in 32 bit mode and run the application on this 32 bit host.
• Removing a tracking profile removes all versions of it.
• Port start/end tracked time are the times when the pipeline finishes up. This means that if there is a an error in the pipeline and the message is suspended then the port start/end time will not be tracked. In the case of pipelines, it is not explicitly clear when the sampling of data occurs. The answer to that is, at the end of the pipeline. The easiest example to understand this is the case of sending data to a sharepoint document library. Well behaved transport adapters will populate a new property that will contain the target address (URL) of the data delivered by the adapter. In order for this to work, obviously, the tracking must occur after the transport completes, which implies "at the end of the pipeline."    

On the receive side, there is a slight nuance to be aware of. Specifically, because of the statement that tracking will occur at the pipeline's end, it might seem that properties like "ReceiveTime" or "PortStartTime" will not be available. However, it is in fact the case that the maximum amount of data (in the form of properties) is available at the end of the pipeline. Therefore, the statement that tracking occurs at the end of the pipeline does NOT mean that properties like "ReceiveTime" or "PortStartTime" will not be available. It simply means that this property value would not be tracked until the end of the pipeline, even though the value of this data source would have been set at the time the message was actually received (typically the lag here would be seconds or less, but it is conceivable that some stateful pipeline components could take significant portions of an hour or longer).

• TPE figures out the begin and end of an orchestration. This is fine and dandy except when TPE is faced with a parallel shape at the beginning/end. Then it is impossible for TPE to figure out the begin/end of the activity. In such a case you will see an error if you map from an orchestration shape on the parallel branch to the ActivityID folder. The only recourse in such a case is to not map to ActivityID at all. This will result in a GUID being assigned to the ActivityID.
• The following shapes can't be mapped and thus can't be tracked: group, message assignment, loop, suspend, terminate, throw exception, transform. These shapes are invalid shapes. Consequently, you can't map from an orchestration if it starts/ends with an invalid shape. TPE will provide GUI hint in the form of a blocked cursor if you try to map from one of these shapes.
• The MessageID can only be tracked from a send/receive shape.
• TPE touches upon a few databases. It stores tracking profiles themselves in the management database, interceptor configurations in the Primary Import Table database and the orchestration xsyms in the DTA database.
• The milestone information captures by TPE is in UTC. You can track the time in local time.
• BizTalk Server 2004 custom pipelines can't be tracked using TPE once they are upgraded to BizTalk Server 2006. This is due to the fact that pipeline tracking is a new feature of BizTalk Server 2006 that never existed in BizTalk Server 2004. Of course, the default xml and pass through and other pipelines are trackable after upgrade. The restriction applies only to custom pipelines.
• Orchestration variables are not exposed and thus can't be tracked using TPE.
• TPE does not allow mapping from adapters and web services. The only support is for tracking system/context properties that are populated by the adapters/web-services/code. An alternative is to use BAM APIs which require no TPE involvement.
• TPE can be used to map and track data from BizTalk artifacts only. This means that if you have a 3rd party custom component/code then there is no alternative but to use BAM APIs to track BAM data. However, what you could do is try to extend your 3rd party custom component to implement the tracking interface which BizTalk uses behind the scenes on every shape which is used by TPE to track and change BAM calls.
• Tracking profiles cannot be added to the BTS application package until sometime after the solution is first deployed to a live BTS management environment. There is no mitigation provided. It is assumed that tracking profiles are easily applied as a finishing act of the overall solution deployment by the IT professional. It is assumed that the BTS application package would include the tracking profiles in subsequent staging of the solution to other environments.
• Storing a tracking profile in the database is no longer referred to as a "deploy" action.  This is due to possible confusion with the more formal BizTalk server deployment feature set, as well as to make it clear that tracking profiles are more "in addition to..." as opposed to some item which is required for the BizTalk application to actually function.  This is a terminology change from BizTalk Server 2004, which called this action "Deploy."  It is now called "Apply."  Un-deploy, which is a new feature for BizTalk Server 2006, is now called "Remove."

THIS CODE AND INFORMATION ARE PROVIDED "AS IS" WITHOUT 
WARRANTY OF ANY KIND, WHETHER EXPRESSED OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.