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 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.