IIS 服务器迁移过程详解

Response.Redirect(“MaintenanceAlert.html", false); 

<httpRedirect enabled="true" destination="Maintenance.htm" 
exactDestination="true" httpResponseStatus="Permanent" /> 

<location path="Hello.htm"> 
   <system.webServer> 
         <httpRedirect  enabled="false /> 
  </system.webServer> 
</location> 

<connectionString  configSource="connection.config"/> 
<appSettings configSource="AppSettings.config"/> 

框架在运行时将会搜索 connection.config  和  AppSettings.config 文件直到与Web.config文件相同的目录位置并且合并它。但是，问题还是没有解决。connection.config文件任然易于管理并且尺寸小，因为每一个条目代表一个数据库路径而且不是每一个网站都会用这么多数据库，但是一天天地 AppSettings.config 文件将会变大、变得不易于管理。因为每一天开发者将会向这个文件增加关键字/值。移动之后AppSettings改变了，因为一些旧的值需要被新的值替换。运行新的网站时，我们发现一些功能的执行和预期不一样。调查后我们发现一些值被不同的不同关键字多次建立。比如在一个地方我们发现：

<add key="smtpHost" value="192.168.0.1" /> 

在另一个地方发现 ：

<add key="mailServer" value="192.168.0.1" /> 

当我们用新邮件服务ip地址代替时，我们只改变了主机关键字，邮件服务关键字任然没有被改变。使用邮件服务关键字的组件不能发送邮件。因此，我们找出了所有重复的值并且用新的值替换了。但是，这是非常艰难的任务。我们没有发现这些关键字的正确说明。 

另一个可能发生的情况是，我们的系统有10-12个.NET可执行文件在windows任务调度程序中运行。每一个文件有它自己的配置文件。假定10个可执行文件有10个配置文件，而且每一个配置文件包含3个数据库连接线。 那么我们就需要替换所有这类文件的值。测试期间，我们的质量保证工程师汇报了一些调度程序没有正确运行的情况。我们发现不知道什么缘故，我们没有上传那个配置文件。为了解决这个问题，我们创建了一个根目录的ConnectionString.config 文件脚本，我们从所有配置文件中找到了那个ConnectionString.config 文件。用这个方法我们仅仅改变了一个文件，而且它将反应所有配置文件并解决那些依然没有被改变的配置值。 

<connectionString configSource="ConnectionString.config" /> 

#p#

文件系统安全问题

在测试我们的新网站时，我们发现网站的日志文件没有写。我们不能确定问题出在哪儿。调查之后，我们意识到我们需要对日志管理者授予必要的权限。哪个使用者需要这个权限呢？用户在其下运行的网站应用程序池帐户(在本例中我们运行网络服务)必须授予权限。

在我们的任务调度器中，我们创建了不同的必要权限的用户帐户来运行调度程序的可执行文件。在开发时期，我们看见许多开发者当面临权限有关的问题时，他允许每个人对他的个人电脑都有完全控制权限和修理权限。但是实际上这个方法忽视了一个问题。如果我们在我们的生产服务器中这样做了那么我们就对我们的整个系统打开了一个安全门，而且在未来这有可能发生很多安全问题。我发现了一个对安全问题最好方法的有效链接。

通用http处理程序(简单处理程序工厂集成)删除动/谓词丢失的问题

我们对异步请求使用通用的http处理程序而不是从我们的服务器中删除资源。这个处理程序将不包含“删除”http动/谓词。因此使用这个处理程序将不会删除任何资源文件。但是，如果有些需要删除，怎么做呢？我们仅仅需向处理程序添加“删除”动/谓词命令即可。预先，我们在旧的生产服务器中做了实验。但在我们的质量工程师汇报他不能在服务器中删除任何资源之前的很长一段时间我们忘了做这个事情。在调查这个问题之后我们发现我们忘了增加那个删除动/谓词了，添加这个词后我们解决了这个问题。#p#

统一登录问题

我们开发了一个网站，用于处理用户身份验证。我们的网站中有少数依赖该网站进行用户身份验证。如果用户身份验证通过，身份验证cookie返回请求的网站。多个站点共享相同的cookie，并允许用户访问该cookie认证的多个站点，简单来说就是登录一次便可访问其他多个站点。我们称之为统一登录。迁移完成后，我们发现我们的网站无法登录。只有一个消息传来-"用户无效"。首先，我们猜测数据库连接字符串是错误的。经过检查，我们发现每一个配置都是正确的。我们没有解决问题。我在本地PC上创建了一个统一登录的环境，发现它工作的很好。我审查了代码但依旧没有发现问题。我们知道进行身份验证登录网站时使用的是WCF安全服务。我们将容错模式"关闭"后在生产环境中独立运行，发现抛出DiretoryNotExists异常，但在我们当前的代码库中，我们没有发现任何这样的目录。我在svn库中需求帮助。我审查了旧版本的代码，发现在一个地方，它读取XML文件，并添加到文件缓存依赖对象。我们搜索这个文件夹发现这个目录在旧服务器上有，但新服务器上没有。我们明白了旧的生产代码没有被更新。我们从我们的临时服务器重新部署这些代码并修复了问题。

32位64位问题

[[75797]]

我刚才提到我们的旧服务器是32位的Windows 2003操作系统，而新的服务器是64位的Windows 2008服务器。迁移只是简单的将我们的代码从旧服务器复制到新的服务器。网站按预期工作。我们有10-12运行Windows任务调度程序的可执行文件，本来可正常工作，但QA工程师报告一些我们可以按需运行通过ajax请求的调度不能正常工作。调查时，我们发现，双击运行它时它没有运行并且不抛出任何错误消息。我们审查了代码和运行exe文件页面的Web方法：

Process.Start("Publish.exe"); 

我们搜索事件日志、错误日志以及网站日志试图发现导致这个情况的原因，但没有发现任何有用的资源。经过多次问题我们明白了，我们的网站应用程序池运行在64位上。但我们的临时服务器是32位。我们使用SVN代码库中建立的可执行文件是32位的。当我们将应用程序池从64位换到32位它是工作正常的，我们定位了问题。我们重置回64位应用程序池，并在64位开发PC上重编译了我们的调度程序，重新部署到新的生产服务器，工作以前正常。#p#

Ajax Pro 在IIS 7.5的注册问题

Ajax pro 是一个基于.NET的ajax交互组件。如果你想知道更多这个组件的细节，请点击下面的链接进行访问。

AjaxPro .NET

我们使用AjaxPro和Jqery库进行ajax的实时交互。在先前的服务器上，我们发现工作得很好。但是在我们新的生产环境里，我们发现Ajaxpro不工作了，但是jquery工作良好，我找到2个解决这个问题得比较好的链接。

• Link1
• Link2

其实在以前的IIS6.0，我们注册组件在下面的节点。

<httpHandlers> 
  <add verb="POST,GET" path="ajaxpro/*.ashx" 
  type="AjaxPro.AjaxHandlerFactory, AjaxPro.2"/> 
</httpHandlers> 

但是在iis7，这个配置如果并不工作，他被新的节点所取代。

<system.webServer> 
  <handlers> 
      <add name="AjaxPro" verb="*" path="ajaxpro/*.ashx" 
      type = "AjaxPro.AjaxhandlerFactory, AjaxPro.2 resourceType="unspecified" /> 
  </handlers> 
</system.webServer> 

System.Transactions.TransactionScope 问题

我们使用System.Transactions.TransactionScope对象执行我们的事务。

但是当我们测试的时候发现这个错误。

我们开始收集这个问题，发现下面这个又有的链接。

How i use TransactionScope

我们的web服务器和数据库是两个不同的物理服务器。

我们需要在两台服务器都需要开启事务，然后我们发现他工作正常了。#p#

HTTP还是HTTPS 问题

在我们的开发和登台服务器（译注：staging server登台服务器，交付准备服务器）环境中，我们使用的是http。但在生产服务器环境中，我们使用https来进行安全通信。在测试新服务器的过程中，我们发现有个奇怪的错误冒出来。我们看到的错误，在crome浏览器中看起来是这样的

在 Internet Explorer这个错误像这样：

我们着手研究这个错误，找到了2个非常有用的链接。

• 链接1
• 链接2

我们明白了是哪里做错了。我们使用的是cdn上http形式的jquey路径

http://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js

所以在我们的https网站中，浏览器抛出了不安全内容的警告。

我们仅仅只是将CDN定位中http替换为https便修复了这个问题。

https://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js

#p#

localhost 与 127.0.0.1 问题

在迁移和配置完新的邮件服务器后，我们发现我们的邮件不能发生。在我们的配置文件中，smtphost间值是使用的localhost。在调查的时候，我们发现了两个非常有用的链接。

localhost or 127.0.01

StackOverflow thred

我们替换了配置节点中的localhost为127.0.0.1，发现邮件发送正确了。

SSRS 报表文件(.rdl) 未上传问题

(译注：SSRs，SQL Server Reporting Services)

从老服务器下载所有rdl文件，在上传到新服务器的时候，我发现有2个文件没有上传。文件抛出异常。异常信息是“ssrs报表私有位置未找到私有程序集custom.dll”。经过研究我们发现有2个rdl文件使用私有程序集custom.dll。SSRS报表从它的私有程序集目录的位置查找那个dll文件。这个位置是：

%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies 

在将那个dll分发到这个目录之后，rdl文件便正常上传并解决了我们的问题。#p#

数据库未启用SQL CLR(SQL 公共语言运行库) 问题

在sql服务器的存储过程中，我们使用了clr函数。我们还使用了一些第三方sql clr函数。结果在测试新服务器的时，发生了一个异常“你的数据库未启用SQL CLR”(SQL CLR not enabled to your database)。在排查这个问题的过程中，我找到了一个非常好的链接启用CLR的过程。

在给我们的生产服务器启用sql服务器clr选项以后，这个问题就解决了。

SSRS 报表文件夹权限问题

在部署完成所有的报表到新的生产服务器后，报表仍然不显示。在调查的时候，我们发现了这个有用的链接（SSRS Report Folder Permission）。

我们创建了一个系统用户帐号，并且分配了新的用户和角色分配给报表文件夹，发现每个报表都可以显示了。

SSRS 报表默认图标不显示

在做报表测试的时候，我们发现一个非常有趣的问题。报表默认导航图标(First, Previous, Next, Last)不显示。在那时我们非常迷惑，应为那时sql server默认的图片。我们不知道怎么来修复这个问题，在那段时间里，我们发现2个非常有用的链接。

• Link1
• Link

我们才明白那是IIS6和IIS7相关的问题，我们需要注册这个处理程序到iis7。

<handlers> 
    <add name ="ReportViewerWebControlHandler" preCondition="integratedMode" 
    verb="*" path="Reserved.ReportViewerControl.axd" 
    type="Microsoft.Reporting.WebForms.HttpHandler, 
    Microsoft.ReportViewer.WebForms, Version=8.0.0.0, 
    Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> 
</handlers> 

在注册完这个处理程序到iis7之后，我们发现默认的图片显示问题得到了解决。#p#

客户端PC中的DNS刷新问题

我们开始测试新迁移的服务器网站时，旧服务器仍在运行，而且两台服务器的dns名字是一样的。那么怎样测试新网站呢？一个解决办法是添加主机条目。但仅仅主机条目并不能解决这个问题。首先我们应该关闭所有浏览器。

然后在命令提示窗口执行dnsflush命令。接着我们就可以打开浏览器，通过url访问网站，观察远端ip并确保请求被发送到新服务器。

总结

我很难覆盖到迁移生产环境服务器时所面对的所有场景。但我已经尽力覆盖了迁移旧服务器到新服务器过程中的尽可能多的场景。我希望在不久的将来，如果有人做类似的工作时，这篇文章可以帮助他。

原文链接：http://www.oschina.net/translate/production-server-migration-challenges

参与翻译：PandaCub, Yoker, super0555, Garfielt