看起来你的问题核心是长时间停机导致集群节点与域控制器的信任关系失效、集群服务账号权限/票据过期，进而引发网络名称资源故障、FCM访问拒绝、AG创建失败等连锁问题。结合Windows Server 2016的特性，给你一步步排查修复的方案：

一、先修复节点与域的信任关系 #

三年停机很容易让节点的计算机账户和域的信任过期，这是最常见的根源：

• 在DB1和DB2节点上，分别以域管理员身份打开命令提示符，运行：

  netdom reset %computername% /domain:你的域名.com
  

  执行后重启节点，这会重置本地计算机账户与域的信任链接。

二、检查集群服务运行账号状态 #

集群服务的域账号很可能因为长时间未使用出现密码过期、权限丢失的情况：

1. 打开服务管理器，找到Cluster Service，查看它的登录账号是不是指定的域服务账号。
2. 登录到域控制器，在AD用户和计算机中找到这个服务账号：
   • 确认账号处于启用状态，密码没有过期；
   • 检查账号权限：需要拥有在AD中创建/修改计算机对象的权限（新建AG时要创建虚拟网络名称的AD对象），同时要加入每个集群节点的本地管理员组。
3. 如果密码过期，先在AD中修改账号密码，再回到集群节点，更新Cluster Service的登录密码，重启集群服务。

三、修复网络名称资源的AD权限问题 #

网络名称资源失败通常是因为AD中对应的计算机对象权限不足，或者对象丢失：

1. 登录域控制器，在AD用户和计算机中查找故障网络名称对应的计算机对象（名称和角色的网络名称一致）：
   • 如果存在：右键属性→安全，确保集群服务账号和两个节点的计算机账户都拥有完全控制权限；
   • 如果不存在：手动创建一个同名的计算机对象，然后赋予上述权限，再回到集群中尝试启动网络名称资源。

四、清除Kerberos缓存并重置SPN #

Kerberos票据过期或SPN配置错误也会导致认证失败：

• 在每个集群节点上，打开命令提示符执行：

  klist purge
  net stop clussvc
  net start clussvc
  

  这会清除过期的Kerberos票据并重启集群服务。
• 检查集群相关的SPN是否正确注册，执行：

  setspn -L 你的集群服务账号名
  setspn -L 集群名称
  

  如果发现缺失关键SPN（比如SQL Server的MSSQLSvc/集群名称:1433），用setspn -A命令添加，例如：

  setspn -A MSSQLSvc/你的集群名称:1433 你的集群服务账号名
  

五、解决Failover Cluster Manager的访问拒绝问题 #

既然用域管理员登录还报错，优先排查本地权限：

• 检查每个集群节点的本地管理员组，确保域管理员组已添加到其中；
• 尝试用域管理员身份手动启动FCM：打开命令提示符执行：

  runas /user:你的域名\域管理员账号 "mmc.exe %windir%\system32\cluadmin.msc"
  

  输入密码后启动FCM，再尝试连接集群。

六、新建Availability Group的额外注意事项 #

新建AG时出现同样错误，重点检查：

• 确保集群服务账号拥有在AD中创建计算机对象的权限（如果之前权限不够，可以临时给账号赋予“创建计算机对象”的权限，完成AG创建后再调整）；
• 登录DNS服务器，删除集群名称或AG虚拟名称的旧DNS记录，让集群重新注册正确的记录。

按照这个顺序排查，一般能解决大部分因长时间停机引发的集群认证问题。

备注：内容来源于stack exchange，提问作者Steve Kaye