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.
Related
I have noticed that over the last year while my app has been in production, it sometimes just switches off.
When I debug the web api project locally and use the connection string of the database on Azure, it works.
Whenever I then publish the project to Azure, it says Error 500, can't handle this request. Even with the connection string hard coded in the appsettings.json.
What I did notice though was when I changed firewall settings on the database server recently, that's when it switched off. I don't know if that's the source.
What could the problem be?
And would you think it, it was the server IP address.
I had to find the virtual IP address of the web app under Properties in the left pane and add it to the server rules of the database.
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'm trying to understand how a web client and a server connect and how those connections are handled in dev mode versus production mode.
The part that I am having trouble wrapping my mind around is how to differentiate making a request to localhost from the client as opposed to making a request to a server that is in production (hosted on Heroku for example).
I know how the client makes a request to the API, but how does the client know whether to make a request to localhost:3000 in dev mode or to a different URL in production mode.
My idea of production mode is that the server is hosted (by Heroku for example) and therefore can no longer be queried at localhost.
Any insight greatly appreciated.
This is almost always handled through configuration (e.g., *.properties) files that are different for each environment. The difference is usually handled in the build (selecting different properties files for build artifact) or by passing arguments or environment variables to the application when it is started.
So when I run my two services locally, I can hit service A which sends a command to service B which picks it up and processes it. Pretty straight forward. However, when I publish these to my web server and I send a request to service A which sends it to service B (I can see the message in service B's queue) but it won't get picked up and processed. I created an endpoint on service B that simply returns an OK response -- if I call this endpoint, effectively "touching" the service, everything kicks on and the messages get processed from that point on.
I figured maybe this had something to do with with late compiling, so I changed the publish to precompile on publish, but I get the same result.
Is there a way to have the service start processing as soon as it is published? Also worth noting that both services are WebAPI 2
Another option (probably more “standard”) would be to move the “handlers” into a Windows Service instead of a web application.
For this Windows Service you can leverage the NServiceBus Host which will turn a standard class library into a Windows Service for you. They have a good amount of documentation about this here: https://docs.particular.net/nservicebus/hosting/nservicebus-host/?version=Host_6
I would argue that this is more stable as you can separate the processing of sending commands (Web Application / WebApi) and processing commands / publishing events (NSB Host). The host can sit on the web server itself or you can put these on a different server.
Our default architecture is to have a separate server run our NSB Hosts as you scale web applications and NSB Hosts differently. If you run the NSB Host on the web server, you can get issues where a web app gets too much traffic and takes the NSB Host processing down. You can always start simple with using 1 server for both, monitor the server and then move things around as traffic increases.
Not sure if this is the "right way" to do things, but what I ended up doing is setting up each site to be always running and auto initialize.
App pool set to "Always Running"
Website set preload enabled = true
Web.config has webServer entry for application initialization doAppInitAfterRestart="true"
Web Role added to server "Application Initialization"
With those things being set, the deployment process is basically to publish the site and iisreset. If there are better options, I'm still looking :)
I have a weird case here at work.
The customer(telecommunication firm) has a server which we publish asp.net web service codes which we designed for them. We use that server and web service to get data from the customers own web service and give out for client(telephone) to use it.
The customer does not allow us to code on the remote server, so we have to work on local computer.
The customer has 2 IPs for its own web services. One of them can be reached only from the remote server, this is an internal IP. Second IP is public which I can reach from my local computer. They address the same methods. For security reasons, they divided IPs.
Everything is fine while developing on local. But when I need to publish web service to the server, I need to change web service URLs to remote servers internal IP. But the local Visual Studio web reference doesn't change web service URLs because it can't reach to service as it is only permitted to reach from the server. So I cannot get a build and publish my code.
Somehow I need to change my visual studio reference URLs to internal IP(so far nobody can reach from local), in order
Hope I am clear.
Thanks
It can be changed from the web.config of your local project.