Upgrade von .NET 3.0 auf 3.5: Websites, die auf den Staatserver gesetzt sind

Question

Szenario:

Nehmen Sie einen Server, der .NET 3.0 und eine ASP.NET -Website, die in einem Anwendungspool mit Webgärten ausgeführt wird, aktiviert (Anzahl der Prozesse: 3). Die Web.config -Konfiguration lautet wie folgt:

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

Aktualisieren Sie nun die Maschine auf .NET 3.5 SP1. Starten Sie den Server neu. Ergebnis: Die Sitzungen werden nicht mehr über Instanzen von W3WP.Exe aufrechterhalten, als wären alle zu Inproc zurückgekehrt. Die Reduzierung auf 1 Arbeiterprozess ist die derzeitige Problemumgehung.

Was seltsam ist: Gleicher Code auf verschiedenen Server hat keine Probleme. Ich habe dieses Problem schon einmal erlebt, aber es verschwand auf magische Weise nach einem Neustart. Ich habe schon einmal neu gestartet, aber bisher keine Freude.

Vergleich der beiden Maschinen.configs und Web.Configs der beiden Server: identisch.

Jemand anderes hat dieses Problem erlebt, aber keine Antwort dort.

Irgendwelche Ideen? Ich bin Ja wirklich auf diesem verblüfft.

Answer 1

Dieser war also einfach unglaublich.

Das Problem scheint auftreten, wenn alle folgenden Bedingungen wahr sind:

• Sie führen Windows Server 2003 (IIS 6.0) und eine ASP.NET 2.0 -Website aus.
• Die Website ist konfiguriert, um Webgärten zu verwenden, bei denen die maximale Anzahl von Arbeitsprozessen größer als 1 ist. Daher haben Sie Ihre Anwendung so konfiguriert, dass Sie einen Speicher außerhalb des Verfahrens verwenden. In diesem Szenario ist der ASP.NET -Statusdienst auf der lokalen Maschine.
• Die Identität des Anwendungspools wird nicht auf Netzwerkdienst, sondern auf ein benutzerdefiniertes, privilegiertes Benutzerkonto festgelegt, das Sie per a erstellt haben Best Practice für den Einsatz.
• Sie führen einen Installateur aus, der das .NET -Framework aktualisiert. In meinem Fall war dies ein Update von .NET 3.0 bis .NET 3.5 SP1.

Wenn das Upgrade abgeschlossen ist und Sie den Server neu starten, stellen Sie fest, dass Ihre Sitzungsvariablen häufig bei der Aktualisierung einer Seite verloren gehen, da nur eine 1: 3 -Chance besteht, dass Sie den ursprünglichen Arbeitsprozess erhalten, der Ihre ursprüngliche Anfrage bedient. Dies sollte jedoch keine Rolle spielen, da Sie den ASP.NET State -Service verwenden. Was ist kaputt gegangen?

Bei Verwendung des ASP.NET -Statusdienstes verwendet ASP.NET einen Wert, der als die genannt wird machineKey Um alle Sitzungsdaten zu verschlüsseln und/oder Hash zu speichern (ich weiß nicht, ob es sich um Verschlüsselung oder Hashing oder beides handelt, aber es ist keine wichtige Unterscheidung für diese Diskussion). Dies ist so, dass wenn ein Arbeitsprozess nach Daten aus dem Dienst mithilfe einer Sitzungskennung fragt, sicher sein kann, dass die Daten nicht manipuliert wurden, während sie in der externen Datenquelle gespeichert wurden.

Wenn Sie auf einer Webfarm sind, haben Sie wahrscheinlich eine Statik machineKey in Ihrem definiert web.config Datei, und dieses Problem tritt nicht auf. Aber für ein Web-Garten-Szenario mit einem Server sind Sie wahrscheinlich auf die Standardeinstellung angewiesen machineKey Einstellung, die auf eingestellt ist AutoGenerate,IsolateApps Für ASP.NET 2.0 -Anwendungen. Dies bedeutet, dass ASP.NET automatisch einen Maschinenschlüssel generiert, der für Ihren Anwendungspool eindeutig ist. Es regeneriert diesen Schlüssel nach einem Algorithmus, aber das ist für diese Diskussion nicht wichtig.

Der generierte Wert wird normalerweise in der Registrierung unter gespeichert HKLM\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys\{SID of the Application Pool Identity}. Das .NET -Framework -Installateur fälschlicherweise (ich glaube, dies ist ein Fehler) zerstört diesen Registrierungsschlüssel und setzt die Berechtigungen auf diesem Schlüssel, dass Ihre benutzerdefinierte Bewerbungspool -Identität nicht in den Registrierungseintrag schreiben kann, die Berechtigungen auf diesem Schlüssel zurück Um seinen neuen Maschinenschlüssel zu erstellen.

Das Ergebnis ist, dass jeder Arbeiterprozess, der im Webgarten zusammenbricht, eine eigene Kopie eines Maschinenschlüssels verwendet, die gerade rechtzeitig generiert wurde, und ein Versehen effektiv ein Webfarm-Szenario erstellt. Zum Beispiel, verarbeitet der Arbeit AutoGenKey Eintritt gibt es (in der Tat kann er nicht einmal lesen IT), generiert sich selbst und beginnt, diese an Hash -Daten zu verwenden, die an den ASP.NET State -Service gesendet werden. Es versucht, diesen neuen Maschinenschlüssel für den Registrierungseintrag zu speichern, scheitert jedoch stillschweigend. Arbeiterprozess B dreht sich und sieht das nein AutoGenKey Der Eintrag existiert, erzeugt seine eigenen und beginnt zu verwenden das Zu Hash -Daten ... Sie sehen, wohin das geht.

Das Ergebnis ist jetzt, dass Sie Sitzungsdaten mit drei verschiedenen Maschinenschlüssel hashiert haben. Obwohl die Daten für die Sitzungskennung vorhanden sind, lehnen zwei von drei der Arbeitsprozesse sie als ungültig/manipuliert ab, da sie einen eigenen Schlüssel verwenden.

Sie können dies umgehen, indem Sie explizit einen Brauch einstellen machineKey in deiner web.config Datei.

Oder Sie könnten erneut laufen aspnet_regiis.exe -ga MachineName\ApplicationPoolUserName Bei einer Eingabeaufforderung, die kaputten Berechtigungen zu reparieren.

Ihr Problem ist gelöst. Zeit ins Bett zu gehen.

---

Update 30. Juni: Pro Bericht über dieses Problem auf Microsoft Connect, Microsoft hat angegeben, dass sie das Installationsprogramm so behoben haben, dass dieses Verhalten nicht mit Upgrades auf .NET 4 stattfindet. Es könnte immer noch für alle zukünftigen 3.0/3.5 -Upgrades passieren, also werde ich diese Frage/Antwort stehen.