Friday, August 21, 2009

An error occurred when validating an AS2 message

In an AS2 BizTalk solution for a client, we began to see a number of errors in the event log and the behaviour was that no messages or MDNs would arrive from a particular third party:

We checked the certificate store and determined the certificate had not been revoked or expired. Searching the certificate store for the certificate to see where it was installed revealed that the certificate was no longer in the Other People store which is used by BizTalk for verifying signed messages. We found the resolution on our own, but after the fact noticed the following MSDN article which seems to be pretty thorough about resolving this issue. Note that our resolution is the last item on the "User Action" list:

http://msdn.microsoft.com/en-us/library/bb898960%28BTS.10%29.aspx

BizTalk and Dynamics AX 2009 AIF Integration

I'm taking the first steps down the road of integrating BizTalk and DAX. By many accounts, it's not the straightest road, but I'm up for the challenge :) I'll include any learnings on this as I go. In the mean time, here is where I have started on this road:

Microsoft Dynamics AX 2009 AIF BizTalk Adapter Configuration White Paper
http://www.microsoft.com/downloads/details.aspx?familyid=EDC62433-5B21-4F74-B065-B075BA6DC86D&displaylang=en

Latest BizTalk HotRod issue
http://biztalkhotrod.com/Documents/Issue7_Q3_2009.pdf

Monday, July 06, 2009

BizTalk BAM Data Archiving

Being a bit late to the finer points of managing a BAM installation, I'm just discovering some useful and important things to know about BAM, particularly managing its archive and understanding its data age policy.

http://seroter.wordpress.com/2007/06/22/biztalk-bam-data-archiving-explained/

As always, thanks Richard for making such in-depth-yet-easy-to-understand posts.  Makes my job a lot easier :)

Thursday, July 02, 2009

BAM Activity and Real-time Aggregations Windows

You can modify the duration data is kept in the BAMPrimaryImport database using the bam_Metadata_Activities table:

http://technet.microsoft.com/en-us/library/ms962341.aspx

In addition, if you are using Real-time Aggregations for BAM data, you can set the window of data kept using the bm utility and the set-rtawindow command:

http://msdn.microsoft.com/en-us/library/aa559458.aspx

Wednesday, October 01, 2008

Changing Default BAM Alerts From Email

By default, the BAM alerts installed out of the box are set up to be mailed with a from address of BAM@microsoft.com This is a security concern for clients, not to mention kind of silly.

I kept looking for a while for the steps to change this, so I'm posting this so I can remember for next time.

General info on the script used is documented in MSDN:
http://msdn.microsoft.com/en-us/library/aa560641.aspx

These steps came from a user named Kent Weare on a BizTalk R2 General forum, but I am reposting his response in case it becomes unavailable in the future. The steps look to be copy-pasted from documentation somewhere, which I have yet to find an original source for. Note: there is no step 1.


Step 2: Retrieve the current BAMAlerts Application Definition File
(ADF)

1. On the Start menu, point to All Programs, point to Microsoft SQL Server 2005, point to Notification Services, and then click Notification Services Command Prompt to open a Notification Services Command Prompt window.
2. C:\Program Files\Microsoft BizTalk Server 2006\Tracking>cscript ProcessBamNSFiles.vbs -Get config.xml adf.xml BAMPrimaryImport

Step 3: Modify Application Definition File (ADF)

1. Copy adf.xml to ClusterAdf.xml
2. Change SMTP from info: from ‘BAM@Microsoft.com’ to ‘’.
4. Save ClusterAdf.xml

Step 4: Update the current BAMAlert Application Definition File (ADF)

1. C:\Program Files\Microsoft BizTalk Server 2006\Tracking>cscript ProcessBamNSFiles.vbs -Update config.xml ClusterAdf.xml
BAMPrimaryImport

Don't worry about the "ClusterAdf.xml" naming convention. We clustered the Bam alerts service hence us calling the file that.