Ben's profileMS Innovations BlogPhotosBlogListsMore Tools Help

MS Innovations Blog

Tips, Tricks, and Workarounds for BizTalk and other Microsoft Technologies
November 09

WCF-SQL Adapter's Database Schema Gotcha

 
Introduction
 
On a recent project I was working with BizTalk 2009 and SQL 2008 and the customer was interested in moving some database objects to a new SQL database schema (for example, from dbo to MySchema). In this post, I refer to types of schemas: BizTalk schemas (XSDs) and database schemas (SQL security mechanism).
 
I had been interacting with these database objects using the WCF-SQL adapter from the BizTalk Adapter pack. Typically, BizTalk's port abstraction will take out all description of the physical connectivity details and provide you with a connection independent message type. Connectivity details are stored in the port properties and persisted as binding information. Through the use of the Adapter pack wizard, BizTalk schemas are created for interacting with various adapter data sources such as with the WCF-SQL adapter and SQL databases.
 
Initial Observations
 
So initially I expected the database schema change would not be a problem because the database object details were all specified as properties of the port. I modified the following port properties to point to the new schema, expecting this to work:
 
  • BizTalk WCF-Custom SOAP Action Headers such as TypedProcedure/dbo/MyProcCall to TypedProcedure/MySchema/MyProcCall
  • BizTalk binding properties with SQL information such as the properties notificationStatement, pollingStatement, or polledDataAvailableStatement, etc.

I restarted my BizTalk application and hosts and I started getting errors that referred to my old database schema. At this point I realized that the database schema is actually hard coded during the BizTalk schema generation process. This is a significant gotcha; that the changing of the database schema for custom objects that BizTalk uses requires a regeneration of the BizTalk schemas. The next section describes the steps I went through to correct the old database schema references after moving my database objects to the new database schema:

Resoluton

In addition to the deployment steps done above, I had to update several of my BizTalk solution artifacts. For my BizTalk solution, I was working with 5 different database objects and I did not want to delete all of my BizTalk schema files (approx. 15 different files) and go through the adapter wizard so many times. I decided to opt for a find and replace solution instead. Here are the steps I did to replace the old database schema references:

  • Open up the base and referenced BizTalk schemas using the Open With..., XML Editor. If you are interacting with rows of data then you may have separate referenced schema files that may also have the old schema in them.
  • Do find/replace and search for "/dbo" or whatever old database schema you are replacing. The "/" comes from the SOAP Action Header.
  • Save the schema changes.
  • Once you replace one database schema reference, your BizTalk schema will be in an inconsistent state until all of the database schema references have been updated. Try opening the BizTalk schema in the BizTalk schema designer and if you get a warning when opening you will know that there are still old database schema references to migrate. When all of the old database schema references are replaced you will no longer get a warning
  • Recompile
  • Then investigate the BizTalk map and orchestration files because these also contain hard coded references to the old database schema.
  • It would seem that a recompile of your BizTalk solution would regenerate the .cs files for the BizTalk maps and orchestrations, but I found this to not be the case. An approach I found that worked was to open any BizTalk maps and make an insignificant change (add a functoid and then remove it) just to change the file status to edited and then to save the map. This would refresh the generated map code.
  • Also, I opened all of my BizTalk orchestrations and double-clicked all of the Transform shapes and then checked the button "Open the map when I click the OK button" to change the file status to edited. This refreshed the generated orchestration code. Even though no actual changes were made the generated code was refreshed.
  • You could alternately remove all of the generated files such as those named like *.odx.cs or *.btm.cs
  • One disadvantage of this find & replace technique is that your old generated binding files will still refer to the old database schema so be sure to discard those.

Conclusion

This post has shown that a change to the database schema for SQL objects can have a major ripple effect on a BizTalk solution that uses the WCF-SQL adapter. I do not expect that changes to database schemas occurs very often so you may never encounter this but if you do, be prepared for a little bit of work to get the updated database schema names back into your solution. Thanks for reading!

November 05

