Integrating BizTalk with CRM 2011 Online Discovery Service


On the MSDN forums there has been quite a bit of traffic and many questions about how to integrate BizTalk with Dynamics CRM 2011. Since I did not have a local CRM 2011 environment setup I thought it would be a good time to look into whether a trial of CRM 2011 existed. Yesterday I setup a trial of BPOS to test out forms services in the cloud. I found out that there was an offer running on a free trial of Dynamics CRM Online so I joined up. This trial was nearly effortless because i was already signed up as an Azure customer through my MVP/MSDN member benefits. Here is a link to the trial offer:

In this post I will document some of the integration experience I have encountered from working with BizTalk and CRM 2011 for basically just a few minutes. I have been very active in discussions in the MSDN forums about how BizTalk relates to CRM 2011 so I was aware of some of the current challenges. A few people had mentioned they were having trouble generating the BizTalk schemas. So this is something I tried out and was successful doing. The bigger discussion about BizTalk and CRM 2011 revolves around the adapter used for integration. In CRM 4 there was a specialized adapter but no specialized one has been found so far for CRM 2011. As far as I can tell the intended approach is to use the WCF adapters.

My hope is that the use of the WCF adapters will enable CRM implementations to achieve high availability. This has been a perplexing and difficult for one of my customers due to known limitations in the CRM 4 adapter.


After signing up for the CRM Online 2011 trial, I was brought to the main form for working with my CRM data, which is https://<organization> This form reminds me quite a bit of working with SalesForce contacts and accounts but the overall feel is much more responsive and a much richer experience. The SalesForce contact and account management features were mind numbing when I worked with them. In contrast, the CRM Online forms are invigorating and stunning.

From my previous investigation into CRM 2011 and BizTalk integration I had found the following source code example: This example shows us how to communicate with the CRM Discovery service which then provides credentials to use when contacting the organization service to work with the CRM entitites. The following line of code is the most important towards pulling out some useful artifacts for BizTalk integration:

CrmDiscoveryService discoveryService = new CrmDiscoveryService();
discoveryService.Url = String.Format("https://{0}/MSCRMServices/2007/{1}/CrmDiscoveryService.asmx",
                        _hostname, "Passport");

The value for the _hostname variable refers to the organization URI <organization> I built up this address by hand and entered it into the browser so that I could see the service description page. So the full address would be This gave me the service description page where I could get the WSDL for the discovery service. I copied this file to my SkyDrive so that others could use it: This file is critical in generating the schemas for BizTalk. Apparently this is not a new technique for CRM – it is fairly well documented:

Next I opened up my VM with BizTalk 2010 and created a new solution for the integration. I copied the WSDL file mentioned above to a location where I could use it on my VM. First I tried creating the schemas by adding a service reference to my BizTalk project. This unfortunately did not create any schemas for me but it did add the service reference successfully. So the next attempt was to Right-click on my BizTalk project and go to Add Generated Items…\Consume WCF Service. Then in the wizard I specified the WSDL file from above. This helped me to generate the schemas successfully.

The schemas that were generated looked quite a bit different from really any I had seen before. Maybe the syntax will not be new to you but I thought it looked unusual. Many of the elements in the BizTalk schema designer have brackets like you would see for an xs:Any element because they are complex types. Here is a picture of the generated schema:

The schema given above actually gives you quite a bit more detail than the service description page which just mentions the Execute method.


Interacting the CRM 2011 Online Discovery service is actually very easy and is quite similar to the way it was implemented in CRM 4. I zipped up the generated schemas and placed them on my SkyDrive here: If you are having trouble generating the schemas you can just use mine. What has been shown here is only part of the overall solution for integrating between BizTalk and CRM 2011 Online but it gets you started nicely.


New BizTalk articles on TechNet Wiki

Here are a few TechNet Wiki articles that have become available recently. I have usually found it difficult to find relevant content on the TechNet Wiki so I thought it would be good to highlight a few of these.

Improving performance when executing a BRE rule:

Implement ordered messaging with BizTalk and SSIS:

BizTalk load testing in VS 2010:

Load testing for simultaneous BizTalk unit tests:

Install and configure BAM in a multi-server environment:


Why would you want a WCF LOB SDK Adapter?


In my last post I mentioned the registry content for registering a custom WCF LOB SDK binding as an adapter. I am still working out the details of how this should be done for a custom adapter and will be hoping how to do this in a walkthrough in a later post. 

