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.

Parsing plain text messages/flat files received through POP3 adapter

Adrian Hamza — Fri, 31 Mar 2006 20:06:00 GMT

Recently I received this question from one of our customers, unfortunately his email address was wrong and I couldn't reply directly to him. Before leaving to the BizTalk Shipping party ... yuuhuuu... I thought to try and provide an answer. See below a scrubbed version of the email I received

I am trying to find someone to help me with few tips related to BizTalk 2006 and POP3 adapter - specifically parsing plain text messages as they are flat files.

We are currently evaluating BizTalk 2006. Parsing of the plain text email messages containing for example orders as the body of the message is one of our tasks.

Do you know of any good resource (blog, samples, ...) to recommend.

I already tried community newsgroups but no help there. I would expect that this is rather trivial task with BizTalk 2006.

POP3 adapter has a built-in MIME decoding feature which is enabled by default ("Apply MIME Decoding" property on POP3 receive location property page). So, when POP3 adapter receives a message, it will convert the email body into BizTalk message part. It will save other email headers on the BizTalk message context. You can use Flat-file disassembler component in the receive pipeline and retrieve the actual business data. You can find some basic information on POP3 adapter here: http://www.microsoft.com/biztalk/techinfo/whitepapers/adapterwp.mspx (Open BTS2k6AdapterEnhance.doc)

Here is the online documentation for BizTalk Server 2006.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/bts06default/html/cadd3bdd-f13b-427d-8979-b2541aa5e21d.asp

If there are other questions, please follow up with me and I'll try to get some answers back to you. Please make sure you fill-in your email address correctly.

Upgrading from BT'04 GotDotNet WSS Adapter 1.0 to BT'06 native WSS Adapter

Adrian Hamza — Wed, 29 Mar 2006 09:30:00 GMT

I finally found some time and tried upgrading from BizTalk 2004 and GotDotNet WSS adapter to BizTalk 2006 and the native BT'06 adapter for Windows SharePoint Services. The idea was to start from a BizTalk 2004 installation with version 1.0 of Steve Resnick & Co. WSS Adapter (http://www.gotdotnet.com/workspaces/workspace.aspx?id=0d1aa85c-cf8d-497e-84f4-3ffec8db115f) , setup a simple messaging scenario using SharePoint, upgrade to BizTalk 2006, verify that messaging still works, upgrade to the native BizTalk 2006 WSS Adapter and then verify that messaging works with the new adapter.

I followed the steps below, in order to create a sample messaging test for SharePoint:

Created Source document library, then renamed it SourceDocLib (this trick causes the document library URL and the document library name to be different and this way I can see if WSSLib adapter really expects the URL or the display name of the document library). Created a View named ‘UpgradeDocuments’ that shows only those documents with ID >= 0 (probably all docs).
Created document library named 'Destination', then renamed it to 'DestinationDocLib'. Created folder ‘Dest Folder’. Added columns SharePointColumn1, and SharePointColumn2.
Created document library named 'Archive', then renamed it to 'ArchiveDocLib'. Created ‘My Folder’ folder in the library just created.
Created receive port and receive location for WSSLib adapter. Used all the fields available in order to make sure that similar field exists in native BT'06 adapter.
Created send port for WSSLib adapter, used all the fields.
(See the exported bindings or the UI captures below to see how the ports were configured. If you want to repro my test, after importing the bindings, you will have to update the filter on the send port to process messages received from the receive location by adding BTS.ReceivePortName == WSSLib-Receive condition. Only then start the send port.)
Sent test messages (see attached).
Exported all bindings.

See images below for the receive location and send port settings:

WSSLib - Receive Location	Receive Location XML <Config xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <pollingInterval>10</pollingInterval> <errorThreshold>10</errorThreshold> <site>http://demoappserver/Sites/BASSite</site> <folder>Source</folder> <view>UpgradeDocuments</view> <archiveFolder>Archive/My Folder</archiveFolder> <uri>http://demoappserver/Sites/BASSite/Source</uri> <userName /> <userPassword>******</userPassword> <userDomain /> </Config>
WSSLib - Send port (upper and lower part of configuration dialog box)
Send Port XML <Config xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <uri>wss://demoappserver/Sites/BASSite/Destination/Dest Folder</uri> <site>http://demoappserver/Sites/BASSite/</site> <folder>Destination/Dest Folder</folder> <overwrite>true</overwrite> <fileName>%GUID%</fileName> <fileExtension>xml</fileExtension> <fileNamespace>po0="http://MyTestNamespace"</fileNamespace> <userName /> <userPassword>******</userPassword> <userDomain /> <propertyName1>SharePointColumn1</propertyName1> <propertySource1>=//po1:PurchaseOrder/po1:Amount</propertySource1> <propertyNamespace1>po1="http://MyTestNamespace"</propertyNamespace1> <propertyName2 /><propertySource2 /> <propertyNamespace2 /> <propertyName3>SharePointColumn2</propertyName3> <propertySource3>=//po3:PurchaseOrder/po3:ChargeTo</propertySource3> <propertyNamespace3>po3="http://MyTestNamespace"</propertyNamespace3> <propertyName4 /> <propertySource4 /> <propertyNamespace4 /> <propertyName5 /> <propertySource5 /> <view/> </Config>

Once I configured the messaging I've sent a couple of messages through (see attached) to make sure that everything is working fine.