Configuring BAM Tools on W2K8 R2

 
Introduction
 
To continue my tradition of trying BizTalk in unsupported (or not fully supported) environments, I have been working with BizTalk 2009 on Windows Server 2008 R2 on 64-bit. This OS is being used at my current client and I have been able to configure everything in BizTalk to work except for the BAM Tools / BAM Alerts functionality.
 
I had posted on setting up BAM with SQL 2008 a few months ago and once the 4 hotfixes were released, I was able to get everything working on a single machine after applying the hotfixes and reconfiguring BizTalk. The current release of the BizTalk install/setup guides only go so far as supporting W2K8 R1 but do not officially announce support for R2. This is due to the way the dates lined up around the BizTalk 2009 release, but I always wonder if there are any issues, especially breaking ones.
 
This post walks you through a hurdle I encountered configuring BAM Tools in a multi-server environment.
 
System Configuration
 

Here is the configuration I am trying now:

  • W2K8 R2
  • SQL 2008 on separate server
  • VS 2008 w/ SP1
  • 4 Hotfixes for Notification Services, etc. (64-bit version)
  • BizTalk 2009

Configuration Issues

After applying the 4 hotfixes I try to configure BAM Tools. I am getting the following error:

Microsoft SQL Server 2008 Data Transformation Services (DTS) for BAM Archiving is not installed on the local machine.  Please install Microsoft SQL Server 2008 Integration Services. (Microsoft.BizTalk.Bam.CfgExtHelper.ToolsHelper)
------------------------------
ADDITIONAL INFORMATION:
Could not load file or assembly 'Microsoft.SqlServer.ManagedDTS, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified. (Microsoft.BizTalk.Bam.CfgExtHelper)
This error looks similar to the one I had back on October 30, 2008 in this post: http://msinnovations.spaces.live.com/blog/cns!62E68922E47BC425!400.entry. With the changes to SQL 2008, the workstation tools were moved into a different package component known as the Management Tools. The similar error was resolved with SQL 2005 by installing the Workstation Tools on the BizTalk server. I was able to resolve the above error by checking the Management Tools (Basic & Complete) SQL 2008 features as shown in the screenshot:
 
 
Conclusion
 
As software products change, their names and subsystems also change. But the documentation for the products usually changes slower so there is often a small gap to watch out for. I found one when configuring BAM Tools for BizTalk 2009 with SQL 2008 on Windows Server 2008 R2. This post can also serve as some of the scant evidence that BizTalk 2009 runs successully on Windows Server 2008 R2, but the issue described above might be one of the supportability gaps.
 
Thanks,
 
 
 

 
November 04

BizTalk 2009 on Visual Studio 2010 Beta 2

 
If you saw my posts a few months ago, I was testing BizTalk 2009 compatibility with VS 2010. My earlier posts found that the BizTalk extensions would only load in VS 2008 and not in VS 2010. In this post, I do a refresh of the install experience and give some preview of the .NET 4 features showing up in BizTalk 2009. The same conclusion about compatibility is reached here: the BizTalk 2009 extensions do not work with VS 2010. There is a new workarounds for getting a VS 2008/VS 2010 environment for working with BizTalk 2009.
 
Application Install Order
 
  • Use a clean VPC image
  • Setup pre-requisites: W2K8, SQL 2008
  • Install VS 2010 Beta 2
  • Install VS 2008, and VS 2008 SP1
  • Install BizTalk 2009

BizTalk Configuration

Then when configuring BizTalk on the first step for Enterprise Single Sign-On I get an error similar to this (cannot remember exact wording sorry):
 
Cannot connect to SSODB (Win32)
0x80131700
 
I found this blog post about re-regasm-ing the SSOSQL assembly: http://blogs.msdn.com/ashishme/archive/2009/08/14/fixing-biztalk-entsso-failure-on-windows-7-vista-or-server-2008-after-vs-2010-beta-installation.aspx#comments. This helped me get around the error when configuring SSO. It is interesting that the problem occurs when VS 2010 is install prior to or after BizTalk 2009. I was then able to go through the BizTalk configuration wizard successfully. I was able to create BizTalk projects in VS 2008 fine. I did open the VS 2010 extensions manager and check for the BizTalk extensions but they are not showing up there.
 
