BizTalk 2006 - Windows SharePoint Services adapter

WebDev.WebServer.exe does not start - Configuration system failed to initialize

Adrian Hamza — Thu, 29 Mar 2007 00:56:00 GMT

I have Visual Studio 2005 with Service Pack 1 installed and I cannot debug any web service or web application. This worked for a while and then it stopped working. I researched this on a couple of sites and the suggested solutions were

- Debug with F5
- Run with CTRL + F5
- copy WebDev.WebServer.exe from another machine if not present in .Net Framework folder
- From .Net Framework folder run WebDev.WebServer.exe /PORT:8081 /PATH:"path to web app"
- disable or open firewall port

I tried all of these and it still failed with several errors
Configuration system failed to initialize
Unable to launch Visual Studio's Localhost Web Server.
ASP.NET Development Server failed to start listening on port 8081.
Error message:
Configuration system failed to initialize

In my case, this error was caused by system.net\machineKey element in machine.config. Removing this element fixed the problem. Of course on a production system you don't want to this but you would not run WebDev.WebServer.exe either so that's not actually a problem.
I hope this helps other people facing the same problem!

Is there a way to configure one send port to send a message to a document library based on a parameter?

Adrian Hamza — Thu, 08 Mar 2007 01:59:00 GMT

This question comes up quite often that it deserves its own post. Is there a way to configure one send port to send a message to a variable destination based on a parameter? For instance when using WSS adapter, can you send a message to a different document library based on the message that's being processed?

The answer is yes, it's possible to do this in two ways:

using dynamic send ports, the destination URI and the configuration of the send port can be set programatically in the orchestration for every outgoing message. This method has the advantage that no ports have to be pre-created.
using role-links and parties. For each party you need to pre-create and configure a pyshical send port. You will have pretty much a party per destination. You enlist the parties in the appropriate role. Then, in the orchestration the only thing that you need to do is set the party associated with the role-link. The physical send port of the party associated with the role-link will be used to process the outgoing message.

I included below more information on how to do this using dynamic send ports which is the more simple & frequent approach.

