BizTalk 2004 Configuration Error Number 80004005

by | Aug 4, 2006 | BizTalk Community Blogs via Syndication

I’m writing about this in the hopes that no one else ever has to suffer the way I
just did trying to get a BizTalk install configured at a client site. 

The symptom was that it would start to configure, reach the BTS WMI
phase of the process and suddenly end with an “Unspecified Error”.  If you review
the log file you would find error 80004005 was returned from btswmi.cpp and absolutely
no other useful information.

The cause of this problem is that NetBIOS is being used to determine
if your computer is already in a BizTalk Group.  NetBIOS only supports machine
names of LESS than 15 characters.

The solution is to rename your machine to something with less than
15 characters.  This will of course take a Domain Admin in a domain situation.

The gotcha is if like me you run off an immediately rename, you can
be left with orphaned jobs on your SQL Server if it is on the same box.  The
sys_jobs table contains the machine name.  Before you rename, be sure to remove
any BizTalk jobs which were created or if you forget like I did, open Query Analyzer
and update sys_jobs to have the new correct computer name.  If you do not update
sys_jobs Enterprise Manager will not let you delete the jobs, and the BizTalk configure
will now fail even earlier in the process.

The other gotcha is that your BizTalk Administrators Group will not
longer have access to SQL Server because it will be known by it’s fully qualified
name <machine>/BizTalk Administrators and so you will need to give this group
rights to the SQL Server again.

BizTalk 2004 on Virtual Machine

by | Aug 4, 2006 | BizTalk Community Blogs via Syndication

While configuring BizTalk 2004 on one Virtual machine (on windows 2003), and SQL Server is located remotely on another VM, I came across this kind of exception, which doesn’t give you much of information, except that the transaction has already been implicitly or explicitly committed or aborted, search on google doesn’t either give you any information, hence I have listed it over here,



Error:
c:\depot4000\jupiter\source\private\mozart\source\setup\btscfg\btswmi.cpp(266): FAILED hr = c0c025b3



[7:30:26 PM Error BtsCfg] Failed to deploy BizTalk system assembly “C:\Program Files\Microsoft BizTalk Server 2004\Microsoft.BizTalk.GlobalPropertySchemas.dll”.



Unspecified exception: The transaction has already been implicitly or explicitly committed or aborted.



[7:33:09 PM Info ConfigFramework] Showing MessageBox with text: Failed to deploy BizTalk system assembly “C:\Program Files\Microsoft BizTalk Server 2004\Microsoft.BizTalk.GlobalPropertySchemas.dll”.
Unspecified exception: The transaction has already been implicitly or explicitly committed or aborted.



Solution:
The Solution is to provide the appropriate domain user accounts for BizTalk configuration wizard, the installer should have access to the SQL Server BizTalk databases. Initially I thought it might be some issue with the MSDTC network clients which were already enabled, how ever it is purely based on the domain accounts which were not yet been created on SQL Server and BizTalk machines..



Error:
Config error: Failed to deploy Biztalk system assembly… DefaultPipelines.dll
When running the config wizard for BizTalk2004 (on windows 2003) the following error occurred:
Failed to deploy Biztalk system assembly “C:\Program Files\Microsoft BizTalk Server 2004\Microsoft.BizTalk.DefaultPipelines.dll”. Unspecified exception: Unable to generate a temporary class (result=1).
error CS2001: Source file ‘C:\WINDOWS\TEMP\dbqvusoe.0.cs’ could not be found.
error CS2008: No inputs specified.
Solution:
The solution is to give the ‘NETWORK SERVICE’ user read and write access to the c:\windows\temp directory.

BizTalk, Commerce Server as Developer Platforms

BizTalk, Commerce Server as Developer Platforms

by | Aug 1, 2006 | BizTalk Community Blogs via Syndication

Jeff Lynch has published a
great article on integrating
Commerce Server 2007 with BizTalk Server 2006 using the new Orders adapter for
BizTalk included with Commerce Server. Very cool technology, and a great introduction
to the topic. My complain is: Why does this kind of thing get published on Technet?
This should be in MSDN, by all means. Which brings
me to the point of this rant:

BizTalk Server and Commerce Server are Developer Platforms.

Currently, for most purposes Microsoft treats BizTalk and Commerce Server as part
of the Windows Server System family of products, and that’s usually fine; after all,
they are server products. However, more than simple server products you buy, plan
and deploy on your organization, like, say, Exchange or ISA Server, BizTalk and Commerce
begin their life cycle in organizations usually as developer platforms on top of which
you develop software to be deployed later on. And this is a key part of the nature
of these products. In that sense, they really aren’t than different than SQL Server.
So, why are they treated totally different?

The BizTalk product team (and I imagine the Commerce server one as well) recognizes
clearly that BizTalk has that duality of developer platform and server product that
needs to be operated and managed. The BizTalk documentation has been substantially
improved on both fronts lately (for which the BizTalk documentation team deserves
a huge thanks from us in the community!). But it seems to me that’s as far as it goes.

The rest of the Microsoft organization completely breaks down on this front and insist
on treating BizTalk (and again, Commerce) as if it was just another server product
like Exchange, instead of it being a significant and important part of the Microsoft
developer stack like the .NET framework and Visual Studio.

