ERROR: The BAM deployment failed. DTS package BAM_DM_InterchangeStatusActivity already exists on server SQL Server Name.

Question

Hi,

 

I'm getting the following error when configuring BizTalk server:

 

[...]

ERROR: The BAM deployment failed.
DTS package BAM_DM_InterchangeStatusActivity already exists on server SQL Server Name.
(Microsoft.BizTalk.Configuration.EDIAS2.Utility)

[...]

 

Obviously I had this error before with previous BT configurations and following the steps in http://support.microsoft.com/kb/939549 I solved this issue.

 

My current configuration is the following:

 

1 SQL Server instance.

2 BizTalk Servers (one for Testing another for Production) --> Both have to use the same SQL Server instance.

 

BizTalk Server 1 --> This BT instance was already installed and configured and currently it's up and running (EDI/AS2 feature working). Default names for BT DBs (BizTalkMgmtDb, BizTalkMgmtDb, BAMArchive, etc...)

 

BizTalk Server 2 --> New BT instance for testing purposes. Using same remote DB server as BizTalk Server 1 so I changed the name of DBs in the configuration process (i.e. BizTalkMgmtDbTEST, BizTalkMgmtDbTEST, BAMArchiveTEST...and so on with the rest of DBs). All features configured but at the end of the configuration I'm getting the error mentioned above with the DTS package BAM_DM_InterchangeStatusActivity.

 

 Is this DTS package shared among all BizTalk/SQL server configurations? If I apply the steps in KB939549 to remove this package and then configure BizTalk Server 2 how this will affect to the BizTalk Server 1 that was already in place and also how this will affect to both BT instances using the same package in the future?

 

Please let me know if anyone had this problem before.

 

Many Thanks,

Jose Gonzalez

Answer 1

JoseGonzalez wrote:

Hi,   I'm getting the following error when configuring BizTalk server:   [...] ERROR: The BAM deployment failed. DTS package BAM_DM_InterchangeStatusActivity already exists on server SQL Server Name. (Microsoft.BizTalk.Configuration.EDIAS2.Utility) [...]   Obviously I had this error before with previous BT configurations and following the steps in http://support.microsoft.com/kb/939549 I solved this issue.   My current configuration is the following:   1 SQL Server instance. 2 BizTalk Servers (one for Testing another for Production) --> Both have to use the same SQL Server instance.   BizTalk Server 1 --> This BT instance was already installed and configured and currently it's up and running (EDI/AS2 feature working). Default names for BT DBs (BizTalkMgmtDb, BizTalkMgmtDb, BAMArchive, etc...)   BizTalk Server 2 --> New BT instance for testing purposes. Using same remote DB server as BizTalk Server 1 so I changed the name of DBs in the configuration process (i.e. BizTalkMgmtDbTEST, BizTalkMgmtDbTEST, BAMArchiveTEST...and so on with the rest of DBs). All features configured but at the end of the configuration I'm getting the error mentioned above with the DTS package BAM_DM_InterchangeStatusActivity.    Is this DTS package shared among all BizTalk/SQL server configurations? If I apply the steps in KB939549 to remove this package and then configure BizTalk Server 2 how this will affect to the BizTalk Server 1 that was already in place and also how this will affect to both BT instances using the same package in the future? I've done this and now both servers are configured although I don't know further implications as I haven't tested AS2 yet.   Please let me know if anyone had this problem before.   Many Thanks, Jose Gonzalez

Answer 2

Hi Jose,

 DTS package are shared if two BizTalk instances are configured on same Sql server instance. DTS packages are required only if status reporting is enabled for EDI. Try configuring EDI without status report  incase you don't need it.

 

Thanks,

Bhola

 

Answer 3

 Bhola,

I need AS2/EDI report status in my scenario so I need to have it. Usually I recommend to have always a separate SQL box for test but I customer asked me for the scenario I posted that's why I needed some more info.

Eventually I've convinced them not to use the approach above.

Thanks,
Jose