There are quite a few valuable improvements with WCF 4 such as WS Discovery support, routing, and additional changes to Windows Workflow. All of these will have an impact on the Connected System landscape. Enjoy!
 
October 30

BizTalk 2009 Roadshow in Chicago

On December 4th I will speaking on the ESB Toolkit 2.0 under the topic "Improving Business Agility with an Enterprise Service Business" This roadshow is actually going to be happening in 20 cities across the world. The roadshow is a morning series of keynotes followed by some food.
 
 
Please join me at this free event!
 
Thanks!
October 22

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. :)
 
 
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:
 
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
Settings\benc\Desktop\machine.config".(System.Configuration.ConfigurationErrorsException) It is an
error to use a section registered as allowExeDefinition='MachineOnly' beyond machine.config.
(C:\Documents and Settings\benc\Local
Settings\Temp\Config\73d27aa8-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
 
Hopefully the documentation will improve in the final version of BizTalk 2006 R2 SP1.
 
Thanks,

VS 2010 Beta 2 Out Publicly

I have been working with VS 2010 quite a bit since the CTP about five months ago. The most recent release is Beta 2 and it was dropped onto MSDN for subscribers back on Monday. Today it rolls out for public consumption:
 
 
I am still working on getting a version of VS 2010 Beta 2 completely installed. I have had 2 failed installs at this point. Here are a few gotchas to watch out for:
 
  • Start with a fresh VPC or system - make sure no previous version of VS 2010 existed on the computer previously
  • Be sure to budget enough time for the install to run - perhaps 4-6 hours. I did a save state on my VPC in the middle and this caused the install to fail in the middle.
  • If any of the features fail, they do not show up in the Add/Remove programs checklist - you would need to start a fresh install.
  • Uninstall is not working completely so this does not provide an option to back out if you get an error or have to stop in the middle.

I have reported a couple bugs already, and if you find any, be sure to report them at:

https://connect.microsoft.com/VisualStudio/content/content.aspx?ContentID=14631

Thanks,

July 20

SharePoint 2010 Sneak Peek and Office 2010 TP

I just learned about the MOSS 2010 sneak peek site (http://sharepoint.microsoft.com/2010/Sneak_Peek/Pages/default.aspx), which shows some very cool screenshots of the upcoming version of SharePoint. There are a couple important points about this release which are exciting from a connected systems perspective.
 
The Business Data Catalog (BDC) definition designer that came with the Office Server SDK is getting a facelift and some updates. The BDC functionality is now called Business Connectivity Services (BCS). If you worked with the BDC in MOSS 2007, you probably know that you could not use WCF bindings other than basicHttp to interact with web services or other services with the BDC. I am speculating, but I would anticipate that BCS will include more WCF functionality than just the basicHttp binding. We will see in a few months.
 
I have used the Microsoft tool and the BDC Meta man tool and consider both to be helpful but fairly limited. There were various ways to encounter issues with the Microsoft tool so I am hopeful this latest release will provide some fixes and a better developer experience. The sneak peek screenshots also show using the tool from within Visual Studio rather than as a separate tool. This means that the new tool will be used with some out-of-the-box SharePoint extensions. The sneak peak also discusses a new designer experience as well. These improvements are significant and provide SharePoint lifecycle benefits for BDC projects.
 
The additional Linq to SharePoint feature extension will be a nice feature as well. The designer screenshots for the BCS tool which is described as being for BCS for entities looks very similar to the LINQ to SQL designer so I would anticipate that the future vision of BCS entities is to provide a richer experience for interacting with the BCS entities like with the ADO.NET entity framework. Previously through the BDC the way to interact with the entities was not on a code level and required web parts or list interactions post deployment. It will be exciting to see how far the LINQ to SharePoint API extends and how much of it applies to BCS entities.
 
Also, the Office 2010 technical preview has been released. I installed all of it (except Visio) on a Windows Server 2008 R1 box successfully. Unforunately, Visio encountered an error so I was not able to install it. In my experience, SharePoint designer does not work on MOSS 2007 sites, although SharePoint Workspace (new name for Groove), does work on MOSS 2007 document libraries. Overall, the graphics are a nice upgrade to Office and I am enjoying the new functionality. :)
 
I also like the new feedback components of the Office 2010 TP, and I thought it would be funny to post on these. After installing Office 2010, you get 2 new icons on the tray, a smiley and a frowny and you can click on each to report feedback experience, as apporpriate. Each one takes a screenshot so you can quickly and easily report screenshots. Here is a picture with the funny faces in the tray:
 
 
Try out the Office TP if you have time and be watching for the SharePoint 2010 release coming up soon!
 
Thanks,
 
July 01

Certifications in Reverse

Over the past week I have taken and passed two certification exams, 70-503: WCF, and 70-529: Distributed Application Development. Rather than take the exams in the .NET framework version order of 70-529 then 70-503 for .NET 2 and then 3.5, I decided to take them in reverse. Here are a couple quick observations of this unlikely certification journey. Hopefully it is humorous:
 
- After studying all of the way to implement interfaces with WCF, it was much easier to understand what was going in WSE 3.
- Sometimes when working with WSE a few years ago I would scratch my head and wonder why it had to work that way or how round-about some of the exposed APIs were and how difficult it was to get my head around the concepts.
- I am very glad that the WCF bindings and BindingElements are organized so much better than the WSE SOAP Extension Types and Policy assertion types.
- If you do this unlikely certification path, of taking tests from most recent backwards, you can use this approach as a test strategy. :)
- During the 70-529 exam, I tried to figure out how the WSE APIs must have evolved in order to be the WCF APIs, and then I could answer the questions based on much more WCF experience. It was a funny endeavor.
 
