La connexion a échoué pour l'utilisateur «IIS APPPOOL \ ASP.NET v4.0»

432

J'ai un projet web (C # Asp.Net, EF 4, MS SQL 2008 et IIS 7) et je dois le migrer localement vers IIS 7 (pour le moment ça marche bien avec CASSINI).

Localement dans IIS, je l'ai Default Web Siteavec mon déploiement. Mon déploiement et mon Default Web Sitepool ASP.NET v4.0 (regardez l'image pour les paramètres) le pool cible Framework 4 comme mon projet Web. Paramètres de la piscine Lors de la visite du site, le navigateur n'affiche pas la page et autorise le navigateur à télécharger la page à la place.

J'ai d'autres projets en cours d'exécution sur IIS localement et ils fonctionnent sans problème (mais ils n'utilisent pas Entity Framework).

En utilisant le journal des événements, je vois des erreurs comme ci-dessous:

Exception information: 
    Exception type: EntityException 
    Exception message: The underlying provider failed on Open.
   at System.Data.EntityClient.EntityConnection.OpenStoreConnectionIf(Boolean openCondition, DbConnection storeConnectionToOpen, DbConnection originalConnection, String exceptionCode, String attemptedOperation, Boolean& closeStoreConnectionOnFailure)


    Login failed for user 'IIS APPPOOL\ASP.NET v4.0'.
       at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
       at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
       at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
       at System.Data.SqlClient.SqlConnection.Open()
       at System.Data.EntityClient.EntityConnection.OpenStoreConnectionIf(Boolean openCondition, DbConnection storeConnectionToOpen, DbConnection originalConnection, String exceptionCode, String attemptedOperation, Boolean& closeStoreConnectionOnFailure)

Question connexe

MISE À JOUR: Vous pouvez lire dans les ressources sur cette question que les autorisations doivent être accordées sur MS SQL 2008 manuellement comme l'expliquent arift dans sa réponse. À l'aide d'IIS 7.5 et de MS SQL 2008 R2, la définition d'une autorisation manuelle ne devrait pas être nécessaire.

GibboK
la source
2
avez-vous autorisé l'autorisation d'identité du pool d'applications sur le dossier du site Web?
Christian
je ne suis pas sûr, pourriez-vous s'il vous plaît me dire comment faire?
GibboK
en fait, comme le dit à la dérive, cela pourrait être un problème de sécurité sql. Il est préférable de définir un compte d'utilisateur NT pour l'AppPool, puis d'accorder cette autorisation au dossier du site Web et aux tables appropriées dans SQL
Christian
1
@GibboK: Je vous encourage à revoir la réponse acceptée ici et à choisir une réponse plus appropriée. La réponse acceptée conduit de nombreuses personnes dans un trou noir de sécurité. Oui cela fonctionne. Non, ce n'est vraiment pas une bonne idée. Voir mes commentaires ci-dessous.
dépensé le

Réponses:

596

On dirait qu'il ne parvient pas à ouvrir une connexion à SQL Server.

Vous devez ajouter une connexion à SQL Server IIS APPPOOL\ASP.NET v4.0et accorder des autorisations à la base de données.

Dans SSMS, sous le serveur, développez Sécurité, puis cliquez avec le bouton droit sur Connexions et sélectionnez "Nouvelle connexion ...".

Dans la boîte de dialogue Nouvelle connexion, entrez le pool d'applications comme nom de connexion et cliquez sur "OK".

entrez la description de l'image ici

Vous pouvez ensuite cliquer avec le bouton droit sur la connexion au pool d'applications, sélectionner Propriétés et sélectionner "Mappage utilisateur". Vérifiez la base de données appropriée et les rôles appropriés. Je pense que vous pouvez simplement sélectionner db_datareaderet db_datawriter, mais je pense que vous devrez toujours accorder des autorisations pour exécuter des procédures stockées si vous le faites via EF. Vous pouvez vérifier les détails des rôles ici .