UPGRADE

I followed these steps http://geekswithblogs.net/darko/archive/2006/01/24/66866.aspx in order to upgrade to BizTalk 2006. The upgrade went through without problems. Another place where you can find upgrade information is this blog http://blogs.msdn.com/biztalk_upgrade/default.aspx Because my BizTalk 2004 installation had the BAS feature installed, after upgrade, both BAS and Windows SharePoint Services Adapter Web Service features were installed on the machine (even though the latter does not show up as enabled in setup, it's there because BAS requires it). If your BizTalk 2004 installation didn't have BAS, after upgrading your SharePoint box, you will have to start setup, add Windows SharePoint Services Adapter Web Service feature, and configure it. That's easy and straight forward so I won't go into details.

After upgrade, I browsed to the BAS site (SharePoint site) to see if SharePoint was still working fine and it didn't. I received the following error:
This Windows SharePoint Services virtual server has not been configured for use with ASP.NET 2.0.50727.42. For more information, please refer to Knowledge Base article 894903 at http://go.microsoft.com/fwlink/?LinkId=42660.

Troubleshoot issues with Windows SharePoint Services

The KB article just tells you to run one command. I run the command below:

stsadm.exe –o upgrade –forceupgrade –url http://demoappserver/sites/BASSite

restarted IIS and after that the BAS site shown up without problems. I started the BizTalk services that I stopped during upgrade, sent a few SharePoint messages through and everything worked fine.

Updating the ports

So I proceeded to update the receive location and send port in order to change from WSSLib adapter to 'Windows SharePoint Services' adapter. First thing I did, was to stop the BizTalk Host Instances that were used by the WSSLib adapter. This is probably not necessary, but in a couple of cases I noticed that the WSSLib ports don't shutdown appropriately and I didn't want to run into issues. After that, for each of the receive location or send port I changed the 'Transport Type' property from 'WSSLib' to 'Windows SharePoint Services' and then re-configured the send port/receive location like below.

'Windows SharePoint Services' - Receive Location	Receive Location XML <ReceiveLocation xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SiteUrl>http://demoappserver/Sites/BASSite/</SiteUrl> <WssLocation>Source</WssLocation> <ViewName>UpgradeDocuments</ViewName> <ArchiveLocation>Archive/My Folder</ArchiveLocation> <NamespaceAliases></NamespaceAliases> <ArchiveFileName></ArchiveFileName> <Overwrite>no</Overwrite> <ErrorThreshold>10</ErrorThreshold> <PollingInterval>10</PollingInterval> <BatchSize>20</BatchSize> <OfficeIntegration>optional</OfficeIntegration> <Timeout>100000</Timeout> <AdapterWSPort>80</AdapterWSPort> <uri>wss://demoappserver:80/Sites/BASSite/Source?ViewName=UpgradeDocuments</uri> </ReceiveLocation>
'Windows SharePoint Services' - Send port (upper and lower part of configuration dialog box)
Send Port XML <SendPort xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SiteUrl>http://demoappserver/sites/BASSite/</SiteUrl> <WssLocation>Destination/Dest Folder</WssLocation> <Overwrite>yes</Overwrite> <NamespaceAliases>po0="http://MyTestNamespace"; po1="http://MyTestNamespace"; po3="http://MyTestNamespace"</NamespaceAliases> <FileName>%MessageID%.xml</FileName> <OfficeIntegration>optional</OfficeIntegration> <TemplatesDocLib></TemplatesDocLib> <TemplatesNamespaceCol></TemplatesNamespaceCol> <CustomTemplatesDocLib></CustomTemplatesDocLib> <CustomTemplatesNamespaceCol></CustomTemplatesNamespaceCol> <PropertyName1>SharePointColumn1</PropertyName1> <PropertySource1>%XPATH=//po1:PurchaseOrder/po1:Amount%</PropertySource1> <PropertyName2></PropertyName2> <PropertySource2 /> <PropertyName3>SharePointColumn2</PropertyName3> <PropertySource3>%XPATH=//po3:PurchaseOrder/po3:ChargeTo%</PropertySource3> <PropertyName4></PropertyName4> <PropertySource4 /> <PropertyName5></PropertyName5> <PropertySource5 /> <PropertyName6></PropertyName6> <PropertySource6 /> <PropertyName7></PropertyName7> <PropertySource7 /> <PropertyName8></PropertyName8> <PropertySource8 /> <PropertyName9></PropertyName9> <PropertySource9 /> <PropertyName10></PropertyName10> <PropertySource10 /> <PropertyName11></PropertyName11> <PropertySource11 /> <PropertyName12></PropertyName12> <PropertySource12 /> <PropertyName13></PropertyName13> <PropertySource13 /> <PropertyName14></PropertyName14> <PropertySource14 /> <PropertyName15></PropertyName15> <PropertySource15 /> <PropertyName16></PropertyName16> <PropertySource16 /> <Timeout>100000</Timeout> <AdapterWSPort>80</AdapterWSPort> <uri>wss://demoappserver:80/sites/BASSite/Destination/Dest%20Folder</uri> </SendPort>

