.NET 3.0 から 3.5 にアップグレードします。StateServer に設定されたサイトが Web Garden の場合に InProc に戻る

Question

シナリオ：

.NET 3.0 を実行しているサーバーと、Web ガーデンが有効になっているアプリケーション プールで実行されている ASP.NET Web サイトを考えます (プロセス数:3)。web.config 構成は次のとおりです。

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

次に、マシンを .NET 3.5 SP1 にアップグレードします。サーバーを再起動します。結果：すべてのインスタンスが InProc に戻ったかのように、セッションは w3wp.exe のインスタンス間で維持されなくなります。現在の回避策は、ワーカー プロセスを 1 つに減らすことです。

何が奇妙なのか:異なるサーバー上の同じコードでは問題は発生しません。以前にもこの問題に遭遇したことがありますが、再起動すると魔法のように消えました。すでに一度再起動しましたが、今のところ喜びはありません。

2 つのサーバーの 2 つの machine.config と web.config を比較します。同一。

他の人もこの問題を経験しています, 、しかしそこには答えはありません。

何か案は？私は 本当に これにはつまづきました。

Answer 1

それで、これは本当に素晴らしかったです。

この問題は、次の条件がすべて当てはまる場合に発生するようです。

• Windows Server 2003 (IIS 6.0) と ASP.NET 2.0 Web サイトを実行しています。
• Web サイトは、ワーカー プロセスの最大数が 1 より大きい Web ガーデンを使用するように構成されています。このため、アウトプロセス セッション ストレージを使用するようにアプリケーションを構成しました。このシナリオでは、ASP.NET State Service がローカル マシン上で実行されます。
• アプリケーション プール ID は、NETWORK SERVICE ではなく、ユーザーが作成した権限の低いカスタム ユーザー アカウントに設定されます。 導入のベストプラクティス.
• .NET Framework を更新するインストーラーを実行します。私の場合、これは .NET 3.0 から .NET 3.5 SP1 への更新でした。

アップグレードが完了し、サーバーを再起動すると、元のリクエストを処理した元のワーカー プロセスを取得できる可能性は 3 分の 1 しかないため、ページの更新時にセッション変数が頻繁に失われることがわかります。ただし、ASP.NET 状態サービスを使用しているため、これは問題ではありません。何が壊れたの？

ASP.NET 状態サービスを使用する場合、ASP.NET は、 machineKey 保存するすべてのセッション データを暗号化および/またはハッシュします (暗号化なのかハッシュなのか、あるいはその両方なのかはわかりませんが、この議論では重要な区別ではありません)。これは、ワーカー プロセスがセッション ID を使用してサービスにデータを要求するときに、データが外部データ ソースに保存されている間に改ざんされていないことを確認できるようにするためです。

Web ファームを使用している場合は、おそらく静的な machineKey で定義されている web.config ファイルが存在する場合、この問題は発生しません。ただし、単一サーバーの Web ガーデン シナリオでは、おそらくデフォルトに依存するでしょう。 machineKey に設定されている設定 AutoGenerate,IsolateApps ASP.NET 2.0 アプリケーションの場合。これは、ASP.NET がアプリケーション プールに固有のマシン キーを自動的に生成することを意味します。何らかのアルゴリズムに従ってこのキーを再生成しますが、それはこの説明では重要ではありません。

生成された値は通常、次のレジストリに保存されます。 HKLM\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys\{SID of the Application Pool Identity}. 。しかし、.NET Framework インストーラーは誤って (これはバグだと思います) レジストリ キーを破壊し、さらにひどいことに、このキーのアクセス許可をリセットして、カスタム アプリケーション プール ID がレジストリ エントリに書き込むことができないようにします。新しいマシンキーを作成します。

その結果、Web ガーデンで起動する各ワーカー プロセスは、ジャストインタイムで生成したマシン キーの独自のメモリ内コピーを使用し、実質的に Web ファーム シナリオを偶然作成することになります。たとえば、ワーカー プロセス A がスピンアップし、何もないことがわかります。 AutoGenKey エントリが存在します（実際には、 読む それ)、独自のデータを生成し、それを使用して ASP.NET State Service に送信されるデータをハッシュします。この新しいマシン キーをレジストリ エントリに保存しようとしますが、何も表示されずに失敗します。ワーカー プロセス B がスピンアップし、何もないことがわかります。 AutoGenKey エントリが存在し、独自のエントリを生成して使用を開始します それ データをハッシュする...これがどこに向かうのかがわかります。

その結果、3 つの異なるマシン キーでハッシュされたセッション データが得られます。セッション識別子のデータは存在しますが、独自のキーを使用しているため、ワーカー プロセスの 3 つのうち 2 つが無効/改ざんされているとして拒否します。

明示的にカスタムを設定することでこれを回避できます machineKey あなたの中で web.config ファイル。

または、再実行することもできます aspnet_regiis.exe -ga MachineName\ApplicationPoolUserName コマンド プロンプトで壊れた権限を修復します。

あなたの問題は解決されました。寝る時間です。

---

6月30日の更新: この問題に関する私のレポートによると、 マイクロソフト接続, Microsoft は、.NET 4 へのアップグレード以降、この動作が発生しないようにインストーラーを修正したことを示しました。今後のすべての 3.0/3.5 アップグレードでもこの問題が発生する可能性があるため、この質問と回答はそのままにしておきます。