BizTalk - The underlying connection was closed: An unexpected error occurred on

Asked By Ronny Drechsler on 15-May-12 07:33 AM
Hi

I have an application which uses an Static Solicit-Response send port (HTTPS) to SEND an EDI message and Receive an synchronous MDN.
Messages will be sent as signed and encrypted.
But after I sent out the message I got every time the follwoing error:

"A message sent to adapter "HTTP" on send port "RSA.SRP_HTTP" with URI "https://xxx.xxx/receive" is suspended. 
Error details: The underlying connection was closed: An unexpected error occurred on a send. 
MessageId:  {0A2DE228-29DB-4691-8A95-859978A55D72}
InstanceID: {02528994-E657-4E80-8135-40CF5E40380E}"

What I have already done:

- check thumbprint on Send Port as mentioned at http://jason.agostoni.net/2010/10/07/biztalk-2009-https-connection-closed-issue/ 
- uncheck the recycling option on the AppPool in IIS as mentioned in http://rohitbiztalk.blogspot.de/ 
- change user and hostinstance for send port to check if the certificates are correct (all seems to be fine)
- check if all check boxes are unchecked in the agreement settings under section "HTTP Settings for MDNs" in the AS2 agreement

Any other ideas?

Thanks a lot!

Ronny
Ronny Drechsler replied to Jitendra Faye on 15-May-12 09:27 AM
Hi Vickey

Didn't you read my post completely?
I already did it on the 2nd step under "What I have already done:"

...
:(
[)ia6l0 iii replied to Ronny Drechsler on 15-May-12 09:52 PM
What does the inner exception have to say? Or is there one at all?

Do you own the remote system to which you are trying to send data? 

I believe it is something to do with the security protocol that these two communicate with.
Somesh Yadav replied to Ronny Drechsler on 16-May-12 01:00 AM
Open the Internet Information Services (IIS) Manager go to Application Pool  and open the properties of the required application pool. Uncheck the "Recycle worker processes (in minutes):" check box.
Somesh Yadav replied to Ronny Drechsler on 16-May-12 01:02 AM

If you are using msdeploy.exe command line, could you please post the command line you are using? The URL is still not correct for connecting to either the agent or handler service - this is usually fixed by altering the computername value. You would want something like the below, but if you post the command line I may be able to tell you how to modify it:

(for non-admin using handler service if you have configured delegation) msdeploy.exe -verb:sync -source:iisapp="MySite" -dest:iisapp="MyRemoteSite",computername="https://myServer:8172/msdeploy.axd?site=MyRemoteSite",username=MyUser,password=MyPassword,authType=basic -allowuntrusted

(for admin using agent service) msdeploy.exe -verb:sync -source:iisapp="MySite" -dest:iisapp="MyRemoteSite",computername=myServer, username=AdminUser,password=AdminPassword

If you are using Visual Studio publishing, in the Publish Web dialog where you enter Service URL be sure to use either "servername" only to use handler service or "http://servername" to use the agent.

If you are using the handler (if you want to publish as a non-admin) make sure you are able to connect first using an inetmgr remote connection.

RAJASEKHAR RAJENDRAN replied to Ronny Drechsler on 18-May-12 07:23 AM
Hi Ronny,

I hope the Issue is with your Firewall.

Disable the Firewall and try the same..

you can also try using the http port(8000) instead of https.

that is instead of URI  "https://xxx.xxx/receive" use  "http://xxx.xxx/receive" 


Thanks & Regards,
Rajasekhar.R
http://rajasekharcbe-biztalk.blogspot.in/ 

Ronny Drechsler replied to RAJASEKHAR RAJENDRAN on 18-May-12 07:27 AM
Hi Rajasekhar,

unfortunately not. As I can only use https (http over 443).
But I probably have found an issue.
I will all let you know once I can confirm that I have found it.

BR
RAJASEKHAR RAJENDRAN replied to Ronny Drechsler on 21-May-12 01:51 AM
Ronny,

Have you tried by stopping the Window-Firewall service and tried ?

Thanks & Regards,
Rajasekhar.R
Ronny Drechsler replied to RAJASEKHAR RAJENDRAN on 21-May-12 09:33 AM
Hi

We don't use a windows firewall.
After some comparisions of TCPDump files on Test and Production system we have recognize different outgoing SSL version (SSL3.0 and TLS1 (which is SSL3.1))
That might be the problem...

I will tell you in the evening...

Best regards