I have a really simple umbraco 7 installation which i recently moved to a new server. Fronten is working fine, but /Umbraco has stopped working and I'm not sure how to fix it.
Screenshot is what chrome is showing me.
All help is much appreciated.
I have checked permissions, removed TEMP files, iisreset ... so far, no luck.
Ensure that you have the proper DLL's corresponding with your version of Umbraco. In the past, I have seen people try to upgrade manually, then when they rebuild in Visual Studio, NuGet has an old version of the Umbraco binaries referenced and replaces them silently.
You can do this with a tool like WinMerge, by the way. Download the Umbraco ZIP file (for your version of Umbraco) and compare that bin folder with the one in your website.
Since /umbraco/Application seems like a dynamic route (as opposed to a static file), I suspect it's an issue with the DLL's.
Hi Nicholas
Thanks, that tool could come in handy.
However, this installation worked perfectly on another server. Stopped working after it was moved to a new server. No DLL's have been tampered with. Simply a copy.
I took a copy of the whole site to my local machine and everything works fine here. Not a single change has been made to any configs.
Guess it must be a server configuration thing then.
At least now I have something to compare it with.
Will post update once I have located the issue.
/Umbraco not working after moving to new server
I have a really simple umbraco 7 installation which i recently moved to a new server. Fronten is working fine, but /Umbraco has stopped working and I'm not sure how to fix it.
Screenshot is what chrome is showing me.
All help is much appreciated.
I have checked permissions, removed TEMP files, iisreset ... so far, no luck.
It would be worth checking your file permissions on the new server. Make sure all file/folder permissions correspond with https://our.umbraco.org/Documentation/Getting-Started/Setup/Install/permissions
Hi Gary
Thanks for replying. I tried that - No luck. It's giving me a 404 on the /umbraco/Application? ..... as shown in the screenshot above. Really weird.
Ensure that you have the proper DLL's corresponding with your version of Umbraco. In the past, I have seen people try to upgrade manually, then when they rebuild in Visual Studio, NuGet has an old version of the Umbraco binaries referenced and replaces them silently.
You can do this with a tool like WinMerge, by the way. Download the Umbraco ZIP file (for your version of Umbraco) and compare that bin folder with the one in your website.
Since /umbraco/Application seems like a dynamic route (as opposed to a static file), I suspect it's an issue with the DLL's.
Hi Nicholas Thanks, that tool could come in handy.
However, this installation worked perfectly on another server. Stopped working after it was moved to a new server. No DLL's have been tampered with. Simply a copy.
In that case, could be something funky about the setup. Would be worth comparing IIS for both installs.
One thing to pay attention to in particular is if you setup Umbraco in a virtual directory, which doesn't play nice last I heard.
Might also be worth looking at the application pool to see what .Net version is being used.
What specific version of Umbraco is the install?
Unforturnately I don't have access to the old server any more :( I thought I was done with it so it was taken down.
Application pool is running clr. 4.0
Umbraco version is 7.2.8 (DLL version)
No virtual directories.
Well ... site is no secret. It's my own website. Troubled URL: http://www.thomasvestergaard.com/umbraco
Frontend works fine.
It looks like maybe you have some URL rewriting rules in place. You may need to add some conditions to negate certain paths in those rules.
For example, here is a default rule added to the Web.config by IIS for adding a trailing slash:
Adding this condition will negate that rule for certain requests:
I was unable to find any specific URL rewriting rules. anywhere.
I took a copy of the whole site to my local machine and everything works fine here. Not a single change has been made to any configs. Guess it must be a server configuration thing then.
At least now I have something to compare it with. Will post update once I have located the issue.
Alright, found out what was wrong. Turns out .NET 4.5 was not registered in IIS. Apparently rendering the frontend is not dependent on this.
Quite strange behavior. Found out that no .NET 4.0 ISAPI filters was present.
Thanks for pitching in guys!
is working on a reply...