Mise à jour de .NET 3.0 à 3.5: Sites mis à StateServer revenir à InProc quand dans le Web Jardin

Question

Scénario:

Prenez un serveur exécutant .NET 3.0 et un site Web ASP.NET en cours d'exécution dans un pool d'applications qui dispose de jardins Web activés (nombre de processus: 3). La configuration web.config se présente comme suit:

    <sessionState
      cookieless="UseCookies"
      cookieName=".authz"
      mode="StateServer"
      regenerateExpiredSessionId="true"
      stateConnectionString="tcpip=127.0.0.1:42424"
      timeout="60"
      useHostingIdentity="true" />

Mettre à jour maintenant la machine à .NET 3.5 SP1. Redémarrez le serveur. Résultat: les sessions ne sont plus maintenus dans les cas de w3wp.exe, comme si tous les sont revenus à InProc. La réduction à une processus de travail est la solution actuelle.

Ce qui est étrange: Même code sur un serveur différent connaît aucun problème. Je l'ai rencontré ce problème avant, mais il est allé comme par magie après un redémarrage. Je rallumées une fois déjà, mais pas de joie à ce jour.

En comparant les deux machine.configs et web.configs des deux serveurs. Identique

Quelqu'un d'autre a connu ce problème , mais pas de réponse là-bas.

Toutes les idées? Je suis vraiment perplexe sur celui-ci.

Answer 1

Alors, celui-ci était tout simplement incroyable.

Le problème semble se produire lorsque toutes les conditions suivantes sont remplies:

• Vous exécutez Windows Server 2003 (IIS 6.0) et un site Web ASP.NET 2.0.
• Le site Web est configurer pour utiliser le Web, où les jardins le nombre maximal de processus de travail est supérieur à 1. En raison de cela, vous avez configuré votre application pour utiliser un stockage de session hors processus; Dans ce scénario, le service d'état ASP.NET en cours d'exécution sur la machine locale.
• L'identité du pool d'applications est configuré pour ne pas SERVICE mais RÉSEAU une coutume, compte utilisateur faible privilégié que vous avez créé par une le déploiement des meilleures pratiques .
• Vous exécutez un programme d'installation qui met à jour le framework .NET; dans mon cas, ce fut une mise à jour de .NET 3.0 à .NET 3.5 SP1.

Quand les finitions de mise à niveau et que vous redémarrez le serveur, vous trouvez que vos variables de session sont souvent perdus lors de l'actualisation d'une page, car il n'y a seulement 1 chance sur 3 de vous obtenir le processus de travail original qui a servi votre demande initiale. Mais cela ne devrait pas d'importance, puisque vous utilisez le service d'état ASP.NET. Que brisé?

Lorsque vous utilisez le service d'état ASP.NET, ASP.NET utilise une valeur appelée la machineKey pour chiffrer et / ou hachage toutes les données de session à stocker (je ne sais pas si elle est le cryptage ou le hachage ou les deux, mais ce n'est pas une distinction importante pour cette discussion). Il en est ainsi que, lorsqu'un processus de travail demande des données du service à l'aide d'un identifiant de session, il peut être sûr que les données n'a pas été falsifiée alors qu'il était stocké dans la source de données externe.

Si vous êtes sur une batterie de serveurs Web, alors vous avez probablement une machineKey statique définie dans votre fichier web.config, et ce problème ne se produit pas. Mais pour un scénario de jardin web unique serveur, vous comptez probablement sur le réglage par défaut machineKey, qui est réglé sur AutoGenerate,IsolateApps pour les applications ASP.NET 2.0. Cela signifie que ASP.NET génère automatiquement une clé de la machine qui est unique à votre application. Il regénère cette clé selon un algorithme, mais ce n'est pas important pour cette discussion.

La valeur générée est normalement stocké dans le registre sous HKLM\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys\{SID of the Application Pool Identity}. Mais le programme d'installation de .NET Framework correctement (je crois que c'est un bug) détruit cette clé de Registre et, pour ajouter l'insulte à l'injure, remet à zéro les autorisations sur cette clé telle que votre identité de pool d'application personnalisée ne peut pas écrire à l'entrée de Registre quand il va pour créer sa nouvelle clé de la machine.

Le résultat est que chaque processus de travail qui tourne dans le jardin Web utilise sa propre copie en mémoire d'une clé de la machine qu'elle produit juste à temps, créant ainsi un scénario agricole web par accident. Par exemple, le processus de travail Un tourne haut, voit qu'aucune entrée de AutoGenKey existe (en effet, il ne peut même pas lire il), génère sa propre et commence à utiliser que les données de hachage envoyées au service d'état ASP.NET . Il essaie de sauver cette nouvelle clé de la machine à l'entrée de Registre, mais échoue silencieusement. Le processus de travail B tourne en place, voit qui n'existe entrée AutoGenKey, génère sa propre et commence à utiliser que de hachage des données ... vous voyez où cela va.

Le résultat est maintenant que vous avez des données de session avec hachurées trois touches de machine. Bien que les données de l'identifiant de session existe, deux sur trois des processus de travail rejetteront comme invalide / falsifié parce qu'il utilise sa propre clé.

Vous pouvez contourner ce problème en définissant explicitement un machineKey personnalisé dans votre fichier web.config.

Ou vous pouvez re-exécuter aspnet_regiis.exe -ga MachineName\ApplicationPoolUserName à une invite de commande pour réparer les autorisations brisées.

Votre problème est résolu. Le temps d'aller se coucher.

---

Mise à jour Juin 30: Par mon rapport de cette questionsur Microsoft Connect , Microsoft a indiqué qu'ils ont fixé le programme d'installation de telle sorte que ce comportement ne se produira pas en commençant par la mise à niveau .NET 4. Il pourrait encore se produire pour tous les futurs 3.0 / 3.5 mises à jour, donc je vais laisser cette question / réponse debout.