Once I updated all the send ports and receive locations, I re-started the host instances, and sent a few messages through. All the messages were processed correctly in the same manner as before and this concluded my upgrade experience. Please notice that my upgrade test was done using version 1.0 of the WSSLib adapter. On GotDotNet there is an RC for the WSSLib adapter version 2.0. A comparision of that WSSLib2 adapter and BizTalk 2006 native 'Windows SharePoint Services' adapter can be found here http://blogs.msdn.com/ahamza/archive/2005/07/27/BizTalk2006WSSAdapters.aspx The only feature supported by WSSLib2 that is not available in the native BT'06 adapter is storing the Username/Password in SSO per send port/receive location. The native BT'06 adapter uses the identity of the host instance to connect and authenticate with SharePoint. Upgrade from WSSLib2 to BT'06 native WSS Adapter should be just as straight forward.

Regardless of the adapter version from which you are upgrading, if you are using some of the adapter context properties in your orchestrations you will have to update your orchestrations to use the WSS.* context properties and that will require you to recompile and redeploy your orchestrations.

BizTalk Server 2006 has RTM'd

Adrian Hamza — Mon, 27 Mar 2006 20:22:00 GMT

BizTalk Server 2006 has RTM'd today ... best BizTalk ever, shipped on time and a very high quality server product. See the announcement here.

http://www.computerworld.com/softwaretopics/software/story/0,10801,109944,00.html

http://www.crn.com/sections/breakingnews/breakingnews.jhtml?articleId=183702861

Of course, my favorite BT'06 features are are WSS Adapter, BAS and BAM ... because my colleagues and I worked on many of these features ... ;-)

I've been working in BizTalk team for 4 years now, this is my second BizTalk release, and I really like the things that I do here. The product and the people are great, there are MANY great opportunities, the mix of technologies that we use or develop is exciting and challenging. This is one of the best places to be at Microsoft. If you are interested, check this post on how to get your resume posted and join the team http://blogs.msdn.com/biztalk_server_team_blog/archive/2006/03/21/556067.aspx
Normally, I would get borred working on the same product for 4 years, but that was not the case with this product. I decided to stay with the BizTalk team and work on the next version of BizTalk that should be even better. However, I will change teams inside BizTalk, I am moving to the engine/message box team. I have admired the work they've done for quite a while now and that seems to be the right place for me going forward.

If you haven't done this already, take a look at the latest BizTalk release here http://www.microsoft.com/biztalk/default.mspx

BizTalk Server product management team has a new blog

Adrian Hamza — Wed, 22 Mar 2006 01:58:00 GMT

Let's say welcome to the BizTalk Server product management team that has a new blog, with Mike Woods, Kris Horrocks, Steve Sloan, and Mark Berman contributing content every week. They’re ready to carry the momentum leading up to and after the ’06 release with great posts, so keep an eye on their blog.

If you are new to BizTalk then take a look at 'BizTalk Beginner Training Roadmap'

Adding a row into a SharePoint List and adding an attachment to it

Adrian Hamza — Mon, 20 Mar 2006 20:43:00 GMT

I recently got this email from a WSS Adapter user

... I saw your 4 last web casts, it helped me a lot to get a good idea about thee WSS adapter.I have a question, Can you help me please and tell me how to add a row into SharePoint list and add an attachment to it? Where can I get more help about WSS adapter other then interrupt you? ...

Unfortunately, the support for lists is not that rich in this release of the adapter. You can send messages to lists (create list row) but you cannot receive messages from lists or add attachments to a list item.

It's very easy to add a row to a SharePoint list using the WSS adapter. The problem is that the adapter does not support adding an attachment to the row that was inserted.

In order to add a row to a list, you just have to send a message to that list the same way you would send the message to a document library. For instance, you can send a message to the Shared Documents document library or you can send a message to the Lists/Tasks list. All lists URLs begin with Lists/ so make sure you use the correct URL for the list. When sending a message to a list, the message will not be saved in the list (as it is saved in the document library) but the property promotion still happens. This means that you can use the Column 01 ... Column 16, Column 01 Value ... Column 16 Value send port properties in order to extract the values from the XML message and save them in the List columns. You can also hard code the SharePoint column values instead of taking them from the message. The Filename field is not used when sending messages to list, instead you will have to update the Title column.