Jeff Ogata
la source
8
merci, j'ai fait ce que vous êtes triste, maintenant je reçois cette erreur: Impossible d'ouvrir la base de données "SiteNameExtension" demandée par la connexion. La connexion a échoué. La connexion a échoué pour l'utilisateur «IIS APPPOOL \ DefaultAppPool».
GibboK
76
TRÈS IMPORTANT: NE CLIQUEZ PAS SUR RECHERCHE POUR ESSAYER DE CONFIRMER LA CONNEXION! Il ne le reconnaîtra pas mais cela fonctionnera. Tapez-le simplement sous IIS APPPOOL \ SimonsAppPoolName. Voir ce stackoverflow.com/questions/1933134
Simon_Weaver
6
Au lieu de cela, il vaut mieux changer «Identity» en «LocalSystem» à partir d'IIS, comme décrit dans la réponse suivante.
Altaf Patel,
Cela peut-il fonctionner lorsque votre instance de serveur SQL se trouve sur une autre machine hôte, puis sur votre machine hôte IIS? Parce que je dois résoudre le même problème, mais SQL et IIS ne sont pas sur la même machine. Donc, utiliser l'authentification Windows pour ce nouvel utilisateur ne fonctionnera pas
Segers-Ian
5
Pour moi, l'utilisateur à ajouter était «IIS APPPOOL \ DefaultAppPool». Ensuite, cela a fonctionné.
Marcel
343

Vous pouvez modifier ApplicationPoolIdentity dans IIS7 -> Pools d'applications -> Paramètres avancés. Réglages avancés

Sous ApplicationPoolIdentity, vous trouverez le système local. Cela fera fonctionner votre application sous NT AUTHORITY\SYSTEM, qui est une connexion existante pour la base de données par défaut.

Modifier: Avant d'appliquer cette suggestion, vous devez noter et comprendre les implications pour la sécurité.

Le A
la source
51
@GibboK, Si vous êtes préoccupé par la sécurité, ne le faites pas. Voir technet.microsoft.com/en-us/library/dd378907(v=WS.10).aspx
Jeff Ogata
4
En plus d'exécuter le pool d'applications en tant qu'identité LocalSystem, j'ai également dû mapper l'utilisateur "NT AUTHORITY \ SYSTEM" aux rôles de base de données
Phil
31
Ça pue. Accorder l'autorité SYSTEM à une application Web est une recette pour un désastre et permet aux malfaiteurs toutes sortes d'opportunités d'infliger des dommages non seulement à votre application Web, mais à l'ensemble du serveur d'hébergement. Le fait que la base de données accepte les connexions de SYSTEM ne signifie pas que vous devez exécuter votre application Web en tant que SYSTEM. Le bureau Windows ne vous permet même pas de fonctionner en tant que SYSTEM (sans sauter à travers des cerceaux). Exécuter une webapp avec cette autorité est une idée vraiment, vraiment stupide. Vous devez obliger la base de données à accepter l'identité du pool d'applications actuel. Je ferais -100 si je pouvais. -1.
dépenser le
8
SYSTEM est plus hautement privilégié qu'Administrateur. Vous ne devez JAMAIS exécuter votre serveur Web avec quoi que ce soit approchant ce niveau.
slugster
1
Je fais simplement du compte Invité un membre du groupe Administrateur. Simple, propre, n'a jamais de problème avec les conneries de sécurité.
29

assurez-vous que vous avez ...

Trusted_Connection=false;

dans votre connexion String

JGilmartin
la source
7
Avoir Trusted_Connection = true dans la chaîne de connexion remplacera les valeurs d'authentification SQL par le profil utilisateur d'identité IIS.
Jeff the Bear
2
dans mon cas, supprimer: Integrated Security = True de la chaîne de connexion l'a corrigé.
Carlos R Balebona
A travaillé pour moi. Enregistré le jour @JefftheBear
D_Edet
26

J'ai résolu ce problème en utilisant sql comme image suivante.

Cliquez avec le bouton droit sur db-> propriétés -> autorisation -> Afficher l'autorisation du serveur -> puis sélectionnez IIS APPPOOL\ASP.NET v4.0et accordez l'autorisation.

db

DevT
la source
Le processus (et l'image) ci-dessus décrit-il les autorisations GRANTing Server Level pour cette identité de pool d'applications? Cela ne semble pas être une bonne idée.
Chris Walsh
2
Cet utilisateur mérite la médaille! Rien n'a aidé mais ça!
Khateeb321
2
@ Khateeb321 absolument, merci beaucoup DevT pour votre réponse.
Azxdreuwa
22

Exécutez ce script SQL

IF NOT EXISTS (SELECT name FROM sys.server_principals WHERE name = 'IIS APPPOOL\DefaultAppPool')
BEGIN
    CREATE LOGIN [IIS APPPOOL\DefaultAppPool] 
      FROM WINDOWS WITH DEFAULT_DATABASE=[master], 
      DEFAULT_LANGUAGE=[us_english]
END
GO
CREATE USER [WebDatabaseUser] 
  FOR LOGIN [IIS APPPOOL\DefaultAppPool]
GO
EXEC sp_addrolemember 'db_owner', 'WebDatabaseUser'
GO
Rolwin Crasta
la source
Merci, moyen le plus simple;) +1
Zolfaghari
11

