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.
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 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 been developing an ASP.NET application and I would like my work colleagues to give me feedback on it. I tried running it on IIS but because the database is located on a remote server, I am unable to host it properly?
Also, how can the colleagues access that site? my host name, etc
You can update your connection string to your remote server (providing the DB accepts external requests).
Something like (assuming SQL)
Data Source=190.190.200.100,1433;Network Library=DBMSSOCN;Initial Catalog=myDataBase; User ID=myUsername;Password=myPassword;
It's an ugly hack, but you can do an if else statement, detect the DomainName (Environment.UserDomainName()) and if matches the server then use one connection string, if it's your office's domain, then use that!
This means, you can still use your local IIS!
You can publish your web site on a local server which has IIS running on it. You can create your application on IIS and your colleagues can access your web site from the intranet via the name of the server easily.
Such as:
http://servername/yourprojectdirectory
And also the local server should have internet access for the remote database.
My webapplication hosted on windows azure, needs to communicate with TFS Server. When any one login to my web app using live id, I want the logged in user to use my Team foundation server(TFS) credentials -username,password and domain to programatically authenticate and connect to our TFS server and create some work items.
I configured my azure connect for the communication to happen between azure WebRole and TFS server (our TFS is non-azure ).I added both the WebRole and the TFS Server into single Connection Group
In my azureportal ,I can see mywebrole and my TFSServer as connected the machine endpoint is active, and that it refreshes since the last connected updates
.But when I try to run my web application from azure and when it tries to communicate with our TFS server ,its throwing error message saying Error message : Team Foundation services are not available from server eg.,http://xyz-abcxyx-01:8080/tfs/eas/. Technical information (for administrator): The remote name could not be resolved: 'xyz-abcxyx-01'
Any suggestions to resolve this issue ?
You should enable remote desktop on your WebRole and connect to one of your instances. Then, try to ping the IP of your TFS server (not the hostname xyz-abcxyx-01). Maybe this is simply a DNS issue (even though using hostnames works with Windows Azure Connect).
If pinging the IP works, but pinging the hostname doesn't work you have a few options left:
Use the IP instead of the hostname. This won't work if you configured your TFS to use host headers.
Create an elevated startup task to modify the hosts file and map the IP to the hostname. In your code you can keep working with the hostname.
Try to modify the DNS server configured in your WebRole to use the default DNS server + your internal DNS server. But to me this doesn't look like a clean solution.
Anyways, in each solution you'll want to store the IP/hostname in the ServiceConfiguration and make sure your code supports changes to the ServiceConfiguration. This will allow you to change the IP/hostname without having to redeploy.
You should check if TFS server is listening on all network interfaces, include the one created by Azure Connect (start with 2a01). Next try to connect to TFS from a machine on the local LAN, just to make sure it is configured correctly. You don't need to use IP for referring to TFS, DNS name is definitely supported out of box.
I have a website in Asp.net that I have installed on my server, and my website's database in SQL Server 2008 R2. My website has pages that contain ActiveX components. When I run my website on the server the ActiveX components are working correctly, but there is a problem when I run website from client.
The pages that do not contain ActiveX components work correctly and I can get and insert data from database. In the pages that contain ActiveX components it gives me SQL Server error number 40, that it could not open the connection.
Can anyone help me resolve this?
As Steve B implies in his comment the problem lies in the ActiveX component making a call to the database directly. The connection string in your app specifies a connection made from the Web server to the Database server. These connections work because your firewall settings allow for inbound connections to the Database server from that Web server. When the connection is set in the ActiveX control to connect directly to the Database, you are getting connection failures because the firewall is blocking the inbound connections from the clients running the ActiveX component. The fix is to redesign your application so the ActiveX component that lives on the client machine no longer makes calls directly against the database; make use of web services or something of that nature. If the clients are all internal to the domain (aka this is a private app and will never be public facing), chances are the Firewall isn't properly configured to allow internal connections to the database server.