The URL for a WSS adapter dynamic send port will be something like this:
     'wss://ServerName/sites/MySite/MyDocumentLibrary/' if you installed the web service on an HTTP site
     'wsss://ServerName/sites/MySite/MyDocumentLibrary/' if you installed the web service on an HTTPS site (notice the additional s in wsss://).

and you can set it programatically from the orchestration (like below) every time you sent out a message
     dynamicSendPortName(Microsoft.XLANGs.BaseTypes.Address) = "wss://ServerName/sites/MySite/" + lookedupDocLibName;

The rest of the send port configuration information must be set on the outgoing message using the Config* context properties documented here
http://msdn2.microsoft.com/en-us/library/aa547920.aspx

For instance:
    outgoingMsg(WSS.Filename) = "file1.xml";
    outgoingMsg(WSS.ConfigOverwrite) = "yes";
    etc.

Video 04-WSSAdapter-PropsInOrchestration.wmv shared here includes one such dynamic send port example
http://blogs.msdn.com/ahamza/archive/2006/04/18/WssAdapterVideosWebcasts.aspx

64 bit and managed code

Adrian Hamza — Mon, 30 Oct 2006 18:45:00 GMT

This article covers some 64 bit aspects regarding managed code and COM+ applications. The 64 bit info regarding managed code was taken from Josh Williams' blog and I want to thank him for putting all this useful information online. Personally, I found his postings very usefull. The COM+ application info I was able to find it in the documentation for CoCreateInstanceEx and CLSCTX enumeration.

Josh's articles cover mostly the subject of porting managed code EXE apps to 64 bit. Here are some links that you will find very useful:

If you don't have the patience to read these articles, here's my scaled down summary with explanations removed:

AMD64 - 64 bit processor designed by AMD, initially named X86-64. Intel has its own compatible processors under the names EM64T, IA-32e, or Intel 64. x86-64 and x64 names are used by vendors to refer to these processors.
IA64 - a 64-bit processor architecture developed cooperatively by Intel Corporation and Hewlett-Packard
Once a process is started up as either 32bit or 64bit all of the dlls/assemblies that are loaded into that process have to be compatible with that bitness. Incidently, the same is true about the .Net Framework version loaded in the process.
.Net 1.0 and .Net 1.1 EXE applications running on a 64 bit machine will run in 32-bit runtime in WOW64 mode. The selection of the .Net Framework (1.0, 1.1 or 2.0) will be determined by the CLR’s loader policy, just as it would be on a 32-bit box.
If you know that your .Net 1.0 or .Net 1.1 EXE app is safe to be run in 64 bit mode, you can run CorFlags.exe with the /UpgradeCLRHeader parameter on your EXE in order to upgrade the IMAGE_COR20_HEADER runtime version to 2.5 (version number for .Net Framework 2.0). This will make your EXE to run as 64 bit app on a 64 bit machine. A v1.0/1.1 image which has had its MinorRuntimeVersion whacked will still be compatible with the v1.0/1.1 runtimes.
.Net 1.0 and .Net 1.1 assemblies can be loaded and executed as 64 bit native into a 64 bit process. This can be done even without setting the IMAGE_COR20_HEADER runtime version to 2.5. If you make a .Net 2.0 executable and link against a v1.0/1.1 dll you will be able to load it into your process as if it was a .Net 2.0 MSIL assembly. If that v1.0/1.1 dll has code that isn’t safe to run in 64-bit mode it may crash.
.Net 2.0 when installed on a 64 bit machine it will also install the 32 bit version of the framework. .Net 2.0 32 bit version will be installed in \WINDOWS\Microsoft.Net\Framework just as it would on a native 32bit machine whereas the 64bit version ends up in \WINDOWS\Microsoft.Net\Framework64.
.Net 2.0 EXEs and DLLs have bitness information attached at compile time. CLR headers of your PE image can be marked with one of four things: MSIL, x86, x64, IA64 (names vary). You can chose how the assembly is being compiled, by default MSIL.

x86 EXE - runs fine on 32 bit, runs in WOW64 mode on 64 bit
x64 EXE - runs as 64 bit on x64 machines, raises BadImageException on anything else (including IA64)
IA64 EXE - runs as 64 bit on IA64 machine, raises BadImageException on anything else (including x64)
MSIL EXE (aka anycpu/neutral/agnostic) - the assembly is not processor specific. It runs as 32 bit on x86 machines, as 64 bit on x64 and IA64 machines.

The articles above, however do not cover the COM+ application case. Let's say I have an out-of-proc managed COM+ component. This component is implemented as a C# class derived from ServicedComponent with attribute ApplicationActivation set to ActivationOption.Server. The assembly containing this component was compiled using .Net 2.0 and it's marked as anycpu/MSIL. This means that the assembly and component are processor neutral and it can run as both 32 and 64 bit on a 64 bit machine. Because the server is out-of-proc, the client and server do not need to share the same bitness. The client can be 32 bit and the server 64 bit, or viceversa. This can be used successfully to integrate legacy 32 bit components into 64 bit applications. Here's an article named 64-bit Insider that covers this aspect.

When a client app instantiates this component, the COM+ component will be created in its own process. Will that process have the same bitness as the client, will it have the bitness determined by the COM+ application settings or by the managed code setting? This article http://windowssdk.msdn.microsoft.com/en-us/library/ms693716.aspx about CLSCTX (paramater to CoCreateInstance) shades some light on some of these aspects, so I included some of the information here. Here's my summary:

the client of the COM+ application can control the bitness of the server process by passing in CLSCTX_ACTIVATE_32_BIT_SERVER or CLSCTX_ACTIVATE_64_BIT_SERVER (when calling CoCreateInstanceEx).
the server COM+ component can have its own bitness setting. If the client passes in one of the values above, the client value will overide the server value.
If neither the client nor the server specifies a preference then

on Windows XP or Windows Server 2003 without SP1 - 64 bit will be tried first with fallback to 32 bit in case of failure
on Windows Server 2003 with SP1 or later - the server will match the client architecture first, and it will fallback to the alternative in case of failure

The table below taken from MSDN documentation shows the results of the various combinations of client architectures and client settings and server architectures and server settings.

I hope you found this information useful.

	32-bit client, no flag	64-bit client, no flag	32-bit client, 32-bit flag¹	32-bit client, 64-bit flag²	64-bit client, 32-bit flag¹	64-bit client, 64-bit flag²
32-bit server, match client registry value³	32-bit server	F⁸	32-bit server	F⁸	32-bit server	F⁸
32-bit server, 32-bit registry value⁴	32-bit server	32-bit server	32-bit server	F⁸	32-bit server	F⁸
32-bit server, 64-bit registry value⁵	F⁸	F⁸	32-bit server	F⁸	32-bit server	F⁸
32-bit server, no registry value⁶	64/32⁹	64/32⁹	32-bit server	F⁸	32-bit server	F⁸
32-bit server, no registry value, Windows Server 2003 SP1⁷	32-bit server	64/32⁹	32-bit server	F⁸	32-bit server	F⁸
64-bit server, match client registry value³	F⁸	64-bit server	F⁸	64-bit server	F⁸	64-bit server
64-bit server, 32-bit registry value⁴	F⁸	F⁸	F⁸	64-bit server	F⁸	64-bit server
64-bit server, 64-bit registry value⁵	64-bit server	64-bit server	F⁸	64-bit server	F⁸	64-bit server
64-bit server, no registry value⁶	64-bit server	64-bit server	F⁸	64-bit server	F⁸	64-bit server
64-bit server, no registry value, Windows Server 2003 SP1⁷	32/64¹⁰	64-bit server	F⁸	64-bit server	F⁸	64-bit server

Additional useful information can also be found in the Serviced Components in 32-bit and 64-bit Architectures article. A COM application will either be 32 bit or 64 bit but it cannot be both. In order to register a 64 bit COM+ application for an assembly containing a serviced component you will have to run the 64 bit version of regsvcs tool. If you want the same serviced component to run as both 32 bit and 64 bit you will need to have 2 separate components sharing (inheriting) a common implementation, each serviced component with its own COM+ application for it.

¹ CLSCTX_ACTIVATE_32_BIT_SERVER.

² CLSCTX_ACTIVATE_64_BIT_SERVER.

³ PreferredServerBitness registry value = 1. See PreferredServerBitness.

⁴ PreferredServerBitness registry value = 2.

⁵ PreferredServerBitness registry value = 3.

⁶ PreferredServerBitness registry value is missing and Windows Server XP or Windows Server 2003 without SP 1 or later is installed.

⁷ PreferredServerBitness registry value is missing and Windows Server 2003 SP 1 or later is installed.

⁸ Fails with CO_CLASSNOTREG error.

⁹ A 64-bit server is activated if it exists; otherwise a 32-bit server is activated.

¹⁰ A 32-bit server is activated if it exists; otherwise a 64-bit server is activated.

BizTalk Server 2004 SP2 Beta is available

Adrian Hamza — Mon, 14 Aug 2006 21:10:00 GMT

From my colleague Bill Ticehurst [MSFT]:

Hi all,

A beta release of Service Pack 2 for BizTalk Server 2004 is now available
from the Connect site. To obtain this beta perform the following steps:

- Go to http://connect.microsoft.com/
- Sign in with your Passport account (you need to do this step for it to be
visible)
- Click on Available Connections
- On the second table on the page you should see "BizTalk Server 2004 SP2
beta"

If you download and install this service pack then feedback on any issues or
problems encountered would be greatly appreciated (that's what beta is for
right!). The email address for feedback is bts4sp2f@microsoft.com .
Positive feedback will also be of value and is appreciated.

Thanks and regards,

- Bill Ticehurst [MSFT]

%Filename% macro is not replaced with the disk filename

Adrian Hamza — Fri, 30 Jun 2006 20:47:00 GMT

I've seen this issue showing a couple of times on the BizTalk Newsgroups so I thought it's worth posting about this on my blog. The user expectation, which is probably correct from usability point of view, is that the %Filename% macro is replaced with the name of the original file no matter if that file was received from the disk through FILE adapter or from a document library through SharePoint adapter. This doesn't happen like that since the WSS adapter send ports will resolve the %Filename% macro to empty string if the message was originally received from any other adapter than WSS adapter. This is by design.

The %Filename% macro is replaced with the name of the SharePoint file (and not with the name of a file on disk). If the message was received through FILE adapter (or any other adapter than WSS) then the %Filename% macro is probably replaced with empty string. Macros (like %Filename%) and context properties (like WSS.Filename) are implemented by each adapter separately, they are specific to each adapter, and there is no 'framework' that would provide a unified set of macros/context properties accross all adapters. This makes sense since '%Filename%' might not make sense for a POP3 adapter or it could have a slightly different behavior for 3rd party adapters. Coincidently, some adapters have used the same macro name (I would guess %Filename% is a common one) and ocasionally the same context property. However, the %Filename% macro in a WSS adapter send port is totally different from a %Filename% macro in an FTP adapter send port, for instance.

To workaround this you can use an orchestration or a custom pipeline. All you need to do is get the disk file name from FILE.ReceivedFileName property and save it in the WSS.Filename property like below. Make sure that the Filename field in the send port UI dialog box is left empty so that the value supplied through the context property WSS.Filename is used to set the filename.
sharepointOutgoingMsg(WSS.Filename) = diskIncomingMsg(FILE.ReceivedFileName);

http://msdn.microsoft.com/library/en-us/BTS06Operations/html/1ff50fb8-7ba0-47b8-9476-d57413989346.asp?frame=true
http://msdn.microsoft.com/library/en-us/BTS06Operations/html/c5ae5339-67bf-4fde-a721-5b1aa3b9caca.asp?frame=true

You don't have to use dynamic send ports for the workaround above. In the case of WSS adapter, you can define the send port configuration through the WSS.Config*, WSS.Filename context properties of the outgoing message and then configure the WSS send port equivalent properties so that they are either empty (text boxes) or have a value of Orchestration (drop-down boxes) in order to not overwrite the configuration information specified through the context properties.

Custom Pipeline Component for Processing DBF, Excel and other ODBC types

Adrian Hamza — Fri, 23 Jun 2006 21:53:00 GMT

Matt Meleski implemented a custom pipeline component to process Excel or DBF files. I did not test this component myself but it seems that other people have tried and it worked well for them. This looks like a nice component that could complement the WSS adapter very nicely.

WSS Adapter handling of InfoPath forms with attachments

Adrian Hamza — Tue, 20 Jun 2006 23:15:00 GMT

InfoPath supports forms with file attachments by encoding the attachement as base64 and including the following PI

<?mso-infoPath-file-attachment-present ?>

at the top of the XML document to indicate that a file has been attached to the document.

WSS adapter works with InfoPath forms with attachements by making sure that it does not add/remove/update any of the PIs that are related to file attachment. If the files are attached to the form in InfoPath then the PI should be there because InfoPath adds it. If the files are attached by your orchestration or some component other than InfoPath, then the orchestration/component needs to add the PI explicitly. The adapter cannot know if a file attachment is included in the form (unless the PI is present in which case there's nothing to be done) so it will never add the PI. You can add the PI explicitly in your orchestration using a construct like this:

msg(XMLNORM.ProcessingInstructionOption) = 1;
msg(XMLNORM.ProcessingInstruction) = "<?mso-infoPath-file-attachment-present ?>";

So, whatever component attaches the files to the form needs to also add the PI. WSS adapter will preserve the PI if it's in the document, but it will never add such a PI to the XML document.

WSS v3 Beta 2 is out - try it with WSS adapter

Adrian Hamza — Tue, 06 Jun 2006 02:17:00 GMT

Windows SharePoint Services V3 Beta 2 is out and you can download it here. WSS v3 does not install a policy file that redirects old SharePoint assembly requests to the new assemblies. For this reason, if you try to use WSS v3 Beta 2 with BizTalk 2006 WSS adapter, you will run into errors. In order to workaround this problem and take WSS v3 Beta 2 for a test drive together with BizTalk 2006 WSS adapter, you will need to write your own policy file or just update the web.config file of the WSS adapter web service. Here's what you need to do:

Open web.config from C:\Program Files\Microsoft BizTalk Server 2006\Business Activity Services\BTSharePointAdapterWS
Paste the following section into the web.config file, configuration section and save the file
<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.SharePoint"
                          publicKeyToken="71e9bce111e9429c" />
        <bindingRedirect oldVersion="11.0.0.0"
                         newVersion="12.0.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
</runtime>

If you have other apps that were compiled against the old SharePoint assembly and you want to see if they will work with the new SharePoint assemblies, you can paste the snippet above in the configuration section of the machine.config file. That will make the changes global to entire machine.

During my tests, WSS adapter worked nicely with WSS v3 Beta 2. There were a few intermittent issues like [Microsoft.SharePoint.SPException] Unable to complete this operation. Please contact your administrator. or [Microsoft.SharePoint.SPException] The URL '/sites/BASSite/DestinationLibraryFromOrch/tmp-db04abaf-4a12-4e11-93c9-4338c17cc78c.xml' is invalid. It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not in the current Web.

However, the operation was succesful on the second retry performed by the adapter and since this is a beta product some annoyances are expected. If you decide to try WSS v3 Beta 2 yourself and you find worse problems, I would like to hear about them from you.

[Content below added/changed on June 14]

BizTalk 2006 Configuration routine for Windows SharePoint Services BizTalk Adapter Web Service/SharePoint Adapter fails to configure on WSS v3 Beta 2 (SharePoint 2007 Beta 2). In order to workaround this you can install and configure WSS adapter on WSS v2 and then upgrade to WSS v3.

An alternative is to configure the adapter web service manually. I haven't tried this approach but it should work. In this case you need to create a virtual folder on the IIS site hosting SharePoint and name that virtual folder BTSharePointAdapterWS. The virtual folder should point to C:\Program Files\Microsoft BizTalk Server 2006\Business Activity Services\BTSharePointAdapterWS folder. This virtual folder must run in its own application pool and this app pool needs to be a copy of the SharePoint app pool (app pool used by _layouts virtual folder). You also need to update the web.config file like below

These are my own workarounds and they are NOT supported by Microsoft. AFAIK, Microsoft has NOT announced yet if BizTalk 2006 will support WSS v3.

BizTalk Server 2006 TechCenter has been launched

Adrian Hamza — Tue, 02 May 2006 21:22:00 GMT

Yesterday, May 1st, we launched the BizTalk Server 2006 TechCenter (http://www.microsoft.com/technet/prodtechnol/biztalk/). The TechCenter provides easy access to BizTalk Server 2006 technical documentation, downloads, and community, as well as to IT Pro favorites such as the Events & Errors Message Center. Each navigation page within the technical library includes quick access to search BizTalk Server newsgroups and knowledge-base articles as seen, for example, on the Getting Started page. Among many things, the site contains

Virtual labs
The end-to-end tutorial as downloadable Word docs
New content on Clustering BizTalk Server
Links to the Installation Instructions
Links to the Production Documentation published on MSDN

In addition to the TechCenter, we also launched the BizTalk Server 2006 Developer Center (http://msdn.microsoft.com/biztalk). This project constituted a complete rebuild of the previous BizTalk Server 2004 Developer Center. For May we are featuring orchestrations. This includes new code samples, an FAQ paper on orchestrations, and in-depth content surfaced from the core documentation. With the re-design of the site it's easier than ever to learn to develop, deploy, administer, and use BizTalk Server 2006.

from Michael McConnell / Technical Writing Lead / BizTalk Server

WSS Adapter webcasts/videos

Adrian Hamza — Tue, 18 Apr 2006 21:28:00 GMT

BizTalk 2006 RTMd last month, and the BizTalk Betaplace has been closed for a few weeks now. Many people have asked me for access to the WSS Adapter videos that were shared on the betaplace and finally, here they are.

The videos are shared on this SharePoint site: http://wssadapter.members.winisp.net/default.aspx, in the Shared Documents document library, WSS Adapter Webcasts folder.

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included videos are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm. Some of the content was developed for the BizTalk Beta builds, but it is still generally applicable to the RTM version.