Si vous avez spécifié dans la chaîne de connexion :

User ID=xxx;Password=yyy

mais dans la chaîne de connexion il y a:

Trusted_Connection=true;

SQL Server utilisera l'authentification Windows, vos valeurs de connexion seront donc ignorées et remplacées (IIS utilisera le compte Windows spécifié dans le profil utilisateur Identité). Plus d'infos ici

Il en va de même si dans la chaîne de connexion il y a:

 Integrated Security = true;

ou

 Integrated Security = SSPI;

car l'authentification Windows sera utilisée pour se connecter au serveur de base de données. Plus d'infos ici

homme araignée
la source
10

allez dans iis -> pools d'applications -> trouvez votre pool d'applications utilisé dans l'application

entrez la description de l'image ici

sélectionnez votre pool d'applications utilisé pour l'application cliquez avec le bouton droit sur sélectionnez les paramètres avancés

entrez la description de l'image ici

Sélectionner l'identité du pool d'applications entrez la description de l'image ici

sélectionnez intégré comme système local et cliquez sur ok

Lijo
la source
7

Je déteste ApplicationPoolIdentity. J'ai toujours défini un compte d'utilisateur Windows comme compte sur AppPools.

Comme le dit adrift, cela ressemble à un problème de sécurité de la base de données. Créez donc un compte utilisateur NT, affectez-le à l'AppPool ASP.NET v4.0, puis accordez-lui l'autorisation sur le dossier du site Web et sur les tables pertinentes dans SQL.

Christian
la source
désolé, aucune idée de comment faire, pourriez-vous me signaler un tutoriel? merci pour votre aide
GibboK
2
Ne faites pas cela, il y a une raison pour laquelle IIS a changé l'identité du pool d'applications, learn.iis.net/page.aspx/624/application-pool-identities
Julien Lebot
@ LeSnip3R lien cassé
Adaptabi
6

N'utilisez pas la sécurité intégrée. UtilisationUser Id=yourUser; pwd=yourPwd;

Cela résout le problème.

bonh
la source
4

J'ai eu ce problème et il était en fait causé par quelque chose de différent - j'avais l'utilisateur 'IIS APPPOOL \ ASP.NET v4.0' dans ma base de données mais cela ne fonctionnait toujours pas.

J'avais récemment mis à niveau mon installation SQL Server et, dans le processus, l'utilisateur s'était déconnecté de la connexion - il y avait donc un 'IIS APPPOOL \ ASP.NET v4.0' sous Base de données -> Sécurité -> Utilisateurs MAIS aucun utilisateur n'est sous sécurité -> Connexions.

Ajout de la connexion 'IIS APPPOOL \ ASP.NET v4.0' à Security -> Logins, SQL Server l'a automatiquement mappé à l'utilisateur dans la base de données (cela devait être fait manuellement) et le problème a été résolu.

Le codeur
la source
1
juste pour ajouter ... à gauche, sous Autorisations ... cochez db_writer et db_reader; et sélectionnez la base de données qui utilisera ces autorisations.
benjieb
4

La première chose que vous devez effacer si vous utilisez l'authentification Windows et que vous ne mentionnez aucun mot de passe de nom d'utilisateur dans votre chaîne de connexion, alors:

Que se passe-t-il lorsque vous exécutez votre code via localhost: lorsque vous exécutez votre client de test wcf à partir de localhost, il pourra communiquer avec la base de données car l'application en mode de débogage local appelle la base de données par le service de votre compte. Il a donc accès à la base de données car devenv.exe s'exécute sous votre compte utilisateur.

Mais lorsque vous déployez votre service Web dans IIS. Comprenez maintenant que ce service fonctionne sous IIS et non sous votre compte. Vous devez donc attribuer des droits d'accès au service IIS pour accéder au serveur SQL pour l'authentification Windows. Ici, votre service Web ne pourrait pas communiquer avec le serveur SQL en raison d'un problème de droits d'accès et d'un échec de connexion pour l'utilisateur_______ (ici, votre utilisateur viendra)