To give you some preview of the process, the adapter class just needs to inherit from Microsoft.Adapters.Common.BizTalk from the BizTalk adapter pack rather than Microsoft.ServiceModel.Channels.Common.Adapter from the WCF LOB SDK. The abstract classes for Microsoft.Adapters.Common.BizTalk are included with the BizTalk Adapter Pack. The GUID values mentioned in the .reg file are set in the derived adapter classes and when calling the base class constructor for the adapter, WcfBtsAsdkAdapterBinding.

While it looks like it is possible to register a custom WCF LOB SDK binding as an adapter, the question comes up as to why would you ever want to do this when you can just use the custom binding in the WCF-Custom adapter anyway. This is one question I have asked repeatedly in reference to why the BizTalk adapter pack gives the developer the option of using the separate adapter rather than the bindings with the WCF-Custom adapter. At this time I am not sure if some of the scenarios I have come up with explain why the BizTalk adapter pack bindings are also exposed as custom adapters.

I wanted to take this post and describe a few scenarios that would be useful for having the capability of an adapter rather than a WCF-Custom binding.


Deciding whether to expose a WCF LOB SDK binding vs. a full adapter is an important question that depends largely on the consumers of your data. If you want the same data and management of the connection to your data to be the same whether it is being called from .NET or BizTalk then use of the standard custom binding makes sense. You will only need to code the logic once as the custom binding. But there are typically many differences between .NET applications and BizTalk applications so it seems like there would be compelling reasons to have other settings or different settings based on whether the binding is being called from a BizTalk system. For example, SSO settings like the SSO Application Name and key should not be exposed unless the binding is being called from BizTalk. These properties will not make sense if you are providing a way to connect to your custom LOB data without going through BizTalk.

The full adapter does have a configuration limitation that prevents it from fully functioning as an equivalent to the WCF-Custom binding. The custom binding configuration exposes the custom behavior config window for all WCF-Custom adapter handler properties. At this point I am not sure if it is possible to have the custom full adapter to provide a customized property page for the adapter handler properties. Interestingly, all of the BizTalk adapter pack custom adapters have the properties button grayed out in the adapter handler window.  So it is not even possible to choose the same adapter handler configuration as found on the WCF-Custom adapter handlers so if you did use a full adapter rather than WCF-Custom you would still need to register the custom WCF behaviors in the machine.config. This could possibly be an overlooked scenario in the current implementation.

So theoretically it is possible to come up with a reasonably good scenario for splitting apart the properties and implementation based on the caller type. But due to the current BizTalk admin console limitation on the adapter handlers configuration, there may unfortunately be some tradeoffs.


Sample .reg file for WCF-LOB SDK Adapter registration

On the forums today someone was asking how to register a custom adapter based on the WCF LOB SDK. The question was not how to get it to show up in the bindings list for the WCF-Custom adapter, it was how to get the custom adapter to show up as an actual adapter. With the BizTalk adapter pack, the custom adapters show up both as custom bindings under the WCF-Custom adapter and as custom adapters under Platform Settings\Adapters. The WCF LOB SDK gives good examples for how to register the custom binding and there are some free tools to help with this like this one: But there are not any .reg files in the samples folder for the SDK like there are for the samples found at c:\Program Files (x86)\Microsoft BizTalk Server 2010\SDK\Samples\Adapter Development\…

