Обновление от.NET 3.0 к 3,5: набор Сайтов к StateServer возвращается в InProc когда в веб-Саду

Так, этот был просто удивителен.

Проблема, кажется, происходит, когда все следующие условия верны:

• Вы выполняете Windows Server 2003 (IIS 6.0) и ASP.NET 2,0 веб-сайта.
• Веб-сайт, настраивают для использования веб-Садов, где максимальное количество рабочих процессов больше, чем 1. Из-за этого Вы настроили свое приложение для использования устройства хранения данных сессии из процесса; в этом сценарии, Государственная служба ASP.NET, работающая на локальной машине.
• Идентификационные данные пула приложений установлены не на СЕТЕВУЮ СЛУЖБУ, но в пользовательскую учетную запись низкого привилегированного пользователя, которую Вы создали на лучшую практику развертывания.
• Вы запускаете установщик, который обновляет платформу.NET; в моем случае это было обновлением от.NET 3.0 к.NET 3,5 SP1.

Когда концы обновления и Вы перезагружаете сервер, Вы находите, что Ваши переменные сеанса часто теряются после обновления страницы, так как существует только 1 в 3 шансах Вас получающий исходный рабочий процесс, который обслуживал Ваш исходный запрос. Но это не должно иметь значения, так как Вы используете государственную службу ASP.NET. Что повредилось?

При использовании государственной службы ASP.NET ASP.NET использует значение, названное machineKey чтобы зашифровать и/или хешировать все данные сессии, которые будут сохранены (я не знаю, шифруют ли они или хешируют или оба, но это не важное различие для этого обсуждения). Это - то, так, чтобы, когда любой рабочий процесс просит данные из сервиса с помощью идентификатора сессии, это могло быть уверено, что в данные не вмешались, в то время как это хранилось во внешнем источнике данных.

Если Вы находитесь на веб-ферме, то у Вас, вероятно, есть помехи machineKey определенный в Вашем web.config файл и эта проблема не происходят. Но для веб-сценария сада единственного сервера, Вы, вероятно, полагаетесь на значение по умолчанию 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 неправильно (я действительно верю этому, является ошибкой), уничтожает этот ключ реестра и, для добавления оскорбления травмы, сбрасывает полномочия на этом ключе, таким образом, что идентификационные данные пула пользовательского приложения не могут записать в ключ реестра, когда это идет для создания его нового ключа машины.

Результат состоит в том, что каждый рабочий процесс, который вращается в веб-саду, использует свою собственную копию в оперативной памяти ключа машины, который он генерировал как раз вовремя, эффективно создав сценарий веб-фермы случайно. Например, рабочий процесс вращения, видит что нет AutoGenKey запись существует (действительно, она не может даже считать его), генерирует ее собственное и начинает использовать это для хеширования данных, отправленных в Государственную службу ASP.NET. Это пытается сохранить этот новый ключ машины к ключу реестра, но перестало работать тихо. Рабочий процесс B вращения, видит что нет AutoGenKey запись существует, генерирует свое собственное и начинает использовать это для хеширования данных... Вы видите, куда это идет.

Результат теперь, Вам хешировали данные сессии с тремя различными ключами машины. Хотя данные для идентификатора сессии существуют, два из трех из рабочих процессов отклонит его как недопустимый/вмешивающийся, потому что это использует свой собственный ключ.

Вы могли обойти это путем явной установки пользовательского machineKey в Вашем web.config файл.

Или Вы могли повторно выполниться aspnet_regiis.exe -ga MachineName\ApplicationPoolUserName в Командной строке для согласовывания поврежденных полномочий.

Ваша проблема решена. Время, чтобы лечь спать.

ОБНОВЛЕНИЕ 30-го июня: На мое сообщение об этой проблеме о Microsoft Connect Microsoft указала, что они исправили установщик, таким образом, что этого поведения не произойдет, начинаясь с обновлений.NET 4. Это все еще могло произойти для всего будущего 3.0/3.5 обновления, таким образом, я оставлю это положение вопроса/ответа.