Donc, si vous utilisez l'authentification Windows pour connecter votre base de données, il vous suffit de modifier les paramètres du pool d'applications IIS. Vous devez changer l'identité du pool d'applications IIS en système local.

Voici les étapes de l'authentification Windows WCF:

1) Ouvrez IIS (windows + R (run) puis tapez inetmgr, puis cliquez sur ok)

2) double-cliquez sur le nom de votre PC sous Connexions

3) Cliquez sur Pools d'applications

4) Sélectionnez votre pool d'applications (DefaultAppPool)

5) Puis sous actions sur le clic droit Paramètres avancés:

6) Allez à la section Modèle de processus et

7) cliquez sur Identité.

8) Sélectionnez maintenant LocalSystem.

Ouvrez maintenant votre studio de gestion de serveur SQL: ouvrez run-> puis tapez ssms -> puis appuyez sur ok Dans ssms, connectez-vous en utilisant votre compte d'authentification Windows. Ouvrez l'onglet de sécurité, développez l'onglet de connexion, vous pourrez voir votre compte.

Maintenant, ouvrez les propriétés de votre compte, accédez à userMapping, sélectionnez la base de données que vous souhaitez connecter, puis cochez les services d'appartenance aux rôles que vous souhaitez utiliser pour la base de données sélectionnée. cliquez sur OK.

(Pour les services réseau, c'est-à-dire les utilisateurs intranet, vous devez également configurer les paramètres ci-dessus pour l'utilisateur NT AUTHORITY \ SYSTEM)

ajouter Trusted_Connection = True; dans votre chaîne de connexion. Enregistrez-le et déployez le service Web. Redémarrez le pool d'applications.

vous pourrez maintenant connecter la base de données.

Amar Gadekar
la source
Parfait! LocalSystem a résolu ce problème pour moi :)
totalitaire
3

J'ai eu ce message et j'utilise l'authentification Windows sur le serveur Web.

Je voulais que l'utilisateur Web actuellement authentifié soit authentifié par rapport à la base de données, plutôt que d'utiliser l'utilisateur IIS APPPOOL \ ASP.NET v4 spécifié dans le pool d'applications.

J'ai trouvé en entrant ce qui suit dans le web.config corrigé cela pour moi:

<system.web>
  <identity impersonate="true" />
</system.web>

https://msdn.microsoft.com/en-us/library/bsz5788z.aspx

Je vois d'autres réponses concernant la création du nom d'utilisateur AppPool dans la base de données SQL ou tout simplement pour utiliser SQL Auth. Les deux seraient corrects si vous ne vouliez pas capturer ou sécuriser des utilisateurs Windows individuels dans SQL.

À M

tommylux
la source
Cela l'a résolu pour nous et nous ne savons pas pourquoi. IIS / AppPool détourne simplement la chaîne de connexion qui dit explicitement "Integrated Security = true"? Pourquoi??
Guy
3

1_in SqlServer Security => Login => NT AUTHORITY \ SYSTEM => RightClick => Property => UserMaping => Select YourDatabse => Public && Owner Select => OK 2_In IIs Application Pools DefaultAppPool => Advance Setting => Identity => LocalSystem => Ok

mehranSattary
la source
2

La définition de l'identité ne fait que fonctionner dans mes pages.

Charles
la source
2

Cassini exécute votre site Web en tant que votre propre identité d'utilisateur lorsque vous démarrez l'application Visual Studio. IIS gère votre site Web en tant qu'identité de pool d'applications. À moins que l'identité du pool d'applications ne soit autorisée à accéder à la base de données, vous obtenez des erreurs.

IIS a introduit App Pool Identity pour améliorer la sécurité. Vous pouvez exécuter des sites Web sous l'identité de pool d'applications par défaut, ou créer un nouveau pool d'applications avec son propre nom, ou créer un nouveau pool d'applications avec son propre nom qui s'exécute sous un compte d'utilisateur (généralement un compte de domaine).

Dans les situations en réseau (qui ne sont pas dans Azure), vous pouvez exécuter un nouveau pool d'applications sous un compte d'utilisateur de domaine Active Directory; Je préfère cela au compte d'ordinateur. Cela donne une sécurité granulaire et un accès granulaire aux ressources réseau, y compris aux bases de données. Chaque site Web s'exécute sur un pool d'applications différent (et chacun d'eux s'exécute sous son propre compte d'utilisateur de domaine).

