gOxiA=苏繁=SuFan Blog

从 SBS2011Std 迁移至 Windows Server 2012 Essentials

        2013年5月 gOxiA 与大家分享了一篇日志，介绍了从 SBS8 Beta 迁移至 Windows Server 2012 Essentials，时隔近3个月 SBS2011Std 到 Windows Server 2012 Essentials（WS2012Ess）的迁移在断断续续中终于也完成了。正如之前所提到的 SBS2011Std 到 WS2012Ess 的迁移非常复杂，除了涉及 AD、文件夹 等基础数据的迁移外，还涉及 SharePoint 和 Exchange。介于篇幅问题，本章将简单介绍整体迁移的过程和大致的步骤，为需要迁移的用户提供可参考的资讯和经验。

        以 gOxiA 的环境为例，SBS2011 到 WS2012Ess 的迁移整体上可以参考前面 SBS8 Beta 的迁移过程，便可轻松完成 AD 和 共享目录、个人文件夹重定向目录的迁移工作。但是在开始前建议先对 SharePoint 进行迁移，为此我们需要单独部署一台服务器运行 SharePoint，本例中采用的是 SharePoint Foundation 2013，关于 SP2010 到 SP2013 的升级可参考http://technet.microsoft.com/zh-cn/library/cc262483.aspx，为了确保迁移，建议前期先搭建一个虚拟环境并参考文档对现有数据库进行升级操作，之后再参考SharePoint 的导入和导出将升级完毕的数据导出最后再导入到生产环境的 SharePoint 上，干干净净而且不会出现莫名其妙的小问题！如果将 SP2010 导出的数据直接导入到 SP2013 上则会失败，如下图所示：

        完成 SharePoint 的迁移后便可以准备 Exchange 的迁移，为此也需要为 Exchange Server 备一台新的机器，Windows Server 2012 Essentials 除了支持 Office 365，也同样支持内部部署的邮件服务器，如果计划使用 Exchange 2013 可参考：Exchange 2013 部署助理，仍打算继续使用 Exchange 2010 则参考：Exchange 2010 部署助理。部署完毕后将原 SBS2011Std 上的用户邮箱及系统账号邮箱全部移动到新的 Exchange 服务器上，然后测试访问如果一切正常，便可开始 SBS2011Std 到 WS2012Ess 的迁移。（注意：此阶段请勿配置 Exchange 的相关证书）

        SBS2011Std 两大主要的系统数据迁移完毕后便可开始迁移 AD 和共享目录，与 SBS8Beta 到 WS2012Ess 的迁移过程没什么区别。

1. 禁用 VPN；
2. 评估SBS2011Std服务器健康情况，检查并解决相关警告或错误；
3. 配置使用外部时间服务器（w32tm /config /syncfromflags:domhirer /reliable:no /update）
4. 安装并执行 Migration Tools；
5. 安装迁移模式的 Windows Server 2012 Essentials；
6. 跟随迁移向导填写相关信息执行迁移操作；
7. 系统的安装和迁移完毕。

        在系统安装和迁移结束后，参考 Move SBS 2011 setting and  data to the Destination Server 将相关的用户数据迁移的新服务器上。因为此时新服务器（WS2012Ess）使用的是动态 IP，所以可先将其配置为静态 IP，然后禁用源服务器上的 DHCP Server，同时启用路由器上的 DHCP Service，并将 25、80、443、1723 端口配置为新服务器的 IP 地址，完成这些操作后便可在 WS2012Ess 仪表板中执行配置向导，启用远程访问等功能。之后将域内所有的计算机和应用服务器通过“http://ws2012ess-servername/connect”加入到新服务器上，然后再为相关服务器申请并启用新的证书。

        迁移工作全部结束后，建议新老系统并存运行一段时间，如没有问题便可开始移除源服务器。首先卸载源服务器上的 Exchange，之后是 ADCS 证书服务，然后执行 dcpromo 对源服务器进行降级，在源服务器成为域成员服务器后，建议运行一段时间，其间因为会涉及服务器重启，可监控事件日志对警告和错误做排错。如果没有问题，则将源服务器退出 AD。

        对于只有单公网 IP 的用户，需要使用 WS2012Ess 提供的“arrconfig.exe”工具进行设置，以允许到邮件服务器的访问请求（https://mail.contoso.com/owa）能够通过 WS2012Ess 自动中转到内部的邮件服务器上。在使用 arrconfig 配置前需要先将 Exchange 上配置使用的证书导出（包含私钥），然后参考下列命令行执行配置操作。

        gOxiA 目前接受 SBS 产品迁移的服务咨询，如果大家有问题可通过邮件方式进行联络。

