嘿，这个场景我太熟悉了——当额外DC离线后客户端找不到主DC，大概率是DNS、DHCP或者AD站点配置出了问题，咱们一步步拆解排查：

1. 先查DHCP的DNS下发配置 #

所有客户端用DHCP，那首先得确认DHCP给客户端发的DNS服务器里有没有主DC的IP：

• 登录你的DHCP服务器，打开DHCP控制台，找到对应的客户端作用域，查看「作用域选项」里的006 DNS服务器
• 要是这里只填了额外DC的IP，那客户端根本不知道主DC的存在，额外DC一离线就抓瞎了
• 赶紧把主DC的IP加进去，然后让有问题的客户端跑一下ipconfig /release && ipconfig /renew刷新配置

2. 检查AD站点&服务的子网关联 #

客户端会根据自己的IP子网匹配AD站点，优先连同站点的DC：

• 登录主DC，打开「Active Directory站点和服务」
• 看看客户端所在的子网是不是只关联了包含额外DC的站点？如果是这样，额外DC离线后客户端就找不到其他站点的主DC了
• 解决办法：把主DC也添加到客户端所在的站点，或者确保客户端子网关联的站点里有多个可用的DC

3. 验证DNS里的DC SRV记录 #

客户端靠DNS的SRV记录找域控制器，得确保主DC的记录正常：

• 在任意客户端打开命令提示符，运行nslookup -type=SRV _ldap._tcp.dc._msdcs.你的域名（把「你的域名」换成实际域名称）
• 输出里应该同时显示主DC和额外DC的记录，如果只有额外DC的，说明主DC的SRV记录没注册成功
• 修复：在主DC上跑net stop netlogon && net start netlogon，强制重新注册SRV记录，等DNS同步后再测试

4. 清空客户端的Kerberos缓存 #

有些Win7/Win10客户端会缓存额外DC的认证信息，离线后没及时刷新：

• 在出问题的客户端上，运行klist purge清空Kerberos缓存
• 接着重启Netlogon服务：net stop netlogon && net start netlogon
• 再试试访问共享驱动器，应该就能用域名正常访问了

5. 确认主DC的健康状态 #

别忽略主DC本身的问题：

• 在主DC上运行dcdiag /v，检查AD复制、DNS服务有没有报错
• 如果主DC存在AD复制故障，客户端也没法获取正确的域信息

先从DHCP和DNS入手，这俩是最常见的诱因，排查起来也最快。

内容的提问来源于stack exchange，提问作者Matthew