升级到 SharePoint 2010 与您经历过的其他升级过程截然不同。甚至在您开始对升级进行规划之前，您就需要熟悉 SharePoint 2010 的系统要求。与之前的 SharePoint 版本不同，SharePoint 2010 只能用于 64 位系统。因此，您必须在 64 位版本的 Windows Server 2008 或 Windows Server 2008 R2 上安装 SharePoint 2010。
SharePoint 需要 SQL Server 数据库，但该数据库不必与 SharePoint 位于同一台服务器上。SharePoint 2010 仍需要 SQL Server，但 Microsoft 做出了一些重要变更。SharePoint 2010 要求数据库必须运行 64 位版本的 SQL Server 2005 或 2008。无论数据库是否以本地方式安装在 SharePoint 服务器上，都必须满足此要求。
尽管从技术角度而言，Web 浏览器不能算作一项系统要求，但您也要考虑所使用的 Web 浏览器。SharePoint 2010 可以更好地利用各种 Web 标准。这意味着用户无论是使用 Internet Explorer 还是 Firefox（3.x 或更高版本）都能获得一致的体验。只有一件事需要注意，那就是 SharePoint 2010 对 Internet Explorer 6 只提供了有限的支持。IE6 用户查看 SharePoint 内容不会遇到问题，但编写内容则需要使用 IE7 或更高版本（或者是 Firefox 3.x 或更高版本）。
就地升级
您可能已经知道，SharePoint 2010 允许从 Microsoft Office SharePoint Server （MOSS） 2007 进行就地升级。但由于 SharePoint 2010 是 64 位的，因此只有当您现有的 MOSS 2007 是运行在 64 位版本的 Windows Server 2008 上时，您才能执行就地升级。如果您现有的 SharePoint 服务器满足所需的系统要求，则可以在 SharePoint 场的每台服务器上执行就地升级。
尽管 SharePoint 完全支持这些升级方法，但只有当您的 SharePoint 部署简单且未进行任何自定义时，我才推荐您执行就地升级。在更为复杂的环境中，我建议执行全面迁移，因为这样可以使您更好地控制升级过程。如果您进行了自定义，也建议采用全面迁移，因为这样可以避免意外覆盖这些自定义内容。
迁移一般需要构建全新的运行 SharePoint 2010 的 SharePoint 场。之后，您可以将现有的 SharePoint 数据库连接到新场。您也可以使用混合迁移策略，既执行就地升级，也使用全新的 SharePoint 2010 服务器。
升级前的检查
无论是执行就地升级还是迁移，您都需要在开始实际操作之前进行规划和准备。运行升级前检查程序就是升级到 SharePoint 2010 之前的最重要准备工作之一。在发布 MOSS 2007 之前，Microsoft 推出了 Prescan.exe 实用程序，帮助您确保 SharePoint 的部署处于良好的状态，可以升级到 MOSS 2007。
尽管 Prescan.exe 在当时是一款很好的工具，但它并不适合用于 SharePoint 2010 的部署前分析。因此，Microsoft 又提供了一款新的工具，名为“升级前检查程序”。升级前检查程序是对 Prescan.exe 的重大改进。对于初学者，升级前检查程序是只读的，因此没必要担心它会更改 SharePoint 服务器。
升级前检查程序真正有用的地方在于与其前身 Prescan.exe 相比，它会进行更全面的问题检测。而且它是可扩展的。升级前检查程序随附一系列规则，当它分析 SharePoint 服务器时，会使用这些规则。这些规则采用 XML 格式，也就是说，如果需要，您可以创建自己的自定义规则。由于采用基于 XML 的规则，因此 Microsoft 在其推荐的最佳实践有变化时，可以轻松地更新升级前检查程序。
升级前检查程序最无可辩驳的优势在于其编译的信息。尽管 Microsoft 将升级前检查程序作为升级到 SharePoint 2010 的准备工具，但很多组织也将其另作他用。有一家公司将升级前检查程序作为灾难恢复计划的一部分。该实用程序其实不会帮助修复出现故障的 SharePoint 服务器，但它收集的信息在重建 SharePoint 部署时非常有用（只需确保在故障发生之前运行了该工具）。
与此类似，另一家组织使用升级前检查程序来确保多台 SharePoint 服务器采用相同的配置方式。通过在每台 SharePoint 服务器上运行升级前检查程序，就可以比较来自每台服务器的报告，从而找出不符合公司侧路的配置元素。
您可以从哪里获得升级前检查程序呢？其实您可能已经拥有了这款工具。Microsoft 在 MOSS 2007 SP2 中包含了升级前检查程序。但可能与您的期望不同，升级前检查程序并不是一个独立的工具。Microsoft 将它内置在 STSADM.EXE 实用程序中。顺便说一句，在应用 SP2 后，我曾数次重新启动我的测试服务器，之后 Windows 才允许我访问新的 STSADM.EXE 功能。
现在我将为您介绍升级前检查程序的工作原理。如前所述，升级前检查程序会分析一个基于 XML 的规则文件，然后对照这些规则来分析您的 SharePoint 部署。升级前检查程序内置了一系列规则。这些规则基于最佳实践分析工具，保存在一个名为 OssPreUpgradeCheck.xml 的文件中。图 1 为您展示了这个文件。
图 1 升级前检查程序使用基于 XML 的规则文件。#p#
当您调用升级前检查程序时，您无需显式调用此规则文件。默认情况下，升级前检查程序会调用它。您也可以使用自定义的规则文件。升级前检查程序的完整语法如下所示：
从上述语法中您可以看到，唯一必需的参数就是 –O 以及 PreUpgradeCheck 一词。–RuleFiles 参数是可选的，只有当您手动指定要使用的规则文件时才需要使用。同样，您可以使用 –ListRuleFiles 参数来显示可用的规则文件。最后，还可以使用 –LocalOnly 参数以便只对本地 SharePoint 服务器运行规则。
为了让您更好地了解升级前检查程序的工作原理，请参见图 2。在此图中，我打开命令提示符窗口，导航到目录结构 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN。在此目录中，我运行以下命令：
图 2 升级前检查程序测试 SharePoint 部署。
正如您在图 2 中所见，升级前检查程序对 SharePoint 部署执行了几项不同的测试。每项测试的结果用不同的颜色标出。红色表示测试失败，绿色表示服务器通过测试。提示性的信息则用黄色标出。
很明显，升级前检查程序的输出并不是非常详细。图 2 中的屏幕截图只能告诉您服务器是否通过了测试，而不能提供任何详细信息。但在屏幕截图的底部，您会看到一条消息，告诉您可以查看一个位于 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs 文件夹中的 HTML 文件来了解测试结果。
每次您运行升级前检查程序之后，它都会创建三个独立的日志文件。其中一个日志文件是升级检查结束时提到的 HTML 文件，另外还有一个 LOG 文件和一个 XML 文件。您可以使用这三个文件中的任意一个，但 HTML 文件是最容易阅读的。
如前所述，升级前检查程序会编译大量信息。因此，所产生的完整日志文件会非常长，这并不令人惊奇。不过您可以通过图 3 来大致感受一下 HTML 日志文件。
图 3 升级前检查程序的结果可以使用 Web 浏览器查看。#p#
识别您的自定义内容
升级规划工作中的另一个重要步骤是识别您对 SharePoint 服务器进行的自定义。无论是执行就地升级还是进行迁移，都很容易在无意间覆盖自定义的内容。因此，您应该记录下自定义内容，备份自定义文件，以便在升级之后，能够在需要时轻松地重新应用自定义。
理想情况下，随着 SharePoint 环境的发展变化，您会完整记录下所有自定义；而实际情况是，要追踪所有变更是非常困难的。因此，即使您认为已经完整记录了所有自定义，也应该花些时间来查看自定义日志。遗憾的是，SharePoint 未提供任何内置工具来帮助您识别自定义。但这并不代表您要手动检查 SharePoint 服务器上的每个文件。
一种可用来查找自定义的方法是一种称为“差异对比”的技术。此技术的理念就是您可以设置一台备用 MOSS 2007 服务器（确保其上运行了与生产服务器相同的修补程序），然后使用差异对比程序来查看生产服务器上的哪些文件与原始 SharePoint 服务器上的文件不同。
Microsoft 推荐使用 WinDiff，但有很多其他的差异对比实用程序可以使用。这些程序中的大多数都比 WinDiff 的功能丰富。
测试升级过程
准备转移到 SharePoint 2010 时，您最终需要制定一个计划，来说明如何执行升级。假设您已经解决了升级前检查程序报告的所有问题，那么升级过程将变得相对顺利。但您也不能掉以轻心。
在尝试升级生产服务器之前，您应该在隔绝的实验室环境中部署 MOSS 2007，然后在此实验室中尝试您的升级计划。您可以在实验室中熟悉升级过程，找出可能在实际升级时带来各种麻烦的问题。
对中小企业 （SMB） 来说，最好的方法是设置一些虚拟服务器，然后将生产服务器的备份恢复到实验室服务器。这样，您就可以在与生产环境几乎一样的环境中测试升级计划。
对于大型企业，创建 SharePoint 生产部署的精确副本可能并不现实。在这种情况下，您可以设置小规模的环境，按照与生产部署相似的方式来配置这个环境。也可以尝试将部分（而不是全部）SharePoint 服务器的备份恢复到实验室环境。这种方法看起来并不尽善尽美，但请记住，您几乎不可能一次将整个部署迁移到 SharePoint 2010，因此应该循序渐进。
验证您的备份
开始升级到 SharePoint 2010 之前的最后一个步骤是验证您的备份正确无误。就在本周，我还遇到有人以为已经辛勤地备份了服务器，结果痛苦地发现备份根本不完整。不要让这种事发生在您身上。测试您的备份，并确保备份可以恢复。
【编辑推荐】
