How to start 2660 port in IIS for Tridion Core Service connection using netTcp - tridion

I am trying to connect to Tridion using core service script, here is my code:
public static SessionAwareCoreServiceClient Client;
Client = new SessionAwareCoreServiceClient("netTcp_2011");
Client.ClientCredentials.Windows.ClientCredential = new NetworkCredential(user, password);
web.Config has following:
<system.serviceModel>
<!-- Default/example WCF settings for Core Service. These settings should be copied into the host application's configuration file. -->
<bindings>
<!-- Default Core Service binding settings are provided here. These can be used as a starting point for further customizations. -->
<basicHttpBinding>
<binding name="basicHttp" maxReceivedMessageSize="10485760">
<readerQuotas maxStringContentLength="10485760" maxArrayLength="10485760"/>
<security mode="TransportCredentialOnly">
<!-- For LDAP or SSO authentication of transport credentials, use clientCredentialType="Basic" -->
<transport clientCredentialType="Windows"/>
</security>
</binding>
<binding name="streamDownload_basicHttp" maxReceivedMessageSize="209715200" transferMode="StreamedResponse" messageEncoding="Mtom" sendTimeout="00:15:00">
<security mode="TransportCredentialOnly">
<!-- For LDAP or SSO authentication of transport credentials, use clientCredentialType="Basic" -->
<transport clientCredentialType="Windows"/>
</security>
</binding>
<binding name="streamUpload_basicHttp" maxReceivedMessageSize="209715200" transferMode="StreamedRequest" messageEncoding="Mtom" receiveTimeout="00:15:00">
<security mode="None"/>
</binding>
</basicHttpBinding>
<netTcpBinding>
<binding name="netTcp" transactionFlow="true" transactionProtocol="WSAtomicTransaction11" maxReceivedMessageSize="2147483647">
<readerQuotas maxStringContentLength="2147483647" maxArrayLength="2147483647"/>
</binding>
<binding name="streamDownload_netTcp" maxReceivedMessageSize="2147483647" transferMode="StreamedResponse" sendTimeout="00:20:00"/>
<binding name="streamUpload_netTcp" maxReceivedMessageSize="2147483647" transferMode="StreamedRequest" receiveTimeout="00:20:00"/>
</netTcpBinding>
</bindings>
<client>
<!--Dev 2013 -->
<endpoint name="netTcp_2011" address="net.tcp://localhost:2660/CoreService/2011/netTcp" binding="netTcpBinding" bindingConfiguration="netTcp" contract="Tridion.ContentManager.CoreService.Client.ISessionAwareCoreService"/>
<endpoint name="streamDownload_netTcp_2011" address="net.tcp://localhost:2660/CoreService/2011/streamDownload_netTcp" binding="netTcpBinding" bindingConfiguration="streamDownload_netTcp" contract="Tridion.ContentManager.CoreService.Client.IStreamDownload"/>
<endpoint name="streamUpload_netTcp_2011" address="net.tcp://localhost:2660/CoreService/2011/streamUpload_netTcp" binding="netTcpBinding" bindingConfiguration="streamUpload_netTcp" contract="Tridion.ContentManager.CoreService.Client.IStreamUpload"/>
<!-- -->
</client>
</system.serviceModel>
Still I get this Error:
Could not connect to net.tcp://localhost:2660/CoreService/2011/netTcp. The connection attempt lasted for a time span of 00:00:01.0520000. TCP error code 10061: No connection could be made because the target machine actively refused it localhost:2660.
Note: localhost can also be an IP of a CMS instance.
Can anyone help?