I developed one custom adapter using the older adapter framework for a major client to interface with the Endeca search index tool ( Based on my experience working with the adapter framework, I knew there was probably a GUID value I could use to find the registry settings for registering a WCF LOB SDK adapter. So I opened the WCF-SQL adapter assembly in Reflector and found the GUID value. Then I opened the registry and searched it under HKLM\Software\Microsoft to find the registry keys for the WCF-SQL adapter. Although this was not surprising to me, it was interesting to see that many of the registry values are similar to the values given for the adapter framework settings in the .reg files of the SDK samples.

Here is the WCF-SQL adapter registry content – shown below. Here is a link for just downloading the .reg file. This seemed like a missing sample file so I will be working on taking the Contoso and Echo adapters and creating registry files for them. There are a couple logical questions about what to do to your custom WCF LOB SDK code in order to make it work with the .reg file so I will be working on that next. Having the .reg file available makes it a lot easier to accomplish the adapter registration.


Windows Registry Editor Version 5.00


"AdapterMgmtTypeName"="Microsoft.Adapters.Sql.BizTalk.WcfBtsSqlManage, Microsoft.Adapters.Sql.BizTalk, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
"InboundTypeName"="Microsoft.Adapters.Sql.BizTalk.WcfBtsSqlReceiver, Microsoft.Adapters.Sql.BizTalk, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
"OutboundTypeName"="Microsoft.Adapters.Sql.BizTalk.WcfBtsSqlTransmitter, Microsoft.Adapters.Sql.BizTalk, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
"AliasesXML"="<AdapterAliasList />"
"ReceiveHandlerPropertiesXML"="<CustomProps><WcfExtensions vt=\"8\" /></CustomProps>"
"ReceiveLocationPropertiesXML"="<CustomProps><Headers vt=\"8\" /><BindingType vt=\"8\" /><BindingConfiguration vt=\"8\" /><ReferencedBindings vt=\"8\" /><ServiceBehaviorConfiguration vt=\"8\" /><EndpointBehaviorConfiguration vt=\"8\" /><InboundBodyLocation vt=\"8\" /><InboundBodyPathExpression vt=\"8\" /><InboundNodeEncoding vt=\"8\" /><OutboundBodyLocation vt=\"8\" /><OutboundXmlTemplate vt=\"8\" /><DisableLocationOnFailure vt=\"11\" /><SuspendMessageOnFailure vt=\"11\" /><IncludeExceptionDetailInFaults vt=\"11\" /><CredentialType vt=\"8\" /><UserName vt=\"8\" /><Password vt=\"8\">Encrypted</Password><AffiliateApplicationName vt=\"8\" /><OrderedProcessing vt=\"11\" /><Identity vt=\"8\" /></CustomProps>"
"SendHandlerPropertiesXML"="<CustomProps><WcfExtensions vt=\"8\" /></CustomProps>"
"SendLocationPropertiesXML"="<CustomProps><Headers vt=\"8\" /><BindingType vt=\"8\" /><BindingConfiguration vt=\"8\" /><ReferencedBindings vt=\"8\" /><EndpointBehaviorConfiguration vt=\"8\" /><StaticAction vt=\"8\" /><UseSSO vt=\"11\" /><UserName vt=\"8\" /><Password vt=\"8\">Encrypted</Password><AffiliateApplicationName vt=\"8\" /><ProxyAddress vt=\"8\" /><ProxyUserName vt=\"8\" /><ProxyPassword vt=\"8\">Encrypted</ProxyPassword><InboundBodyLocation vt=\"8\" /><InboundBodyPathExpression vt=\"8\" /><InboundNodeEncoding vt=\"8\" /><OutboundBodyLocation vt=\"8\" /><OutboundXmlTemplate vt=\"8\" /><PropagateFaultMessage vt=\"11\" /><EnableTransaction vt=\"11\" /><IsolationLevel vt=\"8\" /><Identity vt=\"8\" /></CustomProps>"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{59b35d03-6a06-4734-a249-ef561254ecf7}\Implemented Categories]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{59b35d03-6a06-4734-a249-ef561254ecf7}\Implemented Categories\{7F46FC3E-3C2C-405B-A47F-8D17942BA8F9}]

"Assembly"="Microsoft.Adapters.Sql.BizTalk, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
"DateTime"="12/28/2010 00:20:47"

Recent Licensing Changes to BizTalk-Related Technologies


I got some pretty good traffic for my recent post on the changing BizTalk landscape regarding 3rd party BizTalk adapter companies that no longer sell adapters so I thought it would be good to also try to aggregate some recent licensing changes. Due to new products being out now for both of the license changes, the old terms are no longer available and the old products can no longer be purchased (AFAIK). Both of these licensing changes seemed shocking and a little annoying to me because the previous version was a great deal, especially when paired with a BizTalk standard license.

Forms Services (InfoPath on the web)

  • In SharePoint 2007 it was possible to run Forms Server under a Standard CAL.
  • In SharePoint Server 2010, Forms Services requires Enterprise edition.

From a BizTalk perspective not being able to work with InfoPath on the web without purchasing a full, enterprise edition of SharePoint is a significant barrier to entry. InfoPath has often been used with BizTalk for providing a rich client application for error routing & resubmit scenarios. There are actually many samples of using InfoPath with BizTalk that are included with the BizTalk SDK.  BizTalk standard is a very  good deal for smaller businesses when compared to Enterprise edition. Fortunately it is still possible to use InfoPath with BizTalk 2010 as long as the InfoPath client has been installed.