Continuez à utiliser la sécurité intégrée de Windows dans toutes les chaînes de connexion. Dans SQL Server, ajoutez les utilisateurs du domaine en tant que connexions et accordez des autorisations aux bases de données, tables, SP, etc., par site Web. Par exemple, DB1 utilisé par Website1 a une connexion pour User1 car Website1 s'exécute sur un pool d'applications en tant qu'utilisateur1.

Un défi lié au déploiement à partir de la base de données intégrée de Visual Studio (par exemple LocalDB) et du serveur Web intégré vers un environnement de production provient du fait que le SID utilisateur du développeur et ses ACL ne doivent pas être utilisés dans un environnement de production sécurisé. Microsoft fournit des outils de déploiement. Mais dommage pour le pauvre développeur qui est habitué à tout ce qui fonctionne dans le nouvel VS IDE facile avec localDB et localWebServer, parce que ces outils seront difficiles à utiliser pour ce développeur, en particulier pour un tel développeur sans support SysAdmin et DBAdmin ou leurs connaissances spécialisées. Néanmoins, le déploiement sur Azure est plus facile que la situation de réseau d'entreprise mentionnée ci-dessus.

subsci
la source
2

Si votre chaîne de connexion a été ajoutée dans votre web.config, assurez-vous que "Integrated Security = false;" il utiliserait donc l'identifiant et le mot de passe spécifiés dans le web.config.

<connectionStrings>
    <add providerName="System.Data.SqlClient" name="MyDbContext" connectionString="Data Source=localhost,1433;Initial Catalog=MyDatabase;user id=MyUserName;Password=MyPassword;Trusted_Connection=true;Integrated Security=false;" />
</connectionStrings>
Daming Fu
la source
2

Comme indiqué, n'utilisez pas l'authentification Windows, utilisez l'authentification SQL Server

De plus, si vous avez créé une connexion à l'aide de la boîte de dialogue "Connexion au serveur", assurez-vous de vérifier les connexions dans web.config. Il est probable que vous ayez créé / modifié une connexion et qu'elle a été stockée en tant que connexion sécurisée dans web.config. Utilisez simplement cette authentification

<add name="MyDBConnectionString" connectionString="Data Source=localhost;Initial Catalog=Finantial;User ID=xxx;Password=xxx" providerName="System.Data.SqlClient"/>

ce qui devrait corriger l'erreur.

Hammad Khan
la source
2

Une autre façon d'accorder l'autorisation à la base de données pour l'utilisateur IIS APPPOOL\ASP.NET v4.0est la suivante.
entrez la description de l'image ici


  1. Ajoutez un nouvel utilisateur avec le nom d'utilisateur et le nom de connexion comme IIS APPPOOL\ASP.NET v4.0avec votre schéma par défaut.
  2. Accédez au schéma et à l'adhésion du propriétaire, vérifiez db_datareader, db_datawriter
shana
la source
1

Je pensais que je posterais cela comme une réponse car elle est pertinente pour la question et peut y répondre dans certains cas.

Ce même message apparaît également si la base de données n'existe pas!

Assurez-vous que votre chaîne de connexion ne comporte aucune faute d'orthographe, pointe vers la bonne instance de serveur, etc.

colmde
la source
1

J'ai le même problème que je l'ai résolu en changeant Integrated Security=Trueen faux maintenant son fonctionnement

subramanya46
la source
1

quelque chose de similaire m'est arrivé ce qui a fonctionné pour moi a été de changer la propriété Integrated Security = True en Integrated Security = false dans le web.config du site Web

Erik Rodriguez
la source
cela marche! Je viens de supprimer la sécurité intégrée
Charles Xavier
0

Avez - vous fait ce que @Teddyrecommandé et vous STILL obtenez la même erreur?

Assurez-vous de modifier les paramètres du pool d'applications correspondant à votre répertoire virtuel et non au serveur parent. Chaque répertoire virtuel a son propre AppPool et n'hérite pas.

Simon_Weaver
la source
0

Dans DefaultAppPool, définissez NetworkService dans la propriété Identity et dans Sql Server, ajoutez User Network Service et donnez-lui les autorisations appropriées pour votre base de données, cela fonctionne très bien pour moi, j'ai testé localement, mais je pense que c'est la meilleure configuration pour se connecter à partir de n'importe quel autre ordinateur du réseau. lorsque vous définissez LocalSystem dans l'identité dans IIS, cela fonctionne bien et il n'est pas nécessaire de créer un autre utilisateur dans Sql Server, mais je pense que cela ne fonctionnera pas dans un environnement réseau.

