VMWare Server, Windows Server 2008R2 Freezes

I am using VMWare Server 2 and have created a Windows Server 2008R2 (x64) virtual machine.

Once that was set up, I tried adding some roles to the server, only for it to appear to freeze/lockup in the verifying installation part.

No need to worry, the server itself didn't really lock up, as you can remote in to the virtual machine just fine. The real culprit here are the VMWare video drivers.

The solution is to to into the control panel and uninstall the video driver and do a reboot/restart. The caveat with this, unfortunately, is that you no longer have the nice window resizing feature that you get with the VMWare video driver.

Registering multiple adapter types within the same process is not a supported configuration

I was getting an error in our BizTalk 2009 development box:


The Messaging Engine failed to register an adapter "WCF-WSHttp". Details: "Registering multiple adapter types within the same process is not a supported configuration. For e.g. HTTP and SOAP receive adapters cannot co-exist in the same process"


What seemed to be the issue was that different BizTalk Transport Types (one being WCF-WSHttp and the other being WCF-BasicHttp) were being associated to the same IIS App Pool. Creating a new App Pool for a particular Transport Type (or properly re-assigning the web-site's App Pool designation) should do the trick.

Make sure when you set up your BizTalk web apps (web sites in IIS) that you separate your App Pools based on your BizTalk Transport Types properly.

BAM WebServices authentication

I'd like to expand on Tiho's excellent post. I was having the same issues he came across.

One of the things that I did was to use the identity (credentials) from the BAM app pool configuration within Computer Management console and used that as the owner of the database.

use BAMPrimaryImport
go
sp_changedbowner 'domain\user' -- Identity from BAM app pool
go

Also, depending on how you installed BizTalk, you may get your own user account (or more exact, the individual who installed BizTalk) set as owner for all BizTalk databases, which was also the case for me. Those databases outside of BAMPrimaryImport should be set to sa.

At that point, you can use the BM.exe command line to add the proper accounts to each view, as stated on Microsoft's site. In this case, I added the BizTalk Administrator group for each view. You can expand on that on a case by case scenario.

Bruce

BizTalk 2009 and SQL Server Database Aliases

We are in the middle of installing BizTalk 2009 at my current company. Our database guru decided that all future databases would use database CNames, making the databases a little more flexible if future changes are needed. Flexibility is always a good thing.

A bit of background:

1. We have a clustered SQL Server 2008 environment (Active/Passive failover) that BizTalk is using.


2. We are installing most of the BizTalk install options.


3. We are installing UDDI 3.0 and ESB 2.0 as well (LOTS of blog material on these two to come).

Unfortunately, we ran into problems with the BizTalk Server Configuration tool, as it's not consistent with itself. The Enterprise SSO and BizTalk Rules Engine configurations accept the CName just fine. However, the Group and BAM Tools don't recognize the CName at all... Maybe there were different developers between these sections?

Our database admin came up with another idea: use an alias in the SQL Server Configuration Manager, as shown below. We acknowledge that it wasn't the best solution, but it does allow us to have a single place where we can change the database name if needed.

That worked just fine for the BizTalk Configuration itself.

However, we ran into problems with this with the UDDI and ESB installs. Neither CNames nor Aliases worked - we had to put in the actual SQL Server name!

If anything, it's VERY inconsistent at best. Hopefully Microsoft will recognize this and make changes so that all setups/installers are consistent with each other.

There's also some more entries from Andy Morrison, who is helping me with the install.

BizTalk 2009 BAM Installation Frustration - SSIS jobs installed in wrong location with named database instances

I’m currently installing BizTalk 2009 where I work. The BizTalk database is on a separate physical clustered server – and the database we are installing BizTalk on has its own instance name.

This leads to problems when installing BAM – in particular the SSIS packages.

Background: SSIS does not install on instances – meaning it is installed at the root of the SQL Server servername structure. Therefore, if you install the BizTalk databases on its own SQL instance (servername\biztalk for example), you won’t see the BAM SSIS packages.

The problem is that SSIS doesn’t recognize instances, so you get an error much like below if you try:



The BizTalk 2009 installer doesn’t give you the option to configure the locations for these, so there's no way to fix this up front.

The packages DO get installed to SQL Server, but to the folder structure of the database instance rather than the root servername. If you log onto Integration Services using your root servername, you will get in, BUT you won’t see the SSIS packages.

The solution is to manually(!) migrate the packages to the proper (folder) instance – the root servername (not the instance), as shown below:



You may need to verify/validate the connection strings of the packages – I don’t think there were any changes, but you may want to do this to be safe.