Aggiornamento da .NET 3,0-3,5: Siti impostati StateServer ritornano al InProc quando in Web Garden

Question

Scenario:

Prendere un server che esegue .NET 3.0 e un sito Web ASP.NET in esecuzione in un pool di applicazioni che ha giardini Web abilitati (numero di processi: 3). La configurazione web.config è la seguente:

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

Ora aggiornare la macchina per .NET 3.5 SP1. Riavviare il server. Risultato: le sessioni non vengono mantenute tra le istanze di w3wp.exe, come se tutta la sono ritornati al InProc. Ridurre a 1 processo di lavoro è la soluzione corrente.

Cosa c'è di strano: lo stesso codice sul server di diverse esperienze senza problemi. Ho sperimentato questo problema prima, ma magicamente andato via dopo un riavvio. Ho ricominciato già una volta, ma nessuna gioia finora.

Confrontando i due machine.configs e web.configs dei due server:. Identica

Qualcun altro ha sperimentato questo problema , ma nessuna risposta lì.

Tutte le idee? Sono davvero perplesso su questo.

Answer 1

Quindi, questo era semplicemente fantastico.

Il problema sembra verificarsi quando tutte le seguenti condizioni:

• è in esecuzione Windows Server 2003 (IIS 6.0) e un sito web ASP.NET 2.0.
• Il Sito è configurare per utilizzare Giardini Web, in cui il numero massimo di processi di lavoro è superiore a 1. A causa di questo, è stato configurato l'applicazione per utilizzare una memoria di sessione out-of-process; in questo scenario, il servizio di stato ASP.NET in esecuzione sulla macchina locale.
• L'identità del pool di applicazioni è impostato per non rete di assistenza, ma di una consuetudine, account utente con privilegi ridotti che si è creato per un implementazione delle migliori pratiche .
• Si esegue un programma di installazione che aggiorna il framework .NET; nel mio caso, questo è stato un aggiornamento da .NET 3.0 di .NET 3.5 SP1.

Al termine di aggiornamento e di riavviare il server, si scopre che le variabili di sessione sono spesso perduta al momento l'aggiornamento di una pagina, in quanto c'è solo un 1 in 3 possibilità di voi ottenere il processo di lavoro originale che ha servito la richiesta originale. Ma questo non dovrebbe importare, dal momento che si sta utilizzando il servizio di stato ASP.NET. Che ha rotto?

Quando si utilizza il servizio di stato ASP.NET, ASP.NET utilizza un valore chiamato il machineKey per crittografare e / o hash tutti i dati della sessione da memorizzare (non so se è la crittografia o hashing o di entrambi, ma non è una distinzione importante per questa discussione). Questo è così che quando qualsiasi processo di lavoro chiede dato derivante dal servizio mediante un identificatore di sessione, si può essere sicuri che i dati non sono stati manomessi mentre veniva immagazzinata nella sorgente di dati esterna.

Se siete su una web farm, allora probabilmente avete un machineKey statica definito nel file web.config, e questo problema non si verifica. Ma per uno scenario unico web server da giardino, probabilmente contare su l'impostazione predefinita machineKey, che è impostato per AutoGenerate,IsolateApps per le applicazioni ASP.NET 2.0. Ciò significa che ASP.NET genera automaticamente una chiave macchina che è unico al vostro pool di applicazioni. Rigenera questa chiave secondo alcuni algoritmi, ma che non è importante per questa discussione.

Il valore generato viene normalmente memorizzato nel Registro di sistema HKLM\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys\{SID of the Application Pool Identity}. Ma il programma di installazione di .NET Framework in modo non corretto (io credo che questo sia un bug) distrugge questa chiave di registro e, per aggiungere la beffa al danno, reimposta le autorizzazioni per questa chiave in modo tale che la vostra abitudine identità pool di applicazioni non può scrivere la voce del Registro quando va per creare la sua nuova chiave del computer.

Il risultato è che ogni processo di lavoro che gira nel giardino web sta usando la propria copia in memoria di una chiave di macchina che ha generato appena in tempo, creando di fatto uno scenario Web farm per caso. Ad esempio, un processo di lavoro gira su, vede che nessuna voce AutoGenKey esiste (anzi, non si può neanche lettura di esso), genera il proprio e inizia ad usare che di hash dei dati inviati al servizio stato di ASP.NET . Si cerca di salvare questa nuova chiave macchina alla voce di registro, ma non riesce in silenzio. Il processo di lavoro B gira in su, vede che non esiste alcuna voce AutoGenKey, genera la propria e comincia con che di hash dei dati ... a vedere dove questo sta andando.

Il risultato è ora di avere i dati della sessione hash con tre diverse chiavi della macchina. Anche se esiste il dato per l'identificatore di sessione, due su tre dei processi di lavoro lo rifiuterà come non valido / manomesso perché sta usando la propria chiave.

Si potrebbe ottenere intorno a questo impostando in modo esplicito un machineKey personalizzato nel file web.config.

Oppure si potrebbe ri-eseguire aspnet_regiis.exe -ga MachineName\ApplicationPoolUserName al prompt dei comandi per sistemare i permessi rotti.

Il problema è risolto. È ora di andare a letto.

---

UPDATE 30 giugno: Per la mia relazione di questo problema Microsoft Connect , Microsoft ha indicato che essi hanno fissato l'installatore in modo tale che questo comportamento non accadrà a cominciare con gli aggiornamenti a .NET 4. ancora potrebbe accadere per tutti i futuri 3.0 / 3.5 aggiornamenti, quindi dovrò lasciare questa domanda / risposta in piedi.