需要将Windows Server 2012 / 2012r2升级到Server 2022 / 2019吗?本教程将向您介绍具体方法。
我们将同时介绍从2012到2022 / 2019的原地升级,以及从2012服务器迁移到一台独立的2022 / 2019服务器。
Server 2012已正式进入生命周期终点,Server 2012 R2的支持将于2023年10月23日结束 – 所以您自然不是孤军奋战:2012服务器都应尽快升级。当然,您希望尽量减少花在升级上的时间和精力,并尽可能让升级过程自动化。
在本指南中,我们将介绍把Server 2012升级到2022 / 2019的各种方案,同时完整保留服务器应用程序、数据库、用户配置文件、共享和数据的功能。请注意,同样的流程也适用于非2012服务器;我们只是因为2012将于2023年停止支持而重点介绍它。
升级Server 2012主要有两种方式:
只想了解如何自动化2012到2022 / 2019的升级,而不需要一般性教程?
点击这里跳过 ,直接进入介绍实际升级过程的部分。
以下是Windows Server升级路径图表(来源:Microsoft.com)

从上面的图表可以看出,您无法直接从2012原地升级到2022。不过,对于本地服务器(物理机或虚拟机),可以通过2次“跳跃”来实现:
但是请注意, Azure服务器或AWS服务器无法进行原地升级 – 至少无法以“传统”方式进行。对于这类云端托管的服务器,您应该使用下文介绍的 “迁移升级”方案.
原地升级的 主要优点 (在真正可行的情况下)是 – 至少乍看起来 – 它听上去非常简单省事。毕竟,您只需安装新的Windows Server操作系统(两次),而不必处理应用程序 / 数据的重新安装。您需要做的只是:
这两个步骤都可以通过下载并挂载相应的ISO来完成。
遗憾的是,现实并不总是那么简单。围绕原地升级主要有3个隐患:
您正在破坏当前正常运行的服务器: 原地升级的主要问题在于,一旦开始,您就不再拥有一台可用的服务器,直到新系统完全投入运行为止。原地升级的设计就是如此。当然,您有原2012的备份(这是任何原地升级中绝对必备的),但回滚并不总是那么简单。而且升级过程本身往往耗时很长 – 在此期间,您同样没有可用的服务器。这是原地升级的固有问题,对于关键业务服务器来说,这往往使其根本不可行。
升级过程并不总是一帆风顺: 从纸面上看,“只需安装两次新操作系统”听起来并不糟糕。遗憾的是,残酷的现实是原地系统安装往往不如预期顺利。如果源服务器上存在操作系统相关的问题,您的安装可能根本无法开始,直到您先解决这些问题。此外,任何做过几次原地升级的IT管理员都能告诉您,跑了3个小时的升级进程,最后却收到诸如“0x800F081E The installation failed in the SAFE_OS phase with an error during INSTALL_UPDATES operation”之类的错误,是什么滋味。
最终结果必须经过彻底检验: 假设您成功完成了原地升级过程(2012到2016,再从2016到2022或2019),下一步就是彻底检验服务器上的每个组件和每个应用程序。您跨越的是大约10年的差距,而且不是通过全新安装,而是通过一系列升级来实现的。确保所有操作系统组件仍然正常工作、表现符合预期,这一点非常重要。
总而言之,理论上原地升级听起来很有前景。但实践中并不总是如此。在某些情况下值得一试,通常是针对非关键业务服务器 – 当它确实成功时,能节省大量时间和精力。然而对于大多数服务器来说,原地升级总体上并不是最佳方案。
事实上,许多厂商直接声明应避免原地升级 – 例如 VMWare在这里的说明: “不建议对客户机操作系统进行原地升级(在主要操作系统版本之间,例如从Windows Server 2016或Windows Server 2019升级到Windows Server 2022)。最佳做法是在新的虚拟机中安装新的主要操作系统版本”。
考虑到以上种种,随之而来的问题是 – 如果原地升级不是个好主意,那还能怎么做?答案是 – 从2012到2022 / 2019的 迁移升级 。
迁移升级是“老式”原地升级的替代方案:您安装一台新的Server 2022或2019,然后将2012 / 2012r2上的内容迁移过去。最终结果是所有内容都在2022 / 2019替代服务器上运行。
显然,迁移升级立即消除了上述原地升级的2个缺点:
非破坏性,几乎没有停机时间: 您的原服务器始终保持运行,不会被破坏或受到任何影响。只有当目标服务器完全就绪、可以投入使用时,您才切换过去 – 这将停机时间和风险降到最低(甚至完全消除)。
全新安装,直接从最新操作系统开始: 您不必拖着10年的增量升级和3个不同的操作系统版本前行。相反,您直接运行最新的操作系统。
剩下的就是第3点:升级过程本身。
迁移的问题在于,如果手动操作,会消耗大量的时间和精力。重新安装应用程序、重建配置、努力回忆当初一切是如何搭建的、复制数据和权限、共享、个性化设置,以及所有让服务器正常运转的细枝末节 – 清单很长,而完成这份清单的工作可能持续数天(更不用说人为错误了)。
幸运的是,这个问题有解决方案:迁移可以通过专门的 服务器迁移软件 – Zinstall WinServ – 实现自动化,本教程将向您展示具体方法。
这适用于任意平台组合:物理2012到物理2022、物理机到虚拟机 / 云端、本地2012r2虚拟机到AWS 2019服务器、Server 2012 Azure虚拟机到Server 2022 Azure虚拟机(是的,您可以用这种方式在实际效果上实现“不可能”的Azure原地升级!)。
这一切都是本地原生迁移,而不是应用程序虚拟化 / lift-and-shift / 克隆。应用程序会被真正安装到目标服务器上,共享会被配置好,数据和设置会被迁移过去,唯独不迁移旧操作系统本身。
自动化迁移消除了最后一个缺点,使2012到2022 / 2019的升级得以干净、高效、安全地完成。
让我们看看具体怎么做。
审查您的服务器: 在一个典型的环境中,您会有多种不同类型的服务器。其中会有面向角色的服务器,专注于Windows Server角色,如域控制器、Active Directory、IIS、Exchange、DNS、DHCP。角色迁移不是自动化的,必须手动完成。
不过,更常见的一组是应用程序和文件服务器,它们运行真正的业务应用程序(LOB)并存储公司数据。它们的数量通常远超基于角色的那一组。
应用程序和文件服务器可以使用服务器迁移软件自动化、大规模地迁移(如下所示)。
在规划阶段,您需要准备一份环境中的服务器清单,并弄清每台服务器的职责。哪怕只是知道有多少台角色服务器、多少台应用程序服务器,也已经是一大步。由于应用程序服务器迁移可以自动化,您将能够对迁移所需的时间和精力做出相当准确的估算。
确认您的备份是最新的,并且确实可以恢复: 任何重大升级都有可能出错,如果没有有效的最新备份,您就有可能失去服务器上的所有内容。请务必确认您的备份没有损坏,并且在需要时可以随时恢复!
决定替换服务器的类型: 一旦您决定替换某台服务器,就有几种替换方案可以选择。它可以是一台本地物理Windows 2022 / 2019服务器、一台本地虚拟机服务器(例如ESX / Hyper-V),或者一台在外部运行的云服务器(例如迁移到Azure或迁移到Amazon AWS)。如果您使用WinServ,它支持其中任何一种迁移,因此无论您如何选择,迁移难度都不会有显著差异。
以下流程概述了从Server 2012 / 2012 R2升级到新的Windows Server 2016 / 2019 / 2022的步骤。
我们将介绍本地迁移(目标服务器与源服务器在同一网络中)和异地迁移(目标服务器在外部,例如服务器迁移到Azure / AWS)。
就是这样!这就是整个迁移过程。当然,这并非升级的全部;在运行之前您需要先准备好服务器,之后也需要检查迁移结果(见下文),但您已经把升级中大部分繁琐的工作自动化了。
就是这样!这就是整个迁移过程。当然,这并非升级的全部;在运行之前您需要先准备好服务器,之后也需要检查迁移结果(见下文),但您已经把升级中大部分繁琐的工作自动化了。
在Windows Server 2012上运行的某些遗留第三方应用程序可能与Windows Server 2022 / 2019不兼容。这一点对“老式”原地升级和“迁移”升级来说都是一样的,因为这个限制是应用程序本身的属性。
与Server 2003 / 2008相比,2012上的不兼容应用程序要少得多,但仍有可能出现 – 通常是那些没有针对新操作系统版本更新过的遗留软件。
请注意,“老旧”并不一定意味着“无法运行”。相当多的应用程序仍能正常工作。
如果这些应用程序无法立即移除,而且对组织的持续运营至关重要,那么保留其运行的推荐方案是将这些应用程序虚拟化迁移到一个虚拟的Server 2012实例中,该实例运行在新的替代服务器上。然后,继续采取必要的步骤逐步淘汰这些应用程序,并停止运行虚拟化的2012实例。
WinServ本身是应用通用的工具,甚至可以迁移外界从未见过的自定义和内部应用程序 – 只要它们能够在新服务器上运行。以下是我们的客户过去迁移过的一些常见应用程序的部分列表:
当迁移过程完成后,就该验证结果了。
恭喜!您的2012到2022 / 2019升级现在已经完成。
需要评估许可证 / 批量价格 / 更多信息?