Tonny's questions

我的任务是从头开始设置 Windows 2019 AD 环境（新域）。
通常我们从公司 KMS 系统获得我们的服务器许可证/激活，在这种情况下我们也需要这样做。
通常我会在没有许可证的情况下安装 Windows 服务器。在我添加 AD 角色之前，配置 KMS 并让许可证/激活正常工作......

但是：在这种情况下，新域位于防火墙后面，并且与公司网络没有正常连接。
由于管理疏忽，没有及时请求允许访问 KMS 的防火墙规则。
审批过程很长（很多繁文缛节），直到几天后我才能访问新服务器的 KMS，可能是在 DC 安装日期之后的几周，但我们确实需要尽快让该域运行。

我希望我可以在 Server 2019 上配置 KMS（无需实际激活，因为 KMS 没有响应），然后可以继续进行域设置，稍后它将进行激活。

我知道具有评估许可证的 DC 设置无法升级到正确的许可证，除非您首先将 AD 角色移动到另一台服务器并将此 DC 减少到普通服务器。然后你可以重新授权它。

我想真正的问题是，具有无法访问的 KMS 服务器的 KMS 设置是否被视为评估安装。

对于新域，我们无论如何都需要 2 个 DC。所以我总是可以推迟添加第二个 DC，直到我们拥有 KMS，然后重新许可第一个 DC。
但这需要一些额外的工作和另一次前往现场的旅行（无远程访问），我想避免这种情况。

有人对这个有经验么 ？

我从来没有深入参与管理 AD2003 域控制器。
现在我得到了一个损坏的域倾倒在我的腿上。
我需要一些建议如何进行。

这是故事：

今天早些时候，我从另一个部门继承了一个旧的、管理不善的 3 服务器域。
（它由一家外包服务提供商运营，一年前倒闭，从那以后就无人问津了。）
2 个 Windows 2003R2 DC 和一个运行 1 个应用程序和 SQL2000 服务器的 2003R2 服务器。
在硬件的物理运输过程中，1 个 DC 无法修复。正如您可能已经猜到的那样，根本没有备份。

剩下的 2 台机器启动了，两台机器的 ip 地址都更改为我自己范围内的新地址。之后，两台机器都重新启动了一次。DC 首先和应用程序服务器仅在 DC 完全启动后。
我有此域的域管理员访问权限。我可以登录到两个幸存的服务器。
两台服务器都需要很长时间（DC 15 分钟，应用服务器 10 分钟）才能启动到登录提示。登录后需要很长时间才能进入桌面（另外 5-10 分钟）。

现在是我的问题：我需要让那个应用程序再次运行到年底。

首要任务似乎摆脱了失败的 DC。然后开始对这些服务器进行清理（两者上都有很多已删除和/或部分禁用的应用程序的剩余物）。

事情是：我不确定如何去除 DC。
我需要先做 dcpromo，然后是 ntdsutil/remove server 吗？
只是 ntdsutil/删除服务器？
IP地址的变化对此有影响吗？（如果需要，我可以暂时放回旧的 IP 地址。）

顺便说一下，这个域与我们的正常域有信任关系。这会影响 DC 移除吗？
由于 ip 地址更改，是否需要对这种信任关系做些什么？

任何帮助将不胜感激。

更新 我修复了两台机器上的 DNS 问题。DC 和应用服务器上的主 DNS 现在指向 DC 本身。我更新了 DNS 中两台机器的 DNS 记录。
（我无法为任何一台机器制作正确的反向 PTR。不知道这会有多大问题。新的 ip-range 不在此处的反向区域中，并且不允许此 DC 更新反向指针如果我将该区域添加为副本。）

这似乎已经治愈了两台机器的过度缓慢。
远程桌面登录现在可用。仍然有点迟钝，但显然在一切都搞砸之前就已经是这样了。

我现在正在等待有关该应用程序的用户反馈。

我有 2 台 WSUS 服务器：
一个旧的 W2K3、WSUS 3.0SP2 框和一个启用了 WSUS 角色的全新 2012 服务器。