See topic, 'Supported Windows SharePoint Services Column Types ' in the BizTalk 2006 documentation (beta available for download here http://blogs.msdn.com/luke/archive/2006/02/03/524534.aspx ) for info on how to update particular SharePoint column types. You can also take a look at 'Walkthrough: Module 3 - Accessing SharePoint Properties from an Orchestration '. Unfortunately that's a little bit of an overkill because you need to do tutorial 1 and 2 before you can do 3, and also the main goal of the tutorial is to show how to use dynamic send ports. Sending a message to a list is a very small part of that tutorial and it's done using a dynamic send port instead of the easier way which is using a physical send port.

In order to add an attachment to the list item you just created, you will have to write a .Net Component that invokes the Windows SharePoint Services web services and call that component from a BizTalk orchestration. Most likely you will have to use the http://localhost/_vti_bin/Listswsdl.aspx web service. You can take a look at this http://blogs.msdn.com/ahamza/archive/2006/03/15/WssAdapterBrowseUI.aspx project (source code is included) to see how I have used the WSS web services. That projects uses the Lists web service so you can probably even reuse some of the code.

More information on WSS adapter is available in the BizTalk 2006 documentation (pointer listed above), just search for SharePoint. You can also ask me questions anytime or just forward your questions to BizTalk discussion aliases ( http://blogs.msdn.com/kevin_lam/archive/2005/07/11/437590.aspx ).

Adding Browse UI to BT'06 WSS adapter

Adrian Hamza — Wed, 15 Mar 2006 18:57:00 GMT

The WssAdapterBrowseUI.dll modifies the default WSS Adapter UI so that instead of typing the names and URLs of SharePoint document libraries, lists, or columns you will be presented with a list view/tree view from where you can select the appropriate SharePoint object. The friendly names/titles of SharePoint objects are being shown but the UI is filled with the appropriate value (document library relative URL, document library title, column title, etc). This component does not validate that values entered manually are correct.

Left image above is the original WSS UI included in BizTalk 2006. Right image above, is the modified WSS UI that includes browse SharePoint site functionality. The dropdown box (circled in red in image above) is visible only when the cursor is positioned inside the text box.

This functionality is implemented by wrapping the WSS adapter management class (found in Microsoft.BizTalk.KwTpm.WssAdapter.StaticAdapterManagement.dll) and annotating the returned XSD schemas in order to instruct BizTalk what classes can be used to query and display the SharePoint information. WssAdapterBrowseUI.dll replaces the Microsoft.BizTalk.KwTpm.WssAdapter.StaticAdapterManagement.dll
assembly, forwards all calls to StaticAdapterManagement classes and it modifies the returned results.
Microsoft.BizTalk.KwTpm.WssAdapter.StaticAdapterManagement.dll is still needed since WssAdapterBrowseUI.dll uses it.

Setup steps:
- backup registry information
- copy WssAdapterBrowseUI.dll to BizTalk folder
- modify registry information so that BizTalk uses WssAdapterBrowseUI.dll instead of Microsoft.BizTalk.KwTpm.WssAdapter.StaticAdapterManagement.dll

Disclaimer
Use this code at your own risk. No support is provided and this code has NOT been tested.

Important
If you re-run BizTalk setup, configuration or if you need to apply a BizTalk QFE or future Service Pack, you will have to uninstall this component before doing so. This component is not supported!

Registry Backup
Run command below to make a copy of the default Wss Adapter registration. Open file in notepad to make sure backup worked.
reg export "HKEY_CLASSES_ROOT\CLSID\{BA7DAD66-5FC8-4a24-A27E-D9F68FD67C3A}" OriginalWssAdapterRegistration.reg

Keep this backup since you will need to restore the original Wss Adapter registration before applying any BizTalk SP or QFE.

Copy WssAdapterBrowseUI.dll to BizTalk folder
Copy supplied WssAdapterBrowseUI.dll (or build your own, see How to build WssAdapterBrowseUI.dll) to C:\Program Files\Microsoft BizTalk Server 2006

Update registry
Update Wss Adapter registration to use the new adapter management class
a) open "WssAdapterRegistration-Annotated.reg.RENAMEIT" in notepad and make sure that paths are correct
Notice - if you update any file paths in the registry file make sure you use \\ instead of \
b) Rename "WssAdapterRegistration-Annotated.reg.RENAMEIT" (remove ".RENAMEIT" from the name)
c) import registry settings by opening WssAdapterRegistration-Annotated.reg

How to build WssAdapterBrowseUI.dll
The sources and binaries are included in the attached zip file. Open WssAdapterBrowseUI.csproj in Visual Studio 2005. If references to assemblies
Microsoft.BizTalk.Adapter.Framework.dll
Microsoft.BizTalk.KwTpm.WssAdapter.StaticAdapterManagement.dll
are not correct update the references.

Referenced assembly Microsoft.BizTalk.Adapter.Framework.dll is found under \Program Files\Microsoft BizTalk Server 2006\Developer Tools
Referenced assembly Microsoft.BizTalk.KwTpm.WssAdapter.StaticAdapterManagement.dll is found under \Program Files\Microsoft BizTalk Server 2006
Build the project.

Problem when configuring WSS 2003 with SP2 to run on top of .Net Framework 1.1 and then upgrading to .Net Framework 2.0

Adrian Hamza — Sat, 11 Mar 2006 03:08:00 GMT

A few users have reported this configuration issue when trying to install and configure BizTalk 2006 with Windows SharePoint Services adapter. BizTalk 2006 native adapter for Windows SharePoint Services requires .Net Framework 2.0 but most of the users don't realize this until they try to configure the Windows SharePoint Services Adapter Web Service feature of BizTalk 2006. At that point, in many cases, Windows SharePoint Services has already been configured to run on top of .Net Framework 1.1 so the following error is visible in BizTalk configuration Web site is not configured to use .Net Framework 2.0

Changing the ASP.NET version on IIS site to be 2.0 instead of 1.1 causes Windows SharePoint Services 2003 to stop working completely.

This is not a BizTalk 2006 configuration issue, but BizTalk requirements combined with the succession of installation and configuration steps makes it pretty likely to run into this configuration issue of WSS 2003 with SP2. This is a known WSS 2003 with SP2 configuration issue and can be fixed easily by running STSADM tool with the force ugprade parameter.

In order to quickly upgrade your IIS site and WSS 2003 with SP2 from .Net Framework 1.1 to .Net Framework 2.0, run the commands below:

"%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe" -i

"%CommonProgramFiles%\Microsoft Shared\web server extensions\60\BIN\STSADM.exe" -o upgrade -url http://localhost:80 -forceupgrade