A really interesting and likely cost-competitive workaround would be to use SharePoint Online which will eventually support Forms Services. I was unable to determine if this capability is already available but there are several Microsoft people mentioning this is an upcoming reality. Here is one example:

BizTalk Adapter Pack when used outside of BizTalk

  • With BizTalk 2009 it was possible to purchase a separate license for using the BizTalk adapter pack WCF custom bindings without a BizTalk license.
  • With BizTalk 2010 a BizTalk license (Standard or Enterprise) must be purchased

At the very bottom of the page at, this change to the BizTalk Adapter Pack is listed. I am not sure if this change might have been a trade-off with the developer edition now being free. It seems like a relatively good trade. In my experience I have not seen many people pay for the BizTalk Adapter Pack separately from BizTalk. I was actually surprised when anyone mentioned even knowing about this separate SKU for just the BizTalk adapter pack.

Since BizTalk is not licensed on a CAL model it seems like just a matter of time before the BizTalk Adapter Pack could be remotely hosted (perhaps even in the cloud) and could be provisioned for costs in this way. This is just a guess – I have no knowledge of this being an upcoming trend or possibility. But considering the requirement of needing to upgrade to a BizTalk server edition for anyone currently using the pack in their .NET applications, there seems to be a compelling reason to have a cost-restricted upgrade model.


So both of these licensing changes can make a big impact on your architectural estimates for projects unless you look at using a cloud or ASP based workaround.


Handling Google Web Services Throttles


