Wayyyy back in November of 2006, I wrote about a bug in BizTalk 2006:

This bug is encountered when you attempt to start a BizTalk 2006 application definition with orchestrations that have been bound to different hosts.  (Say, OrchA in HostA, and OrchB in HostB.)  After the application has been deployed, the first time the application is started (and 'orchestration start/enlist' is included in the start options) you will receive an error that looks something like this:

Microsoft.BizTalk.ExplorerOM.BtsException: Could not enlist orchestration 'BizTalkSample.Orchestrations.Echo,BizTalkSample.Orchestrations, Version=1.0.0.0, Culture=neutral, PublicKeyToken=05a4a8d4071035d9'. Could not enlist orchestration 'BizTalkSample.Orchestrations.Echo,BizTalkSample.Orchestrations, Version=1.0.0.0, Culture=neutral, PublicKeyToken=05a4a8d4071035d9'. Value does not fall within the expected range.

There was a fix for this bug  back at that time, but somehow it crept back in (even in R2.)  The KB number for the problem is the same, however (KB927052) and a fix is available.

Minor update to the BizTalk naming conventions here.  The big thing is that for a long while now I’ve thought physical send/receive ports should be named with just a plainly-worded phrase that will be as transparent as possible to operations staff.  (Whereas, back in the days of BizTalk 2004, you wanted something brief enough to fit in a HAT column…)

Team Foundation Server 2008 provides the ability to specify a “remote” Sql Server Analysis server as well as a remote Sql Server Reporting server.  Normally, your Analysis Server is located with the data tier, and the Reporting Server is located on the application tier.  (Of course, everything can be collapsed on a single physical tier as well.)

However, by editing the “msiproperty.ini” file within the “AT” directory of your installation media, you can customize this.  The relevant keys are VSTF_RS_SERVER (reporting) and VSTF_AS_INSTANCE (analysis).  See the Team Foundation 2008 installation guide for details.

What you should know, however, is that apparently Reporting Server instances are not really supported.  If you attempt to specify an instance name in the VSTF_RS_SERVER property, the installation will fail.  This property needs to refer to a server name only.  TFS 2008 apparently expects the instance name to match the data tier instance name (a strange assumption.)  If that doesn’t work, it tries the default instance.  (After that, it will try the first instance it finds…so you might see “WARNING: Selecting the first instance name of…” in the installation log.)

According to this, you won’t see a change in this behavior with TFS 2008 SP1…

I have a few clients that would like to see TFS make use of an enterprise Reporting Services infrastructure (rather than spinning up a new reporting server…)  If you do as well, this is something to keep in mind.

Update: Slides from the talk we gave are available here.

I’ll be doing a talk with Geof Lory about Team Foundation Server and Application Lifecycle Management (ALM) at TechFuse this coming Tuesday (February 26^th, 2008)…

Looks like a great event all in all for those in the Twin Cities!

So, I should have moved the BizTalk Deployment Framework to CodePlex long ago, but better late than never.  Find it here.

A few small items:

• Better support for 64 bit platforms in scripting operations
• Support for using the 64 bit isapi extension for http adapter
• A "startApplicationOnDeploy" property you can use to control whether your application immediately starts after deploying
• Bug fixes for the lightweight "Update Orchs/Comps" tool menu item
• Automatic creation of "ProjectPath" sso config item – that lets you know where your developer workspace or server installation directory resides.
• Better support for pre-processing bindings on developer workstations

But the cool item is integration of Tom Abraham’s improved “SettingsFileGenerator” – see here.  It moves the process of generating individual environment setting files from a VB macro inside of the SettingsFileGenerator.xls spreadsheet to an external command-line tool.

It also allows you to use the Excel XML format for the SettingsFileGenerator spreadsheet.  The Excel XML format allows for the ability to do standard diff/merge activities, a big improvement…

The way we’ve intergated this tool into the deployment framework allows you to treat the individual settings files as "transient" - they will get auto-generated by the deployment process now on the fly, and do not need to be version controlled or manually generated after spreadsheet edits. 

Enjoy!

TFS Deployer is a great tool that allows you to automate application deployments.  It does so by acting as a service that listens for “Build Quality” change events dispatched by TFS – and then kicking off a PowerShell script that is appropriate for the server and the build type.

I’ve had very good luck making use of TFS Deployer with a few clients to facilitate unattended deployments of BizTalk applications.  I’ll have more to say about the “BizTalk” piece of that in coming months, in collaboration with my good colleague Dave Comfort.  Suffice to say that if you’re using the Deployment Framework – but would like a one-click solution for deploying to multi-server environments, you will want to watch this space.

In the mean time, if you are making use of TFS Deployer already, you might find it helpful to share some slightly more formal documentation with your operations staff, etc.  You can certainly glean what you need to from here and here, but I believe you’ll find this consolidated resource a help.

(p.s. – keep an eye on the future of the TFS Deployer project here.)

“Error creating UDDI entries... Error 285023” – are you getting this while attempting to get the ESB Guidance up and running? 

If your event log has an entry containing “UDDI_ERROR_AUTHTOKENREQUIRED_NOTOKENPUBLISHATTEMPT” chances are you have anonymous authentication enabled for your UDDI virtual directory.  Turn it off, and try again.  If this isn’t the issue (or you are having other UDDI issues while installing the ESB Guidance) try cranking up logging to “verbose” for the UDDI service itself.  (See Administrative tools, UDDI Services, properties on your machine.)  There is generally enough context in there to troubleshoot…

I’ve had a few folks ask recently about the presentation I did for MDC 2007 on release management and branching strategies with Team Foundation Server.  The PDF was available on the conference site, but not the PowerPoint, so here it is.

1/9/2009: I recently updated this tool to delegate the work to "tfpt.exe" (the TFS power tool) when obtaining individual changesets.  This works much better in conjunction with rename/delete activity.

I was working with a shop recently that wanted to be able to do very fine-grained deployments (of a web application) into production.  They were pretty far into their Team Foundation Server adoption, and wanted to be able to deploy the files contained in the changeset(s) that were tied to a particular work item. 

So, for instance, to close a particular bug work item, three changesets might be checked in (each associated with that work item.)  Each of these changesets might comprise multiple files.  When preparing to stage the fix, the client wanted to simply say “go get work item 1237” and have the right thing happen (i.e. all files retrieved, preserving folder structure) – even without a workspace defined.

They were happy to let me share the solution with you, so you can download it here.  You’ll have to build it yourself, pointing at the correct TFS assemblies.

It is a command line utility – the command line help is as follows:

GetCSForWI v1.0.0.0
Copyright 2007

Retrieves files associated with changesets or changesets
that have been associated with a particular work item.

Usage: GetCSForWI.exe [@argfile] <tfsServer> [/changeset:<changesetNumber>]
       [/workitem:<workitemNumber>] [/path:<localFolder>] [/help|?|h] [/version|v]


@argfile                      Read arguments from a file.
tfsServer                     TFS Server name
/changeset <changesetNumber>  Changeset number to retrieve
/workitem <workitemNumber>    Workitem number to retrieve changesets for
/path <localFolder>           Local folder to copy to (after getting to
                              workspace)
/help                         Show usage.
/version                      Show version.