- Ben
May 14

WebSphere on Windows (WOW)

Microsoft recently conducted some interesting studies on running WebSphere on Windows. Their research is published at the website http://www.websphereloveswindows.com/, which has an intro splash that looks more like a flash-based Valentine's card than anything else. I recommend clicking the "Skip Animation" link and digging into the research information. This is a compelling study to consider running Windows for WebSphere applications rather than IBM OSes and Unix variants.
 
I look at this information as being  another step forward, similar to announcements like integrating PHP with Windows Azure data resources (see http://phpazure.codeplex.com/).
 
The Stock Trader sample download that was used in the benchmarks for the study includes some very interesting code from a WCF perspective. I recommend everyone explore this sample for more information about the study.
 
Thanks,
April 28

More BizTalk 2009 Install Guide Info Updates

I checked in the Windows Server 2008 English BizTalk 2009 pre-requisites redistributable and it DOES now include the ADOMD v10 install. Yahoo!
 
So after exploring the new information available on BizTalk 2009, I noticed that the whole SQL Server Notification Services documentation story has been updated dramatically. I had posted a few days ago about how the link from the 2009 Beta install guide for SSNS went to a version from SQL 2005 RC1 did not provide enough files and resulted in lots of errors. Now the documentation sends you to a Microsoft support site where you can download the missing SQL dependency files (SMO among them): http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=953752. This should be a huge improvement - this should enable BAM Alerts to work without needing to install a secondary SQL 2005 instance. The result of my configuration research shows there is more than one supportable configuration for using SSNS - either as a scaled down version or on a separate SQL 2005 instance.
 
For the last couple of months I have been playing with BizTalk 2006 R2 on Windows Server 2008 and SQL 2008 to get a better understanding of software compatability between these products. I had posted on the gap of information about what server roles and features would be necessary to use BizTalk in a Windows Server 2008 environment. Fortunately, the recently released BizTalk 2009 install guide for Windows Server 2008 does mention the required roles and features for Windows Server 2008 under the section describing what should be installed with IIS. The install guides have now been split up by OS, but there is unfortunately not one for installing onto Windows 7 - perhaps we will have to wait for this to be released later. :)
 