解决因开启 32BitApponWin64 后出现的 HTTP 503 故障问题

        自从离开 Hosting 行业，好久没有做过 IIS 方面的排错，今天算是遇到了一个，感觉会很常见，所以记录下来以备后用。用户购买了一套 ASP+Access 的小程序（PS：别问为什么还要买这么老旧的架构程序！），配置到用户的 Windows Server 2012 Essentials 环境中运行正常，操作过程并无什么特别，只是为其应用池开启 32位程序支持即可，整个过程非常顺利。

        反而在之后配置到 gOxiA 的 Windows Small Business Server 2011 Standard 环境中后一直无法正常运行，IE 访问时提示“Service Unavailable”，经典的 HTTP 503 故障。起初检查 IIS 配置没有发现异常，但是看到对应的应用池会被停掉。于是打开事件查看器查阅日志，发现了很多来源为“IIS-W3SVC-WP”的错误，其内容大致如下：

“由于配置问题，无法加载模块 DLL “C:Program FilesMicrosoftExchange ServerV14ClientAccessOwaauthexppw.dll”。当前配置仅支持加载为 x86 处理器架构构建的映像。……”此外，除了 exppw.dll 文件外还有 kerbauth.dll 也出现错误。

        综上分析，应用程序池的 32位应用支持是正常打开了，但是却无法加载 64位的 DLL 文件。而关闭“enable32BitAppOnWin64”后应用程序池恢复正常，但无法访问 ASP 程序。那么原因应该是出在应用程序池和加载模块的问题上。“exppw.dll”和“kerbauth.dll”文件都属于服务器上的 Exchange Server 2010 所有，这两个文件本身肯定是没有问题的。

        看来还是要锁定到应用程序池方面，应用程序池本身是64位的，只是开启了32位应用支持，所以应用程序池在设置后是正常运行状态。当触发访问请求时，该应用程序池会启动一个新的32位模式的进程，来接受 ASP 类型的访问请求，此时就会导致 32位应用程序池进程（w3wp.exe）与加载的 64位 DLL 出现系统策略上的冲突，被系统强行终止，最终出现前面所述的故障。

        要解决这个故障貌似挺难的，难不成跑了64位应用（Exchange Server 2010）的服务器就不能跑 32位 的 ASP 程序了？！看来只能网上找找是否有相关的资料，这还真的找到了！参考资料：http://blogs.msdn.com/b/rakkimk/archive/2007/11/03/iis7-running-32-bit-and-64-bit-asp-net-versions-at-the-same-time-on-different-worker-processes.aspx

        文中末尾提到可以修改“applicationHost.config”文件，为加载的 DLL 指定对应架构模式的 ISAPI Filter 来运行。即，在每个 DLL 加载配置行尾附加“preCondition”参数，如果该 DLL 是 32位那值为“bitness32”，而 64位的则是“bitness64”。修改后的结果可以参考下图：

        针对本例，我们需要修改的有两个：“exppw.dll”和“kerbauth.dll”。最后测试一下结果，网站已经能够正常访问，至此故障消失问题得到了解决！同样，有遇到类似故障的都可参考此法解决。

在 Windows 8 上为 Outlook 2013 设置 CRM for Outlook

        接上篇《安装 Microsoft Dynamics CRM 2011 Workgroup》我们完成了 CRM Server 的安装，在文末 gOxiA 曾提到测试的客户端是 Windows 8 + Office 2013，并且在初次设置时遇到了一些麻烦，所以本文将与大家分享在 Windows 8 上为 Outlook 2013 设置 CRM for Outlook 的过程。

        Microsoft Dynamics CRM 2011 除了支持通过浏览器访问以外，还可以与 Outlook 集成使用。当我们首次访问 CRM 站点时会提示获取 CRM for Outlook 的提示，为了获得更好的体验并提高效率，建议安装 CRM for Outlook，根据提示下载并安装。

        但是在配置向导中输入地址进行连接测试时失败了，提示“与 Microsoft Dynamics CRM 服务器通信时出现问题。服务器可能不可用。请稍后重试。如果此问题仍然存在，请与您的系统管理员联系。”而故障的要点是“调用方未由服务进行身份验证。”具体可参考下图：

        在网上查了一下 KB 提示要先进行 Web 访问测试，但之前 Web 访问是正常的，而 CRM for Outlook 连接配置向导只让填写了 CRM Server 地址而未让我填写账号和密码，因为测试的客户端未加入到 AD，所以问题应该出在身份验证的过程上。回忆之前《在未加入域的客户端计算机上自动登录 SharePoint Companyweb》这篇文章，颇为相似！于是将 CRM Server 的地址加入到 IE 的本地 Intranet 区域中，再次测试故障解除。

        但接下来又出现了另外一个错误“无法加载与 8082 版本的 Ado.NET 提供程序相对应的 SQL Server Compact 的本机组件。请安装 SQL Server Compact 的正确版本。有关详细信息，请参阅知识库文章 974247。”参阅了 KB974247 也安装了给出的 SQL Server Compact 但还是出现一样的故障，后来继续搜索才找到了最终正确的版本，即安装 SQL Server Compact 3.5 Service pack 2 的累计更新 2（KB2289547），注意：该补丁需要向微软注册申请。

        现在终于设置连接上了，可进入 Outlook 2013 后，当切换至 CRM for Outlook 时又出现了错误，如下图所示！不过这个问题比较容易解决，只需为 CRM Server 打上最新的补丁即可。