BizTalk Server 2004 Configuration Failures – Medium

I started this post to list suspect issues that may impact loading a BizTalk configuration (i.e., running configframework.exe in either a silent or interactive mode). I’m now splitting it into separate posts (simple, medium, difficult). I am not trying to offer specific solutions to all failures in this post, although I do provide some suggestions and pointers to solutions where I’ve seen these issues. This really is a collection of things you can confirm during the configuration steps.

The application of a BizTalk configuration file can be your delight or downfall, and differs for most every environment in which I’ve installed. Kudos to the big brains at MS for spending their resources on all that’s great about BizTalk; I’m confident they’ll come around to my wish list of easier/faster/better configuration options.

So, that said, let’s look at what makes a configuration fail, from the ‘medium’ perspective (note: these are from a multi-server deployment on a domain; some items will not apply to single-server deployments).

Medium (will likely require restoration to vanilla, and removal of the present configuration):

• IIS Application Pool identity failure (if installing BAS, ensure you log on with the same account that the BAS application pool runs under).
• Inadequate permissions on the SQL Server for the WSS (BAS) administration account (be sure this user has database creator and security administrator roles).
• Improper group membership (if configuring using domain accounts, forgetting to include the domain name for a particular service, causing the configuration to look for a local group that will not exist).

The result of these errors is a rollback, where BizTalk removes the configured components from the server, leaving behind the SQL databases and other artifacts. See the post titled “Restoring BizTalk to a Vanilla State“ to recover from these errors.

I am keen to receive any feedback and other posts. Please submit comments.