I have recently been trying to migrate some websites from a 2003 server with IIS 6 to a 2012 server with IIS 8 installed. I am using Microsoft's Web Deploy tool and have been successful in copying a few web sites one at a time using the following command (changing the site identifier # for each site).NOTE: The reason the mumbo jumbo with replacing the drive exists is because our new server has a different data drive on it, and MSDeploy didn't like that. Could that be breaking things as well?
msdeploy -verb:sync -source:metakey=lm/w3svc/#,computername=SourceServerNameHere -dest:metakey=lm/w3svc/# -replace:objectName=metaProperty,scopeAttributeName=name,scopeAttributeValue=Path,targetAttributeName=value,match="F:",replace="E:" -enableLink:appPoolExtension > migration.log
The main issue is that when I try to navigate to any site one of three errors happens..
1. 503 Service Unavailable
2. 401.2 Unauthorized
3. 404.17 Not Found
These errors start from 1, and progress to 3 as I am trying to troubleshoot the IIS configurations. But this kind of defeats the purpose of using the Web Deploy Tool. Has anyone had any luck migrating sites being completely successful, or does the tool not actually support "IIS 6.0 or higher migration?"
Thanks in advance.
EDIT: So I have been able to get the main page of my site working by reverting the Handler Mappings and Default Documents to their parent configurations, and making sure that the AppPools don't conflict with versions, etc. The problem with this, is that I have to figure out how to do this for every app and app pool under the sites... Does anyone else have a similar problem?
Try using the iisApp provider instead of the MetaKey provider. For example,
msdeploy -verb:sync -source:iisApp=Site1/ContosoApp,computerName=Server1 -dest:iisApp="Site1/ContosoApp",computerName=Server2
https://technet.microsoft.com/en-us/library/dd569054(v=ws.10).aspx
I ended up contacting Microsoft Support to get this sorted out and ended up spending 3 hours on the phone with them...There were multiple issues that came up during the deploy tool's migration.
The bulk of the issues were corrected by changing the application pools to 64-bit and commenting out abomappercustom handlers in the applicationhost.config.
Related
I have a problem regarding White Screen Of Death (WSOD) at my site.
I will try to explain what I have tried until now.
I know it is not a triviel error to debug, but maybe some of you have tried something similar.
Here is the setup: One Windows Server 2019 v1809 with one IIS: 10.0.17763.1.
Multiple websites with associated application pools.
It's a MVC solution, and we are using .net 4.7.2.
What I have tried:
Recycled application pools every night
Restarted the server every night
Issued a IISReset every night
Deleted temporary files in C:\Windows\Microsoft.NET\
Looked at the IIS logs
Looked at the application log, our own log
Looked at the Windows log
Searched the Internet for similar problems
Made sure there always were some traffic at the website
Made sure no errors were shown when pressing F12 in the browser, the site always returs code 200
The WSOD comes at varies times, and not all the sites are affected at the same time.
A manuel recycle of the website always helps.
My question is, have any of you encounted similar problems?
And how did you solve it?
If you need more information please ask, and I will try to provide it.
/Regards Søren
This kind of problem is very unusual in IIS, because there is almost no record and useful information in the log file.
You can try to use this plan to repair IIS.
Unregister all the versions of ASP.NET with command "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis –ua". and the framework 64 also versions. 3.0 and 3.5... etc
Delete ASPNET account from "Local Users and Group – Users".
reregister ASP.NET with IIS using "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis –i". and framework64... net 3, 3.5 etc
Give permissions to the ASPNET account using "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis –ga machinename\ASPNET". for framework 32 and 64 and versions.
Reset IIS .
I have a very basic ASP.Net 5 application that I created following this guide https://www.asp.net/vnext/overview/aspnet-vnext/create-a-web-api-with-mvc-6, and it works grate from VS.
However I cant get that to work on azurewebsites. I keep getting the yellow runtime error page on the browser and this exception on the log file:
<EventData>
<Data>3005</Data>
<Data>An unhandled exception has occurred.</Data>
<Data>11/22/2014 9:39:33 PM</Data>
<Data>11/22/2014 9:39:33 PM</Data>
<Data>9e1c1ecb36f647ddb1f4b1856b2a105c</Data>
<Data>1</Data>
<Data>1</Data>
<Data>0</Data>
<Data>/LM/W3SVC/46675609/ROOT-1-130611659736590153</Data>
<Data></Data>
<Data>/</Data>
<Data>D:\home\site\wwwroot\</Data>
<Data>RD00155D431959</Data>
<Data></Data>
<Data>21084</Data>
<Data>w3wp.exe</Data>
<Data>IIS APPPOOL\glMigrations</Data>
<Data>DirectoryNotFoundException</Data>
<Data>
Couldn't find package 'KRE-CoreCLR-x86.1.0.0-beta1'. Locations probed:
D:\home\site\approot\packages\Migrations\1.0.0\packages\KRE-CoreCLR-x86.1.0.0-beta1
D:\home\site\approot\packages\Migrations\packages\KRE-CoreCLR-x86.1.0.0-beta1
D:\home\site\approot\packages\packages\KRE-CoreCLR-x86.1.0.0-beta1
D:\home\site\approot\packages\KRE-CoreCLR-x86.1.0.0-beta1
D:\home\site\packages\KRE-CoreCLR-x86.1.0.0-beta1
D:\home\packages\KRE-CoreCLR-x86.1.0.0-beta1
D:\packages\KRE-CoreCLR-x86.1.0.0-beta1
at AspNet.Loader.KRuntimeLocator.GetPathToSpecificKrePackage(DirectoryInfo appPhysicalPath, String krePackage)
at AspNet.Loader.KRuntimeLocator.LocateKRuntime(MapPathHelper mapPathHelper, Boolean& isCoreClr, String relativeAppBasePath)
</Data>
I tried with the core and the full version and got the same results.
Any advice will be appreciated.
I came across the same error when deploying to a local IIS server. The issue turned out to be caused by the project build settings not having "Produce outputs on build" ticked. I've just tried running my test project on Azure Website and managed to get it working.
I also had another issue deploying to the default "Free" plan website, as I was using the X64 KRE and only the "Basic" and "Standard" plans support X64.
I wrote a Blog Post on how I got ASP.NET 5.0 working on local IIS, which I've updated with the Azure website findings, as my rep here is not high enough to post pictures.
Edit:
In case the link to my blog post breaks the following is a basic description of the steps I took to get ASP.Net 5.0 running on IIS and then Azure Websites
Created an ASP.NET 5.0 Site using the Visual Studio 2015 Preview template running on Windows 10 Technical preview
For the local IIS I then ensured that IIS had all the required features, which you can obviously skip for azure
I then changed the "Build Settings" of the project to enable "Produce Outputs on Build" for both "Debug" and "Release" configurations
Next I updated the project.json file to use the url I had configured in IIS, again this may not be necessary for azure
I then created a Publishing profile to the local IIS server, which worked nicely.
Having seen this post, I then attempted to deploy to Azure by simply creating a new publishing profile targeting Azure Websites
I came across a similar error at this point, as I was targeting the X64 KRE, and the default Azure Website had been created as a "Free" site which does not support X64.
I then changed the Azure Website to the "Basic" plan, and enable X64 cpu.
Finally I redeployed using the earlier created Azure Publishing profile, Which this time resulted in a working site
OK, I've created an Azure Mobile Services project in Visual Studio 2013.
I run it up as-is, then in the browser I test it by adding a todo item via the simple browser app that seems to get baked into these service projects. It gives me a '201 success' message - brilliant.
I then convert the project from IIS Express to Local IIS as the web host, recompile and try again, and although I get the same smiley face app telling me that everything is OK, when I try and add a todo item I get a 404 error. This is contrary to the Microsoft article that gives these instructions, which clearly says I am able to choose either IIS Express or Local IIS when setting up the project.
My guess is that web.config is missing something when this project runs on the local IIS server.
I'm hoping someone already has a solution before I spend hours trying to work out how to configure IIS for this type of project.
I've already wasted a load of time working through loads of bugs and gotchas with Azure Mobile, and I'm starting to run out of steam - so I'm hoping someone can help me before I go and grab an account at Parse.com
Many thanks in anticipation.
Dean
The easiest approach for your situation might be to just deploy to the cloud, and use that service for your testing. Visual Studio 2013 Update 2 makes it easy to deploy your app and connect to it for remote debugging. It is a little slower than using a local instance, but you are also assured that there will be no surprises when you eventually go live (since you are live the whole time).
That said, we will investigate the issue you are seeing with using IIS directly. Some things you might want to try on your own:
Verify that you can view the web side from your Mac's browser, to make sure that the firewall is letting the requests through.
Try using the "Getting Starting" link from the smiley-face page, to see if the REST endpoints are behaving correctly.
I have a deployed a web application in IIS. Which used to work without any issues. Recently i have shifted that web application to another machine, Here is the problem. Once i setup the Webapplication when i opened the default document in IIS im getting the File not found error as following
Internal Server Error
\?\C:\inetpub\wwwroot\application\web.config
I have no clue why the IIS is not able to find the web.config. The file is present in the path C:\inetpub\wwwroot\application\web.config but the IIS is looking in the path \?\C:....
Please let me know how to resolve this??
Firstly this is documented on support.microsoft.com so I would suggest that anyone who has this issue read this first as it covers a number of solutions which I won't
Now from personal experience I encountered this error after setting up a new development machine. What I had forgotten to do was install the Url Rewrite 2.0 IIS module. Sadly the IIS error gives absolutely no idea that this is the actually issue.
Therefore to solve this issue investigate the system.webServer setting in our web.config and ensure that you have installed all the iis modules that you use. I did this by systematically removing elements from my web.config until I came across the cause.
In my case, I was running ASP .NET Core website so I had to install .Net Core Runtime from
https://dotnet.microsoft.com/download/dotnet-core/current/runtime
I know it's old post but I resolved the same issue as follows:
If you are using TFS and you are getting this problem then Reason is ".vs" file is not excluded from commit.
Because of that ".vs\config\applicationhost.config" gets the local version of another user/Developer.
To Solve the error, First open that file Update Physical path inside "" xml tag.
Also ask user to exclude this folder from TFS to prevent future issues.
If you are getting mysql localhost error. What I will do will work for you.
Control Panel(View by: Large Icons) >> Programs and Features >>
(Usually upper left corner) Turn Windows Features on or off >>
Internet Information Services >> Web Management Tools and World Wide Web Services
After Restart.
So I figured out that by adding the ResetWebServer="FALSE" attribute to the solution manifest prevents SharePoint from recycling any app pools.
However, when upgrading a solution that originally did not specify ResetWebServer="FALSE" or when retracting a solution that does specify ResetWebServer="FALSE", the application pools are still being recycled. Is there a way to prevent any auto-recycling of app pools?
This does not seem possible given the document on MSDN (see below), note that I included Deploying a Solution over Upgrading a solution as underneath it is effectively doing a file replacement. I believe the restart/recycling is necessary as a result of how IIS functions. An option to explore if you wanted to manage when this occurs is to ensure that all deployments are done via timer jobs and execute when their impact will be minimized.
Deploying a solution
Initially, manifest and feature manifests are parsed to find assembly and _layouts files, which are copied to the appropriate locations. All other files contained within a feature directory are copied to the feature directory. After solution files are copied to the target computers, a configuration reset is scheduled for all front-end Web servers; the reset then deploys the files and restarts Microsoft Internet Information Services (IIS).
Retracting a solution
On each front-end Web server, the following occurs:
Microsoft Internet Information Services (IIS) is disabled.
Files are removed from the system.
IIS is re-enabled and Windows SharePoint Services is reloaded when
a user browses to a page.
You might also take a look at the "-local" switch. Didn't try it yet but it seemed that it allowed deployment server per server when you are in a load balanced situation.
Might be a good lead.