旧机器工作正常，并通过公司代理从 MS 提取更新。（BITS 设置为默认后台模式。）
新的具有完全相同的配置设置，包括代理配置和代理的相同用户帐户。新服务器可以很好地同步，甚至可以导入并验证我从旧服务器复制过来的所有更新。
但是新服务器不会从微软下载任何新鲜的东西。
我不断收到错误错误 364：

内容文件下载失败。原因：值不在预期范围内。源文件：/msdownload/update/software/defu/2013/05/am_delta_f1860b39acfcbfcf1d701c7c19d28faa97dd9e71.exe 目标文件：D:\WsusContent\71\F1860B39ACFCBFCF1D701C7C19D28FAA97DD9E71.exe。

代理显然正确支持 Range 命令。毕竟其他服务器使用相同的代理，下载管理器也没有问题。（也尝试了另一个代理：同样的问题。）
我尝试将 BITS 设置为前台模式。没有任何区别。

我已经完全删除了 WSUS 角色（包括注册表项等）并重新安装。重新安装后问题又回来了。

我找不到其他日志记录可以更清楚地说明问题。

任何想法可能是什么原因造成的？

更新：

经过一些试验后，我将其缩小如下：
a) BITS 作业由 WSUS 服务创建，但它们在创建后立即（同一秒）被取消。这在 Bits 事件日志消息中可见。（没有明显的取消原因。）
b) 服务器是域 X 的成员。用于代理的帐户是域 Y 的成员（并且在服务器上具有管理员权限）。在旧机器上，一切都在域 Y 中。这可能是问题的一部分。

我将在 X 中获得一个具有代理访问权限的帐户，并将其用于 WSUS 传输。不幸的是，我有一些繁文tape节需要费力才能获得另一个帐户，因此我今天将无法再对其进行测试。

更新 2： 在与服务器本身位于同一域中的帐户后，我仍然遇到了问题。显然这没有任何区别。
我还在旧的工作服务器上测试了这个新帐户。（因此在那里产生了跨域问题。）另一台服务器很满意，使用新帐户没有问题。

明天我将采取深入的尝试：完全删除 WSUS 和 IIS 服务器角色，删除所有相关的注册表项，从 IIS 和 WSUS 中删除所有内容文件并丢弃 WID 数据库。重新启动服务器并重新执行所有操作。
我也想完全重新安装操作系统，但这不可行。服务器由另一个部门管理。我可以在一个上获得完整的本地管理员权限，但不允许我安装一个。

更新 3： 不知何故，Windows 安装本身在所有试验中变得乏味。
我不得不硬着头皮要求重新安装服务器。
...
好的，我有一个全新的服务器安装。
按书重做 WSUS 设置。
同样的效果：错误 364

我已经黔驴技穷了。什么可能导致 WSUS（或 BITS）认为下载有问题？（BITS 只是立即取消下载而实际上没有做任何事情。）
我猜真正的问题是其他问题，处理不当并导致这个误导性错误 364。
任何关于解决方案的建议，或者只是尝试的事情欢迎排除故障。

带有板载 SmartArray 6i 控制器的 Proliant DL380-G4。

Raid 1+0 组由 2 个 72 G 和 2 个 300 G 磁盘组成（后来添加了更大的磁盘）。

有效容量约为 140 GB，当然，它已满。

我无法添加更多磁盘，因为剩余的 2 个插槽已被另一个 2 磁盘镜像占用。我可以用 300 G 磁盘替换 72 G 磁盘（一次 1 个）并（在重建后）扩大阵列。虽然在磁盘交换期间没有冗余。那 2x :-(

或者我将阵列从 Raid 1+0 更改为 Raid 5，这只会给我额外的 70 G（这就足够了），但（希望）在更改期间保持冗余不变。

备份，终止阵列，替换小磁盘，创建新阵列，然后恢复不是一个选项，因为我需要让这个盒子一直在线。

我不担心重建期间的性能损失。（幸运的是，在这种情况下，用户对数据的访问非常轻松。）

我正在寻找如何快速升级磁盘空间的建议，如果可能的话，同时保持冗余。

编辑：将服务器类型更改为 G4（我在服务器机房中都有，但把它们弄混了。）