Actualización desde .NET 3,0 a 3,5: Sitios fijados a StateServer vuelven a InProc cuando en Web Jardín

Question

Escenario:

Tome un servidor que ejecuta .NET 3.0 y un sitio Web ASP.NET que se ejecuta en un grupo de aplicaciones que tiene jardines web habilitados (número de procesos: 3). La configuración web.config es como sigue:

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

Ahora actualice la máquina para .NET 3.5 SP1. Reinicie el servidor. Resultados: sesiones ya no se mantienen a través de las instancias de w3wp.exe, como si toda la han vuelto a InProc. La reducción a 1 proceso de trabajo es la solución actual.

Lo que es extraño: el mismo código en un servidor diferente experimenta ningún problema. He tenido este problema antes, pero mágicamente se fue después de un reinicio. Me reinicia una vez ya, pero no alegría hasta ahora.

Comparando las dos machine.configs y web.configs de los dos servidores:. Idéntica

Alguien más ha tenido este problema , pero no hubo respuesta allí.

¿Alguna idea? Estoy realmente perplejo en este caso.

Answer 1

Por lo tanto, éste era simplemente increíble.

El problema parece ocurrir cuando todas las condiciones siguientes:

• se ejecuta Windows Server 2003 (IIS 6.0) y un sitio web de ASP.NET 2.0.
• El sitio Web es configurar para usar el hospedaje, donde el número máximo de procesos de trabajo es mayor que 1. Debido a esto, se ha configurado la aplicación para utilizar un almacenamiento de sesión fuera de proceso; En este escenario, el Servicio de estado de ASP.NET que se ejecuta en la máquina local.
• La identidad del grupo de aplicaciones no está configurado para la red de servicio, pero a una costumbre, con pocos privilegios de cuenta de usuario que creó por un despliegue de las mejores prácticas .
• Se ejecuta un instalador que actualiza el marco .NET; en mi caso, se trataba de una actualización de .NET 3.0 a .NET 3.5 SP1.

Cuando finalice la actualización y reiniciar el servidor, se encuentra que sus variables de sesión se pierden frecuentemente al actualizar una página, ya que sólo hay un 1 en 3 posibilidades de conseguir que el proceso de trabajo original que sirvió su solicitud original. Pero esto no debe importar, ya que está utilizando el servicio de estado de ASP.NET. Lo rompió?

Cuando se utiliza el servicio de estado de ASP.NET, ASP.NET utiliza un valor llamado la machineKey para cifrar y / o hash de todos los datos de sesión para almacenar (no sé si es el cifrado o hash o ambas cosas, pero no es una distinción importante para esta discusión). Esto es para que cuando cualquier proceso de trabajo pide datos del servicio utilizando un identificador de sesión, puede estar seguro de que los datos no han podido ser manipulados mientras estaba siendo almacenada en la fuente de datos externa.

Si usted está en una granja de servidores web, entonces es probable que tenga un machineKey estática se define en el archivo de web.config, y este problema no se produce. Pero para un escenario de un solo servidor web jardín, es probable que confiar en la configuración por defecto machineKey, que se fija a AutoGenerate,IsolateApps para aplicaciones ASP.NET 2.0. Esto significa que ASP.NET genera automáticamente una clave de equipo que es único en su grupo de aplicaciones. Regenera esta clave de acuerdo con algún algoritmo, pero eso no es importante para esta discusión.

El valor generado se almacena normalmente en el registro bajo HKLM\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys\{SID of the Application Pool Identity}. Sin embargo, el programa de instalación de .NET Framework de forma incorrecta (yo creo que esto es un error) destruye esta clave del Registro y, para colmo de males, restablece los permisos en esta clave de tal manera que su identidad de grupo de aplicaciones personalizadas no puede escribir en la entrada de registro cuando se va para crear su nueva clave de equipo.

El resultado es que cada proceso de trabajo que gira en el jardín web está utilizando su propia copia en memoria de la llave de la máquina que genera justo en el tiempo, creando un escenario de servidores Web por accidente. Por ejemplo, un proceso de trabajo empiece a girar, ve que no existe ninguna entrada AutoGenKey (de hecho, no puede ni siquiera leer es), genera su propia y comienza a utilizar que para discutir los datos enviados al Servicio de estado de ASP.NET . Se trata de salvar esta nueva llave de la máquina a la entrada del registro, pero no en silencio. El proceso de trabajo B empiece a girar, ve que no existe ninguna entrada AutoGenKey, genera su propia y comienza a utilizar que para cifrar los datos ... a ver dónde va esto.

El resultado es que ahora usted tiene los datos de sesión hash con tres teclas de la máquina diferentes. Aunque existen los datos para el identificador de sesión, dos de cada tres de los procesos de trabajo de la rechazarán como no válido / manipulado porque está utilizando su propia clave.

Se puede evitar esto mediante el establecimiento de un machineKey explícitamente en su fichero de web.config.

O se podría aspnet_regiis.exe -ga MachineName\ApplicationPoolUserName volver a ejecutar en un símbolo para arreglar los permisos rotos.

Su problema está resuelto. Es hora de ir a la cama.

---

ACTUALIZACIÓN 30 de junio: Por mi informe de este temaen Microsoft Connect , Microsoft ha indicado que se han fijado el instalador de tal manera que este comportamiento no ocurrirá comenzando con las actualizaciones a .NET 4. aún podría suceder para todos los futuros 3.0 / 3.5 actualizaciones, así que voy a dejar esta pregunta / respuesta de pie.