My IdentityServer worked fine when selfhosted (Kestrel) but throws an error when hosted in IIS: "An error occurred using the connection to database 'MyTestIDS' on server '.'" and "Login failed for user '(my machine name)$'". I have a connection string defined in appsettings.json with a value "Server=.;Database=MyTestIDS;trusted_connection=True;" and it connects to a SQL Server on my local machine. As I mentioned before, it's been working fine selfhosted until now when I host in IIS. I checked my deployed code and the appsettings.json is there. Does the app still read configuration settings from appsettings.json under IIS? Or should I move it to somewhere else?
I have figured out the issue - the format of the connection string. When slfe-hosting, I used "Server=.;Database=MyTestDB;trusted_connection=True;" and it worked just fine there. But under IIS, I have to change it to something like "Server=MyServer,MyPort;Database=MyTestDB;user id=MyUsrID;Password=MyPassword". Now I am working fine.
Related
Problem:
We have a .NET Core Web API that we have just deployed as an Azure Web App. Testing locally everything works fine, however we are unable to connect to our DB from the deployed API in Azure.
From Application Insights I can see we are getting the following error:
Microsoft.Data.SqlClient.SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible.
Our setup:
We have our connection string included in appsettings.json
"ConnectionStrings": {
"DefaultConnection": "Data Source=<source>.com,<port>;Initial Catalog=<db>;User ID=<username>;Password=<password>;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=True;Connection Timeout=30;"
},
We know our API is using this connections string because we can see in Application Insights that there is a timeout connecting to the db specified in that exact connection string.
We do not have access to DB configuration as we have read only access granted to us from a third party. We can connect via SSMS/Azure Data Studio and when testing our Web API locally (which makes us think the connection string is correct).
Other Posts we have Referenced:
Connection String in Azure Web App Configuration - I have tried including and not including our connection string from the Azure App Service Configuration - neither changed that we got a timeout and subsequent 500 error.
Include Connection String in appsettings.json - We have our connection string included in appsettings.json and testing locally, we can connect to the db without issue.
Improperly Formatted Connection String - The connection string works when testing locally, so we do not believe it to be an issue with the formatting of the connection string. Additionally, because Application Insights says that there is a timeout connecting to the DB specified in the connection string, it appears to be using the connection string we are providing.
Any ideas as to what might be going on here and how we can connect to the DB would be greatly appreciated.
In this case, we needed to request that the third party whitelist our Azure Web Apps Outbound IP's.
Your Azure Web App Outbound IP's can be located in a number of ways.
Via Azure Portal
Web Apps > Your Web App > Under "Settings" go to Networking > Outbound Addresses
Via Azure CLI
az webapp show -n yourwebappname -g yourresoucegroup --query "outboundIpAddresses"
I have developed a simple Web API and deployed it on an Azure server along with a SQL Server database. The database and the Web API are hosted on the same server. I can connect to the database from my development machine. If I run the Web API in Visual Studio 2017, everything works fine, I can call all Web methods and I get the proper expected response.
Now, that I deployed the Web API on the server and run it under IIS, if I make a Web API call using Postman I get this error message after about 30 seconds of wait time:
"A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)"
I know this error has been discussed here many times, but none of the suggestions made help solve my problem. The hosting Azure VM is a 64-bit Windows Server 2016.
In the connection string used by my Web API I had the data source set to the computer's name, its internal Ip address, the "localhost" keyword or the "127.0.0.1" back-loop IP address, but I get the same error listed above in each of those situations. SQL Server Management Studio (running locally on the same server that hosts the database and my Web API) is able to connect to the database if I use either of the three data sources: localhost, internal IP address or computer name.
In the situation in which it works, when I run the Web API in Visual Studio, the data source in the connection string is set to the external Ip address of the Azure Server. That would be the only difference, as far as the data source is concerned.
I need to mention that I have a couple of web methods that do not require database access. These work fine and return the expected result.
Are there other specific settings that I would need to do in IIS to allow this to happen?
TIA,
Eddie
I figured what the problem was. My Web API was developed in ASP.Net Core and as such, it produces its own executable. That is looking for a config file that is named TheNameOfTheApplication.exe.config.
Due to a temporary lapse of reason, I was modifying the connection string in the "app.config" file and left the one in the "TheNameOfTheApplication.exe.config" file with the external IP address that was not correct.
I am trying to get local nuget server with the help of following link.
http://www.codeproject.com/Articles/872230/Create-Your-Own-Private-NuGet-Server-in-Windows-Az
Its hosted without much issue and I can view the hosting page. However when I try to publish a package to this nuget server it throws 405 error (Method not allowed).
I know this is something to do with IIS setting as I try it using IISExpress and it publishes ok.
All above is on local iis server (not on azure or any other remote server).
Any idea?
I am trying to set up a new azure website. I have done this before and everything just worked, this time I'm having real trouble getting the database set up.
I setup both site and database in the deploy wizard, and have a connection string named the same as on my local box. The error I'm getting is below:
A network-related or instance-specific error occurred while
establishing a connection to SQL Server. The server was not found or
was not accessible. Verify that the instance name is correct and that
SQL Server is configured to allow remote connections. (provider: SQL
Network Interfaces, error: 26 - Error Locating Server/Instance
Specified)
If i copy paste the connection string from azure to my local box (and add my local ip to the whitelist for SqlAzure) then it works fine locally (which is why I'm a little stumped)
The only thing that that I have noticed is that if I download the web.config for the site as configured in azure there are no connection strings. I imagine that this is because they are doing some clever security thing.
Any idea what I can even try next to diagnose this?
I have a .net 2.0 app being hosted on IIS, that connects to a Ingres DB. The connection uses iBatis with an ODBC driver to connect to an ingres database being protected behind an installation password.
For some reason, when I'm debugging my code, everything runs fine. It establishes the connection without any problems. However, when I try to host the site on my local IIS, ingres comes back with this error
ERROR [5000H] [CA][Ingres ODBC Driver][Ingres]User authorization check failed.
Your user identifier was not known to this installation.
Contact your system manager for further assistance.
ERROR [08S01] [CA][Ingres ODBC Driver][Ingres]The connection to the server has been aborted.
I'm wondering why the installation password would work fine against my debug session, and refuse to connect behind IIS? Does IIS use a different 'name' that isn't my computer name to establish a connection with the installation password?
The connection is being rejected because the target server is not aware of the user trying to connect or that user has not been added. Check to see if the process owner of your local IIS instance is a valid ingres user. IIRC the account name is normally something like IUSR_MACHINENAME, where MACHINENAME is the hostname of your IIS box. Add the user account using the following SQL on the server:
echo "create user IUSR_MACHINENAME\g" | sql iidbdb