Nous avons du mal à migrer nos applications ASP.NET à Windows Server 2008 R2 X64 et IIS7.5. Le problème est que nos applications ASP.NET Écrivez des fichiers journaux et ces fichiers journaux ne sont pas écrits. La seule façon dont les applications écrivent leurs fichiers journaux est si je suis connecté au serveur en tant qu'utilisateur administrateur local ou si I Cliquez avec le bouton droit de la souris et exécutez-vous, c'est-à-dire comme étant exécuté en tant qu'administrateur, aucune autre n'est une solution acceptable pour nous.
Notre plate-forme est: Windows Server 2008 R2 X64 (paramètre UAC est le paramètre par défaut) IIS7.5 ASP.NET 4.0 (Utilisation de l'authentification Windows et de l'impersonnation, à la fois sur Web.config)
Notre application est installée à: D: [AppName] [Appnamewebsite] (tous les fichiers .aspx, .dll, etc. sont ici) \ Journal (l'application essaie d'écrire le fichier journal dans ce dossier)
sur le serveur: Créer un nouveau pool d'applications (Nom: [Appname], .NET 4.0, Mode de pipeline géré: Classic, Identity: ApplicationPooLidentifity, Charger le profil utilisateur: FAUX, toutes les autres propriétés sont les valeurs par défaut) Création de l'application IIS pointant vers D: [AppName] [Appnamewebsite] et l'a ajouté le nouveau pool d'applications (niveau de confiance complet) Avoir un utilisateur de domaine dans le groupe d'administrateurs locaux
Avec toutes les paramètres de configuration et de défaut répertoriées ci-dessus, l'application ASP.NET n'écrira pas le fichier journal. L'application semble fonctionner correctement dans le navigateur, mais aucun fichier log.txt.
essayer de "résoudre" ces problèmes, nous avons essayé beaucoup de choses: Cadre de pool d'applications essayé: Mode de pipeline géré: intégré Cadre de pool d'applications essayé: Identité: Networkservice Cadre de pool d'applications essayé: Identity: LocalSystem Définition du pool d'applications essayé: Charger le profil utilisateur: true A donné que les utilisateurs Group Contrôle complet du système de fichiers de notre structure de dossiers d'application (dossier d'appName Essayé, essayé uniquement dossier de journal, essayé appnamewebsite et dossiers de journal uniquement) A donné IIS AppPool [AppName] (correspondant au nouveau pool d'applications) Utilisateur Contrôle complet de l'utilisateur pour le système de fichiers de notre structure de dossiers d'application (dossier d'appName essayé, essayé uniquement du dossier de journal, a essayé uniquement des dossiers de logement et de journal)
Aucune de ces choses a aidé. Encore une fois, l'application fonctionnerait bien, tout simplement pas de fichier journal créé.
Comme mentionné ci-dessus, la seule façon dont le fichier journal est créé lorsque l'application est exécutée si nous vous connectons au serveur à l'aide du compte administrateur local (ce qui est logique puisqu'il est un super utilisateur) ou si nous exécutons, c'est-à-dire comme administrateur et. Élevez les privilèges.
Toute suggestion? Aider? Questions?
merci!
4 Réponses :
J'ai eu du mal avec celui-ci pendant un moment. L'applicationPoolIDIDIDIENTITY est membre du groupe d'utilisateurs et le groupe d'utilisateurs a un accès limité.
de l'explorateur, cliquez avec le bouton droit de la souris sur le dossier où vous essayez d'écrire et d'aller à la sécurité. Cliquez sur le bouton Avancé. Vous verrez que les utilisateurs ont lu et exécutent une autorisation et que le groupe d'utilisateurs peut ou non avoir des autorisations spéciales. Sinon, cliquez sur Modifier les autorisations et donnez aux utilisateurs la capacité de Essayez de créer à nouveau la création de fichiers journaux. C'est la seule autorisation que je devais régler pour le faire fonctionner.
Merci pour l'info. J'ai essayé de jouer avec des autorisations de système de fichiers sur le dossier de journal mais toujours pas de chance. Comme je l'ai déjà mentionné, j'ai un utilisateur de domaine qui figure dans le groupe Administrateurs sur le serveur. Je me connecte au serveur comme utilisateur de domaine. J'ai donné au groupe d'utilisateurs locaux Contrôle complet (lire, écrire, tout) au dossier de journal du système de fichiers (c'est-à-dire que le groupe d'utilisateurs a obtenu le contrôle total à D: \ AppName \ Log). Remarque Le groupe Administrateurs local a déjà un contrôle complet de lecture / écriture / modification complète (héritée) dans le dossier de journal du système de fichiers. Toujours aucun fichier journal créé.
J'ai donné le contrôle complet de l'utilisateur du domaine (lecture, écriture, tout) au dossier de journal du système de fichiers (c'est-à-dire que l'utilisateur du domaine a obtenu le contrôle complet de D: \ AppName \ Log). Toujours aucun fichier journal créé. J'ai donné IIS AppPool [Appname] (correspondant au nouveau pool d'applications) Utilisateur Contrôle complet de l'utilisateur (lecture, écriture, tout) au dossier de journal du système de fichiers (c'est-à-dire que l'utilisateur IIS AppPool [AppName] a obtenu le contrôle complet de D: \ appName \ journal). Toujours aucun fichier journal créé.
J'ai donné le contrôle complet du groupe IIS_IUSRS local (lire, écrire, tout) au dossier de journal du système de fichiers (c'est-à-dire que le groupe IIS_IUSRS a obtenu le contrôle total à D: \ AppName \ Log). Toujours aucun fichier journal créé. Aucune de ces choses n'a contribué. Donc, j'ai essayé de donner un contrôle complet du système de fichiers à tous les utilisateurs et groupes pertinents et toujours sans fichier journal. Je pense que cela ne peut pas être un problème d'autorisations de système de fichiers.
Aucune suggestion? Aider? Des questions? Merci!
WOW - Je vais examiner de plus près ma configuration au cas où il y a quelque chose d'autre qui pourrait fournir un indice. Cela ressemble à un problème de sécurité car il fonctionne lorsque vous exécutez l'administrateur, mais vous avez donné toutes les autorisations à tous les utilisateurs, cela devrait donc fonctionner.
Je sais, bizarre, non? Maintenant voici une torsion encore plus confuse. Comme mentionné ci-dessus, j'ai essayé de vous connecter directement au serveur avec toutes sortes d'autorisations de système de fichiers différentes. Mais comme il s'agit d'une application ASP.NET, je pensais essayer d'un poste de travail client. Je réinitialise tous les paramètres du système de fichiers et de l'IIS et des autorisations aux paramètres par défaut, comme si je venais de créer le dossier de journal et le site Web IIS.
Je me suis connecté au poste de travail client (Win 7 Pro X-64) avec un autre utilisateur de domaine. L'utilisateur du domaine du poste de travail se trouve dans le groupe Administrateurs local du poste de travail client et que le même utilisateur de domaine est dans le groupe Administrateurs sur le serveur (pour nous donner l'authentification et l'impersonnation de Windows que notre application nécessite). Lorsque j'exécute l'application ASP.NET à partir du poste de travail client, le fichier journal est écrit sans aucun problème sur le serveur dans le dossier D: \ AppName \ journal! Cela fonctionne comme prévu.
Donc, maintenant je suis vraiment à perte. Pourquoi, lorsque vous vous connectez à partir d'un poste de travail, le fichier journal est créé mais, lors de la connexion sur le serveur lui-même, le fichier n'est jamais créé ????
Eh bien, après jours d'essayer toutes les options IIS, les comptes utilisateur et les comptes de groupe, les autorisations du système de fichiers, l'explorateur de processus, etc., je pense que nous l'avons fait fonctionner: < / p>
et succès! Le fichier journal est écrit comme prévu, peu importe ce que l'utilisateur utilise l'application ASP.NET, et si elle l'exécute sur le serveur lui-même ou à partir d'une station de travail.
Je ne sais pas si désactiver la configuration de sécurité améliorée d'Internet Explorer sur le serveur est la chose "correcte" à faire ou si elle viole les meilleures pratiques, mais cela semble fonctionner pour nous.
Quelqu'un a-t-il quelque chose à ajouter?
J'ai essayé d'accorder chaque autorisation possible et n'obteniez toujours pas de fichiers journaux. Enfin, je suis tombé sur Ceci suggéré de modifier la propriété de mon répertoire de logfiles. J'ai vérifié et la propriété d'annuaire a été définie sur le système. Je l'ai changé en administrateurs et j'ai appliqué le changement récursivement. J'ai rebondi IIS, appuyez sur une page Web du site dans le navigateur et j'ai maintenant des fichiers journaux. Hourra!
Remarque: la chose qui vous a appuyée sur le journal des événements système. J'avais obtenu 15006 erreurs disant "propriétaire du fichier journal ou répertoire C: \ inetpub \ logfiles \ w3svc1 \ \ \ \ logogne est invalide. Cela pourrait être dû au fait que un autre utilisateur a déjà créé le fichier journal ou le répertoire."
Pour moi, l'astuce donnait un accès en écriture pour Si vous soupçonnez que ceci soit le problème, vérifiez le journal des événements sous Logs / Système Windows. Ce problème se manifeste comme une entrée d'erreur de la source httpevent, et se lit sur "Impossible de créer un fichier journal C: \ Chemin \ to \ Logs \ w3svc1 \ u_extend1.log. Assurez-vous que le répertoire de journalisation est correct et cet ordinateur a accès à l'écriture. ce répertoire. "
P.s. Cela est vrai pour IIS 10 mais peut également s'appliquer à d'autres versions. système et Administrateurs non seulement sur le dossier de journal lui-même, mais aussi chaque dossier dans le chemin . Ce n'est pas la manière dont les autorisations fonctionnent généralement dans Windows, mais IIS semble être vraiment plutôt particulière à ce sujet. Pas qu'il y ait une bonne raison de supprimer ces deux des ACLS pour commencer.