I'm really hoping somebody can help apply some sanity to this IIS issue that has been driving me crazy. I seem to be experiencing the same problem as the poor soul in this thread: https://forums.iis.net/t/1240175.aspx.
NOTE: I posted this earlier today on Superuser - I realized there is a large base of IIS-tagged questions on SO so thought I'd also post here.
OS:
Windows 10 Pro 64-bit 2004 19041.508
Problem:
Basically, IIS will not serve static content over a certain arbitrary size - static files over that size will just timeout eventually. Non-static content, for example asp files do not have this limit and load as expected regardless of size. This started happening seemingly out of nowhere with no directly related IIS/system/network/permission changes.
Things I've Tried:
Yes, static content is turned on!
Same thing, every browser
Completely virus/malware free
Disabled ad blocker/anti-virus/firewall/etc.
No proxies (except when Fiddler is running)
Completely removed IIS (disabled feature, moved \inetpub and \windows\system32\inetsrv) and re-enabled feature which recreated them)
Checked logs, enabled tracing
SFC scan clean
Checked permissions, toggled app user between IUSR and domain user
Details:
About a 1 or 1.5 months ago my local IIS stopped working, out of the blue. By out of the blue I mean the the previous day it was working fine as always and the next it stopped - without having done any system changes whatsoever. By stopped working I mean (eventually realized) that it was only static files that were not serving correctly. Unfortunately/fortunately, I noticed the problem because I had created the obligatory personal COVID tracker. It was html/js running against a .NET API back end. The pages stopped loading and I spent time wondering what I had borked in the code (which I also hadn't touched).
Eventually I realized no static content - images, css, js, html, txt etc. - was loading properly. I ran some tests and I found that there was a cutoff point in size of content that would load, but it is somewhat arbitrary. For example, the iisstart.png image in the default IIS website does not load - it's 97K. I replaced it with an 8k file that loads fine. I could get about 1500 bytes served in an html file - 1501 bytes would send it off the rails but 1500 worked. Same sort of thing was found for text files although I was able to send more than 1500 bytes - don't remember how much but did find a point where a 1 byte difference caused a problem.
Test Load of Default IIS Website:
IIS log is not helpful - it reports the failed attempt as a 200 but says it took 19 seconds. It is returning a win32 status code of 121 though:
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2020-10-23 13:36:12 127.0.0.1 GET /iisstart.png - 80 - 127.0.0.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64;+rv:82.0)+Gecko/20100101+Firefox/82.0 http://localhost/ 200 0 121 18944
The tracing mostly doesn't fire I guess because the 200 is eventually returned?
Fiddler gives me this for the image request:
[Fiddler] ReadResponse() failed: The server did not return a complete response for this request. Server returned 0 bytes.
For this site the actual html loads fine - it's only 696 bytes - the image it references does not though (97K).
If anybody can shed some light on this or give me a direction in troubleshooting I would greatly appreciate it.
Thanks
Related
I have a Wordpress site running on IIS site which returns a hard 403 response for certain user agent strings (IE 6 - 10 and Firefox 33 Mac and Win). After some poking around by manually changing the user agent string I determined that the strings Trident/4 , Trident/5 , and Firefox/3 all cause this site to exhibit this behavior. There might be other combinations, but clearly this is something going on in either the code or the IIS level.
I've scanned the code at a high level and found some mentions of both Firefox and Trident, all related to user agent sniffing, but they appear to be core Wordpress files and not app specific code. I've been searching all afternoon and the only things I find mention of are telling the user to adjust the "directory browsing" settings in web.config. However I can replicate the behavior by directly accessing a static asset such as a CSS file. That tells me not only is it not related to directory browsing, but it's probably also not anything to do with application code.
Can anyone offer insight into what might be happening here? To head off questions:
We just noticed this behavior a few weeks ago, unsure of how long it's been going on.
I'll be checking access/error logs as soon as I can get them.
EDIT
Turns out that the previous developers had added some very specific URL rewriting rules for the site. They were explicitly returning a 403 for any user agent with the patterns I listed above, along with a few other generic patterns and some specific botnames. I knew it had to be something with the web server...we just had to poke around in IIS long enough to find them.
I have an issue on a node.js application running on an Azure webapp. After a random time of execution, the static files are put in error 404. But not all files.
For example, today I have a logo.jpg picture in my public folder public/images/. When the application is freshly started, no problem. But after 1h, sometimes 1 day, the same url will give a 404 error. By restarting the webapp, the problem is corrected for a time. 2nd precision, when I redeploy the missing file with ftp, the error disappeared, just briefly, (1 minute) before reappearing. Is this a cache error? My web.config not set correctly?
Thank you in advance for your help as I have been on this error for many days and I am beginning to lose hope.
I haven't been here for some time.. This time I think I have one of those "Rocket Science" problems, so shall I start?
alright, tl;dr - I started to work in a company as a Sysadmin and the last guy that I replaced really messed some stuff around and I'm spinning around trying to fix them..
I'm going to try to sum up everything in one post to avoid being asked the same questions over and over again.
The Problem:
I cannot access ECP/OWA, no matter which credentials I give it (and they are validated as correct vs Outlook itself) - Outlook works, ECP/OWA does not.
The error I get, no matter where I access it from (Internally / Locally) -
"The user name or password you entered isn't correct. Try entering it again."
- I think the problem relies within owa (Exchange Back End) / ecp (Exchange Back End), as I tried various solution suggestions I may have deleted the back end Virtual Directory to recreate them.
Some Info:
OS and Exchange: Windows Server 2016, Exchange 2016
Exchange CU Version: CU6
Logs & Debugging:
Event Viewer:
The Outlook Web App configuration settings couldn't be read and updated. Virtual directory: "owa". Web site: "Exchange Back End".
Error message:
"The Active Directory configuration settings couldn't be accessed for virtual directory "owa" under Web site "Exchange Back End"."
-> Source: MSExchangeOWA
-> Event ID: 64
--> Qualifiers: 49152
Image -
IIS:
W3SVC1 (Default Web Site?) + W3SVC2 (Exchange Back End?) log files don't say much actually , no indication of errors when I try to login. Here's a few lines I found (but its about health mail boxes);
2018-07-19 00:28:34 ::1 POST /owa/proxylogon.owa &ClientId=Some_Content_Here&ClientRequestId=&ActID=Some_Content_Here&CorrelationID=<empty>&userContextLogonIdentityName=DOMAIN_NAME\HealthMailboxc66d8b0&userContextLogonIdentitySid=Some_Content_Here&userContextMbGuid=Some_Content_Here&redir=lang 444 DOMAIN_NAME\HealthMailboxc66d8b0 ::1 Mozilla/4.0+(compatible;+MSIE+11.0;+Trident/7.0;+rv:11.0;+Windows+NT+6.1;+MSEXCHMON;+ACTIVEMONITORING;+EACBACKENDLOGON) - 302 0 0 3768
2018-07-19 00:28:34 ::1 GET /ecp/About.aspx ActID=Some_Content_Here 444 - ::1 Mozilla/4.0+(compatible;+MSIE+11.0;+Trident/7.0;+rv:11.0;+Windows+NT+6.1;+MSEXCHMON;+ACTIVEMONITORING;+EACBACKENDLOGON) - 401 1 2148074254 3
2018-07-19 00:28:34 ::1 GET /ecp/About.aspx ActID=Some_Content_Here 444 DOMAIN_NAME\HealthMailboxc66d8b0 ::1 Mozilla/4.0+(compatible;+MSIE+11.0;+Trident/7.0;+rv:11.0;+Windows+NT+6.1;+MSEXCHMON;+ACTIVEMONITORING;+EACBACKENDLOGON) - 302 0 0 82
2018-07-19 00:28:34 ::1 GET /owa/languageselection.aspx url=%2fecp%2fAbout.aspx&ClientId=Some_Content_Here&ClientRequestId=&ActID=Some_Content_Here&CorrelationID=<empty> 444 - ::1 Mozilla/4.0+(compatible;+MSIE+11.0;+Trident/7.0;+rv:11.0;+Windows+NT+6.1;+MSEXCHMON;+ACTIVEMONITORING;+EACBACKENDLOGON) - 401 1 2148074254 2
2018-07-19 00:28:34 ::1 GET /owa/auth/error.aspx url=%2fecp%2fAbout.aspx&ClientId=Some_Content_Here&ClientRequestId=&ActID=Some_Content_Here&CorrelationID=<empty> 444 DOMAIN_NAME\HealthMailboxc66d8b0 ::1 Mozilla/4.0+(compatible;+MSIE+11.0;+Trident/7.0;+rv:11.0;+Windows+NT+6.1;+MSEXCHMON;+ACTIVEMONITORING;+EACBACKENDLOGON) - 200 0 0 17
ADSI vs IIS:
You can see that there is no "owa (Exchange Back End) / ecp (Exchange Back End)", that might be the problem.. didn't have time to compare these vs my local hosted mail server to confirm.
This is in:
CN=HTTP,CN=Protocols,CN=Mail_Server,CN=Servers,CN=Exchange Administrative Group (GUID_HERE),CN=Administrative Groups,CN=DOMAIN_NAME,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=DOMAIN_NAME,DC=local
IIS:
Default Web Site
Exchange Back End
I think it'll be important to mind that I've had a lot of problems before that and they have been fixed and that one popped up (probably my mistake) recently after solving a lot of errors that came before that about OWA.
Believe me I dug every hole in the internet to find a solution without success, I have a final solution planned (as a Plan B at the moment) which is upgrading Exchange from CU6 to CU10 (planned to happen soon) but I can't really do that at the moment, keeping in mind that those are production servers and I cannot do whatever I want.
Tried solutions:
Recreating virtual directories (including webApplications) & Recycling AppPools (OWA & ECP)
Changing authentication methods and SSL settings back to default (https://learn.microsoft.com/en-us/exchange/clients/default-virtual-directory-settings) + comparing to a local mail server hosted at home.
Checking permissions (permissions are fine)
Checking Bindings and SSL cert attached to https bindings
Comparing IIS config files found at C:\Windows\System32\inetsrv\config\ vs My local hosted Mail Server (didn't really find much difference)
Restarting IIS ofcourse (tons of times) and Rebooting
Analyzing with Exchange Analyzer (https://gallery.technet.microsoft.com/office/Exchange-Analyzer-6e20132e) - no critical errors or anything noticeable relating ECP / OWA / Webservices
Updating CAS (C:\Program Files\Microsoft\Exchange Server\V15\Bin\UpdateCas.ps1)
Testing Exchange connectivity (https://testconnectivity.microsoft.com/) - No errors whatsoever
More (can't remember anymore.. too much)
I hope all of this helps analyzing the problem and fixing it , hope we can find a fix for this without having to upgrading exchange / reinstalling and thanks for reading
I have finally fixed the problem!
Here's what I did for reference to people having the same or familiar problem:
NOTE: You are going to need to have an Exchange 2016 server with a working ECP/OWA to make a comparison between the broken Machine's files and fix the problem (I have installed a local Virtual Machine at my home's PC, you can do so too)
Fixing EventID 64 # Event Viewer:
This is for people getting this error # Event Viewer
The Outlook Web App configuration settings couldn't be read and updated. Virtual directory: "XXX". Web site: "XXX".
Error message:
"The Active Directory configuration settings couldn't be accessed for virtual directory "XXX" under Web site "XXX"."
-> Source: MSExchangeOWA
-> Event ID: 64
--> Qualifiers: 49152
I was suspecting that this was the problem and after some research I have found this article (follow the article): https://dirteam.com/dave/2010/12/23/fixing-a-broken-owa-2010-virtual-directory/
In my situation, after doing the steps in the article the errors went away but I still Couldn't log-in!
I have had no errors anymore, not in the Event Viewer or IIS logs so, I have been thinking to myself that maybe the same way I have been doing in https://dirteam.com/dave/2010/12/23/fixing-a-broken-owa-2010-virtual-directory/ to fix the ADSI Object of ECP and OWA That I would do the same concept but instead of comparing between ADSI's, this time maybe Comparing between an example machine's working ECP/OWA config files and a broken ECP/OWA config files may reveal the problem to me!
So, I fired up my local Exchange 2016 server back at home and compared 3 Files using https://www.diffchecker.com/ to check what is wrong.
I have gone ahead and compared between those 3 web.config files located at:
Text
[Exchange_Install_Drive]\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ecp
[Exchange_Install_Drive]\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa
C:\inetpub\wwwroot
To my surprise I have found some wrong and empty parameters in those files , so I went ahead and made a backup for those files and carefully removed those parameters, saved those files and restarted the IIS service (iisreset)
ECP and OWA are now fully working for me!
Hope this helps anyone!
I have a strange issue with 404 pages loaded on our new site. We just moved our site from a ColdFusion 8 single instance setup to a ColdFusion 10 setup with 3 instances of ColdFusion running. This is running on IIS 7.5 with Windows Server 2008 R2. The IIS site has it's 404 error set to load /404.cfm which was a setting copied from the previous server setup.
The issue is that when you load a page that does not exist, some of the time the 404 page loads and sometimes you just get a connection reset error. For example, if you go to http://www.weblisters.com/doesnotexist and refresh repeatedly, you will see many times the connection is reset and some other times it will display the 'Sorry, Page Not Found' template.
I thought that this might be due to the multiple instances so I turned off 2 of the 3 instances so only 1 would be running and it did not affect the behavior.
Does anyone else have any ideas to what could cause this intermittent behavior?
EDIT: Here is a screen cast of what is happening on my end. http://screencast.com/t/0gD0lwZiRI
Had this same problem today. I found the comments by Charlie Arehart on this page to be most helpful: http://forums.adobe.com/message/4784188
Basically: after updating CF10, make sure to run the Web Connector as admin.
When I'm viewing IIS log files I can see various times during the day where the header line is written out to the log file. The only time I've seen this is happening is when IIS resets; or starts up.
For example the header line below;
#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2010-10-18 07:28:06
#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
The customer is saying there is no IIS resets happening; but does this entry in the log file mean that IIS was definitely reset for some reason which may be outside of the customers control.
Eventually figured in out in the wee hours of the morning. If you have W3C logging enabled for different web sites/services, but have different fields configured for those web sites/services then when site1 is hit it output the list of fields and later on when site2 is hit it appends any different fields onto the list of the 1st fields and outputs the combined set of fields.
So having multiple sets of the # directives in the log file does not necessarily means that IIS was reset.
According to Dean Cron (Microsoft engineer working in IIS team) the logging headers are re-written on:
IIS reset
Server reboot
App Pool recycling
If you've added or removed one or more logging fields in the logging configuration.
If a site doesn't receive requests for a set period of time (15 minutes), the handle to the associated log file is closed. The next time a request comes in, the log file is re-opened and the log headers written.
You can find more details in Dean's blog post.
So no, the header appearing in the log file does not mean that IIS was reset.