I found an interesting error, always on call 256 in an process (there can be several running at the same time, but always the 256 call from each process will fail)
We are getting Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
An error occurred while receiving the HTTP response to [uri]. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.
What is can be wrong, it seems to be the client, but it is?
Could it be because any limitation in Windows 7 and Windows Server Web Edition?
I expect the wcf and/or TCP stack to run out of connections.
have a look here:
http://msdn.microsoft.com/en-us/library/ms731078.aspx
and see if fiddling with the idleTimeout or MaxConnections help.
Try adding a custombinding to your config.
<customBinding>
<binding name="mynettcp">
<binaryMessageEncoding />
<tcpTransport
maxPendingConnections="100"
maxPendingAccepts="10"
listenBacklog="100">
<connectionPoolSettings
idleTimeout="00:00:00"
maxOutboundConnectionsPerEndpoint="0" />
</tcpTransport>
</binding>
</customBinding>
Then in the binding attribute of your service change the value to mynettcp
I it is in my company's firewall.
Thanks for your help rene
Related
I have a orchestration in BizTalk which is collect to data via web services from SAP.
My process is as below.
We have a SOAP service on receive port and when we get an request from SOAP we transform it to SAP RFC File format and send it to SAP. When we try to get a response from SAP we get an error when response data is big. If response message size is so big our service get a timeout error. Otherwise there is a no problem if the message size is not big.
I tried to increase timeout duration on BizTalk management console but still fails. Whatever I did, the timeout duration is always in 1 minutes.
After Adding below XML config tags to machine.config file I get an error as below figure.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config
<configuration>
<system.transactions>
<machineSettings maxTimeout="00:20:00" />
</system.transactions>
</configuration>
Below image is SAP Send Port
SAP Send Port Details
In the detail as you can see my time out duration about 10 hour but in SOAP UI I get an timeout error after 1 minute.
Below image is Receive Port
Also you can find biztalk event viewer error as below.
A response message sent to adapter "SOAP" on receive port "WebPort_SAP/MusteriFaturaT/ABC_SAP_Fatura_T_FaturaOrch_InvoiceReceivePort" with URI "/SAP/MusteriFaturaT/ABC_SAP_Fatura_T_FaturaOrch_InvoiceReceivePort.asmx" is suspended.
Error details: The original request has timed out. The response arrived after the timeout interval and it cannot be delivered to the client.
And SOAPUI response screen is blank as below
On WCF Custom send port, change the value of time out (close, open, send, receive) to increase timeout. See the link for more details
You can also use SOAPUI tool to test your web service outside BizTalk to see the response time and response size.
Problem is about SOAP UI timeout issue. When i change the timeout property of SOAP our timeout duration was increase to 110 second. 110 second is default soap timeout duration. For fix this issue you have to add below config options to web.config file.
<system.web>
<httpRuntime executionTimeout="43200" />
</system.web>
Also you have to add below configs to client app.config file.
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="IBRAHIM_SAP_Fatura_T_FaturaOrch_InvoiceReceivePortSoap" maxReceivedMessageSize="2147483647" receiveTimeout="03:00:00"
sendTimeout="02:00:00" transferMode="Streamed"/>
</basicHttpBinding>
</bindings>
</system.serviceModel>
UPDATE:
Now we have the error it is indicating that it is the client that timed out rather than BizTalk, in this case SoapUI. As per the answer from this question SoapUI: ConnectException: Connection timed out:
Default socket timeout is set to 60000 milliseconds. You can change it:
File -> Preferences -> HTTP Settings -> Socket Timeout
When you are connecting with another client, you will also have to check/set the timeouts in that.
ORIGINAL POST:
If you are using BizTalk 10 or above check the response timeout on the host is set to a value greater than a minute.
I had an issue with Timeouts as well an this was one setting I changed (in this case to the maximum).
You can set up a specific Host for large transactions where the Response timeout in minutes is changed and only those ports that need it use it.
However even after I changed that to the maximum value I encountered a timeout after 15 minutes.
For that I had to disable Use Transaction, only do this if you still encounter issues and you are retrieving data and not inserting/changing data.
The above images are from my blog post about the issue BizTalk Server Negative Acknowledgement issues in SAP and WCF.
As to setting the system.transaction setting in the config, that is rather dangerous to do as it will affect everything, not just that port.
You have to increase your timeout in the machine.config file
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config
<configuration>
<system.transactions>
<machineSettings maxTimeout="00:20:00" />
</system.transactions>
</configuration>
You must also set the property allowExeDefinition to "MachineToApplication" from "MachineOnly"
I built a WCF Service in one of my machines of my local network, it has both http and net.tcp (htpp,net.tcp) as enabled protocols in IIS manager.
From another machine a build a client app, and define the endpoints automatically using the Add Service Reference... dialog, I type the service address and when it appears I set the name and click OK. The App.config is updated with two endpoints, one for http (BasicHttpBinding) and the other for net.tcp (NetTcpBinding) as expected.
When running the client app, if I use the BasicHttpBinding:
"using (var proxy = new ProductsServiceClient("BasicHttpBinding_IProductsService"))"
it runs OK, and shows the expected data.
But when I use the NetTcpBinding:
"using (var proxy = new ProductsServiceClient("NetTcpBinding_IProductsService"))"
It throws a SecurityNegotiationException saying that:
"A remote side security requirement was not fulfilled during authentication. Try increasing the ProtectionLevel and/or ImpersonationLevel."
If I do it all in the same machine, I don´t get any exception.
What should I do?
Rafael
By default, the BasicHttpBinding supports no security. So when calling the service from another computer, it will work also.
But by default, NetTcpBinding requires a secure channel. And the default security mode is Transport, so when calling the service from another computer, it will throw a security exception.
The most easy way to solve it is to set the security mode to None as following:
<bindings>
<netTcpBinding>
<binding name="netTcpBindingConfiguration" >
<security mode="None" />
</binding>
</netTcpBinding>
Then we use it in the endpoint
<endpoint address="net.tcp://nelson-laptop:8080/Whatever"
binding="netTcpBinding"
bindingConfiguration="netTcpBindingConfiguration"
contract="ProductsService.IProductsService"
name="NetTcpBinding_IProductsService" />
In Your question you are using the default net.tcp port 808 but have opened port 80 in the firewall. If it is not a typo in the question it could be why it fails.
I've got a WCF service that's running on IIS 6, with integrated authentication and impersonation using NTLM.
Relevant portions of Web.Config
<system.web>
<identity impersonate="true"/>
<customErrors mode="Off"></customErrors>
</system.web>
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
...
</system.web>
...
<wsHttpBinding>
<binding name="wsHttpEndpointBinding">
<security mode="Transport">
<transport clientCredentialType="Ntlm" />
</security>
</binding>
</wsHttpBinding>
I just added the aspNetCompatibility because I want to know who the user is that's logged in (at least as far as IIS is concerned). From the few searches I've done that's how you get the user.
Well, after adding that line and publishing my server I get what's possibly the stupidest error I've seen:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'.
I thought, "Well obviously they're doing a very case-sensitive comparison." So I searched my entire client solution for Ntlm and replaced all non-variable occurrences with NTLM. No luck.
My primary goal, of course is to get whatever user was authenticated through IIS+NTLM. If I'm going about it the wrong way, I'd be happy to know of an easier/better way. Otherwise, how do I tell my client (or my server) that it's OK to go ahead and authenticate?
One other possibility if you are running across this error is that you are experiencing an issue with the loopback check with NTLM. I have a service which runs self-contained on a non-domain (workgroup) server. WCF is configured using BasicHttpBinding with Transport security mode and Ntlm client credentials. When trying to access the service using https://servername it works great. If I try to access it using the FQDN (https://servername.domain.com) it fails with the same error:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'.
If you look inside the Windows security log you will see an Audit Failure with event ID 4625. In this you will see the following failure information:
Failure Information:
Failure Reason: An Error occured during Logon.
Status: 0xc000006d
Sub Status: 0x0
To resolve this you need to either add the back connect host names (preferred) or disable the loopback check. This was a security enhancement added for NTLM in Windows Server 2003 SP1 and later to close out an attack vector against the protocol. The fix, however, causes a lot of unclear error messages like this one from WCF and continues to haunt me in many obscure ways to this day.
Start Here . This should resolve your issue
TL;DR version is at the bottom.
I have constructed three WCF web services -- one that's using .NET 4 and two that's using .NET 3.5 -- that is consumed by an Android client. The Android client performs the calls using ksoap2-android. When the services were complete and the client could make all the calls and get all the data from the services, we decided to activate HTTPS communication for the web services. They are hosted on a server running IIS.
I'm not alone on this task. I work full-time with it, mainly the Android client. I have two coworkers, both of which have a lot of other responsibilities. The first is mostly involved in the services and the second is mostly involved in the server.
I've read a lot of guides, blogs and articles on the Internet on how to enable HTTPS for a WCF web service, but still I haven't been able to completely resolve this. For the Android client to be able to consume the client, we are limited to using the basicHttpBinding, since the wsHttpBinding contains some security details that are not supported by Android, or something. I'm not sure, but I read it some forum somewhere. If I'm wrong, I'd happily be corrected!
Okay, so I'll give a short account of what I've done so far:
I've enabled transport security, this is how the binding(s) looks:
<bindings>
<basicHttpBinding>
<binding name="basicHttp" closeTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00">
<security mode="Transport">
<transport clientCredentialType="None" />
</security>
</binding>
</basicHttpBinding>
</bindings>
I've enabled meta data publishing over HTTPS using this line of code:
<serviceMetadata httpsGetEnabled="true" />
and this:
<endpoint address="" binding="mexHttpsBinding" contract="IMetadataExchange" />
Also, my second coworker has installed a trusted certificate (a real certificate from a CA) on the IIS server and added a https binding on the server.
Okay, so far, so good. Now we could connect to the services in the browser.
When we had done this it was possible to visit the service in the browser in a secure, encrypted, manner.
The problem is that it isn't possible to make a call to the service, neither in Android nor WCF Test Client. If I call the service on the https address, I get a 404 in response. WCF Test Client returns this:
There was no endpoint listening at https://[my service address] that could accept the message. This is often caused by an incorrect address or SOAP action.
To be able to debug this, I'm using Wireshark to intercept the messages and see what really happens. I've found out that after the set up procedures (handshake, establishing trust etc.) the client sends the header and get a 101 Continue in response, after which it POSTs the body. This should be normal behavior. But then the service returns 404 Not Found. Wireshark says that the full request URI is the http address. I've configured the server to use the https address, so why does it make a call to the http address?
I've tried setting the address and listenUri attribute of the endpoint to https and http respectively and the other way around. If I do that, the server answers the request with 405 Method Not Allowed.
Is there any way to solve this? What am I missing?
What am I missing?
TL;DR version below
I'm hosting three WCF SOAP web services with IIS, one using .NET 4 and the others using .NET 3.5. I'm trying to make a call from the WCF Test Client over HTTPS. I've enabled transport security, meta data publishing over HTTPS, installed a trusted certificate and added a https binding on the server.
When I try to make a call from WCF Test Client it says that there was no endpoint listening at the address. Wireshark tells me it makes the call to the http version of the service (i.e. "http://[my address]" instead of "https://[my address]"), although it is configured to call the https address. The service returns 404 Not Found. If I set the address of the service to https and listenUri to http, I get 405 Method Not Allowed. If I do it the other way around it says that it cannot be activated. What am I missing?
I solved this by removing the endpoint and using the <protocolMapping> tag, like this:
<protocolMapping>
<add scheme="https" binding="basicHttpBinding" bindingConfiguration="basicHttps" />
</protocolMapping>
We are currently migrating a WCF service from IIS 6 to IIS 7. The service contains some non-SSL endpoints for internal streaming purposes and some exposed endpoints secured with SSL.
The public, secure endpoints are implemented using wsHttpBinding and security mode="TransportWithMessageCredential". The binding reads as follows:
<wsHttpBinding>
<binding name="CustomSecurityBinding">
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName" />
</security>
</binding>
</wsHttpBinding>
The credentials are authenticated against a custom user repository for validation.
After deploying the service to IIS 7 (64bit Win2k8), all services (basicHttpBindings) respond correctly, expect for the wsHttpBindings. If triggered using https, we always get a HTTP 400 status code (Bad Request).
After enabling tracing in IIS, we could kinda narrow down the problem, although the message from the trace did not really help:
MODULE_SET_RESPONSE_ERROR_STATUS Warning
ModuleName="ManagedPipelineHandler", Notification="EXECUTE_REQUEST_HANDLER",
HttpStatus="400", HttpReason="Bad Request", HttpSubStatus="0", ErrorCode="Der
Vorgang wurde erfolgreich beendet. (0x0)", ConfigExceptionInfo=""
Steps done so far:
re-installed WCF extensions in IIS 7 (ServiceModelReg.exe -r -y)
enabled https protocol for host, added self-signed certificate to host
played around with dns/identity setting in wcf configuration
added a base address to wcf service config
After 2 hours of googling and trying to make this work, i ask you as a last resort of hope: Does anybody know this strange behaviour of IIS 7?
Have you verified that the SSL binding is configured in applicationHost.config (%windir%\system32\inetsrv\config\schema\IIS_Schema.xml) and that the HTTP.sys store contains a valid certificate has and store name for the binding? Secondly, the true error could be masked by the 400 error, have you tried altering your wsHttpBinding in configuration to increase the maxBufferPoolSize and maxReceivedMessageSize to some extremely high values and see if this continues?