把第二台域控分散到另一台物理宿主机，直接迁移健康 VM 通常更简单。这次我选择从黄金镜像新建可写 DC、更新并提升、验证复制，再正常降级旧 DC2；新机使用新名称，最终接管原 IP。
2026 年 9 月 21 日，核心切换和功能验收完成。旧 VM 已退域、关机、断网，尚未销毁。最容易遗漏的是：相同 IP 不会继承旧 FQDN、TLS 证书或客户端依赖。
2026/9/21大约 8 分钟
这次身份集成最终打通了 Windows AD → authentik → Cloudflare 控制台。域用户用 AD 身份登录 authentik，再点击应用卡片进入 Cloudflare。最后一个障碍竟然是卡片的地址：普通控制台首页只是书签，并不会自动发起这套 SSO。
本文基于 2026 年 9 月 16 日的部署记录。authentik 为 2026.8.2，连接两台可写域控和一台云端 RODC；完整控制台登录已由用户实际确认。下文域名统一为示例，不包含口令或客户端密钥。
2026/9/16大约 9 分钟
macOS 能使用 AD 域账号，不意味着它会按 Windows 的方式处理设备策略。我在一台 macOS Sequoia 实验 VM 上做了绑定、GUI/SSH 登录、移动账户和 GPO 对照；最有价值的结果是把“目录身份”和“设备管理”拆开。
原环境为 PVE 虚拟化 macOS，仅作为这次实验背景，本文不展开安装路线，也不把单台实验机结果推广成所有 Mac 的兼容性保证。域名、OU、账号与地址均换成示例。DNS 域使用 corp.example.com，NetBIOS 名单独设为 LAB，不能把两者混用。
2026/9/16大约 8 分钟
2026 年 8 月 14 日来电后，两台 PVE 域控启动，主机名能解析，部分 IPv4/IPv6 探测正常，DC1 从 DC2 拉取 Schema 的最近一次复制却报 8524。
随后在 DC2 请求 DNS 注册、重启 Netlogon，修正远程命令包装并定向重试，复制恢复。9 月 15 日整理记录时，最值得纠正的是当时过快的解释：恢复成功不证明最初一定缺了某条 DNS 记录。
2026/9/15大约 7 分钟
旧 Windows Server 域控制器从早期 EC2 虚拟化栈迁移到 Nitro 平台时，通常要处理 PV、ENA 和 NVMe 驱动。普通成员服务器驱动失败可以换卷救援，但域控制器还涉及 AD DS、SYSVOL、FSMO、DSRM 和 System State，不能只把它当成一次设备驱动安装。
下面是一套面向双域控的变更流程。命令中的主机名、卷和区域均为示例，执行前必须结合 Windows 版本、实例代际和 AWS 当前驱动包验证。
2026/8/17大约 5 分钟
在 PVE 中部署第二台 Windows Server 域控制器时，DC2 的 IPv4 DNS 已经明确指向 DC1，AD DS 配置向导仍然提示无法联系域。显式向 DC1 查询 SRV 记录却完全正常。
最终根因是 iStoreOS/OpenWrt 通过 DHCPv6 和 RA/RDNSS 把路由器自身的 IPv6 地址通告为 DNS。Windows 优先向它查询内部 AD 域，收到有效的 NXDOMAIN 后不再尝试 DC1。
本文中的地址、域名和设备标识均已泛化。
2026/8/17大约 4 分钟
客户端无法通过 DNS 别名访问 FSx 文件服务器，抓包显示网络层全程可达，失败点在 Kerberos——KDC 找不到别名对应的服务主体。根因是别名缺少注册在 FSx AD 计算机对象上的 HOST/ SPN。
2026/7/3大约 3 分钟
使用自建 Active Directory 创建 FSx for Windows File Server 时，如果 Single-AZ 2 或 Multi-AZ 文件系统创建失败，并且报 Get-ADComputer: Unable to contact the server，要重点检查 FSx 子网到域控 TCP 9389 的连通性。
2026/6/4大约 2 分钟