Luis
la source
0

J'ai rencontré le même problème lors du test de l'API Web ASP.NET

Développé Web.Host dans Visual Studio 2013 Express Base de données créée dans SQL Server 2012 Express Test exécuté à l'aide d'IIS Express intégré (en fonctionnement) Modifié pour utiliser IIS Local (à partir de la page des propriétés - option Web) Test Ran avec Fiddler Erreur reçue - impossible d'ouvrir la base de données pour le fournisseur .... citant 'APPPOOL \ DefaultAppPool'

Solution qui a fonctionné.

Dans IIS

Cliquez sur le pool d'applications 'DefaultAppPool' Set Identify = 'ApplicationPoolIdentity' Set .NET framework = v4.0 (même si mon application était 4.5)

Dans SQL Server Management Studio

Cliquez avec le bouton droit sur le dossier Sécurité (sous le moteur SQL Server s'applique donc à toutes les tables) Cliquez avec le bouton droit sur Utilisateur et ajoutez `` IIS APPPOOL \ DefaultAppPool '' Dans les éléments sécurisables de la colonne `` Accorder '', cochez les options que vous souhaitez donner. En ce qui concerne ce qui précède, si vous êtes un DBA, vous savez probablement et souhaitez contrôler quelles sont ces options. Si vous êtes comme moi, un développeur voulait juste tester votre service d'API WEB qui se trouve également accéder à SQL Server via EF 6 dans le style MVC, alors cochez tout. :) Oui je sais mais ça a marché.

Brian Quinn
la source
0

Si vous ajoutez une nouvelle connexion, assurez-vous que sous les propriétés du serveur (clic droit -> propriétés) / sécurité, le mode d'authentification est défini à la fois sur sqlserver et sur windows, pas seulement sur windows.

badr slaoui
la source
0

Ajoutez "Tout le monde" sous sécurité. Si vous avez ajouté le serveur et les utilisateurs qui se connectent à la base de données, c'est quelque chose qui vous manque. J'espère que cela t'aides.

avinava basu
la source
Nous définissons les autorisations en fonction de nos besoins, la partie authentification est gérée et nous vérifions l'autorisation par code pour autoriser l'accès. N'hésitez pas à me corriger si vous sentez qu'il y a une ambiguïté. Merci.
avinava basu
0

Pour mémoire, si vous rencontrez cette erreur après être passé de LocalDBà SQLEXPRESS, assurez-vous que la base de données existe déjà SQLEXPRESS. Vous pouvez le vérifier dans Management Studio.

J'ai eu le même problème lors de l'utilisation Entity Frameworkaprès le passage à SQLEXPRESS from LocalDB. J'ai dû exécuter la Update-Databasecommande. J'ai pu me connecter avec succès après cela.

Irshu
la source
0

J'ai fait exactement ce que @JeffOgata a dit mais j'ai eu l'erreur:

Windows NT user or group 'IIS APPPOOL\ASP.NET v4.0' not found. Check the name again. (Microsoft SQL Server, Error: 15401)

J'ai regardé à nouveau mon message d'erreur et il a dit Login failed for user 'IIS APPPOOL\DefaultAppPool'.

Après avoir ajouté un utilisateur nommé, IIS APPPOOL\DefaultAppPooltout a fonctionné.

Ogglas
la source
0

J'ai utilisé SQL Server Profiler (disponible dans SSMS => menu Outils) et j'ai vu (lorsque IIS a tenté de se connecter à la base de données) que mon utilisateur IIS était pour une raison quelconque NT AUTHORITY \ IUSR, peu importe toutes les étapes recommandées dans les réponses à cette question . J'ai donc ajouté cet utilisateur à SQL Server, et cela a fonctionné ...

alexkovelsky
la source
0

Dans le formulaire Web Asp.net,

cette erreur corrigée lors de l'installation d'asp.net à partir de:

Gestionnaire de serveur> Gérer> Ajouter un rôle et une fonctionnalité> Rôles de serveur> Serveur Web (IIS)> Serveur Web> Développement d'applications> ASP.NET 3.5 / 4.6 est installé.

mon problème résolu.

Zolfaghari
la source