Okay, so Over the time I educated myself and can clearly say that the error target machine actively refused it localhost:2660 clearly says that the port is not open for you to use.
So do these two things to be sure:
Make sure you have allowed net.tcp in IIS
And the port 2660 open in the windows firewall?
run a netstat -tan to see whether anything is running on 2660, if not then you can not access it.
Also If you are running your code form local system or from another server, in case netTcp is not working, try to use wsHttp or BasicHttp (provided you have these bindings in your server core service's web.config)

The Core Service runs as a Windows Service, not from IIS. Open Windows Services and make sure that the Tridion Content Manager Service Host is running.

Related

Why is my front-end not retrieving information from my back-end?

If I run my application locally (using localhost) it works perfectly.
But when I decided to switch to my global ip address (when I say global I mean not my lan ip address, but the one given by my ISP).
It just doesn't load the data from my back-end.
This is how I make the requests from my front-end:
this.http.get("http://my-isp-ip:52899/api/Student/ListStudents").subscribe(response => {
this.users = response["Users"];
});
And this is how I got my applicationhost.config on my back-end:
<bindings>
<binding protocol="http" bindingInformation="*:52899:localhost" />
<binding protocol="http" bindingInformation="*:52899:my-isp-ip" />
</bindings>
And I run the front-end application like this:
ng serve --host 0.0.0.0
And I already opened the ports both in my router and my firewall.
Now, in my router I only opened the ports: 4200 since this is the one running on my front-end and 52889 which is the one running on my back-end.
What can I be doing wrong?
Solution:
I changed:
<bindings>
<binding protocol="http" bindingInformation="*:52899:localhost" />
<binding protocol="http" bindingInformation="*:52899:my-isp-ip" />
</bindings>
To:
<bindings>
<binding protocol="http" bindingInformation="*:52899:localhost" />
<binding protocol="http" bindingInformation="*:52899:*" />
</bindings>
And run Visual Studio as Administrator...

Could not find a base address that matches scheme https. wcf on visual studio localhost

I am trying to use wcf on both https and http.
I manage to config the web.config to work on the server both http and https.
the problem is that wcf not working on the visual studio localhost(doesn't have ssl).
the web.config look like this
<webHttpBinding>
<binding name="webBinding">
<security mode="Transport">
</security>
</binding>
<binding name="webBindingNotSecure">
<security mode="None">
</security>
</binding>
</webHttpBinding>
and then 2 endpoint for http and https:
<service name="Website.WebServices.ddPoplute">
<endpoint behaviorConfiguration="Website.WebServices.ddPopluteAspNetAjaxBehavior"
binding="webHttpBinding" bindingConfiguration="webBinding" contract="Website.WebServices.ddPoplute">
</endpoint>
<endpoint behaviorConfiguration="Website.WebServices.ddPopluteAspNetAjaxBehavior"
binding="webHttpBinding" bindingConfiguration="webBindingNotSecure" contract="Website.WebServices.ddPoplute" />
</service>
as mention above in the server that has https everything just fine, but on localhost that doesn't have the ssl I am getting error:
Could not find a base address that matches scheme https for the endpoint with binding WebHttpBinding. Registered base address schemes are [http]
If I delete the endpoint with security mode="Transport" the wcf work on the localhost but not on https(in server).
ant idea what to do?
Thnaks
Baaroz
visual studio doesn't support https and ssl and the error return because the protocol doesn't exist.
for solving the problem you should install iis express and use it in visual studio.
check here for learn how to use iis express
http://joel.net/setting-up-visual-studio-2010-and-iis-express

Web Service Error "There was no endpoint listening at..." Firewall Concern

So I have a web service service reference that works localhost and can be pinged from its production url but I can't get access to it via the Service Reference call in production. I believe the issue is my firewall . I have two websites on the same server each with their own dedicated IP address. I am trying to call the web service on the second website from the first website. If I open a browser on my production server I cannot navigate to either website.
Error Description:There was no endpoint listening at http://[209.112.245.103]/Services/OfferService.asmx that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
Inner Exception:Unable to connect to the remote server
The calling website is on the same server (different IP of course) and is calling the web service via a service reference:
Dim offerService As New ServiceReferenceOffer.OfferServiceSoapClient("OfferServiceSoap")
offerService.BroadcastOfferChange(offer.PropertyID, offer.OfferID, offer.ResultResponse)
And my web.config contains the following service endpoint information:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="OfferServiceSoap" />
<binding name="ConversationServiceSoap" />
</basicHttpBinding>
<customBinding>
<binding name="OfferServiceSoap12">
<textMessageEncoding messageVersion="Soap12" />
<httpTransport />
</binding>
<binding name="ConversationServiceSoap12">
<textMessageEncoding messageVersion="Soap12" />
<httpTransport />
</binding>
</customBinding>
</bindings>
<client>
<endpoint address="http://209.112.245.103/Services/ConversationService.asmx"
binding="basicHttpBinding" bindingConfiguration="ConversationServiceSoap"
contract="ServiceReferenceConversation.ConversationServiceSoap"
name="ConversationServiceSoap" />
<endpoint address="http://209.112.245.103/Services/ConversationService.asmx"
binding="customBinding" bindingConfiguration="ConversationServiceSoap12"
contract="ServiceReferenceConversation.ConversationServiceSoap"
name="ConversationServiceSoap12" />
<endpoint address="http://209.112.245.103/Services/OfferService.asmx"
binding="basicHttpBinding" bindingConfiguration="OfferServiceSoap"
contract="ServiceReferenceOffer.OfferServiceSoap" name="OfferServiceSoap" />
<endpoint address="http://209.112.245.103/Services/OfferService.asmx"
binding="customBinding" bindingConfiguration="OfferServiceSoap12"
contract="ServiceReferenceOffer.OfferServiceSoap" name="OfferServiceSoap12" />
</client>
</system.serviceModel>
Your configurations are correct. I just accessed your server and everything went fine (so it's not code related).
Since the site and the website are in the same server, you may need to use a different IP or address to access the wcf (try 127.0.0.1, localhost or an internal server ip).

WCF Error - unexpected response: (400) Bad Request

I'm having trouble finding an answer for this problem. Most similar posts lean seem to be fixed by adjusting some of the maximum size settings in the web.config file. However, none of those suggestions have fixed my issue.
To give a little more background, I'm porting a asmx web service, to a WCF web service hosted in Windows Azure. This problem came up during testing. If I pass a small number of transactions to my webservice in a single call, it tends to work just fine. This error come up though when my transaction size gets around 50-60 (transactions). Serialized to xml, the file size is around 300K, so it's nothing insanely large. But it does tend to lean towards a size issue.
Also, turning on WCF tracing, I found the following exception occuring:
System.ServiceModel.ProtocolException: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.
at System.ServiceModel.Channels.HttpInput.ThrowHttpProtocolException(String message, HttpStatusCode statusCode, String statusDescription)
at System.ServiceModel.Channels.HttpInput.ThrowMaxReceivedMessageSizeExceeded()
at System.ServiceModel.Channels.HttpInput.ReadBufferedMessage(Stream inputStream)
at System.ServiceModel.Channels.HttpInput.ParseIncomingMessage(Exception&amp; requestException)
at System.ServiceModel.Channels.HttpChannelListener.HttpContextReceived(HttpRequestContext context, Action callback)
So from the exception, it looks as though one of the settings if off in my web.config, but here is what that looks like:
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
<behavior name="MetadataEnabled">
<serviceDebug includeExceptionDetailInFaults="true"/>
<serviceMetadata httpGetEnabled="true"/>
<useRequestHeadersForMetadataAddress>
<defaultPorts>
<add scheme="http" port="8081"/>
<add scheme="https" port="444"/>
</defaultPorts>
</useRequestHeadersForMetadataAddress>
<dataContractSerializer maxItemsInObjectGraph="111024000"/>
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service name="Bandicoot.Core" behaviorConfiguration="MetadataEnabled">
<endpoint name="HttpEndpoint"
address=""
binding="wsHttpBinding"
bindingConfiguration="wsHttp"
contract="Bandicoot.CORE.IRepricer" />
<endpoint name="HttpMetadata"
address="contract"
binding="mexHttpBinding"
bindingConfiguration="mexBinding"
contract="Bandicoot.CORE.Stack" />
<host>
<baseAddresses>
<add baseAddress="http://localhost/Core"/>
</baseAddresses>
</host>
</service>
</services>
<bindings>
<wsHttpBinding>
<binding name="wsHttp" maxReceivedMessageSize="111024000"
messageEncoding="Text" maxBufferPoolSize="111024000"
textEncoding="UTF-8">
<readerQuotas maxBytesPerRead="111024000"
maxArrayLength="111024000"
maxStringContentLength="111024000"/>
<security mode="None"/>
</binding>
</wsHttpBinding>
<mexHttpBinding>
<binding name="mexBinding"/>
</mexHttpBinding>
</bindings>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
Does anyone have any other suggestions, or is there something mis-configured in my web.config that I'm just not seeing?
Thanks for any advice!
Edit: Here is the settings from my client's app.config
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_CORE" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="14194304" maxBufferPoolSize="14194304" maxReceivedMessageSize="14194304"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="1000" maxStringContentLength="111024000"
maxArrayLength="111024000" maxBytesPerRead="1024000" maxNameTableCharCount="111024000" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
Edit: adding addition client information:
<client>
<endpoint address="http://localhost:92/CORE.svc" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_CORE" contract="Core.CORE"
name="BasicHttpBinding_CORE" />
</client>
Edit: Attempted changing the service bindings to basicHttpBinding - config changes:
<basicHttpBinding>
<binding name="basicHttp" maxReceivedMessageSize="111024000"
messageEncoding="Text" maxBufferPoolSize="111024000"
textEncoding="UTF-8">
<readerQuotas maxArrayLength="111024000" maxBytesPerRead="111024000" maxStringContentLength="111024000"/>
<security mode="None" />
</binding>
</basicHttpBinding>
<service name="Bandicoot.Core" behaviorConfiguration="MetadataEnabled">
<endpoint binding="basicHttpBinding"
bindingConfiguration="basicHttp"
contract="Bandicoot.CORE.IRepricer" />
<endpoint address="mex"
binding="mexHttpBinding"
bindingConfiguration="mexBinding"
contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://localhost/Core"/>
</baseAddresses>
</host>
</service>
And the client's app.config as well for reference:
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_CORE" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="100000000"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:92/CORE.svc" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_CORE" contract="Core.CORE"
name="BasicHttpBinding_CORE" />
</client>
You need to be setting the maxReceivedMessageSize on the client (where the message you're returning from your service is incoming) - in its app.config or web.config:
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="wsHttp" maxReceivedMessageSize="111024000"
messageEncoding="Text" maxBufferPoolSize="111024000"
textEncoding="UTF-8">
<readerQuotas maxBytesPerRead="111024000"
maxArrayLength="111024000"
maxStringContentLength="111024000"/>
<security mode="None"/>
</binding>
</wsHttpBinding>
<mexHttpBinding>
<binding name="mexBinding"/>
</mexHttpBinding>
</bindings>
<client name="whatever">
<endpoint name="HttpEndpoint"
address=""
binding="wsHttpBinding"
bindingConfiguration="wsHttp"
contract="Bandicoot.CORE.IRepricer" />
</client>
</system.serviceModel>
The default value for maxReceivedMessageSize is 64K, unless you change it.
I finally figured this one out this morning. The problem was that my service was not using the configuration settings that I thought it was. The reason? The service name in the configuration needs to be a fully qualified path to the service being implemented.
I found this link helpful figuring it out.
I found it a little odd that my service worked without pointing it to an actual endpoint, I guess it just uses a series of default values and if you want something different you can configure them in the web.config? I think this explains why I was getting a basicHttpBinding when I consumed the webservice in my client, instead of wsHttpBinding.
Took a few days to figure it out, but was educational. Thanks for the suggestions!
I had the same error and the cause was revealed to be a configuration error, too.
But in my case this was, like marc_s already posted, the maxReceivedMessageSize setting on the server side. The server was still using its default configuration, which was as low as 64 kb.
As obvious as this now sounds, that long it took me to find out that the error was not on my (client) side.
I hope that this may help someone else.
Hi Question Poster "Brosto"!
This supplements your Nov 17 '10 at 15:29 answer.
We had a “fun”, or should I say “educational” Production Deployment Testing issue today that took most of the day to resolve, and it was literally caused by one keystroke. We only confirmed the source of the problem, after we found out the problem disappeared after the Web Farm was fully deployed.
Here was the cause. When we test our Production Deployment, and do so against a “Single Server” by changing our hosts file, we are bypassing the Load Balancer, and the call to the Single Server ends up going over the default http port 80! When we test against the “Load Balancer”, the call to the Single Server from the Load Balancer, ends up going over the Load Balancer defined port 81!
Since the Service Endpoint Address must be “fully qualified”, to enable the service to find its Custom Bindings, the Services.config file on the Single Server must be changed to reflect the difference between “Single Server” vs “Load Balanced Server” endpoint connections, as follows:
Single Server connection:
endpoint address="http://www.myserver.com:80/Services/MyService.svc"
Load Balanced Server connection:
endpoint address="http://www.myserver.com:81/Services/MyService.svc"
My boss correctly diagnosed the core problem early, saying that the server was acting like the custom bindings were being ignored and the defaults were being used instead. After showing him your comment above where you mention the requirement of “fully qualified” service endpoint address, he realized that the host file redirection was causing our browser request to go to the Single Server over default port 80, instead of the Load Balanced port 81, which in effect altered the fully qualified service endpoint address, which caused the server to ignore the custom bindings and revert to default settings. Please note that it did NOT fail to call the service, it only failed to bind the custom bindings!
Hopefully someone will remember this posting the next time we Production Test a Service with custom bindings :)

WCF Authentication on the Internet

I have a WCF service using the basicHTTP binding. The service will be targeted to be deployed
in production in a DMZ environment on a Windows Server 2008 64 bit running IIS 7.0 and is not
in an Active Directory domain.
The service will be accessed by a business partner over the Internet with SSL protection. Originally,
I had built the service to use x.509 Message authentication with wsHTTPBinding and after a lot of
problems I punted and decided to back up and use basicHTTP with UserName authentication.
Result: same exact, obscure error message as I received with certificate mode.
The service works perfectly inside our domain with the exact same authentication but as soon as
I move it to the DMZ I get an error reading: "An unsecured or incorrectly secured fault was received
from the other party. See the inner FaultException for the fault code and detail".
The inner exception message is: "An error occurred when verifying security for the message."
The services' web config with binding configuration is as follows:
<services>
<service behaviorConfiguration="HSSanoviaFacade.Service1Behavior" name="HSSanoviaFacade.HSSanoviaFacade">
<endpoint address="" binding="basicHttpBinding" contract="HSSanoviaFacade.IHSSanoviaFacade" bindingConfiguration="basicHttp">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="https://FULLY QUALIFIED HOST NAME CHANGED TO PROTECT/>
</baseAddresses>
</host>
</service>
</services>
<bindings>
<basicHttpBinding>
<binding name="basicHttp">
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="HSSanoviaFacade.Service1Behavior">
<serviceMetadata httpsGetEnabled="True" />
<serviceDebug includeExceptionDetailInFaults="True" />
</behavior>
</serviceBehaviors>
</behaviors>
The test client's configuration that gets the error:
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IHSSanoviaFacade" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="None" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="https://HOST NAME CHANGED TO PROTECT"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IHSSanoviaFacade"
contract="MembersService.IHSSanoviaFacade" name="BasicHttpBinding_IHSSanoviaFacade" />
</client>
As mentioned earlier, the service works perfectly on the domain and the production IIS box is not on a domain.
I have been tweaking and pulling my hair out for 2 weeks now and nothing seems to work. If anyone can help I
would appreciate it. Even a recommendation for a work around for authentication. I'd rather not use a custom
authentication scheme but use built-in SOAP capabilities.
The credentials pass in thru the proxy i.e. proxy.ClientCredentials.UserName.UserName and
proxy.ClientCredentials.UserName.Password are valid accounts on both the internal domain in the test
environment and as a machine account on the DMZ IIS box.
Well, maybe not exactly what I wanted but I got it to work. Must be a difference in IIS in a domain versus not.
Here are my changes to the service web config:
<security mode="Transport">
<transport clientCredentialType="Basic" />
</security>
As I understand it, this doesn't pass the credentials in the SOAP header but in the HTTP header which means message level security doesn't work in this scenario. Its all protected by an SSL certificate.

Resources