ASP.NET/IIS7.5 Schreiben der Protokolldatei funktioniert nicht (Berechtigungen, UAC, Konfig., ???)

Question

Wir haben Probleme bei der Migration unserer ASP.NET-Anwendungen auf Windows Server 2008 R2 x64 und IIS7.5. Das Problem ist, dass unsere ASP.NET-Anwendungen Protokolldateien schreiben, und diese Protokolldateien werden nicht geschrieben. Die einzige Möglichkeit, wie die Anwendungen ihre Protokolldateien schreiben, ist, wenn ich auf dem Server als lokaler Administrator-Benutzer angemeldet bin oder wenn ich mit der rechten Maustaste auf den IE klicke und ihn als "Als Administrator ausführen" ausführe, was beides keine akzeptable Lösung für uns ist.

Unsere Plattform ist: Windows Server 2008 R2 x64 (die UAC-Einstellung ist die Standardeinstellung) IIS7.5 ASP.NET 4.0 (mit Windows-Authentifizierung und Impersonation, beide in web.config aktiviert)

Unsere App wird installiert auf: D:[appname] [appnameWebSite] (alle .aspx-, .dll- usw. Dateien befinden sich hier) \Log (die Anwendung versucht, die Protokolldatei in diesen Ordner zu schreiben)

Auf dem Server: Neuer App Pool erstellt (Name: [appname], .NET 4.0, Managed Pipeline Mode: Classic, Identity: ApplicationPoolIdentity, Benutzerprofil laden: False, alle anderen Eigenschaften sind die Standardeinstellungen) Erstellen Sie eine IIS-Anwendung, die auf D:[appname][appnameWebSite] zeigt, und fügen Sie sie dem neuen App Pool hinzu (volle Vertrauensstufe). Sie haben einen Domänenbenutzer in der lokalen Administratorengruppe

Mit allen oben aufgeführten Konfigurations- und Standardeinstellungen schreibt die ASP.NET-Anwendung die Protokolldatei nicht. Die Anwendung scheint im Browser gut zu funktionieren, aber es gibt keine log.txt-Datei.

Um dieses Problem zu "beheben", haben wir viele Dinge ausprobiert: Anwendungspool-Einstellung ausprobiert: Verwalteter Pipeline-Modus: Integriert Versuchte Anwendungspool-Einstellung: Identität: NetzwerkDienst Versuchte Anwendungspool-Einstellung: Identität: LokalesSystem Versuchte Anwendungspool-Einstellung: Benutzerprofil laden: True Der Gruppe Users volle Kontrolle über das Dateisystem für unsere Anwendungsordnerstruktur gegeben (ausprobiert: appname-Ordner, ausprobiert: nur Log-Ordner, ausprobiert: nur appnameWebSite und Log-Ordner) Dem IIS-Benutzer AppPool[appname] (passend zum neuen App-Pool) volle Kontrolle über das Dateisystem für die Ordnerstruktur unserer Anwendung gegeben (versucht: appname-Ordner, versucht: nur Log-Ordner, versucht: nur appnameWebSite- und Log-Ordner)

Nichts von alledem hat geholfen. Auch hier lief die Anwendung einwandfrei, es wurde nur keine Protokolldatei erstellt.

Wie bereits erwähnt, wird die Protokolldatei bei der Ausführung der Anwendung nur dann erstellt, wenn wir uns mit dem lokalen Administratorkonto beim Server anmelden (was sinnvoll ist, da er ein Superuser ist) oder wenn wir den IE als Administrator ausführen und die Berechtigungen erweitern.

Irgendwelche Vorschläge? Hilfe? Fragen?

Danke!

Answer 1

Ich habe versucht, alle möglichen Genehmigungen zu erteilen, aber ich habe immer noch keine Protokolldateien erhalten. Schließlich stieß ich auf diese der vorschlug, den Eigentümer des Verzeichnisses "logfiles" zu ändern. Ich überprüfte das, und der Eigentümer des Verzeichnisses war auf SYSTEM eingestellt. Ich änderte ihn auf Administratoren und wendete die Änderung rekursiv an. Ich startete IIS, rief eine Webseite der Website im Browser auf, und jetzt habe ich Protokolldateien. Hurra!