Using DelayedFileSystemWatcher sample

Adrian Hamza — Tue, 07 Feb 2006 04:44:00 GMT

See attached file for a sample on how to use DelayedFileSystemWatcher class described in my previous post FileSystemWatcher generates duplicate events - How to workaround

FileSystemWatcher generates duplicate events - How to workaround

Adrian Hamza — Sun, 05 Feb 2006 05:09:00 GMT

I had to use the FileSystemWatcher class these days and I found out that it raises multiple duplicate events. If you are not familiar with FileSystemWatcher class, this class allows you to watch a particular folder and receive notifications/events every time there is change happening in that folder. You can subcribe to all sorts of events: file created, file changed, file renamed, file accessed, directory created, directory renamed, directory accessed, etc.

The problem is that multiple duplicate events are being raised. For instance, if I copy a file over an existing file, instead of raising one file changed event, the FileSystemWatcher object will raise 5 !!! such file change events that are identical. If you are creating a file, the FileSystemWatcher class will raise a file created event and at least a file changed event.

I think that some of these issues are caused by the Win32 APIs and they are normal, others (like the file createad and file changed events when creating a file) are probably caused by applications. Many applications will first create an empty file and then they will update the file with the file content hence the file created, file changed events being raised when creating a new document.

This can be worked around by queueing the events (let's say over a 1 second period) and then remove any duplicates. And this is what I did. I implemented my own version of FileSystemWatcher class (named DelayedFileSystemWatcher) that mimics MOST of the FileSystemWatcher behavior and it removes duplicate events.

DelayedFileSystemWatcher class will delay processing of any events that are being raised. All events that are raised (except error events) by the inner FileSystemWatcher object will be queued to a collection. The ElapsedEventHandler method will be invoked automatically (through a System.Timer.Timer event) every 1 second. This method will analyze all events in the queue. The first time an event is found, it will be marked as "Delayed" and it won't be processed. The next time the method is executed, the already "Delayed" events will be raised but first all events that are duplicate of "Delayed" events will be removed. An event in the queue will either be delayed (processing postponed for next timer event), raised (it's already delayed and it's the first event of his kind), or deleted (delayed or not but there was an event in front of it that was similar/duplicate).So this class mimics FileSystemWatcher but it removes duplicate events that show up within 2 timer events. A second event is duplicate of a first event if both events are of the same type and have all properties equal or if the second event is a an update/changed event, first event is a create event and both events refer to the same file.

See code file attached. DISCLAIMER: Use this code at your own risk. No support is provided and this code has NOT been tested.

[Last file update - February 09, 2006]

BizTalk Server 2006 Beta2 is out - What's new in WSS Adapter?

Adrian Hamza — Tue, 22 Nov 2005 21:15:00 GMT

Microsoft BizTalk Server 2006 Beta2 is now available on Microsoft Beta Place. If you have not signed up already for BizTalk 2006 Beta program you can follow the instructions that I posted in this previous post in order to download the bits. If you have already signed up for BizTalk Beta 1 then you can just go to https://beta.microsoft.com, sign in with your account and download the latest BT 2006 beta.

The setup/configuration is pretty much the same so you can follow the steps from my previous post but now you have to use the RTM version of Visual Studio 2005 and Windows SharePoint Services 2003 with SP2.

BizTalk 2006 Beta 2 is a production-ready build, and of course upgrade from Beta 2 to RTM will be supported.

So, what's new feature wise in Windows SharePoint Services adapter included in BizTalk 2006 Beta 2 when compared to previous Beta 1? See below:

new macros %Filename% and %Extension% are supported in all send port/receive location fields that accept macros. These macros are replaced at runtime with the filename and extension values computed from the WSS.Filename context property of the message being processed. All messages that are received from SharePoint have this property automatically initialized to the filename of the SharePoint file that generated the BT message. As a result these macros will be replaced with the filename and extension of the original SharePoint file (if the message originated from SharePoint), or with the filename and extension defined in the orchestration/custom pipeline if the orchestration/custom pipeline specifies a value for the WSS.Filename context property of the message. Unlike the rest of the WSS adapter macros, these two macros cannot be used in WSS adapter context properties values that are defined in an orchestration/pipeline. This feature addresses a part of Edgardo's well justified complaint that he made a while ago . The other part of the complaint (about Versioning support) was not possible to address in this release but it might be addressed by a future release.
the send port "Microsoft Office Integration" setting now supports an "Yes (InfoPath Form Library)" option. If this option is enabled and the XML message is being sent to a SharePoint InfoPath form library, the XML file being created will automatically be linked to the InfoPath solution attached to the SharePoint form library so that the file will open up in InfoPath. When Microsoft Office Integration is set to "Yes (InfoPath Form Library)", no values are required for the other Microsoft Office Integration fields but the message must be sent to a SharePoint InfoPath Form Library.
The behavior for "Optional" setting of "Microsoft Office Integration" send port property has been changed slightly to accomodate the new value "Yes (InfoPath Form Library)". When Office Integration is set to “Optional”, the adapter will try to use both discovery mechanisms ("Yes" and "Yes (InfoPath Form Library)"). If both mechanisms return a solution, the solution found in the Templates Document Library/Templates Fallback Document Library will be preferred. If no InfoPath solution is found the message will not be suspended, instead it will be saved as-is (no change here).
the send port "Overwrite" setting now supports a Rename option. If a file with the same name exists in SharePoint, the name of the file being created will be made unique by appending the message identifier %MessageID% to it. This option is not supported for receive location 'Archive Ovewrite' property.

Configuring Windows SharePoint Services on 64 bit machines/OS

Adrian Hamza — Mon, 21 Nov 2005 17:01:00 GMT

WSS with SP2 can run in 32-bit emulation mode on a 64-bit machine/OS but there are a few manual steps that need to be done in order to get that working.

Step 1 - First of all, set the IIS application pool to run as 32 bit. On 64 bit machines, SharePoint runs in 32-bit emulation mode. This means that you need to update IIS settings so that the IIS application pool processes run as 32 bit processes. One caveat here is that the setting that controls this applies to all application pool processes. This means that all IIS app pools will run either as 32 bit or as 64 bit but not both. To do that you will have to set the W3SVC/AppPools/Enable32bitAppOnWin64 metabase property to 1. For more details see KB article http://support.microsoft.com/default.aspx?scid=kb;en-us;895976

To do that run the following commands from the command prompt
CScript "%SystemDrive%\InetPub\AdminScripts\adsutil.vbs" set w3svc/AppPools/Enable32bitAppOnWin64 1
iisreset

Step 2 - Enable the ASP.NET extensions for the 32 bit ASP.NET version. To do that you will have to run the commands below from the "Visual Studio 2005 Command Prompt".
%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -i -enable
iisreset

Make sure you run this command from the Framework folder and not from the Framework64 folder.

Step 3 - Install the slipstream version of WSS 2003 with SP2 (kit of WSS 2003 containing SP2 instead of kit of WSS 2003 and then separately apply SP2). If you don't install the slipstream version of WSS 2003 with SP2, then I think you need to first install .Net Framework 1.1 as described by step 2 in http://support.microsoft.com/Default.aspx?id=905854.

Troubleshooting and fixing errors
I purposely reproed a few of the errors that I knew you could run into in order to see how these errors manifest themselves and how they can be fixed.

A) Windows SharePoint Services requires a more recent version of Microsoft ASP.Net. To install a more recent version, go to Add or Remove Programs, click Add/Remove Windows Components, click Application Server, click Details, and then select ASP.NET.

