我们公司使用多个第三方服务器应用程序（作为服务安装，桌面有客户端应用程序）与 SQL Server 一起安装在 Windows Server（虚拟）上。所有这些都在同一个域下（也许这就是问题所在？）。每个应用程序都有自己的方式（配置文件和数据库条目）来管理典型设置：服务器名称、数据库名称、运行服务的帐户等。
以下是典型的升级场景：
- 当前系统与前一版本保持同步。名称：当前
- 创建测试服务器（通常将操作系统从 2003 升级到 2008），并从头开始安装、配置和测试新版本的应用程序。名称：测试
- 创建新的生产服务器，安装并配置新系统（希望与测试相同）。名称：新 ** 所有这些系统都同时运行并继续使用。当前系统最终将被删除，但直到我们知道新系统正在运行并且我们不需要查看“旧系统如何工作”时才会删除。
问题：
- 我们必须保持当前系统完好无损，因为我们永远不知道何时需要参考它进行各种设置，或者在新系统崩溃时将其保留在生产中。即使我们安装了以前的版本并执行升级，配置也会丢失。我指的不仅仅是服务器名称，还有其他设置。
- 由于服务器名称不同，配置文件不能直接从一台服务器复制到另一台服务器。
- 这些应用程序中的许多都具有作为不同服务运行的多个组件，并且所有组件都有自己的配置。即，存在多个配置。
- 我们公司中没有任何人在安装和配置原始应用程序时在场，并且他们没有留下任何文档。
- 我们打交道的许多公司都无法给我们关于升级将如何影响配置设置的完整答案，而是依赖于“只查看出现的问题并尝试修复”的方法。
我们如何创建测试环境，使测试服务器和数据库具有相同的名称，以避免这些冲突？我们需要单独的域吗？这是否会带来其他问题和限制，例如尝试将文件从一个域复制到另一个域？重命名虚拟服务器难道不应该很容易吗？
抱歉，网络管理不是我的专业领域。我希望为我们公司中那些正在做这些决定的人提供一些启示。
答案1
我以前在类似情况下的做法是（学术环境，五个校园，五台服务器，运行相同的产品，均基于 SQL Server）：
第一步，大致类似于您的测试环境：获取虚拟机（此时可以是 VMware 工作站）并在其上练习升级，并记录所有内容。这应该可以帮助您确定需要保存和复制哪些配置项，还将教您如何更改服务器名称。;) 然后获取一个新的虚拟机并再次执行此操作。如果您遇到新的可怕错误，请获取一个新的虚拟机并第三次练习。继续这样做，直到它不再可怕，或者至少直到您对升级产品感到相对有信心。（注意：通常数据库名称和数据库服务器名称存储在注册表中。如果您要复制注册表项，请查找该注册表项以确保您不会过早升级产品的数据库。同样，您可能需要在更改服务器名称后更改此值。）
然后，在计划的停机时间内，对 [oldname] 进行实际升级，在此期间我将：
- 保存我提前知道的任何配置项（例如，在一种情况下，包含正则表达式值的注册表项和文本配置文件）。
- 获取我崭新的虚拟机。将其命名为 [oldname]-new。
- 安装 SQL。
- 附加旧数据库（将文件 [productdbname].mdf 和 [productdbname].ldf 复制到新服务器并使用“附加数据库”命令——必须在旧服务器上停止 SQL 才能执行此操作，这意味着您也需要停止 [productname] 服务）。
- 复制任何其他所需文件（那些注册表项/文本文件）
- 运行安装程序，它通常会检测数据库并提供为您升级数据库（耶！）
- 将旧服务器重命名为 [oldname]-old，并赋予其新的 IP 号码。
- 将新服务器重命名为 [oldname]，并赋予其 [oldname] 的 IP 号码。
第一次升级有时很难，即使经过练习也是如此。到第五次升级时，您已经是老手了，升级就很容易了。记下任何问题以及您是如何解决这些问题的。
至于那些配置项，它们通常位于注册表中的 HKLM/Software/[产品或供应商名称] 下或程序文件目录中，但并非总是如此。有一个供应商将某些东西放在一个奇怪的路径中（尽管它在注册表中被引用），并且必须将一个文本文件复制到 c:\windows\system32 才能让软件找到它（加密设置）。唉，除非你尝试，否则你不会找到这些（也许最后还要打电话给供应商，唉）。
祝你好运！