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.
Related
I have written an ASP.net website that gets the machine name from the person browsing the website using
sName = System.Net.Dns.GetHostEntry(Request.UserHostAddress).HostName.ToString
If I publish this to a web server on our local network, it works fine.
We also have an Azure server and I want to publish it to that server, but it does not return the machine name. We have the Azure server connected to our local network via a permanent tunnel.
I'm assuming that the code can't resolve the name as it can access the DNS on the network. Is there a way around this?
Thanks
Gareth
AFAIK, Our app will not work with Azure DNS Private Zones automatically. To work with Azure DNS Private Zones we need to add the below in app settings:
WEBSITE_DNS_SERVER with value 168.63.129.16
WEBSITE_VNET_ROUTE_ALL with value 1
For more information please refer this MS Q&A as suggested by # didier3001
And this for use Dns.GetHostEntry Method
I'm about to deploy an ASP.NET web application for testing in production. Essentially, this is just a table that is linked to a SQL Server table/view that is obviously dynamic when the data in the tables are updated.
I have a hosting plan with a site that I'll be pushing the files to, which includes a SQL Server database in the hosting plan. I also host a SQL Server instance on the network.
My question is, what is the standard way of dealing with SQL Server in this deployment? I think I have the options below, but as someone who has only ever developed applications offline, this is new to me, so please excuse my novice ignorance.
Have the application connect via IP address in the connection string to my SQL Server instance, as specifying the server name (SQLDEVSRV01 for example) won't be on the "network" when it's sitting in the site's FTP. Am I to assume my connection string will only work on the network, and once deployed to a website, will cease to function unless connecting via TCP/IP?
Host the server on the web in the same site host location. So upload the site files to my website host and setup the SQL server there. Would I be able to just specify the Server name (SQLDEVSRV01 for example) in the connection string there, as whilst it wouldn't work in development as it wouldn't be on the same network, it would then work once deployed on the web?
Embed a SQL Server instance within the app using localdB or something similar to hold the background data. If this is the case, can the data be accessed from the backend, either using SSMS or some other method?
Essentially, my aim here is to have the web app retrieve the data live from a view/table hosted in SQL server, where the backend data can be amended, manipulated and updated independently of the app, so the app can just pull the data when refreshed.
The standard way of doing this is to deploy your database to the hosting providers SQL Server instance and then connect your app to it using a connection string with their details. As it is normally a shared instance you do not have to normally worry about having the SQL instance machine patched etc.
Personally I would not be installing SQL Server myself unless I decided there was benefit to having an instance I wanted the control over nor would I be changing the structure or implementation of my application to suit a hosting providers setup.
I have an ASP.NET 2 (very old) web app that I am trying to migrate to a new server. BTW, I am a complete ASP.NET noob but have a good amount experience with other web technologies.
In the web.config, I can see the following connection string XML:
<connectionStrings>
<add name="myCon"
connectionString="Data Source=DEVELOP\DEV_SQL2008R2;Initial Catalog=QO2_New;Persist Security Info=True;User ID=sa;Password=q"/>
</connectionStrings>
I did "nslookup" on the machine name 'DEVELOP' and RDP into the server. To my surprise, I don't see any SQL Server process running. Also, there is no SQL Server installed on that server. I am 100% that the app is running and I am very confident that there are content that comes from the database. I also did a search on the code base and it seems like the connection string is being used.
On a side note, we do have some other databases on separate machines. My questions are the following:
Can the machine DEVELOP somehow redirect the DB connection to somewhere else? If yes, how do I find out which IP is it being redirected at?
If DB connection cannot be redirected, then what is going here exactly?
Unfortunately, I have very little people whom I can ask what is going with this app. Any tips that you can share is much appreciated.
Nslookup uses DNS but there is a chance your machine has a hosts file entry that points DEVELOP to somewhere else..
However, if you RDP'ed into DEVELOP (as in, used that name when connecting RDP, not the ip address given by nslookup) then you should have been able to see a sqlserver install in the list of services.
If there is surely no sqlserver installed there then, from within your RDP session, use TCPView from sysinternals to see what process is listening on port 1433. Could be some kind of TCP redirector like PortTunnel from SteelBytes, bouncing the connection somewhere else. Remember to run tcpview on the server, not your local machine
Perhaps you can try getting connected to the sqlserver using management studio, using the credentials in the web config, you can get sqlserver itself to tell you more about where it is running, such as:
SQL - Query to get server's IP address
Using Environment variables in T-SQL
I am truly ashamed to inform everyone that the database in the web config was never being used. Therefore, even though it is pointing to a non-existing database, it still works. The data from the old database have been converted to static files.
I should have checked this the first thing I came across it. Thanks again for all the help.
I'm trying to connect and getting an error like:
Login failed. The login cannot be used with Windows Authentication
I'm using mirrored local accounts on SQL Server and web server because I'm simply trying to use a trusted connection between machines not on the same domain. It seems like something that would be fairly common, but after days of trying to find an answer that applied to my situation, I do not recognize that any of the answers were applicable... that or the fact that I'm only a .NET developer and not a sysadmin or DBA means I have it and just don't know it.
Here's what I can say:
CMS web server: ASP.NET 4.0 web app running on Windows Server 2008, IIS7, on corporate DMZ
CMS database server: SQL Server 2008 R2 on a domain server
For various reasons that I won't go in to, encrypting the credentials is not sufficient.
The database port that the application needs to connect on is not the standard port and is set up to listen on a different port.
Setting up DB mirroring isn't an option and doesn't really address the requirements (in my way of thinking)
Also, FYI if this is helpful to know:
Content entry happens on internal web server which publishes content to same DB that is accessed by the DMZ web server.
Content server is set up to have the website run the app pool in integrated mode with a windows domain user that has been set as a service account using the -ga switch and given all the appropriate rights and everything runs perfect.
External web server, without domain access, using mirrored accounts (same username and password set up on the SQL Server machine and web machine).
Local account on the web server set as a service account using -ga switch and running as the app pool identity for my app.
On the SQL Server box, created local user with identical creds and given same permissions that the domain user identity has
Connecting to SQL Server via MGMT studio installed on web server with the SQL Server user creds works fine.
Now, if I put in the username in to the connection strings, everything is perfect. As soon as I put the trusted_connection=yes in the connection string like I did with the domain server connection strings, I get the trust error.
So if my connection string is like this, it works fine:
Server=myServerAddress;Database=myDataBase;Username=MyUser; Password=MyPassword;
If I change my connection string to either of these, it fails:
Server=myServerAddress;Database=myDataBase;Trusted_Connection=True;
or
Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
I'm working with one of the client's network admins and he's not necessarily a DBA and doesn't have experience with configuring web apps. So it's possible that we're missing something and any advice or ideas would help. What am I missing?
If using SQL credentials are not an option, then you should use Active Directory and create a one-way trust (have DMZ server domain trust your internal domain), create a service account in your internal domain which your DMZ application can use, and grant that account access to the database. Then it will be able to generate SSPI context.
Our website connects to a database correctly when running the website locally using the built-in web server. But, when we deploy the site to our server running IIS, we get a database connection error. The database server is different from our IIS server. Note that a trusted connection to a different database on the SAME server as IIS works fine.
What do we need to do to connect to a SQL database on a different server with a trusted connection?
When you're running a web site using Cassini, the account used by the web server process is your own account that you use to log on to your Windows machine. That account will be different on IIS.
Consider the security implications of opening the database up to a broader access than you may need with trusted connection. Perhaps you could use Windows authentication with a service account. That is, create an application-specific user in SQL Server with limited permissions. Then, you will get the benefits of connection pooling while avoiding passing credentials.
I'd check the user account that app domain in IIS is using to connect to SQL Server. The account in IIS may not have access to network resources as well which would explain the trouble reaching the other database server.
Sounds like you need to configure the database server to provide access to the database you're trying to connect to.
Assuming SQL Server, log into SQL Server Enterprise Manager and under Security -> Logins, open the properties for the applicable user (probably the Network Service or ASP.NET account of the web server) and go to the Database Access tab and ensure that the Permit checkbox is ticked for the database you are connecting to.