Hinweis: Der Auslöser war die Überprüfung des Systemereignisprotokolls. Ich erhielt 15006 Fehler, die besagten, dass der Eigentümer der Protokolldatei oder des Verzeichnisses C:\inetpub\logfiles\W3SVC1\some.log ist ungültig. Dies könnte daran liegen, dass ein anderer Benutzer die Protokolldatei oder das Verzeichnis bereits erstellt hat."

Answer 2

Nun, nach Tage Nachdem wir alle IIS-Optionen, Benutzer- und Gruppenkonten, Dateisystemberechtigungen, den Process Explorer usw. ausprobiert hatten, hat es nun geklappt:

• Wir setzen alle IIS-App-Pool- und Website-Einstellungen auf ihre Standardwerte zurück
• Wir haben auch die Ordner-/Dateisystemberechtigungen für unseren Log-Ordner auf die Standardeinstellungen zurückgesetzt
• Dann haben wir die verstärkte Sicherheitskonfiguration für Internet Explorer auf dem Server deaktiviert

Und Erfolg! Die Protokolldatei wird wie erwartet geschrieben, unabhängig davon, welcher Benutzer die ASP.NET-Anwendung verwendet, und unabhängig davon, ob er sie auf dem Server selbst oder von einer Workstation aus ausführt.

Ich weiß nicht, ob die Deaktivierung der verstärkten Sicherheitskonfiguration für Internet Explorer auf dem Server die "richtige" Vorgehensweise ist oder ob sie gegen bewährte Verfahren verstößt, aber bei uns scheint sie zu funktionieren.

Hat jemand etwas dazu zu sagen?

Answer 3

Ich habe eine Weile mit dieser Frage gerungen. Die ApplicationPoolIdentity ist Mitglied der Gruppe Users, und die Gruppe Users hat nur begrenzten Zugriff.

Klicken Sie im Explorer mit der rechten Maustaste auf den Ordner, in den Sie zu schreiben versuchen, und wählen Sie Sicherheit. Klicken Sie auf die Schaltfläche Erweitert. Sie werden sehen, dass Benutzer die Berechtigung Lesen und Ausführen haben und die Gruppe Benutzer die Berechtigung Spezial haben kann oder auch nicht. Falls nicht, klicken Sie auf Berechtigungen ändern und geben Sie den Benutzern die Möglichkeit Dateien erstellen / Daten schreiben y Ordner erstellen / Daten anhängen . Dies ist auf diesen Ordner beschränkt. Ich verwende normalerweise einen Unterordner, damit ich keinen Schreibzugriff auf meine gesamte Website ermögliche.

Versuchen Sie, erneut Protokolldateien zu erstellen. Dies ist die einzige Berechtigung, die ich einstellen musste, damit es funktioniert.

Answer 4

Für mich bestand der Trick darin, Schreibzugriff für SYSTEM y Administrators nicht nur in den Protokollordner selbst, sondern auch jeden Ordner im Pfad . Dies ist nicht die Art und Weise, wie Berechtigungen in Windows normalerweise funktionieren, aber IIS scheint hier wirklich sehr wählerisch zu sein. Nicht dass es einen guten Grund gäbe, diese beiden aus den ACLs zu entfernen, um damit zu beginnen.

Wenn Sie vermuten, dass dies das Problem ist, überprüfen Sie das Ereignisprotokoll unter Windows-Protokolle/System. Dieses Problem manifestiert sich als Fehlereintrag der Quelle HttpEvent und lautet "Unable to create log file C:\path\to\logs\W3SVC1\u_extend1.log. Vergewissern Sie sich, dass das Protokollierungsverzeichnis korrekt ist und dieser Computer Schreibzugriff auf dieses Verzeichnis hat."

P.S. Dies gilt für IIS 10, kann aber auch auf andere Versionen zutreffen.