It looks like the updated documentation does not include any mention of the two separate BizTalk 2009 RFID install images - one bundled with the BizTalk server software, and one as a separate ISO. The separate ISO has a lot more samples on it so be sure to get the separate ISO too. Both are available on MSDN.
April 27

BizTalk 2009 RTW (Release to World)

I just found out that the BizTalk 2009 release has been extended to the general public: http://seroter.wordpress.com/2009/04/27/quick-thoughts-on-formal-biztalk-2009-launch-today/. I have been posting on various issues with the RTM version. It looks like the 2009 install guides can now be found at

http://go.microsoft.com/fwlink/?LinkID=128383 - the link was reset and it connects successfully. Additionally, the install guides now mention ADOMD v10 so please stop using the Beta install guide - it has now been replaced. I will be posting here soon about whether the updated prerequisites CAB includes ADOMD v10 and some other details I have been working on from the RTM version. Interestingly, the MSDN downloadable version is still from 4/6/09 (when the RTM release occurred) so it does not look like there has been an updated build; just updates of the supporting files.

If I notice anything in the install guides or the other support files, I will be sure to post about it here.

Thanks,

April 16

BizTalk 2009 RFID - new WCF Endpoint Behavior

I was looking around in BizTalk 2009 RTM trying to find new features that have been mostly undocumented and found one today! It looks like there is a new endpoint behavior that comes with the BizTalk 2009 RFID installer for use with RFID events. The WCF-Custom adapter properties does not really give you the ability to edit the endpoint's array of events so I opened up a WCF Service Application to explore it more. The following blog post gives an example of how to build a WCF service that takes advantage of this new endpoint adapter: http://blogs.msdn.com/krishg/archive/2009/04/13/epcis-support-in-biztalk-rfid-2009-part-1.aspx. Here is a screenshot of the WCF Service Configuration Tool (it is right in the middle):
 
 
I did a little reading on the blog post mentioned above to find out that this endpoint behavior basically is like an event pipeline or event bus for working with RFID in a standards-based way. Previously, you could work with BizTalk RFID using an event-sinks approach and then connect the dots and add decision logic using the Business Rules Engine. Custom events with EPCIS can be implemented and exposed on a WCF service and called on the basis of a event chain based on device events or programmatic .NET code. One of the examples in the BizTalk RFID help file shows using REST behaviors to interact with the service that exposes EPCIS events. This is really interesting because it provides a way to interact over WCF events with the BizTalk RFID infrastructure. Since .NET 3.5 WCF services can be exposed from a WF, this development makes it a very interesting development because RFID-workflows could be created. I am still learning about the BizTalk RFID capabilities, but thought this was worth blogging on.
 
There seem to be some interesting new areas to learn about with the advances in BizTalk RFID provided with the 2009 release.
 
Thanks,
April 15

Getting BAM Alerts to Work on SQL 2008

With the release of BizTalk 2009 RTM, I wanted to have a development VM to do all of the latest and greatest in BizTalk development. So I decided to build a VM with SQL 2008, BizTalk 2009, and all of the adapters I could pull together. I used the BizTalk 2009 beta install guide and installed SQL Server Notification Services (SSNS) 2005 RC1 which was the version linked to the beta install guide. When I tried to configure BAM Alerts (which depends on SSNS), I got an error, then another error and I realized there must be a gap in the 2009 beta install guide. Since a 2009 RTM install guide has not been released, I was stuck trying to figure out a way to get BAM Alerts to work. BAM Alerts configures fine on SQL 2005, but due to SQL 2008 not including SSNS, there is a cliff you can fall off trying to get BAM Alerts to work properly. This post describes the errors I received and the final workaround I came up with to get BAM Alerts to configure properly and work on a server with BizTalk 2009 and SQL 2008.
 