This has significant consecuenses for how the products are brought up to potential
customers by Microsoft, the status they enjoy (or even if they get mentioned at all!)
in conferences and other events. Take this as an example: a few weeks ago the local
Developer Days event took place, with a big focus on WinFX, Office 12 and Vista. We
approached some of the Microsoft people responsible for organizing the event, who
mostly worked as DPEs (Developer Platform Evangelism) and asked if they were interested
in having at least one BizTalk-focused presentation at the event, or, maybe do a BizTalk
related event in the future.

The answer? “Oh no, we can’t do that. We’re with DPE and we don’t handle BizTalk.
You’ll need to talk to the Server Platform people about that since they are the only
ones that can fund it”. So, you couldn’t cover BizTalk, but you could cover the new
Office 2007 UI and how to create cool looking charts with Excel 12? Humm… makes
you wonder, doesn’t it?

Now, I’ll admit that this level of disconnect might just be a problem with how our
local Microsoft subsidiary is organized (or rather the whole Andean region, for that
matter); I do not know if it is like this in other countries. However, I find it is
inconvenient and hinders the adoption of the product and prevents potential customers
from getting the information they need about them and how to approach the tools.

Fun With BizTalk Batching and Promoted Properties

by | Aug 1, 2006 | BizTalk Community Blogs via Syndication

I recently had a bit of time to figure out answers to some questions about how BizTalk handles promoted values in
batches. Specifically, do promoted values from the “envelope” transfer to the “body”, and what if you want to interact with those
values from an orchestration? I’ll also show how to add the flat file header content to each debatched outbound message.

First step was to build working samples of both XML and flat-file debatching. Setting up an XML debatching scenario is fairly simple.
First you build the “body” schema. Then you construct an Envelope schema. This is done by (a) marking the schema-level property called
Envelope to true and (b) setting the Body XPath property of the root node to the XML element you wish to rip apart.

Now, I’ve demonstrated before that if you map fields in the header and body to the same Property Schema field, then the value in the header
gets demoted down to each debatched message. However, what if you don’t want to have a field set aside in the message body to hold
header content values? So, I created a property schema and promoted two of the nodes from the header portion of the XML document. After
deploying the solution, and feeding a batched up message into BizTalk, each message got debatched, AND, the promoted fields got copied
down to each message. The documentation states this, but I had to see it.

Next, I wanted to see how it behaved with flat files. Given that we handle flat file debatching differently, I wanted to see if the
promoted property behavior was the same. So, I used the Flat File Wizard to generate both a header and body schema. The debatching key
in the body schema is to flip the repeating batch field element to Max Occurs equals 1.

Finally, I created the necessary receive pipeline to disassemble the flat file input. I pointed the Document Schema and Header
Schema to the previously created flat file schemas. Also, I flipped the Preserve Header flag to true. This crams the
header message into the context of each debatched message.

When I redeploy the solution (now with flat file schemas) and add new receive/send ports, drop the flat file in, I can see the header
message sitting in the FlatFileHeader context value. You could use this data however you want. But, what if we want behavior
just like the XML debatching example above? Specifically, distinct promoted values from the header? So, I went back and promoted the
values in the flat file header schema. After redeployment, I can go back and see that indeed, I have not only the whole header in a single
context field, BUT each promoted value is isolated as well.

Now that I’ve gotten this far, I can demonstrate adding the flat file header BACK to each outbound message. It’s easy. Simply create
a send pipeline with a flat file assembler component, and again choose the Document Schema AND add the Header Schema. What
this does is take that header blob out of context and reapplies it to the outbound message automagically.

My last question was how do interject an orchestration into the mix. Clearly we are working with promoted fields that don’t exist
in the individual message. They’ve been snagged from the parent. So by default, you can’t access these promoted values from within
an orchestration. However, if you go to your property schema, and click on a given element, you’ll see a field called Property
Schema Base. This setting determines where BizTalk looks for the data in a promoted property. I flipped my value to
MessageContextPropertyBase which means that the value will be looked for in context, not the message itself. After I change
this flag, I can now see the property field in my orchestration.

What I wasn’t sure of was how this solution would behave now. By flipping the value to MessageContextPropertyBase would I screw
up the pipeline when it writes to context? I didn’t think so, but wasn’t 100% sure of what this would do. So, after dropping my XML
batch message in, I checked the context of the message after it has passed through the orchestration (which changed the promoted property
value to something else). Sure enough, the value in the outbound message was changed successfully.

Cool stuff. It would be easy then to change the promoted values inherited from the parent, and then send the message directly back
to the MessageBox for additional content-based processing. So there you go, all sorts of fun with BizTalk batches.

Technorati Tags: BizTalk

Commerce Server 2007: Integrating Commerce Server Orders with BizTalk Server

by | Aug 1, 2006 | BizTalk Community Blogs via Syndication

The first in a series of Commerce Server 2007 articles written by me has just been published on Microsoft’s TechNet web site. At the end of the article is a link to where you can download the sample code shown in the article.


Integrating Commerce Server Orders with BizTalk Server


Please let me know what you think about this article and what other Commerce Server related topics you’d like to see published in the future!


As always, your feedback is greatly appreciated!


Technorati Tags: Commerce Server, BizTalk Server, BizTalk

Share this post: Email it! | bookmark it! | digg it! | reddit!| kick it!