The error is a notorious creature that can sip hours of work from your daily life. It did for me, then I started collecting steps to go around this hurdle when I started my As2 journey.
To Start with, our friends in BizTalk Hot Rod have produced a good List we will add on that list for more convenience
You can verify the following in order to troubleshoot the 500 Internal Server
- Verify the physical path drive:\Program Files\Microsoft BizTalk Server 2009\HttpReceive (If its a BizTalk 2009 installation for R2 it will \Program Files\Microsoft BizTalk Server 2006\HttpReceive)
- On the Virtual Directory Access Permissions page, select Execute (such as ISAPI applications or CGI).
- Verify the account which application pool is running is part of IIS worker process group (IIS_WPG).
- Check whether at least one ReceiveLocation is listening to this HTTP URL (And only one Receive location can listen to a website)
- Make sure the identity used in the application pool for the BtsHttpReceive virtual directory has access to the BiztalkMsgBoxDb.
- Make sure that an Isolated host instance is created for HTTP Receive adapter.
- Make sure that the receive handler is running under 32 bit host instance. This is required for AS2 functionality to work.
- Make sure that IIS6 is configured to allow your BTSHTTPReceive.dll ISAPI extension to run. By default, it will block any attempt to do so until you go to the IIS manager console, into the Web Services folder and manually enable it.
But there are other culprits behind all of this which are hard to catch,
The Isolated Host and the IIS Host should run on the same account and should that has SQL access permission. In the act of solving the 500 Internal Server error the main rules should not be broken and this is one of them.
And another major pain is the worker process, w3wp process that will be running, so as mentioned above you will check the app Pool and change the account. But the worker process which has been spawn before will be running with the old account you will notice it Task manager under the user account column value of the process. So after any change that you do to the app pool kill the process and do a recycle of the app pool. After that check if the worker process is running with the account.
The most helpful tool for Debugging is the Event log. Never over look it, there will be warning as well as errors, please go through them and you will know the exact reason for the failure 9 out of 10 times. Checking the event log and following its guidance makes you a better 500 Internal Server Error debugger (or in general a better debugger).
If you have any other way to Tackle 500 Internal Server error in BizTalk when encountering As2, please comment about it :). There is always a new or a better method and it will be more helpful if its shared.