When I go to enable Shared Configuration in IIS 10 on Server 2022 and point it to my configuration folder and enter the encryption key the interface just hangs. There are no entries in event viewer to give any indication what happened. I have to kill off the IIS Mgr process. The server I used to "export" the config is also IIS 10 but on server 2019, in case that matters.
As a test I tried exporting the config on the Server 2022 host and pointing Shared Configuration to that and it worked fine. So there must be something about the config export from the other server it doesn't like. I've ensured that all the same IIS features are installed on both servers. Same SSL certificates are available and the same wwwroot is available.
Any ideas what might be going on? Thanks.
OK I figured this out and wanted to report back in case anyone else has this issue down the road. Through more troubleshooting I traced the issue down to the configEncKeyAes.key file that's generated when you export your IIS config using the tool in the IIS Shared Configuration window.
I found that if I exported the config on the destination server and just used the key file generated and retained the configuration files from the source server the Shared Configuration would finally apply without freezing. All sites came over as expected. The only issue is any credentials saved in the config (e.g. custom AppPool credentials) could not be decrypted and had to be reset. This made sense since I was using a different key file than the one generated with the original export on the source server.
This led me to the site below that talked about the need to export the IIS WAS and Configuration Keys from the source server and import them on any other IIS nodes at play. Doing so immediately fixed the issue and the shared configuration applied without issue and the embedded credentials I had on a couple sites carried over as well.
https://byronpate.com/2014/08/troubleshooting-iis-shared-configuration/
I've read several articles about deploying Shared Configuration and none of them mention this seemingly necessary step. But I'm finding that documentation and support around this feature leaves much to be desired.
Related
Using the instructions in this link and the "How to Deploy Klondike"
github instructions I have installed the Klondike release on my local IIS (Version 10.0.15063.0). At first it looked promising, but then I realized that the main page is showing "loading..." rather than the Klondike URL. See image:
Additionally the when I click the API page tab, the site navigates to http://localhost:8081/api which returns a 404.0 HTTP error. This error may not seem very surprising as the site's directory does not contain an api directory. However, I have reverse engineering a working server with Klondike configured on it and it also does not have the api directory. Here is an image of the 404.0 error:
Additionally, when I try to nuget pushto localhost:8081, it results with the error in the image here (note, the red blocked out text is the apikey).
Finally, I have left the handleLocalRequestsAsAdmin is set to true, but even though I am on localhost, it does not show me the "LocalAdministrator" link. I believe that all these symptoms are linked to the same issue.
I have tried the following with no affect on the behavior:
Putting this site in c:\inetpub\wwwroot and also in C:\Klondike;
Using different port numbers, such as 8081 and 80;
Putting a 127.0.0.1 alias in my hosts file and binding the value in IIS to the host name; and
Installed the Debugging tools for Windows install as was suggested on the github site and set the debuggingToolsPath to its path.
(at this point, I'm just guessing at the issue)
The settings I have changed in settings.config file are as follows:
packagesPath = C:\Klondike\App_Data\Packages
Left lucenePath = empty string (I also tried this with a value of C:\Klondike\App_Data\Lucene with no affect.
symbolsPath = C:\Klondike\App_Data\Symbols
debuggingToolsPath = C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
ignorePackageFiles = "true"
I have not changed any values in the web.config file from the default web.config release values.
Thank you for any help that you can provide.
I ran into the same problem, although I was installing Klondike on a remote server rather than locally, but still IIS 10. The problem might be you don't have all the IIS components installed or enabled. More specifically, .NET or one of its required components might not be installed or enabled. If you look at the error on the /api link - it has to do with the MapRequestHandler and Static file handler in IIS - this indicates IIS doesn't know how to handle the request, which is an indicator you might be missing the ExtensionlessUrlHandler in IIS, as well as other components. To solve the problem, go to Start -> Control Panel -> Turn Windows features on or off (varies per system, might be under "Programs and Features"), then find the IIS Application Development Features. These might be listed under Internet Information Services -> World Wide Web Services, or Web Server (IIS) -> Web Server, depending on your system. Once you find these Application Development Features, make sure you have an ASP.NET option checked - you might just want to check all the options. Below is screenshot of what it looks like on my system. You might want to reboot after adding those features - not sure if a reboot is required, but it doesn't hurt. After you enable those features, you might start to run into all kinds of file permission errors when running the Klondike app - you might want to just remove Klondike and reinstall it from the zip file. I have a feeling it Klondike doesn't run cleanly the first time it has problems, as it needs to create an App_Data folder with sub directories.
I've setup a UNC share for IIS shared config using a specific AD service account and set to FULL CONTROL. I've also exported the config from one IIS server and set-up an additional IIS server to point to the share. When I open the applicationhost.config for example on the UNC share and remove an application pool, I can see the entry also remove in both IIS servers.
So I know:
1) I can export to the share with the specific service account
2) Both IIS servers can read the config when I edit manually
3) However when I remove an app pool from one of the IIS servers through the manager I get the above error.
I've tried using the process monitor utility to see what account is being used to write to the config and it seems it is my own AD user account rather than the shared service account. I know IIS Manager has my username e.g. ROOT\MYNAME logged on, but I wouldn't have thought it would use this to write changes to the shared config. Surely it would use the service account?
Does anyone know how to prevent this error? Why does the shared config and tied service account not come into play when making changes on one of the servers?
So, IMHO, this error is a red herring. I was publishing to a server and got a message saying I was out of space. So, I logged in, realized there was a bit of cruft in extra apps published in IIS, we didn't need. I right clicked and tried to remove one. I got the same error as you.
Having done some manual changes to applicationHost, I thought it "might be me" but it seemed very odd that editing this file would cause such a thing. However, I had recently learned that windows does some funky 32 vs 64bit machinations with this file (google it).
Deciding I had better things to do, I asked our IT to add space to the VM and guess what? I am no able to remove these apps. My guess is that I was at the end of the line on space and the backend management of these special files was not completing and throwing this not-so-helpful exception.
I'm not a 100% about this. For full disclosure, I will add that updates had been applied recently, but I'm pretty confident that this is a possible solution.
I have three web servers running Windows Server 2008. Two are clustered, the third a standalone server (two live, one test). They use shared configuration with the configuration file located on a central file server. Every so often one live web server will stop responding. The event log shows the following error.
The worker process for application pool 'My Website' encountered an error 'Configuration file is not well-formed XML
' trying to read configuration data from file '\\?\C:\inetpub\temp\apppools\My Website\My Website.config', line number '3'. The data field contains the error code.
The config file has the following data
<!-- ERROR: There's been an error reading or processing the applicationhost.config file. Line number: 0 Error message: Cannot read configuration file
-->
There is nothing in the event viewer on the file server.
When I restart the web server everything works fine.
Any ideas?
Edit
I have around 30 websites. 10 are true standalone websites running in their own application pools. The other 20 are old websites that just redirect all requests to a different URL (some on my server, some external), these share the same application pool.
One of the 10 "standalone" websites is running php. One is .NET 2.0. One is classic asp with two virtual directories set up to run as a .NET 2.0 applications. The other 7 are running classic asp only.
It's quite old but I came here because I had this issue today and it seems to be still around. The reason is usually the DFSR feature, which is especially valid if one runs a cluster. There are three possible solutions.
Change a registry key to reduce the speed of synchronization and avoid the file lock the leads to the error as described here: https://blogs.msdn.microsoft.com/asiatech/2013/12/01/you-may-experience-configuration-file-is-not-well-formed-xml-error-while-using-dfsr-to-synchronize-the-iis-configuration-files/
Install a Hotfix provided by Microsoft. The direct link is https://support.microsoft.com/de-de/hotfix/kbhotfix?kbnum=960412&kbln=en-US
Configure your DFSR environment properly and exclude the folder *\inetpub\temp\apppools* explicitly (after DFSR replicated the applicationHost.config the WAS will rebuild the files anyway)
Despite the Hotfix I personally like the third option most.
The purpose of this late answer is documentation, as others may come here and the page seems well ranked on Google.
This is a long shot but...
If the file is accessed through netbios and its regularly accessed you may be hitting the fileserver too hard and windows thinks you are trying to do a DOS attack so it starts rejecting requests. This may also be caused by a firewall interpreting this very samething when accessing the file server.
Also, from this, check you that the temp folder for the iis user is full, the problem may not only be the file server, but failure to temporary store the config file.
Can you share some volume information of your server layout? (# application pools / # websites , etc)
Edit:
I assume you're not interested in workarounds to this, especially if it means changing the location of the file :)
I have a web application project in VS2012 which I'm publishing using a "Web Deploy Package". I want this package to include app-pool settings, specifically creating an IIS app-pool and assigning the newly created application to it.
I'm familiar with the option "Include application pool settings used by this Web project" available when the project is configured to use an IIS instance (not IIS Express), but IIS configuration is not part of the project file, and thus not source controlled. What happens when somebody builds a deployment package on a machine that hasn't had IIS meticulously configured? Not ideal.
How else then, can I go about getting AppPool settings into my web deploy package? I understand that the appPoolConfig provider is IIS7+ only, I'm fine with that limitation. I've banged my head against this issue in the past and never found a solution. 18 months later, we've got a new VisualStudio version, and a new web-publishing-pipeline, are there new options to address this? Or maybe something I missed when I first tackled this problem?
Edit
OK, I'm seeing the following as options:
Configure my project to sync settings from an IIS instance. As mentioned, I'm not a fan of this given that it puts settings outside of the project, meaning the environment has to be meticulously configured to build + publish. Plus it drags along other IIS settings I don't want included.
Inject something into the web-publishing-pipeline (WPP) to modify the archive.xml. I've toyed with this in the past and had limited success. One problem is the pipeline isn't exactly co-operative with working directly on the archive.xml file, another problem is some of the more cryptic attributes involved, like MSDeploy.MSDeployProviderOptions which appears to have some Base64 encoded binary? No idea what to put in there.
Find an existing "provider" that can do what I want. I might be out of luck here, the appPoolConfig provider only seems to want to read / write IIS, not, say, an XML file of settings. Does anybody know otherwise?
Write my own "provider" to produce manifest output entries. I'm not sure, is it possible to write a custom provider that writes to a manifest using the name of an existing provider? As in, MyCustomPoolProvider writes appPoolConfig sections into a manifest? This sounds like a potentially painful exercise that may or may not work. Would I still need to figure out the encoding of whatever is going into MSDeploy.MSDeployProviderOptions?
I get the feeling that the fundamental obstacle with Web Deploy for what I'm trying to accomplish, is how strictly it leans on "providers". The pre-existing providers are largely designed for IIS synchronisation, not primary development and publication. It so happens that some of these providers can be relatively easily hooked into via MSBuild, but the majority insist on pulling data from IIS, and that's that.
You are correct in your understanding of the appPoolConfig provider, in that it can only sync between App Pools and can't be provided with the configuration directly. What you could potentially do is keep a copy of the appPool in question in package form (ie. msdeploy -verb:sync -source:appPoolConfig=PoolName -dest:package=apppool.zip) and attempt to hijack the pipeline so that the MSDeploy call adds the application content into the package, leaving the existing content there.
Alternatively, you could always keep the packages separate and deploy them with different calls to MSDeploy.
FYI, MSDeploy.MSDeployProviderOptions is simply an encoded version of the parameters supplied to the provider when it was packaged. For example, -source:dirPath=c:\,ignoreErrors=0x10293847 -dest:package=package.zip would package the ignoreErrors value.
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.