升级从.NET 3.0到3.5：设置为StateServer站点恢复使用inproc在Web园时， [英] Upgrade from .NET 3.0 to 3.5: Sites set to StateServer revert to InProc when in Web Garden

问题描述

方案：

以运行.NET 3.0的服务器和ASP.NET网站在启用了Web园应用程序池中运行（进程数：3）。在web.config配置如下：

Take a server running .NET 3.0 and an ASP.NET Web site running in an application pool that has Web gardens enabled (number of processes: 3). The web.config configuration is as follows:

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

现在机器升级到.NET 3.5 SP1。重新启动服务器。结果：会跨的w3wp.exe的实例，不再维护，好像所有的都恢复了使用inproc。降至1工作进程是当前的解决方法。

Now upgrade the machine to .NET 3.5 SP1. Reboot the server. Result: sessions are no longer maintained across instances of w3wp.exe, as if all of the have reverted to InProc. Reducing to 1 worker process is the current workaround.

什么是奇怪的：不同的服务器上同code遇到任何问题。我以前就遇到过这个问题，但它奇迹般地走在重新启动后。我重新启动一次了，但没有喜悦为止。

What's strange: Same code on different server experiences no problems. I've experienced this problem before, but it magically went away after a restart. I restarted once already, but no joy so far.

两相比较machine.configs两台服务器和web.configs：相同

Comparing the two machine.configs and web.configs of the two servers: identical.

否则有人遇到过这个问题，但没有答案了。

任何想法？我的真正的难住了这一点。

Any ideas? I'm really stumped on this one.

推荐答案

那么，这个人只是惊人的。

So, this one was just amazing.

这个问题似乎当所有下列条件为真会发生：

The problem appears to occur when all of the following conditions are true:

• 您正在运行Windows Server 2003（IIS 6.0）和ASP.NET 2.0的网站。
• 在该网站是配置为使用Web园，在那里工作进程的最大数量大于1。正因为如此，你已经配置你的应用程序使用进程外的会话存储;在这种情况下，运行在本地计算机上的ASP.NET状态服务。
• 在该应用程序池标识设置为不网络服务，而是一个自定义的，你每一个的部署的最佳实践。
• 您运行更新.NET框架的安装程序;于我而言，这是从.NET 3.0到.NET 3.5 SP1的更新。

• You are running Windows Server 2003 (IIS 6.0) and an ASP.NET 2.0 web site.
• The Web site is configure to use Web Gardens, where the maximum number of worker processes is greater than 1. Because of this, you have configured your application to use an out-of-process session storage; in this scenario, the ASP.NET State Service running on the local machine.
• The application pool identity is set not to NETWORK SERVICE but to a custom, low-privileged user account that you created per a deployment best practice.
• You run an installer that updates the .NET framework; in my case, this was an update from .NET 3.0 to .NET 3.5 SP1.

当升级完成并重新启动服务器，你会发现，你的会话变量经常丢失后刷新页面，因为只有1/3的机会，你得到的服务您的原始请求中的原始工作进程。但是，这不应该的问题，因为你使用ASP.NET状态服务。怎么打破？

When the upgrade finishes and you reboot the server, you find that your session variables are frequently lost upon refreshing a page, since there is only a 1 in 3 chance of you getting the original worker process that served your original request. But this shouldn't matter, since you're using the ASP.NET state service. What broke?

在使用ASP.NET状态服务，ASP.NET使用一种叫做值的machineKey 来加密和/或散列所有的会话数据存储（我不知道它是否加密或哈希或两者兼而有之，但它不是一个重要的区别为这个讨论）。这是这样，当任何工作进程请求使用会话标识符从服务数据，它可以是肯定的数据没有被篡改，而这是所存储的外部数据源与