When I used the SSNS 2005 RC1 version, I started encountering errors that indicated there must be other dependencies that this install relied on. Here is the first error I was getting while configuring BAM:
 
 
The main error here is "Could not load file or assembly 'Microsoft.SqlServer.Smo, Version=9.0.242.0' ...". So I tried copying all of these SQL 2005 assemblies to my VM and then dropped them in the GAC. Then I tried to configure the BAM Alerts again and got this message:
 
The main error here is "This SQL version (10.0) is not supported.". So obviously at this point I was steaming mad - what is the problem here? I did some searching on the nscontrol.exe named in the error and found this http://download.microsoft.com/download/f/4/e/f4e80c76-3b69-4a42-a90b-79aeaca1177d/ReadmeSQL2005SP3NotificationServices.htm which mentions that there are 3 dependencies of SSNS and all must be loaded in order for SSNS to function properly. I tried download all three but still could not get BAM Alerts to configure properly. At this point I realized the next option to try would be to install a named SQL 2005 instance because SSNS really requires the 9.0 database version to work properly. This turned out to be what worked for me. I later found out that in order for BAM Alerts to configure properly, all of the BAM databases have to be on the same SQL instance so you need to have the SQL 2005 database services there anyway in order for BAM to all configure properly. Below I give the final install order if you want to use BAM Alerts with SQL 2008.
 
Final successful install order:
VM Base: Windows Server 2003 R2 SP2, SQL 2008, VS 2008 (minus SQL Express) installed in this order.
VM Diff:
  • Don't use the SQL 2005 SSNS RC1 linked in the 2009 beta install guide. Use a SQL 2005 full verson.
  • Install SQL 2005 as a named instance (installing after SQL 2008 was the default instance worked fine for me), install the database services, notification services, and analysis services.
  • Run SQL 2005 SP2. If you forget this step, the BAM Alerts tells you the current SQL 2005 instance is not supported.
  • Install BizTalk 2009 full
  • Configure BizTalk 2009, use the named instance of SQL 2005 for all of the BAM databases.
April 09

BizTalk 2009 RTM Install Guide Missing

For anyone that is downloading the BizTalk 2009 RTM from the MSDN downloads, you may have found that the Installation Guide.htm on the image refers to http://go.microsoft.com/fwlink/?LinkId=128383, which is the location of the BizTalk 2006 R2 guides. This link should be updated soon. As far as I know, no new installation guide has been released yet so your best guide is the 2009 Beta install guide download from https://connect.microsoft.com/site/sitehome.aspx?SiteID=218.
 
Once I hear about a new version of the install guide I will post more about this. Good luck to everyone trying out BizTalk 2009 RTM.
 
Thanks,
April 08

BizTalk 2009 RTM

Well I guess I missed the launch party - BizTalk 2009 is now available for MSDN subscribers. I reported a lot of bugs during the BizTalk 2009 Beta and TAP releases so it will be interesting to see if people encounter any of these. Thanks to my friend Thiago Almeida for pointing out the ADOMD 10 error (http://connectedthoughts.wordpress.com/2009/04/06/biztalk-2009-rtm-prerequisites/). I had seen this during the TAP version and unfortunately it looks like a final bug.
 
The following screenshot shows what you will see if you install BizTalk 2009 in an environment with SQL 2005:
 
This error is due to the installer needing the SQL 2008 version of ADOMD, v10. I have downloaded ADOMD v10 from SQL 2008 and run it on a SQL 2005 instance to get the BizTalk 2009 installer to work. Hopefully this will be resolved soon. There may be a couple of other issues out there too.
 
It is exciting to see the launch of the new product and it will be exciting to see people talking about this new version of BizTalk!
 
Thanks!
 

My Communities

I frequently answer questions on forums and report pre-release bugs. See my postings via the image links below:




Ben Cline

Occupation
Location
Interests
BizTalk Consultant @ Magenic

Certifications:
MCSD.NET, MCPD, MCTS: BizTalk,
MCDBA, MCTS: SQL 2005, Security+,
MCTS: WSS 3

Syndication