This error is raised by Windows SharePoint Services 2003 with SP1 setup when the .Net Framework 1.1 is not installed. This error is also raised when you have installed .Net Framework but it's version 2.0. This error is not raised by Windows SharePoint Services 2003 with SP2 setup. Windows SharePoint Services 2003 with SP2 supports .Net Framework 2.0 and you are going to need it anyway if you want to run WSS on the 64 bit OS. So instead of installing WSS 2003 with SP1, you should download and install WSS 2003 with SP2 from here http://www.microsoft.com/downloads/details.aspx?familyid=B922B28D-806A-427B-A4C5-AB0F1AA0F7F9&displaylang=en.

The .Net Framework installation instructions from the error message do not apply to the 64 bit OS, so you will have to download and install the .Net Framework 2.0 from one of these 2 links
Microsoft .NET Framework Version 2.0 Redistributable Package (x64) - http://www.microsoft.com/downloads/details.aspx?familyid=B44A0000-ACF8-4FA1-AFFB-40E78D788B00&displaylang=en
Microsoft .NET Framework Version 2.0 Redistributable Package (IA64) - http://www.microsoft.com/downloads/details.aspx?familyid=53C2548B-BEC7-4AB4-8CBE-33E07CFC83A7&displaylang=en

B) Windows SharePoint Services requires a more recent version of Microsoft ASP.NET. Go to the Microsoft Web site at www.microsoft.com to download and install a more recent version.
This error is raised by Windows SharePoint Services with SP2 when one of the following is true
       1 - .Net Framework has not been installed on the machine. See bulet A) above on how to download and install .Net Framework.
       2 - .Net Framework has been installed but ASP.NET is not enabled. See step 2 above on how to enable ASP.NET
       3 - ASP.NET has been installed, but IIS application pools are running in 64 bit mode. See step 1 above on how to switch the app pools to 32 bit mode.

C) The Microsoft .Net Framework version 1.1.4322 must be installed before this package can be installed.
WSS 2003 with SP2 does not require .Net Framework 1.1 if 2.0 is installed but somehow I managed to get the machine in this state and after that I couldn't remove or re-install SharePoint. No matter what I did, I got the same error message referring to .Net Framework 1.1.
If your machine is in this state you can remove SharePoint by temporarilly installing .Net Framework 1.1 from here http://www.microsoft.com/downloads/details.aspx?FamilyId=262D25E3-F589-4842-8157-034D1E7CF3A3&displaylang=en.
Then you can re-install and configure WSS 2003 with SP2 and only after that remove .Net Framework 1.1.

D) RpcProxy.dll failed to load
If you get the following 2 errors in the Application Event Log, then you need to uninstall/reinstall RPC Over HTTP Proxy. You will have to do that from Control Panel -> Add Remove Programs -> Add/Remove Windows Components -> Networking Services -> RPC Over HTTP Proxy

Event Type: Error
Event Source: W3SVC-WP
Event Category: None
Event ID: 2214
Date:  11/16/2005
Time:  12:58:23 PM
User:  N/A
Computer: MachineName
Description:
The HTTP Filter DLL C:\WINDOWS\System32\RpcProxy\RpcProxy.dll failed to load. The data is the error.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 7e 00 00 00 ~...