When using the ASP.NET state service, ASP.NET uses a value called the machineKey to encrypt and/or hash all session data to be stored (I don't know if it's encrypting or hashing or both, but it's not an important distinction for this discussion). This is so that when any worker process asks for data from the service using a session identifier, it can be sure that the data was not tampered with while it was being stored in the external data source.

如果你是一个Web场，那么你可能有一个静态的machineKey 中定义的的web.config 文件，并且此问题不会发生。但是，对于单服务器Web园的情况下，你可能依赖于默认的machineKey 设置，它被设置为自动生成，IsolateApps 为ASP.NET 2.0应用程序。这意味着，ASP.NET自动生成一个机器密钥是唯一的应用程序池。它再生该键按照某种算法，但这不是在本讨论重要

If you are on a web farm, then you probably have a static machineKey defined in your web.config file, and this issue does not occur. But for a single-server web garden scenario, you probably rely on the default machineKey setting, which is set to AutoGenerate,IsolateApps for ASP.NET 2.0 applications. This means that ASP.NET automatically generates a machine key that is unique to your application pool. It regenerates this key according to some algorithm, but that is not important for this discussion.

生成的值通常存储在注册表中 HKLM \ SOFTWARE \微软\ ASP.NET \ 2.0.50727.0 \ AutoGenKeys \ {应用程序池标识的SID} 。但是，在.NET Framework安装程序错误（我相信这是一个错误）破坏此注册表项，并于雪上加霜的是，重置在这关键的权限，使您的自定义应用程序池标识不能写入注册表项时，它会创造了新的计算机密钥。

The generated value is normally stored in the registry under HKLM\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys\{SID of the Application Pool Identity}. But the .NET Framework installer incorrectly (I do believe this is a bug) destroys this registry key and, to add insult to injury, resets the permissions on this key such that your custom application pool identity cannot write to the registry entry when it goes to create its new machine key.

其结果是，每个工作进程的旋转起来，在Web园是使用机械钥匙了自己的内存拷贝，它产生的只是在时间，有效地创建一个Web场方案意外。例如，工作进程旋转起来，认为没有 AutoGenKey 项存在（事实上，它甚至不能的读的吧），生成自己，并开始使用散列发送到ASP.NET状态服务的数据。它试图挽救这款新机关键注册表项，而是静静地失败。工人进程B旋转起来，认为没有 AutoGenKey 项存在，产生自己的，并开始使用的是的散列数据......你看到这个是怎么回事。

The result is that each worker process that spins up in the web garden is using its own in-memory copy of a machine key that it generated just in time, effectively creating a web farm scenario by accident. For example, worker process A spins up, sees that no AutoGenKey entry exists (indeed, it cannot even read it), generates its own and begins using that to hash data sent to the ASP.NET State Service. It tries to save this new machine key to the registry entry, but fails silently. Worker process B spins up, sees that no AutoGenKey entry exists, generates its own and begins using that to hash data...you see where this is going.

其结果是，现在你有散列有三个不同的计算机密钥的会话数据。虽然数据会话标识符存在，三分之二的工作进程将拒绝为无效/篡改，因为它使用自己的密钥。

The result is now you have session data hashed with three different machine keys. Though the data for the session identifier exists, two out of three of the worker processes will reject it as invalid/tampered because it is using its own key.

您可以围绕这明确地设置一个自定义的的machineKey 在的web.config 文件。

You could get around this by explicitly setting a custom machineKey in your web.config file.

或者你也可以重新运行 ASPNET_REGIIS.EXE -ga计算机名\ ApplicationPoolUserName 在命令提示符来修复破碎的权限。

Or you could re-run aspnet_regiis.exe -ga MachineName\ApplicationPoolUserName at a Command Prompt to fix up the broken permissions.

您的问题就解决了​​。时间去睡觉。

Your problem is solved. Time to go to bed.

---

更新6月30日：按我这个问题的报告<一href="http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=412881">Microsoft连接，微软已经表示，他们有固定的安装等，这种行为不会发生与升级开始.NET 4它仍然可能发生以后的所有3.0 / 3.5的升级，所以我会离开这个问题/应答的地位。

UPDATE June 30th: Per my report of this issue on Microsoft Connect, Microsoft has indicated that they have fixed the installer such that this behavior won't happen beginning with upgrades to .NET 4. It still could happen for all future 3.0/3.5 upgrades, so I'll leave this question/answer standing.

这篇关于升级从.NET 3.0到3.5：设置为StateServer站点恢复使用inproc在Web园时，的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！