Atualize do .NET 3.0 para 3.5:Sites definidos como StateServer revertem para InProc quando estão no Web Garden

Question

Cenário:

Considere um servidor executando o .NET 3.0 e um site ASP.NET em execução em um pool de aplicativos que tenha ambientes da Web habilitados (número de processos:3).A configuração do web.config é a seguinte:

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

Agora atualize a máquina para .NET 3.5 SP1.Reinicie o servidor.Resultado:as sessões não são mais mantidas nas instâncias do w3wp.exe, como se todas tivessem revertido para o InProc.Reduzir para 1 processo de trabalho é a solução alternativa atual.

O que é estranho:O mesmo código em servidores diferentes não apresenta problemas.Já tive esse problema antes, mas ele desapareceu magicamente após reiniciar.Já reiniciei uma vez, mas nenhuma alegria até agora.

Comparando os dois machine.configs e web.configs dos dois servidores:idêntico.

Alguém já passou por esse problema, mas não há resposta lá.

Alguma ideia?Eu sou realmente perplexo com este.

Answer 1

Então, este foi simplesmente incrível.

O problema parece ocorrer quando todas as seguintes condições são verdadeiras:

• Você está executando o Windows Server 2003 (IIS 6.0) e um site ASP.NET 2.0.
• O site está configurado para usar Web Gardens, onde o número máximo de processos de trabalho é maior que 1.Por causa disso, você configurou seu aplicativo para usar um armazenamento de sessão fora de processo;neste cenário, o serviço de estado ASP.NET em execução na máquina local.
• A identidade do pool de aplicativos não é definida como NETWORK SERVICE, mas como uma conta de usuário personalizada e com poucos privilégios criada por você melhores práticas de implantação.
• Você executa um instalador que atualiza o .NET framework;no meu caso, foi uma atualização do .NET 3.0 para o .NET 3.5 SP1.

Quando a atualização termina e você reinicia o servidor, você descobre que suas variáveis ​​de sessão são frequentemente perdidas ao atualizar uma página, já que há apenas 1 chance em 3 de você obter o processo de trabalho original que atendeu sua solicitação original.Mas isso não deveria importar, já que você está usando o serviço de estado ASP.NET.O que quebrou?

Ao usar o serviço de estado ASP.NET, o ASP.NET usa um valor chamado machineKey criptografar e/ou fazer hash de todos os dados da sessão a serem armazenados (não sei se é criptografia, hash ou ambos, mas não é uma distinção importante para esta discussão).Isso ocorre para que, quando qualquer processo de trabalho solicitar dados do serviço usando um identificador de sessão, ele possa ter certeza de que os dados não foram adulterados enquanto estavam sendo armazenados na fonte de dados externa.

Se você estiver em um web farm, provavelmente terá um arquivo estático machineKey definido em seu web.config arquivo e esse problema não ocorre.Mas para um cenário de web garden de servidor único, você provavelmente depende do padrão machineKey configuração, que está definida para AutoGenerate,IsolateApps para aplicativos ASP.NET 2.0.Isso significa que o ASP.NET gera automaticamente uma chave de máquina exclusiva para seu pool de aplicativos.Ele regenera esta chave de acordo com algum algoritmo, mas isso não é importante para esta discussão.

O valor gerado normalmente é armazenado no registro em HKLM\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys\{SID of the Application Pool Identity}.Mas o instalador do .NET Framework incorretamente (acredito que seja um bug) destrói essa chave de registro e, para piorar a situação, redefine as permissões dessa chave de forma que sua identidade personalizada do pool de aplicativos não possa gravar na entrada do registro quando ela for para criar sua nova chave de máquina.

O resultado é que cada processo de trabalho que gira no web garden está usando sua própria cópia na memória de uma chave de máquina gerada na hora certa, criando efetivamente um cenário de web farm por acidente.Por exemplo, o processo de trabalho A gira, vê que não AutoGenKey entrada existe (na verdade, ela não pode nem ler it), gera o seu próprio e começa a usá-lo para fazer hash dos dados enviados ao serviço de estado do ASP.NET.Ele tenta salvar essa nova chave de máquina na entrada do registro, mas falha silenciosamente.O processo de trabalho B gira, vê que não AutoGenKey entrada existe, gera a sua própria e começa a usar que para hash de dados... você vê onde isso vai dar.

O resultado é que agora você tem dados da sessão com hash com três chaves de máquina diferentes.Embora os dados para o identificador de sessão existam, dois em cada três processos de trabalho irão rejeitá-los como inválidos/adulterados porque estão usando sua própria chave.

Você poderia contornar isso definindo explicitamente um personalizado machineKey na tua web.config arquivo.

Ou você pode executar novamente aspnet_regiis.exe -ga MachineName\ApplicationPoolUserName em um prompt de comando para corrigir as permissões quebradas.

Seu problema está resolvido.Hora de ir para a cama.

---

ATUALIZAÇÃO em 30 de junho: De acordo com meu relatório sobre este problema em Microsoft Conexão, a Microsoft indicou que corrigiu o instalador de forma que esse comportamento não aconteça a partir das atualizações para o .NET 4.Isso ainda pode acontecer em todas as atualizações futuras 3.0/3.5, então deixarei esta pergunta/resposta como está.