On a recent project I was working on some integration with the Google Web Services static map API (documented here: as part of an overall BizTalk solution. The integration was being used to record the latitude and longitude of coordinates of stores.

The calls to the Google Web Service were going through a custom .NET method due to some extra business logic being executed before making the call to the web service. When testing the integration on one or two geographic locations, everything worked successfully. But when the integration was tested for hundreds of geographic locations that all needed to be updated in a short period of time, the web service would just return empty data after a period of time. This was a notoriously hard bug to resolve because there was not any additional contextual information about why the web service calls were just returning empty information.

It took some digging but eventually I realized that the Google web service throttles itself to limit usage and prevent a Denial-of-Service (DoS). This limitation is documented here: When the web service throttled the results came back as 0 Latitude and 0 Longitude (0,0) so this is confusing and misleading because this is actually a location on the globe, just right in the middle of the Atlantic ocean. A fault with a descriptive error message would have been better.


Due to this limitation, I had to add some customized delays and locking to the .NET method so that the calls to the web service would not overwhelm the Google web service’s throttle. This scenario was even more complicated because we did not want more than one BizTalk orchestration instance to overflow the web service throttle either. Because the .NET assembly is running in the BizTalk process custom use of threading  is suspect – you do not know if it will work properly. It was difficult to determine the right interval of polling the Google web service that gave us the maximum thoroughput without causing the service to throttle. But following code worked for us in handling this scenario:

public static object LockObject = new object();

public static string GetLatLonCoordinates(string addressLine)
string ret = "";

lock(LockObject) {

// delay for 10 seconds - to avoid the Google request rate limitation.
// For more information on the limits of the Google Static Maps API,
// see:

if (addressLine == null) { return "0,0"; }
if (addressLine.Trim().Length == 0) { return "0,0"; }


GoogleCoordinates coor = GoogleWebServiceWrapper.GetCoordinates(addressLine);
ret = coor.Latitude.ToString() + "," + coor.Longitude.ToString();

catch (Exception e)
System.Diagnostics.EventLog.WriteEntry("Application", e.Message, EventLogEntryType.Error);
return ret;

BizTalk 2010 on SQL 2011 CTP 1 (Denali)

Today I kicked off an install test of BizTalk 2010 with SQL Server 2011 CTP 1 (Denali). Here is my install order, all on a single box using local accounts:

This install order did produce one error when setting up VS 2010. The SQL 2008 R2 management objects could not be installed. I was not sure if this was important for BizTalk or not so I just ignore the error. Everything else with VS 2010 installed correctly. BizTalk installed. I am still working on getting Notification services and BAM installed so I will update this post later. The configuration wizard went through quite quickly and I did not have problems. So at this point I think BizTalk 2010 is working successfully on SQL 2011 CTP 1.


Some tips for a BizTalk catastrophic event


Today I witnessed a BizTalk catastrophic event. One of the SQL drives for a company I work for failed. In scrambling to find some solutions and fixes for the errors we were seeing I realized I could not find a great case study in a catastrophic event for BizTalk. One thing that would be nice would be to have sort of a list of errors you may see and a list of resolutions. In this post I just want to document a few errors I did not know about and mention what was helpful and what you can do to resolve the issues.

One helpful page I found on BizTalk errors is at


Today we have seen quite a few errors. A couple errors were logged indicating the catastrophic errors:

The following stored procedure call failed: ” { call [dbo].[bts_InsertPredicate_BtsWebServices]( ?, ?, ?, ?, ?, ?, ?, ?)}”. SQL Server returned error string: “Warning: Fatal error 823 occurred at <datetime>. Note the error and time, and contact your system administrator.”.

The following stored procedure call failed: ” { call [dbo].[bts_InsertProperty]( ?, ?, ?, ?, ?)}”. SQL Server returned error string: “Connection failure”.

There were lots of other similar ones. Basically if you see { call [dbo].[bts_<anything>](?*) } then it means some BizTalk stored proc is failing.

We started investigating at this point. The fatal error 823 is a disk I/O error and is documented here: A handy tip for SQL errors is to just search “MSSQLSERVER_” + error code to find the TechNet article. So for us it was searching on MSSQLSERVER_823.

Eventually it was determined that we needed to restore the BizTalk databases. The following link was really helpful as far as getting ready for the restore process: Our system did not have log shipping enabled (the article refers to it but it still provides some good details). So I stopped the remaining host instances in the BizTalk admin console. Then I had to switch to the Service Control Manager to stop other services.

But errors keep getting thrown. The BizTalk applications were still running so I stopped them. Then I checked the ports and they should be stopped by this point but a few were not. I had to manually stop the receive locations, which stopped without complaint. Then when trying to stop the send ports I get this error for every one:

Could not stop Send Port ‘<name>’. Unable to acquire the necessary database session for this operation.  (Microsoft.BizTalk.SnapIn.Framework)

Sometimes I am also getting this error:

Could not retrieve transport type data for Receive Location ‘<name>’ from config store. Both SSO Servers (Primary='<servername1>’ and Backup='<servername2>’) failed. Backup server failure: Exception from HRESULT: 0xC0002A0A (Microsoft.BizTalk.SnapIn.Framework)

The BizTalk administration console is unable to resolve this error while the database is in an inconsistent state. I tried a couple things such as restarting MSDTC or the WMI service (some common admin console workarounds) as well as restarting the admin console but it did not work. One weird thing is that the admin console is able to connect to the group database server, but it seems like something about the send port information in the database cannot be retrieved.

— Update —-

The above errors occurred because something about the BizTalk databases was having problems. For lack of a better word the databases were corrupted. After talking to Microsoft Product Support (shout out to Anzio Breeze), they helped us resolve the problem. The problem was that a BizTalk backup had been restored successfully but was not functioning properly. To diagnose the problem, dbcc checkdb was run on BizTalkMsgBoxDb and SSODB.  The resolution was to restore an older backup. The older backup restored and took longer so we are guessing that more data restored than the previous restore attempt.

If you get a SQL fatal error 824 then one possible symptom is that a database is corrupted. Try restoring from a backup.


Tips for your profile.ps1 file when using BizTalk with Powershell


I have been meaning for a while to add some PowerShell posts to my blog but had been busy lately. I have been using the BizTalk PowerShell provider ( that my friend Randal van Splunteren helped create. I now use PowerShell  all the time in my BizTalk work and find it to be very helpful for common administrative tasks like deploying pipeline components, exporting backups of binding files, and handling automated deployments. I am definitely not a PowerShell expert but more of an enthusiast at this point. I will post some of the tips and tricks I have found in using PowerShell for BizTalk development. I am not going to introduce PowerShell for beginners but approach this as giving you some interesting, useful scripts.

I have found it typically difficult to find lots of useful examples of BizTalk PowerShell. So I aim to change this by providing some of mine so that other people can take advantage of them.

Today I am going to show most of my profile.ps1 file which is called by PowerShell when starting up the shells.


Working with PowerShell and BizTalk is still a relatively involved task. This is primarily because of BizTalk’s still heavy dependence on x86 architecture. The install guide for the BizTalk PowerShell provider mentions you need to load the 32-bit version of the PowerShell shell to add the snap-in. When I first started working with this provider I kept loading the 64-bit provider and I kept getting this error:

Add-PSSnapin : The Windows PowerShell snap-in ‘BizTalkFactory.Powershell.Extensions’ is not installed on this machine.
At line:1 char:13
+ Add-PSSnapin <<<<  BizTalkFactory.Powershell.Extensions
    + CategoryInfo          : InvalidArgument: (BizTalkFactory.Powershell.Extensions:Stri
   ng) [Add-PSSnapin], PSArgumentException
    + FullyQualifiedErrorId : AddPSSnapInRead,Microsoft.PowerShell.Commands.AddPSSnapinCommand

So be sure to load the 32-bit shell. There are quite a few challenges for the BizTalk PowerShell scripter because the SQL provider is based on 64-bit architecture. In my daily work I often want to kick off a SQL agent job so this requires managing more than one PowerShell instance at a time. For this reason, there is some complexity in loading all of the useful providers. It is handy to do this provider loading in the profile.ps1 file. To simplify my work, I also set a few executable aliases that I frequently call during deployment of BizTalk artifacts. Most of my profile.ps1 file is shown below:

# This script is for a 64-bit system
if(([diagnostics.process]::GetCurrentProcess()).path -match '\\syswow64\\') {

	Write-Host "32-bit Powershell"

	Write-Host "Loading Powershell provider for BizTalk snap-in"
	Add-PSSnapin BizTalkFactory.Powershell.Extensions

	New-PSDrive -Name BTS -PSProvider BizTalk -Root BTS:\ -Instance "." -Database BizTalkMgmtDb
	Set-Location -Path BTS:
else {

	Write-Host "64-bit Powershell"

	Write-Host "Loading SQL Provider"           # from
    $ErrorActionPreference = "Stop"

    if (Get-ChildItem $sqlpsreg -ErrorAction "SilentlyContinue")  {
       throw "SQL Server Provider is not installed."
    else {
        $item = Get-ItemProperty $sqlpsreg
        $sqlpsPath = [System.IO.Path]::GetDirectoryName($item.Path)

    # Set mandatory variables for the SQL Server rovider
    Set-Variable -scope Global -name SqlServerMaximumChildItems -Value 0
    Set-Variable -scope Global -name SqlServerConnectionTimeout -Value 30
    Set-Variable -scope Global -name SqlServerIncludeSystemObjects -Value $false
    Set-Variable -scope Global -name SqlServerMaximumTabCompletion -Value 1000

    # Load the snapins, type data, format data
    cd $sqlpsPath
    Add-PSSnapin SqlServerCmdletSnapin100
    Add-PSSnapin SqlServerProviderSnapin100
    Update-TypeData -PrependPath SQLProvider.Types.ps1xml
    update-FormatData -prependpath SQLProvider.Format.ps1xml

    # More of my code
    New-PSDrive -Name localSql -PSProvider SqlServer -Root SQLSERVER:\SQL\Bencpc
    Set-Location -Path C:


# Setup some useful shortcuts for commonly used executables in BizTalk deployment
Set-Alias gac "C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\gacutil.exe"
Set-Alias msbuild "C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe"
Set-Alias btstask "C:\Program Files (x86)\Microsoft BizTalk Server 2010\btstask.exe"

The Changing BizTalk Landscape

Today has been a bit of whirlwind. In my search for a MAPI adapter I found out that Kayxo went out of business recently and their Exchange BizTalk adapter no longer exists as a buyable product. No wonder I did not get a response from them by email. This also explains their poor website. Perhaps I missed a Business Week or a USA Today article but I can honestly not find very good information on their closing. If you want a copy of the download, just let me know.

Also, I found out that iWay does not sell BizTalk adapters. If you look at their website they look like an adapter provider but I found out today they do not actually sell native adapters. For example, take this page:, it all looks like the adapters are BizTalk adapters. In the past I had definitely recommended iWay as a BizTalk adapter provider but I heard today they sell a competing integration platform and do not actually provide BizTalk adapters.

So the MAPI adapter search is definitely dead now, I will have to build one. Please let me know if you know of another MAPI adapter provider.


Blog at

Up ↑