Logging is enabled for a site in IIS with the following settings:
One log file per: Site
Format: W3C
Directory: %SystemDrive%\inetpub\logs\LogFiles
Encoding: UTF-8
Schedule: Daily
However, logging data is still just appended to a single file (a new one is not created every day). Has anyone else experienced this? If so, how do we resolve it?
I had the same problem.
I found possible solutions on: https://social.technet.microsoft.com/Forums/en-US/704f1998-ee9e-43e9-b618-c1bbfb64f0e6/iis-not-creating-log-files?forum=winserver8gen
You could double check the permission on the log file folders, IIS will not write to folders owned by certain groups, such as users.
The folder should be owned by "Administrators" or "SYSTEM".
Also check that the W3C Logging Service is running!
In my case the W3C Logging Service was not running.
Related
Been fighting with the problem for a month now. Have Drupal 9 set up on Azure App service with docker images running php8 (base image drupal:9.1.7-php8.0-apache)
I have found out that there are two ways to have the "sites/default/files" public files directory served in azure:
Symlink "sites/default/files" folder to "/home/files" folder and set WEBSITES_ENABLE_APP_SERVICE_STORAGE to true in application settings.
Mount Azure file share directly on top of "sites/default/files" folder using Path mappings (currently in preview).
Both options works, my files are uploaded successfully and I can see them in the storages. Drupal also sees those files, BUT every time I try to access any of the uploaded files, I get 500 error with the only error being Failed to forward request to application. Encountered a System.Net.Http.HttpRequestException exception after 119.915ms with message: Received an invalid status line: 'anges: bytes'.. Check application logs to verify the application is properly handling HTTP traffic. If I delete the uploaded file, the app reacts and shows that file not found instead.
If I disable persistent storage (any of the options mentioned above), the files are uploaded correctly, no errors are shown, but the problem is that every time the app is restarted or deployed, the files are gone.
Drupal has no errors in its log. Apache logs have no more useful info (GET seems to be ok and returns 200). Have tried messing with apache.conf, with php.ini, with both .htaccess files allowing all kinds of nasty things, but still have no clue. Had multiple colleagues look into this and nothing seems to work.
Adding EnableSendfile On into Dictionary block resolved the problem.
Example:
<Directory /media/share/www/>
EnableSendfile On
Options Indexes FollowSymLinks Includes ExecCGI
AllowOverride None
Require all granted
</Directory>
Quick update: Tried every last thing I could imagine. Had numerous people try and help, but the same error 500 or 502 appears. Two weeks no answer from microsoft support.
Created new app service not with docker containers but php 7.4 and manually uploaded all drupal files to /home/site/wwwroot, also set WEBSITES_ENABLE_APP_SERVICE_STORAGE to true so that /home dir stays persistant and the web seems to be working just fine, files are all good.
In previous attempts and now azure ssh shows all files inside /home dir as nobody:nogroup 777, will investigate this further as this might lead to some security issues if this is true (but checked settings.php etc. files and they are protected atleast from web access)
I am using the Failed Request Tracing component in IIS. One of the logs it has written ends with a LOG_FILE_MAX_SIZE_TRUNCATE error.
According to the documentation, this is controlled by the maxLogFileSizeKB settings:
If failed request tracing logs exceed this value, IIS will truncate the logs at the maximum file size and specify LOG_FILE_MAX_SIZE_TRUNCATE for the trace event.
The default value is 1024.
Apparently, I am supposed to be able to configure that value by clicking the Sites node, and then opening the website default dialog box. However, that maximum log size setting doesn't seem to be in there (German screenshot, but it should be analogous in other localized versions of IIS):
The docs also explain how to change the setting directly in Web.config, but instead of the depicted <traceFailedRequestsLogging> element, I only have a <traceFailedRequests> element in my Web.config files.
Curiously, I cannot even find any Web.config file on my entire disk that contains the general settings configured for the module (e.g. the target path for the log files):
What am I doing wrong?
The actual reason behind the error message was the FREB logs were too big. By default, IIS truncates the FREB log files at 512KB. for the FREB logs there was simply too much data for the log files to complete.
To resolve the issue you could run the following commands so the next time an HTTP error was triggered you will receive the full FREB log file and it pinpointed the exact problem:
cd /d "%windir%\system32\inetsrv"
appcmd set config /section:sites -siteDefaults.traceFailedRequestsLogging.maxLogFileSizeKB:1024
note: do not forget to run the command prompt as administrator.
you could also make these changes by using the iis Manager GUI:
1)open iis manager. select server node
2)double click on the configuration editor from the middle pane.
3)in configuration editor select section "system.applicationHost/sites".set the value for maxLogFileSizeKB.
4)apply the changes and restart the iis server.
you could refer the below link for more detail:
FREB: LOG_FILE_MAX_SIZE_TRUNCATE
Normally IIS store logs based on the website ID directory
Is there any way to change the log directory to the website name?
Instead of the W3SVC folder, I would like to have my custom folder,
For example, SchoolWebAPP , ID 7, i would like to have a SchoolWebAPP Log directory.
Anyone knows if this is possible?
Researched and found this advanced logging module. https://learn.microsoft.com/en-us/iis/extensions/advanced-logging-module/advanced-logging-for-iis-custom-logging
We have intranet website that is deployed on IIS 6 with windows authentication and ASP.Net Impersonation enabled. It works perfectly, but when we moved to IIS 8.5, logging (to a log file) seems to stopped working. When we ran Process Monitor, it shows access denied to the folder where logs are written. And it also shows that, it is impersonating logged in user to write the logs. Where we want the system to use app pool user to log. I tried everything available on internet, changing entries in applicationhost.config to adding location paths and adding web.config to that particular location, nothing seems to work.
Update:
Just executed Process Monitor on old server and below is the comparison. it is exactly same, except new server denies the access. In both the cases, impersonating user (logged in user) tries the access to folder. I think something to with OS. Old server us Windows Server Standard and new one is Windows Server 2012 R2 Standard.
Old Server
Operation:CreateFile
Result:SUCCESS
Path:XXXXX\log.txt
Desired Access:Generic Write, Read Attributes
Disposition:OpenIf
Options:Synchronous IO Non-Alert, Non-Directory File, Open No Recall
Attributes:n/a
ShareMode:Read, Delete
Impersonating:domain\username
OpenResult:Opened
New Server
Operation:CreateFile
Result:ACCESS DENIED
Path:XXXXX\log.txt
Desired Access:Generic Write, Read Attributes
Disposition:OpenIf
Options:Synchronous IO Non-Alert, Non-Directory File, Open No Recall
Attributes:n/a
ShareMode:Read, Delete
Impersonating:domain\username
I want to reference a javascript file at the bottom of a page template.
I added the .js file under cmssitemanager / development / javascript files and then added the following to the master template (portal engine):
<script src="/CMSScripts/Custom/FOO/BAR.js"></script>
When I open the page in any browser, the javascript in the file isn't executing.
When try to access the file directly in the browser at domain.com/CMSScripts/Custom/FOO/BAR.js I get redirected to the Kentico logon page.
I don't see how/where I can specify security for the CMSScripts directory, but the user should not have to be logged in to access this file.
Any suggestions?
Update with info from first answer:
We are not currently using Windows Authentication, and I verified that the application pool user account has file-system permissions. I also verified that the application can add/delete/modify files using the cmssitemanager > administration > system > files > "test files" utility which resulted in OK status for creating/deleting/modifying folders and files.
I do have Check files permission checked in cmssitemanager > settings > system > files > security. Unchecking this option does not change the behavior, including after restarting both the application and the windows services.
The site is valid and has the correct license however there was NOT a domain alias defined. I added one however this did not change the behavior.
We have not made any changes to the web.config save for connection string information. If you are referring to this documentation on CMSUseTrailingSlashOnlyForExtensionLess in the web.config, this was not previously in there however adding it did not change anything. To that end, I wasn't seeing the site trying to redirect to domain.com/CMSScripts/Custom/FOO/BAR.js/ so I truly think it's tied to some kind of security ACL that is out of order.
Here is the solution provided by user FroggEye on the Kentico DevNet forum thread on this same issue:
You're best bet is to use the syntax below. Kentico does URL processing on all directories unless excluded and you'd have to exclude the CMSScripts directory from processing which isn't hard but the code below is a better solution.
<script src="/CMSPages/GetResource.ashx?scriptfile=/CMSScripts/Custom/FOO/BAR.js" type="text/javascript"></script>
This will do 2 things:
give you a standard place to call resources from (you can get stylesheets here as well)
allow you to use the build-in minimization functions.
Charles,
This is a strange behavior, it does not normally do that.
Do you have any windows auth going on ? where you possibly removed anonymous access (in IIS) to directories in the website folder ?
Do you have Check Files permissions turned on as a Kentico Site setting? (even though I'm fairly sure that won't affect requests to the JavaScript files in JS module)
Is it a valid site (enabled and running in CMSSiteManager) and domain name with a correct license and alias ?
Any custom modifications to web.config file that possibly changed httpHandlers or modules ? And are you running the correct extensionless URL settings in web.config ?