I'm using signalr in my application to notify user how the proccess is doing. When i test it in localhost, everything works well, but when I deploy the same code in production i get the error bellow:
The ConnectionId is in the incorrect format.
My production enviroment is configurated with NLB (Network Load Balance) of windows server. This can cause the intermittent problem? Are there a solution to resolve it?
Thaks
Have a look at your settings in the balancing:
Normally, when running ASP.NET in a load balanced environment in a
webfarm, you make the machine keys the same on all servers so when
clients flip flop between machines, they encryption and signing work
consistently in your farm.
https://github.com/SignalR/SignalR/issues/2292
Related
We have run into a problem with IIS, TLS 1.2 and domain users. I searched SO and other forums, but all possibly related topics didn't lead me to a solution.
Please don't judge the configuration, it wasn't invented by me, I just need to solve this problem.
What happens is the following:
We have an old web application, that opens an executable with Process.Start and that executable calls an external webservice. This used to work fine with TLS 1.0, but in the near future, the external webservice demands TLS 1.2.
So now we are trying to make this work, and we are almost there: we upgraded the executable's .Net Framework version to 4.7.2 and enabled TLS 1.2 on the Windows Server 2008 R2. The web app's .Net Framework version is set to 4.6.1. It seems to me that this should be everything there is to it.
And indeed, when we run the executable stand alone (not called by the web app) from the server, so owned by the domain user logged on to the server (with RDP), everything works as expected; we receive the proper answer from the web service.
Also, when we call the executable by the web app and in IIS the application pool identity is set to a build in account: ApplicationPoolIdentity, everything works as expected as well.
But, when we set the application pool identity to a dedicated domain account (so a different one than the one that executed the executable earlier), the trouble begins. Connecting the web service fails with the following exception:
System.ServiceModel.EndpointNotFoundException: There was no endpoint
listening at https://<some url>/<some webservice name>.asmx that could
accept the message. This is often caused by an incorrect address or
SOAP action. See InnerException, if present, for more details. --->
System.Net.WebException: Unable to connect to the remote server
---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected
host has failed to respond ...
Now the question is of course, what could be causing this?
I like to believe that the failing domain account is configured correctly, but it seems it is not. Or could it be something else, that I don't even know the existence of...
EDIT:
I managed to narrow it down to a permissions issue: when the dedicated domain account runs the application stand alone, it works as it should. When the dedicated account runs it from within the IIS context (started by the web app), it doesn't work, but when the dedicated account is given admin rights, it also works as expected.
That leaves me to the question: what additional permissions does IIS need to allow this setup? Maybe in combination with TLS 1.2 thingies.
Any help would be greatly appreciated.
I have some websites that should be able to get data from each other by a webservice.
Every website is using the "same" code so in every website(s) web.config, you have both the service and client config.
When doing a request, url is set in runtime like:
foreach(var sibling in mySiblings)
{
var client = new MySoapClient("MySoapClient", sibling.Host + "/webservice/MySoapClient.asmx");
var info = client.GetInfo();
allInfo.Add(info);
}
(only pseudo code)
All sites are hosted on the same server.
When code is executed, you get an error after a while:
"There was no endpoint listening at 'http://host_address/webservice/MySoapClient.asmx' that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details."
InnerException: "Unable to connect to the remote server"
Adding log to the code above, checking the "client.EndPoint.ListenUri.AbsoluteUri" gives you a correct path, that can be reached when entered in a browser.
Now, the real annoying problem:
There are some servers/sites that CAN connect - and some that can't.
There is another server, with "same" sites - only this is the test-sites.
(Copy of the code, copy of the databases - other dns-names)
The test-sites can connect to the other test-sites webservices and get data.
The test-sites can NOT connect to Prod-sites
The prod-sites can connect to sites on the test-server.
The prod-sites can NOT connect to Prod-sites. (Not even to it self)
So, it seems like there is a problem with the prod-sites/server.
Only problem with that...if you set it up on you local machine - you can get data from both test - and prod.
I also built a simple test-client, (aspx-page) containing a dropdownlist with hostnames, For prod and for test. And a button.
Click the button: Make a call to a simple method in the webservice of selected host.
I then set this up in the IIS as "http://public-ip-number/wsTest" on four locations.
Running this on my own computer: Can connect to both test and prod.
Running this on the test-server: Can connect to test.
Running this on the prod-server: Can connect to test.
Running this on a third server I have access to: Can connect to both test and prod.
Test and Prod are hosted by a hosting company. Both servers has been setup the exact same way, since test should reflect prod. (Windows 2016 server) Or at least they should.
My system: Windows 10
The third server: Windows Server 2012.
Since the code is identical on the two servers, I don't think that's the problem. Specially since everything works when calls are done "from the outside".
I have access to the servers through VPN/RDS, and have full administrator roles. But there is no visual difference on how the servers are set up, as far as I can see.
Could there be some firewall blocking on the hosting-part?
I really don't know where to look!
Anyone with any ideas...I'm all ears!
Update:
This wasn't actually a coding-problem.
The hosting-company had indeed added a rule to the firewall, "The problem is NAT Loopback. This means that the server shall access itself on public IP addresses."
After they fixed it, everything worked as it should.
Followed the instructions in https://msdn.microsoft.com/en-us/library/gg492140.aspx
SSAS is running on a hosted server. No domain.
Able to connect with anonymous authentication, but when basic is enabled, neither SSMS or Excel will connect.
Error from SSMS is "The remote server returned an error (401). Unauthorized"
Credentials are set up on the remote machine as DOMAIN:443
Credentials have admin privileges on the server.
Excel says "connection cannot be made to remote machine or SSAS is not running"
HTTP or HTTPS doesn't matter.
When it connects with anonymous, no cubes are returned so it is apparently doing nothing with the userid/password. Just connecting.
When I connect via port 2383 using the same credentials, I have no problem in SSMS or Excel.
Help is GREATLY appreciated. Thanks.
This was partially solved by starting over and following the steps in this article:
https://technet.microsoft.com/en-us/library/cc917670.aspx
Honestly, I can't pin down the exact resolution, but I believe it has to do with using a different folder structure (other than inetpub/wwwroot...) on my D drive and therefore losing the standard security configuration.
I created an OLAP folder on C:/inetpub/wwwroot and it works... with the exception of SSL which still does not work.
HTTP connects fine, but not HTTPS. Still working on that.
I have an ASP.NET webservice which is deployed on Server2008 IIS7. We use two servers, Production and UAT (test server) and this webservice is deployed on both servers, the same compile is on both of them (no code changes, revisions etc, pure copy/paste from one to another).
The only difference between the applications is a connection string in web.config, one points to PROD database, the other UAT.
If I make a call to the test webservice I get an expected response and all is well, but when I do the same thing on the production webservice I promptly get and error
Server was unable to process request. ---> Object reference not set to an instance of an object.
I am suspecting there must be a configuration issue as the webservices are running under their own Pool which is run by a service account/user (local admin on the servers) and they are set to only run through SSL (https:// only) on a special port.
I tired sniffing with Fiddler and got two identical SOAP requests, the only difference being the server name in URL. I can access the WSDL of both webservices from IE browser, I can successfully refresh my web reference in Visual studio (for both prod and uat services).
Does anyone have any hints what should I be looking at, perhaps someone had a similar problem?
This is resolved. As I suspected the error was in production server configuration. When the sys team added a service user into the local Administrators they added it through Active directory groups, which as I am told requires a logoff/logon or a restart.
Server restart was the solution in my case.
I have an application that runs transactions spanning over multiple databases on the same server. Naturally this involves the Microsoft Distributed Transaction Coordinator and everything works like it is supposed to.
Howver, when I remotely connect to the network where the server is hosted via VPN and run the application on my local machine I receive the following error:
System.Transactions.TransactionManagerCommunicationException:
"Communication with the underlying transaction manager has failed."
Caused by:
System.Runtime.InteropServices.COMException:
Error HRESULT E_FAIL has been returned from a call to a COM component.
Here is the stack trace for the originating exception:
at System.Transactions.Oletx.IDtcProxyShimFactory.ReceiveTransaction(UInt32 propgationTokenSize, Byte[] propgationToken, IntPtr managedIdentifier, Guid& transactionIdentifier, OletxTransactionIsolationLevel& isolationLevel, ITransactionShim& transactionShim)
at System.Transactions.TransactionInterop.GetOletxTransactionFromTransmitterPropigationToken(Byte[] propagationToken)
The problem arises only when I connect to the server through a VPN tunnel.
Note also that I have temporarly disabled Windows Firewall on my local machine, just to be sure it doesn't block the MSDTC.
Does anyone know of any issues when running MSDTC through VPN?
I suggest you run DTCPing (available from the Microsoft site somewhere) This is run at the same time on both machines and detects all manner of DTC problems.
Be careful I had great difficulties with this tool until I actually read the instructions and started both sides of the test up before I clicked the start test button.
Do you administer the VPN connection? There might be restricted ports on the VPN. Likewise, do you administer your servers? Your servers might only allow connections from IP addresses on the inside and not on the segment used for VPN service. If you are the administrator, perhaps saying which VPN software you are using will help.
I'm having the same problem using a Windows 7 x64 client and a Server 2003R2 server. I have been able to make it work (on the same vpn, same server) using XP, Vista x86, and Windows 7 x86. I have a support call with Microsoft open and they are looking into it. I'm curious - what operating system are you guys using on your client machines?