E) Could not load all ISAPI filters for site/service. Therefore startup aborted.
or
ISAPI Filter 'path to filter' could not be loaded due to a configuration problem. The current configuration only supports loading images built for a AMD64 processor architecture. The data field contains the error number. To learn more about this issue, including how to troubleshooting this kind of processor architecture mismatch error, see http://go.microsoft.com/fwlink/?LinkId=29349.

You probably
    1 - skipped step 1)
    2 - you performed step 1) but then some other application has reverted the setting so that the IIS app pools run as 64 bit
    3 - you have 32 bit and 64 bit filters installed on the same machine in which case only one set of the filters will work

Installing SharePoint Portal Server 2003 SP2 on a Windows Server 2003 x64 Edition
For installing SharePoint Portal Server 2003 SP2 on a Windows Server 2003 x64 Edition see the following KB article http://support.microsoft.com/Default.aspx?id=905854

New WSS Adapter videos are available on the Microsoft Beta site, BizTalk Server 2006 program

Adrian Hamza — Tue, 15 Nov 2005 01:30:00 GMT

Hi folks,
Sorry for the long delay since my last post, I just got back from a 3 weeks vacation. My parents visited US for the first time and I took some time off to show them how wonderful Puget Sound is. Originally, I am from Romania but I moved here 5 years ago and this was their first visit.

When I got back from vacation I had the surprise to see that the new WSS Adapter demos that I recorded before going on vacation have been approved and posted online on the BizTalk Beta Place, so here they are ...

WSSAdapter-SetupAndConfig-Short.wmv (9.58 MB) - Windows SharePoint Services 2003 with SP2 and BizTalk Server 2006 Beta 1 setup and configuration
WSSAdapter-SendReceiveCBR.wmv (10.25 MB) - basic send and receive scenario using Content Based Routing feature in BizTalk
WSSAdapter-InfoPathIntegration.wmv (15.11 MB) - using InfoPath integration feature of the adapter
WSSAdapter-PropsInOrchestration.wmv (28.58 MB) - tutorial for BizTalk developers showing how to access SharePoint properties from BizTalk orchestrations, how to configure SharePoint adapter dynamic send ports and how to send messages to SharePoint lists like the Tasks list

The demos included in these videos build one on top of each-other so it makes sense to view them in the order I listed above.

The previous webcast "BTS 2006 Windows SharePoint Services (WSS) Adapter Deep Dive" is also available.

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

Service Pack 2 for Windows SharePoint Services 2003 has been released

Adrian Hamza — Tue, 04 Oct 2005 23:15:00 GMT

Service Pack 2 for Windows SharePoint Services 2003 has been released last week on September 27.

You can download the SP2 here .
You can download the full version of Windows SharePoint Services with SP2 integrated (slipstream) from here .

From my perspective, most interesting features added by this service pack are:
- Whidbey (.Net Framework 2.0) support: both side-by-side with .Net Framework 1.1 and also support for running against Whidbey
- Support for 64 bit - WSS with SP2 can run in 32-bit emulation mode on a 64-bit machine

Information for BizTalk 2006 Beta 1 Users
WSS adapter and BAS included with BizTalk Beta 1 require the preview build of WSS SP2 which has been made available through the BizTalk 2006 Beta program.
The RTM build of WSS SP2 seems to not work with BizTalk 2006 Beta 1 due to compatibility issues (they are compatible with different builds of .Net Framework 2.0).
BizTalk Beta 1 requires .Net Framework 2.0 Beta 2. WSS SP2 preview build is compatible with Beta 2 build of the .Net Framework where the RTM build of WSS SP2 seems that it's not or at least I wasn't able to get it to work.

BizTalk 2006 Beta 2, probably shipping sometime in November 2005, will most likely work with the RTM bits of WSS SP2 and .Net Framework 2.0.

Information for BAS feature users in BizTalk 2004
If you have installed WSS SP2 build on a SharePoint machine with BizTalk 2004 and BAS feature then you probably have to apply a BizTalk 2004 hotfix, otherwise the SharePoint messaging feature in BAS will be partially broken. For more details see KB article http://support.microsoft.com/kb/908359

WSS Adapter webcast recording is now available on Microsoft Betaplace

Adrian Hamza — Wed, 21 Sep 2005 00:53:00 GMT

I mentioned before that I'll be doing a webcast on the Windows SharePoint Services native adapter included in BizTalk 2006 (see SeptemberWSSAdapterWebcast).

The "BTS 2006 Windows SharePoint Services (WSS) Adapter Deep Dive" webcast is now available on the Microsoft Beta Place http://beta.microsoft.com/ , Microsoft BizTalk Server 2006, under the Additional File Downloads section.

If you haven't signed-up already in the BizTalk 2006 Beta program, then go to bts2006beta to see the instructions.

[April 18, 2006] The BizTalk Betaplace is closed now.

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.

"I cannot access the MSMQC adapter properties in an orchestration" issue

Adrian Hamza — Sat, 10 Sep 2005 05:09:00 GMT

