I'm migrating a web server to another server. Currently both web servers are working. They are using the same physical path. I have one of my sites (coded in asp) which uses server side includes for asp. The issue is that the old site is working fine in terms of SSI, however the new site is not. The new site is showing some code instead of loading the included file. I checked to make sure that all IIS settings are the same and everything looks the same. Appreciate your ideas to find out what else that I missed in IIS settings. (I assume the code is correct since it is working fine for the old server)
Related
I need to migrate an old .asp site onto our new server (Server Essentials 2016).
The site runs off an Access database and is currently hosted in IIS on a windows 7 pro machine.
I have enabled asp.net 4.6 on the new server and copied the whole website from the old server (Windows 7 Pro) into an equivalent directory on the new server, (C:\inetpub\wwwroot - I know it's not best practice to store the site here but I am eliminating variables to get the site working - once it works, I'll move it...).
Plain HTML pages now work fine, so the sites folder is clearly accessible but any page that needs to access the database gives an error 500 - both from the server's own browser and from other PC's on the network... The site and it's database are both in the same wwwroot folder and have an identical filepath to that on the windows 7 machine so the only thing different is the computer name and OS.
I have multiple other (php) sites running on the new server but cannot get this asp site to work!
What am I doing wrong? Short of rewriting the whole site in php I'm stuck!
Thanks in advance!
Fixed it, I needed to change the connections file from "Provider=Microsoft.Jet.OLEDB.4.0;" to "Provider=Microsoft.ACE.OLEDB.12.0;" None of the error messages hinted at this but we got there in the end!
So to recap for anyone else in this situation:
Step 1: In IIS highlight the site in the left hand pane and double click the "ASP" icon, then change "Enable Parent Paths" to "True"
Step 2: Download and install the Microsoft Access Database Engine (https://www.microsoft.com/en-us/download/details.aspx?id=13255)
Step 3: Change the code in your connections file to "Provider=Microsoft.ACE.OLEDB.12.0;"
Thanks for the guidance!
I am trying to set up my Windows Server 2012 to run an ASP.NET website. The website can serve html pages and .svc pages, but whenever I visit an .aspx page, it will simply time out.
Error 118 (net::ERR_CONNECTION_TIMED_OUT)
If I would at least get some sort of error description, I could go from there, but I just get a timeout message, as if the server is completely unavailable, so I am stuck with this problem.
It seems the aspx pages are not loaded at all, since I've already tried drastic measures such as putting a "throw Exception" in the first line of Page_Load.
If I create a new site and put just an aspx page in there, it executes fine.
The Event Log is not showing anything in relation to this.
Does anyone have any suggestions?
Creating a new web site in IIS8 and pointing to the same folder made it work. Now the site is working fine and running code as normal.
My guess is, that if I created the website before installing all needed features, they were not part of that site. Now, after installing a new site, it contains all the current features.
It doesn't make TOO much sense, though, as the server had ASP.NET 4.5 from installation (it's Windows Server 2012).
Open up the Web Platform Installer.
Now look for IIS: ASP.NET 4.5 and install that.
I had the same problem as everyone else and nothing worked until I did that.
There is a difference between installing dotNET on your computer/server and dotNET for IIS.
I try to configure IIS 7.5 on a new server (Windows Server 2008 R2), in order to run an ASP.NET 4.0 application. Two "domains" are defined on the server (managed with Parallels Plesk), each one appearing as a site in IIS. One domain is for the public site, the other is used for tests. At the present time, the DNS of the test site points to that new server while the DNS of the public site still points to our old server. We transfer the test site first, to see if everything is OK, before transfering the public site to the new server.
Pointing to the test site in IIS, if I run the Browse command on the folder of the application, I get the HTTP Error 403.14, with the message: The Web server is configured to not list the contents of this directory. The strange thing is this: if I put the exact same folder structure in the other domain on the same server, and I run the same Browse command, I see the default page of the application (I don't know if everything works after that but, at least, the first page shows up as expected). I should add:
Both sites use the same application pool.
Both sites have the same permissions (I checked one by one, also compared with cacls)
The default page is not set in IIS but is the authentication form specified in Web.config
So, same setup but different results. I don't know if there is something else that I should check. I am on very shaky ground when I talk about server configuration and IIS; so I hope that this description is clear enough and makes sense.
I think I found it. It probably doesn't work for both sites on the new server. When I run the Browse command, it shows the page in IE using the DNS of the site. Since the DNS of the public site still points to the old server, the page displayed in IE is not from the folder that I clicked, but rather from the old server site.
I can now look for standard solutions to the 403.14 problem on the new server...
I have a WebForms application hosted in IIS 7. When I run the site from Visual Studio 2010, my static content all loads perfectly. We have the same site hosted in another production environment and the site works great there also.
However, when I am trying to host the site in a new production environment, it is giving me a status code of 302 Found whenever it attempts to load the static content.
When I open up Chrome's Developer Console and look at the network, it shows this:
/login.aspx?ReturnUrl=%2fjs%2fjquery.js
This leads me to believe that something in IIS7 is forcing authentication to occur on static content. Is there anything I should check to see what the likely cause of this problem is?
Ok, for whatever reason, I had to add the IUSR user and give it access to Read on my web apps. I am not sure what changed that made this a requirement. If anyone knows, please feel free to add comments.
If you set the same permissions as for wwwroot folder the problem disappears:
Users and IIS_IUSRS - read access
My setup:
Vista 64-bit PC (my local PC)
IIS 7 obviously
VS 2008
I setup a new "Application" manually under the IIS default site. It's running.
The application is pointing to the correct directory (where my default.aspx exists)
I've setup this same exact setup on our dev server running Server 2008 and it runs fine
But for me, when I go to http://localhost/MyAppName I get a 404 not found.
I have no clue why.
So since that did not work and still got a 404, then I tried instead changing from using the VS web server to using IIS in my web project properties in the "Web" tab in VS 2008. Then clicked the "Create Virtual Directory" button and it created a new Application in IIS for me. Same thing though. If I go to that address, I get a 404 on my local machine where it's running.
Ok, I had not installed the IIS 6 functionality of IIS in Vista. I did not know it still used legacy features in IIS 7 to run sites locally....I guess. Not sure why but I guess it uses these IIS6 features. Will have to research why it's dependent on this stuff.
Do you have the home directory to look for "default.aspx" as the default page?
A couple things to check:
First, look at your access logs to see exactly what request is getting logged.
Check your IIS config - you may have a default.aspx page, but is IIS configured to use that as one of the default pages? If you go to http://localhost/AppName/default.aspx do you still get a 404?
If you put a static test.html file in the same directory, can you access it?
These should all help determine the cause.