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”。最后测试一下结果，网站已经能够正常访问，至此故障消失问题得到了解决！同样，有遇到类似故障的都可参考此法解决。

为指定的事件日志附加任务以实现自动化处理

        gOxiA 所在公司 IT 环境基于 Windows Small Business Server 2011 Standard（SBS2011Std）构建，与 Branch Office 通过光缆相连，使用 SBS2011Std 提供的 DHCP Service 为整个网络提供 Dynamic IP address。由于 SBS2011Std 的独有特性，当 Branch Office 的员工将未配置好的 Wireless Router 接入网络后，SBS2011Std 的 DHCP Service 就会立刻停止。这是因为 SBS2011Std 检测到网络中有其他提供 DHCP Service 的设备，便会停止自身的 DHCPService，此时当其他员工启动系统后便会发现无法正常访问网络，在事件查看器的系统事件中会记录两条错误事件。IT 管理员要解决该问题，除了要排除掉非法的 DHCP Service 以外，还要登录到 SBS2011Std 上重新启动 DHCP Service。其实我们完全可以利用 Windows 的计划任务功能为事件执行特定的任务，以实现类似问题的自动化处理。

        下面就以 DHCP Service 故障作为案例与大家分享如何为指定的事件日志附加任务以实现自动化处理。首先确定要附加任务的事件日志，本例选择的是来源：DHCP-Server，事件：1054，内容：该计算机上的 DHCP/BINL 服务即将关闭。原因请参阅以前的事件日志消息。

        然后鼠标右键点击事件，并选择“将任务附加到此事件…”，如下图所示：

        之后跟随向导创建基本任务，可以使用默认名称也可重新命名，如下图所示：

        确认当日志来自系统，源为 DHCP-Server，事件 ID 为 1054 时执行任务，如下图所示：

        事件附件任务支持“启动程序”、“发送电子邮件”、“显示消息”三个任务，因为本例要执行重启 DHCP Service 的操作，所以这里选择“启动程序”，如下图所示：

        执行启动 DHCP Service 的命令是 net start dhcpserver，所以在“启动程序”设置页面中，指定“程序或脚本”为“C:＼Windows＼System32＼net.exe”，“添加参数”这里写入“start dhcpserver”，点下一步继续。可参考下图：

        在“摘要”页面，确认信息，建议复选“当单击“完成”时，打开此任务属性的对话框。”便于之后做进一步的设置以完善此任务。

        由于该事件发生时，IT 管理员并不一定登录在服务器上，所以在任务属性的常规选项卡下选择“不管用户是否登录都要运行”，因为默认开启了 UAC，所以复选“使用最高权限运行”。

        至此，为事件附加任务的操作便完成了。当下次再次出现此事件时，系统便会自动启动 DHCP Service。同理，我们可以根据日常维护工作遇到的事件指定相关的任务或通知，以实现自动化处理。

        有关任务的安全信息可参考：http://technet.microsoft.com/zh-cn/library/cc722152(v=WS.10).aspx