Some tips for a BizTalk catastrophic event

Introduction

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 http://www.codedigest.com/Articles/BizTalk/250_BizTalk_-_Errors_and_Warnings_Causes_and_Solutions.aspx.

Details

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: http://technet.microsoft.com/en-us/library/aa337267.aspx. 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: http://msdn.microsoft.com/en-us/library/cc296638(v=BTS.10).aspx. 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.

Thanks,

New BizTalk Service Pack Model: Cumulative Updates

Introduction

Recently I heard from Microsoft that there is now a new release model for hotfix rollups for BizTalk. The new model is similar to the service pack model (like with BizTalk 2006 R2 SP1) but is known as a Cumulative Update (CU). From what I have heard this is to provide greater frequency to the collective hotfix releases and a more predictable iteration for releases. This model is similar to what is being done with SQL Server and SharePoint Server. This new model of releases applies to all currently supported BizTalk versions including BizTalk 2006 R2 SP1, BizTalk 2009 and BizTalk 2010. Cumulative updates should be applied after running the older rollup of SP1 for BizTalk 2006 R2. It may seem like old news since BizTalk 2006 R2 SP1 is already at CU 3 but I had not heard many announcements about this or people mention CU 3 so I think most people do not know that the rollup release model was changed.

The BizTalk Developer Center Support page at http://msdn.microsoft.com/en-us/biztalk/aa937674.aspx mentions a little more about the new CU model, that the expected frequency is every 2 months, and that each subsequent CU will include all previous CU hotfixes. I was wondering what was the best way to find all of the latest CU releases and the way that worked for me was to search at support.microsoft.com for “BizTalk cumulative update”, so here is the link for this: http://support.microsoft.com/search/default.aspx?query=biztalk+cumulative+update&catalog=LCID%3D1033&mode=r. The released CU versions show up at the beginning of the search results, ordered, nice and easy.

At this time the CU releases are not being localized so if you are using a localized version of BizTalk you will need to install the English version of the CU. If you encounter any issues with the English CU release on your non English system you should report this as a bug so that a corrected localized version of the CU may be created.

Related Resources

BizTalk 2006 R2 SP1 CU 3: http://support.microsoft.com/kb/2286501/en-us 

Thanks,

BizTalk 2010 Party Migration Tool Issues & Workarounds

Introduction

Back during the BizTalk 2010 beta I was testing out the Party Migration tool. This tool enables a smoother migration path from BizTalk 2006 R2 and BizTalk 2009 to BizTalk 2010. It is very useful once you get it to run successfully. Back during the beta I experienced quite a few issues and apparently these issues remain in the final version (RTM) of the tool. This post will describe these issues and give the full steps for a workaround. I am using very similar steps I used during the beta here.

Issues

The party migration tool can be found on the install media at <install media path>\core\BT Server\PartyMigrationTool\PartyMigrationTool.exe. The help description found at http://technet.microsoft.com/en-us/library/aa578307(BTS.70).aspx mentions this should be run from a CD.  It would be nice to know this when trying to run the tool but this is not mentioned in the error messages.

Back during the beta the files were distributed just as they are now with the BizTalk 2010 Developer edition – as an extractable exe that does not come as an ISO. This is problematic because the intention for running this tool is that it will be loaded on an ISO or removable media. So you will need to either burn an ISO or use a workaround.

This tool does require you to right-click Run as Administrator or to execute it from an elevated prompt. Otherwise you will get odd CAS errors:

Request for the permission of type ‘System.Security.Permissions.UIPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089′ failed.. For more details please see the event log.

Initially, if you are using the BizTalk 2010 Developer edition or have not burned an ISO, and try to open the PartyMigrationTool.exe you will receive assembly not found errors like this:

System.IO.FileNotFoundException was unhandled
Message: Could not load file or assembly ‘Microsoft.BizTalk.Migration.PartnerManagement, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35′ or one of its dependencies. The system cannot find the file specified.

If you run off the ISO or removable media everything works but there is another way for this to work.

Workaround

1. If you are using BizTalk Developer edition or did not make an ISO, go to the PartyMigrationTool folder. Keep this open.
2. You will need to add 3 assemblies to the GAC next. I found it easiest to copy these three assemblies to the PartyMigrationTool folder to keep everything together. All of these assemblies are found on the BizTalk 2010 install media. The assemblies you will need are:
   a. Microsoft.BizTalk.B2B.PartnerManagement.dll in \core\BT Server\MSI\Program Files\Developer Tools
   b. Microsoft.BizTalk.Migration.PartnerManagement.dll in \core\BT Server\MSI\Program Files
   c. Microosft.BizTalk.Migration.PartnerManagement.XmlSerializers.dll in \core\BT Server\MSI\Program Files