Recently, somebody asked me how to access the MSMQ label from BizTalk, in order to access some information that is passed by its own C# application through the MSMQ label.
See issue described below.
----------------------------------
Below I give my problem, Please give me a good solution for me.
I have a C# application. It has an upload page. If user uploads a XML file,the C# application reads it and send this to MSMQ as a Message.
The code is below.

StreamReader sr = new StreamReader(Path); string str; str = sr.ReadToEnd(); System.Messaging.Message mm = new System.Messaging.Message(); mm.Formatter = new ActiveXMessageFormatter(); mm.Body = str.ToString(); mm.Label = UserID; mq.Send(mm);

I create a Orchestration with receive and send ports. The receive ports looks message from the MSMQ using MSMQ adapter. then I use schemas and maps to transfer the Message. After that, I use a file adapter for save the final message to a folder.

Every thing works fine. My problem is, I want to identify the User who uploads the file. In C# application I set the label for the message as USERID.

I want to save the name of the output file is [userid].xml.

I use %SourceFileName% and MsgOut(FILE.ReceivedFileName) to rename the output file. But how to get the userid from the C# application and set the file name. I cant able to access MSMQT.Label in Expression Editor. Because I use MSMQ adapter. Please give me a good solution.

The main problem is identify the user who uploads the file.
----------------------------------
The problem with the existing implementation of MSMQC lies in the MSMQPropertySchema.xsd file that seems to be incorrect.
This XSD schema must be updated so that the properties are marked as context properties. To do this, select each property and change the "Property Schema Base" property from default value (no value) to MessageContextPropertyBase. Once you do this, re-build and re-deploy the updated schema project, and you should be able to access these properties from your orchestration.
This is how the schema should look like

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns="http://schemas.microsoft.com/BizTalk/2003/msmqc-properties" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" targetNamespace="http://schemas.microsoft.com/BizTalk/2003/msmqc-properties" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:annotation>
    <xs:appinfo>
      <b:schemaInfo schema_type="property" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" />
    </xs:appinfo>
</xs:annotation>
<xs:element name="AppSpecific" type="xs:int">
    <xs:annotation>
      <xs:appinfo>
        <b:fieldInfo propertyGuid="ec76abf6-1c10-4383-8182-635eaf20a790" propSchFieldBase="MessageContextPropertyBase" />
      </xs:appinfo>
    </xs:annotation>
</xs:element>
<xs:element name="ArrivedTime" type="xs:dateTime">
    <xs:annotation>
      <xs:appinfo>
        <b:fieldInfo propertyGuid="3d8ae2da-2f26-4422-a68a-67f005cf32c8" propSchFieldBase="MessageContextPropertyBase" />
      </xs:appinfo>
    </xs:annotation>
</xs:element>
<xs:element name="Authenticated" type="xs:boolean">
    <xs:annotation>
      <xs:appinfo>
        <b:fieldInfo propertyGuid="36e29190-e4cc-4e64-b181-4a63488ccd75" propSchFieldBase="MessageContextPropertyBase" />
      </xs:appinfo>
    </xs:annotation>
</xs:element>
<xs:element name="CorrelationId" type="xs:string">
    <xs:annotation>
      <xs:appinfo>
        <b:fieldInfo propertyGuid="d16e9d65-f742-4982-9c71-59089fa23b22" propSchFieldBase="MessageContextPropertyBase" />
      </xs:appinfo>
    </xs:annotation>
</xs:element>
<xs:element name="Id" type="xs:string">
    <xs:annotation>
      <xs:appinfo>
        <b:fieldInfo propertyGuid="c0e64a4d-8a6f-4b21-936c-5531abb255f4" propSchFieldBase="MessageContextPropertyBase" />
      </xs:appinfo>
    </xs:annotation>
</xs:element>
<xs:element name="Label" type="xs:string">
    <xs:annotation>
      <xs:appinfo>
        <b:fieldInfo propertyGuid="1ff2b7af-2dd8-4b38-8360-2373e5fb05f6" propSchFieldBase="MessageContextPropertyBase" />
      </xs:appinfo>
    </xs:annotation>
</xs:element>
<xs:element name="Priority" type="xs:int">
    <xs:annotation>
      <xs:appinfo>
        <b:fieldInfo propertyGuid="7f13d6b8-21c6-4914-9025-b91dc03c0b24" propSchFieldBase="MessageContextPropertyBase" />
      </xs:appinfo>
    </xs:annotation>
</xs:element>
<xs:element name="ResponseQueue" type="xs:string">
    <xs:annotation>
      <xs:appinfo>
        <b:fieldInfo propertyGuid="8cf607f9-165e-43c8-b730-07559d876b5c" propSchFieldBase="MessageContextPropertyBase" />
      </xs:appinfo>
    </xs:annotation>
</xs:element>
<xs:element name="SentTime" type="xs:dateTime">
    <xs:annotation>
      <xs:appinfo>
        <b:fieldInfo propertyGuid="603ffea4-4fd9-443c-9362-b662b8aacddb" propSchFieldBase="MessageContextPropertyBase" />
      </xs:appinfo>
    </xs:annotation>
</xs:element>
<xs:element name="SourceMachine" type="xs:string">
    <xs:annotation>
      <xs:appinfo>
        <b:fieldInfo propertyGuid="32fbdf7b-d19f-4e27-9b45-331810780eef" propSchFieldBase="MessageContextPropertyBase" />
      </xs:appinfo>
    </xs:annotation>
</xs:element>
</xs:schema>