3. [Note]: I had previously recommended modifying the PartyMigrationTool.exe.config to redirect the assemblies but upon retrying with the RTM bits I thought it was just easier to GAC everything necessary. 2.a. fails anyway because there is not an entry for it in the config.

I did want to mention one other note. When you finally get the tool running, you will need to connect to SQL Server using Windows authentication, SQL authentication is not supported.

Thanks,

Top 10 BizTalk Hotfixes

I was at the MVP Summit just a few weeks ago and wanted to help publicize a few important fixes coming out of Redmond that can help your BizTalk development. Some hotfixes get combined into a rollup and others do not. Also, for some reason not all of the fixes make it into the KBAlertz that I subscribe to so you should periodically check around like at the BizTalk Customer Response Team blog (http://blogs.msdn.com/biztalkcrt/default.aspx).

 

I was thinking through all of the recent ones I had downloaded and realized these would make a good top ten list. I will make some comments along the way. Be sure to watch which version I reference because not all fixes apply to both 2006 R2 and 2009. Another good tip is to save the email for your hotfix password with your hotfix so you have the password for later. Passwords on hotfixes expire, saved emails do not. Just make sure to encrypt that hotfix password file…

 

Here is the list (in reverse for fun):

 

10. To start off with, I strongly recommend you download BizTalk 2006 R2 SP1 because it includes so many hotfixes all rolled up: http://support.microsoft.com/default.aspx/kb/974563.

 

9. On the forums I recently helped handle a situation for someone where the MQSC adapter was not working for 64-bit on BizTalk 2009. A hotfix had been released which overcame this problem on BizTalk 2006 R2 SP1: http://support.microsoft.com/default.aspx/kb/939202 The forum poster went ahead and installed the hotfix on their BizTalk 2009 server and it overcame the issue anyway, even though the hotfix was only targeted for BizTalk 2006 R2 SP1. Sometimes you can check the released version information on the hotfix to see if it matches with your server, but other times you just do not know the result of installing an older hotfix on a newer system.

 

8. The next one provides the software for installing SQL Notification Services with BizTalk 2009: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=953752.

 

7. The BizTalk team released the HIPAA 5010 extension pack earlier this year as part of a hotfix: http://support.microsoft.com/kb/973415

 

6. When I worked on an EDI project there was an annoying problem where the GS02 and GS03 identifiers would get mixed up during the BizTalk EDI processing. This was resolved here: http://support.microsoft.com/kb/954557

 

5. This one is only really useful if you are working with VS 2010 RC and BizTalk vNext – Get intellisense back – http://support.microsoft.com/kb/980610. Hopefully it gets applied in VS 2010 RTM and does not need to come to the world as a Windows Update.

 

4. On BizTalk 2009, UDDI support only works on the default instance of SQL Server. Silly! There is a fix at this point for 32-bit but not 64-bit: http://support.microsoft.com/kb/975684.

 

3. If you have been using BizTalk 2009, you may have noticed some issues in VS when compiling and developing. I think these issues were introduced when the VS BizTalk extensions were updated to work with BizTalk 2009. Some people in the MVP community helped Microsoft identify and test out these issues. There are two fixes that are relevant to mention: http://support.microsoft.com/kb/977428. I did not personally have this problem, but many expressed this was a problem for them.

 

2. The other VS issue for BizTalk 2009 hotfix was resolved with http://support.microsoft.com/kb/979153. I encountered this one many times on larger projects, especially when using expression shapes in orchestrations.

 

1. Now for a really good one that everyone should install. I frequently encounter red herrings in doing diagnostic work and I am excited when hotfixes come out that actually solve the root problem. Here is one that clears up some compilation issues that surface as out of memory exceptions: http://support.microsoft.com/default.aspx/kb/975118. This is a good one to install on both developer and server boxes.

 

Happy hotfixing!

 

BizTalk 2006 R2 SP1 WCF Extensions

A few days ago a service pack for BizTalk 2006 R2 (known as BizTalk 2006 R2 SP1) was released and it includes a large number of rollup fixes accumulated from quite a few hotfixes. I ran it on my local development box and it installed fine for the most part. It did do have a hickup on HL7 though. It also includes some new product features which is a little unusual for a service pack release. Perhaps it should be called BizTalk 2006 R2.5.

 

Here is the link on the release announcement: http://blogs.msdn.com/biztalkcrt/archive/2009/10/09/announcing-biztalk-2006-r2-sp1.aspx

 

One of the major new product features in the service pack is better tooling around WCF extensions. This post is going to give an introduction on how this worked prior to the service pack, then go through a brief tutorial of how I tested the new functionality. This post is based on SP1 beta so it is subject to change.

 

Prior to SP1:

 

If you implemented a WCF extension prior to SP1 then you had to go through a considerable amount of complexity to get the extension to show up in the BizTalk WCF port configuration pages. I retraced Richard Hallgren’s steps in his post http://www.richardhallgren.com/category/wcf/ as a good example of getting an WCF extension in the form of an EndpointBehavior. The relevant steps I want to focus on are:

 

• Develop the extension behavior
• Add a line similar to machine.config:
  <add name="addCustomWCFProperties" type="CustomWCFProperties.Behavior.PromoteUserNameBehaviorElement, AddCustomWCFPropertiesBehavior, Version=1.0.0.0, Culture=neutral, PublicKeyToken=705e34637fdffc54" />
• Configure the WCF port and choose the behavior.

The difficulty with this approach is that for every custom behavior (which might be used on a per port basis), you have to put stuff in machine.config. In most server environments this can require moving mountains to edit machine.config. Also, if you use behaviors on many ports it can quickly become difficult to manage. SP1 limits the scope of the config item to the executing host but it also introduces a couple challenges of its own. 

 

With SP1:

 

The current SP1 approach is to configure config options using a tab on the adapter handler properties. The directions are given for the custom send handler here:

http://msdn.microsoft.com/en-us/library/ee519505(BTS.20).aspx. This comes from the overall documentation for the release: http://msdn.microsoft.com/en-us/library/ee532481(BTS.20).aspx

 

Basically what is involved is importing a config file that has the custom behavior defined. The SP1 beta documentation mentions this as a custom binding but it means the custom behavior. Here is a screenshot of what the page will look like after SP1 is installed:

 

 

Then here is what the page looks like after you have imported a custom extension:

 

This current documentation does not provide a template or starting point for what the imported config file should be so there is essentially a gap. What I did was try to use the machine.config from the Pre SP1 directions because I thought this is the most direct route that people are likely to do after they run SP1. A better approach would be to use the template I have at the bottom of this post as a starting point for the config file you import.

 

Unfortunately the process is more complicated using machine.config because there are extra nodes in the machine.config that the import config button does not like.

You will get errors like:

 

—————————
Import WCF configuration
—————————
Unable to import configuration from file "C:Documents and

SettingsbencDesktopmachine.config".(System.Configuration.ConfigurationErrorsException) It is an

error to use a section registered as allowExeDefinition=’MachineOnly’ beyond machine.config.

(C:Documents and SettingsbencLocal

SettingsTempConfig73d27aa8-b21b-4d47-abeb-c81ec7a756fc.config line 202)

So if you want to go this route, follow these steps to clean the machine.config to the point that the page imports the config file properly. These steps are subject to what is in your machine.config. Also, I am not sure if any of these steps will have any undesired consequences and you should use these steps at your own risk. But these worked for me:

 

• Copy your machine.config and work on the copy
• Find all attribute occurences of allowExeDefinition="MachineOnly" and remove this attribute
• Remove the commonBehaviors ConfigSection and Config elements and children
• Remove the machineSettings ConfigSection and Config elements and children
• Find behaviorExtensions element below <system.servicemodel><extensions> and remove all of the existing ones except for your custom ones.

Then try to import again and it should work. The screen will look exactly alike to the picture Richard Hallgren had for choosing the custom behavior, you just took a different path. The custom WCF extension behavior is the first in the list shown below:

 

 

I am guessing that the import config button is trying to merge part of the imported configuration into some master configuration and this is why it is failing. If you try to import a config file that does not cause errors and does not have any extensions, you will not get a message back that nothing was imported, the text box just stays blank.

 

You will then be able to select the custom behavior for a port running under the handler where you imported the config file.

 

I have found that it is actually possible to import the same config file multiple times across multiple handlers so this means it is possible to have one WCF extension configured for multiple BizTalk hosts.

 

Once you get through the wizard you can then export the WCFExtensions config file which gives you a template for the future that I have included here (not sure why the ESB line exported here):

 

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <enterpriseLibrary.ConfigurationSource selectedSource="ESB File Configuration Source" />
  <system.serviceModel>
    <behaviors>
    </behaviors>
    <extensions>
      <behaviorExtensions>
        <add name="addCustomWCFProperties"

type="CustomWCFProperties.Behavior.PromoteUserNameBehaviorElement, AddCustomWCFPropertiesBehavior,

Version=1.0.0.0, Culture=neutral, PublicKeyToken=705e34637fdffc54" />
      </behaviorExtensions>
    </extensions>
  </system.serviceModel>
</configuration>

 

Here is a link to my exported .config file (shown above) that I used to successfully import Richard Hallgren’s

custom endpoint behavior: http://cid-62e68922e47bc425.skydrive.live.com/self.aspx/Public/WcfExtensions.config

 

Hopefully the documentation will improve in the final version of BizTalk 2006 R2 SP1.

 

Thanks,

BizTalk Performance Guides vNext

One of the themes I have been blogging on for a while is the relationship of BizTalk Server 2006 R2 and Microsoft’s 2008 product stack including Windows Server 2008, SQL 2008, and Visual Studio 2008. As everyone should know, the 2008 product stack is not supported with BizTalk Server 2006 R2. Over the past couple of weeks I have learned that some of the BizTalk Server Performance Optimization Guide articles (starting at http://msdn.microsoft.com/en-us/library/cc558617.aspx) should not be applied to Windows Server 2008 BizTalk implementations due to some performance differences between Windows Server 2003 R2 and Windows Server 2008. Even though it is a best practice to avoid unsupported environment configurations, I know for a fact there are quite a few organizations that have BizTalk 2006 R2 running with Windows Server 2008. I recommend against this configuration on production boxes due to the supportability issues, but it is very valuable from a BizTalk vNext perspective especially if you are working on a BizTalk 2009 migration plan.

 

So what is the result of following the performance guide in an unsupported configuration of BizTalk 2006 R2 and Windows Server 2008? Well, the guide was made with the assumption that Windows Server 2003 was being used, so the optimizations made specifically for that OS will not be the best ones for 2008. So watch out for OS tuning parameters or options in the guide because these will not always be the best ones for Windows Server 2008. Microsoft will be releasing an updated performance optimization guide a couple weeks after BizTalk 2009 is released under RTM. So if you are working in a high performance BizTalk environment and want to migrate to Windows Server 2008 then I would wait to deploy your applications until after the new optimization guide is released because the newer guide will include optimizations for Windows Server 2008.

 

But wait, what if you want to use BizTalk 2006 R2 in the unsupported configuration in production? Unfortunately, I have not heard the configuration will ever be supported, but I would still wait for the updated optimization guide so you can at least optimize the OS settings. If I uncover any other snafus or gotchas of using the updated performance guide in the unsupported configuration, I will be sure to let you know about them.

 

Thanks,

 

 

Simplify the Install Experience of the BizTalk SAP Adapter

During a recent project I was using the BizTalk SAP Adapter to interact with a custom BAPI that was exposed as an RFC. In order to get the Add Adapter Service Wizard in BizTalk to work properly, I had to install all of the SAP dependency libraries on the BizTalk server. I was amazed at how complicated this whole process was. There are a couple things I would like to do in this blog post:

• Give the names of all of the files that must be used for 32-bit and 64-bit installs of the SAP dependencies for the 6.4 version of the SAP RFC SDK.
• Provide a shell script for copying all of the SAP dependencies for 32-bit and 64-bit installs of the SAP dependencies
• Provide some additional details on the SAP Adapter installation.

The reasons I am posting on this is because I think the InstallGuide.htm which is included with the BizTalk Adapter Pack is a little vague. The file is already very long and inclusive but some important details like the names of many of the SAP client files is not included. Below is an expanded list of directions for the 6.4 version of the SAP client dependency installation:

SAP client version	Required drivers
6.4 32-bit	librfc32u.dll (SAP RFC SDK 6.40 UNICODE). This is available as part of SNOTE* 413708. The instructions to download this are available at http://go.microsoft.com/fwlink/?LinkID=94691. [BC Comment] Copy to C:WindowsSystem32 DLLs available from SAP as part of the package, UCLIB.SAR. See SNOTE* 785368 (http://go.microsoft.com/fwlink/?LinkID=94692) for more information. This package is available as part of SAP KERNEL 6.40, which is available from the SAP Service Marketplace. While downloading the SAP Kernel, make sure you download the “database independent” version. [BC comment] So the following DLLs will need to be copied to c:WindowsSystem32: icudt26l.dll icudt30l.dll icuin26.dll icuin30.dll icuuc26.dll icuuc30.dll DLLs available from SAP as part of R3DLLINST.zip. This contains Microsoft run-time DLLs and can be downloaded from the SAP site. See SNOTE* 684106 for more information. You can download the .zip file from http://go.microsoft.com/fwlink/?LinkID=94693. This link has an “Attachments” option from where you can download the package. [BC comment] So the following DLLs will need to be copied to c:WindowsSystem32: mfc71.dll mfc71u.dll msvcp71.dll msvcr71.dll If you will be using SAP Secure Network Communications (SNC) to connect to an SAP system, you must also have the relevant DLLs from SAP. These DLLs are different for 32-bit and 64-bit platforms and are available with SNOTE* 352295. You can download the DLLs from http://go.microsoft.com/fwlink/?LinkID=104032. This link has an “Attachments” option from where you can download the package. The names of the DLLs are: Copy to C:WindowsSystem32: gsskrb5.dll, gssntlm.dll [BC Comment] To create a simple deployment package for all of the DLLs, copy all of the DLLs from the above steps to a separate folder. Then use the following script to install all of these into the correct place. I found using a script was a lot easier for administrators and vastly simplified the overall process. Here is the script (rename to .bat after downloading): InstallSAPDLLs32-bit.txt
———-	————————————————————————————-
6.4 64-bit	librfc32u.dll 64-bit (SAP RFC SDK 6.40 UNICODE). This is available as part of SNOTE* 413708. The instructions to download this are available at http://go.microsoft.com/fwlink/?LinkID=94691. [BC Comment] Copy to C:WindowsSystem32 librfc32u.dll 32-bit (SAP RFC SDK 6.40 UNICODE). This is available as part of SNOTE* 413708. The instructions to download this are available at http://go.microsoft.com/fwlink/?LinkID=94691. [BC Comment] Copy to C:WindowsSysWow64 DLLs available from SAP as part of the package, UCLIB.SAR. See SNOTE* 785368 (http://go.microsoft.com/fwlink/?LinkID=94692) for more information. This package is available as part of SAP KERNEL 6.40, which is available from the SAP Service Marketplace. While downloading the SAP Kernel, make sure you download the “database independent” version. [BC comment] So the following 32-bit DLLs will need to be copied to c:WindowsSysWow64: icudt26l.dll icudt30l.dll icuin26.dll icuin30.dll icuuc26.dll icuuc30.dll Very similar 64-bit DLLs will need to be copied to C:WindowsSystem32: icudt26l.dll icudt30l.dll icuin26.dll icuin30.dll icuuc26.dll icuuc30.dll DLLs available from SAP as part of R3DLLINST.zip. This contains Microsoft run-time DLLs and can be downloaded from the SAP site. See SNOTE* 684106 for more information. You can download the .zip file from http://go.microsoft.com/fwlink/?LinkID=94693. This link has an “Attachments” option from where you can download the package. [BC comment] So the following DLLs will need to be copied to c:WindowsSystem32: mfc71.dll mfc71u.dll msvcp71.dll msvcr71.dll If you will be using SAP Secure Network Communications (SNC) to connect to an SAP system, you must also have the relevant DLLs from SAP. These DLLs are different for 32-bit and 64-bit platforms and are available with SNOTE* 352295. You can download the DLLs from http://go.microsoft.com/fwlink/?LinkID=104032. This link has an “Attachments” option from where you can download the package. The names of the DLLs are: For 32-bit copy to C:WindowsSysWow64: gsskrb5.dll, gssntlm.dll For 64-bit copy to c:WindowsSystem32: gx64krb5.dll, gx64ntlm.dll [BC Comment] To create a simple to use install script for 64-bit it is a little more complicated because the names are the same for many of the DLLs for 32-bit and 64-bit versions. Make a folder to hold the files and then make sub folders for UCLIB-32, UCLIB-64, RFC-32, and RFC-64. Copy all of the 32-bit UCLib files to UCLib-32 and similarly for UCLIB-64, RFC-32, and RFC-64. Then use the following script in the root folder of the install files to install all of these into the correct place. I found using a script was a lot easier for administrators and vastly simplified the overall process. Here is the script (rename to .bat after downloading): InstallSAPDLLs64-bit.txt

 I wonder if the reason Microsoft is not able to provide a redistributable of these SAP components is due to SAP licensing restrictions. In any case, these directions will help you simplify the complexity of the SAP adapter dependencies’ install and dramatically improve the install experience after you get all of the files downloaded.

 

Thanks,

 

Operations Management for BizTalk published in BizTalk Hotrod

I just found out the latest BizTalk HotRod to hit the web (February 2009) does include an article I did on Systems Center Operations Manager (SCOM) and BizTalk. Go here to get a copy of the article: http://biztalkhotrod.com/Documents/BizTalk%20HotRod%20Magazine%20Q1%202009.pdf. This is my first published article so it is exciting for me. This is partially based on my Operations Management for BizTalk presentation from about a year ago.

 

Thanks,

Major BizTalk Incompatibility – IIS 7 and WCF Publishing Wizard

On my current project the client has been dabbling with BizTalk 2006 R2 in a very unsupported configuration with Windows Server 2008, and SQL 2008. In previous posts I talked about Windows Server 2008 and some challenges installing BizTalk on this OS. Generally, Windows Server 2008 behaves well for BizTalk. SQL 2008 has behaved well and has not presented any problems for BizTalk other than the fact that it does not include Notification Services so you must install this optional component from the installer included with SQL 2005. This post describes some new difficulties I have identified when using BizTalk Server 2006 R2 with IIS 7.

 

Working in the unsupported environment has been very interesting because it has identified that there are issues with BizTalk’s WCF integration on Windows Server 2008. Windows Server 2008 includes IIS 7 which has been overhauled extensively. Several issues have been identified with IIS 7 and BizTalk Server 2006 R2:

 

- It is possible to run the BizTalk WCF Publishing Wizard through completely to create a .svc WCF endpoint and a virtual directory to host the WCF service but by default IIS 7 is not configured to support the .svc extension. In order to setup the .svc extension, use the IIS 7 directions at http://msdn.microsoft.com/en-us/library/ms752252.aspx.

 

- When running the BizTalk WCF Publishing Wizard sometimes IIS 7 will get dumped out completely. From time to time running the wizard the web.config at c:\Inetpub\wwwroot and all of the virtual directories in this folder get removed during the time that the WCF Publishing wizard is running. For this reason, I strongly recommend you backup the web.config in the web root and all virtual directories stored under the web root before running the WCF Publishing wizard on a box that includes IIS 7. If you just registered the .svc handler and IIS 7 gets dumped out you will need to create it again. Due to this issue, I also strongly recommend that if you need to work with HTTP or IIS related adapters, use Windows Server 2003 R2 with IIS 6 rather than Windows Server 2008 with IIS 7.

 

- The BizTalk WCF Publishing Wizard may require additional permissions when run on Windows Server 2008 than on Windows Server 2003 due to the secure by default nature of IIS 7. I identified issues with the NetMSMQ binding and MEX-only endpoints created with the BizTalk WCF Publishing Wizard in which permissions must be loosened while the wizard is running although they may be tightened afterwards.

 

Thanks,

 

 

Variation on WSS Adapter Error & Workaround

On my current project I was working to configure the WSS adapter for BizTalk on a separate server than BizTalk. This requires running the BizTalk installer on the SharePoint box and then running the BizTalk Configuration Wizard to setup the WSS adapter web service. I was running the configuration wizard and was just using the defaults and received the following error:

 

d:depot2300mercuryprivatekwsourcebizofficecodebizofficeconfigurationwssadacfgwssadacfg.cpp(467): FAILED hr = 80070002

This is a similar error to the one reported at https://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=3350889&SiteID=17 but I identified a different workaround that did not require an updated DLL from Microsoft. Rather than use "Default Web Site" as the application where the WSS adapter web service should be installed, I used an already existing web site such as "SharePoint – 80". This enabled me to install the WSS adapter successfully.

 

While discussing this issue I wanted to mention that the WSS adapter configuration instructions at http://msdn.microsoft.com/en-us/library/aa547280.aspx mentioned that you needed to install "Windows SharePoint Services SP2" but this refers to WSS 2 SP2 and is not required if you currently have WSS 3.

 

Thanks,