必须综合PwdLastSet超120天、LastLogonTimestamp超180天、Enabled为True及OU/描述标签交叉验证，再经“发现→通知→冻结→清理”四步法操作，全程启用AD回收站并记录日志。
直接删掉“很久没登录”的计算机对象，大概率会误删仍在用的测试机、离线运维终端或刚重装完还没入域的设备。必须用 pwdlastset 和 lastlogontimestamp 交叉验证，并结合 ou 归属与启用状态做综合判定。
怎么看一台计算机是不是真陈旧
单看 LastLogonTimestamp 不可靠——它默认有最多 14 天延迟同步，且只在域控制器间复制一次；LastLogon 虽实时但需遍历所有 DC 才能取最大值，不适合批量筛查。真正有效的组合是：
-
PwdLastSet超过 120 天：计算机账户每 30 天自动改密，超 4 个周期未更新，基本确认已离线 -
LastLogonTimestamp超过 180 天：作为辅助佐证，排除近期临时断网但仍在用的机器 -
Enabled -eq $true：禁用（Disabled）状态的计算机优先冻结，不直接清理 - OU 路径含
"Test-Computers"、"Decommissioned"或描述字段含"retired"、"migrated"：可直接标记为候选
用 PowerShell 筛出高置信度陈旧计算机
以下命令导出满足全部条件的对象，避免漏掉跨 DC 时间差导致的误判：
Get-ADComputer -Filter {
(PwdLastSet -lt (Get-Date).AddDays(-120)) -and
(LastLogonTimestamp -lt (Get-Date).AddDays(-180)) -and
(Enabled -eq $true)
} -Properties PwdLastSet, LastLogonTimestamp, Description, DistinguishedName |
Select-Object Name, DistinguishedName, Enabled, PwdLastSet, LastLogonTimestamp, Description |
Export-Csv "stale-computers-report.csv" -NoTypeInformation
注意：PwdLastSet 是 FileTime 格式，导出后需用 [datetime]::FromFileTime() 转换才易读；若需更高精度，可用 Get-ADReplicationAttributeMetadata 查某台机器在各 DC 的 LastLogon 值取最大。
为什么不能直接执行 Remove-ADComputer
AD 删除不可逆，除非提前启用了 AD 回收站（AD Recycle Bin），否则删错无法还原。常见踩坑点包括：
计算机网络安全服务公司网站模板
下载
计算机网络安全服务公司网站模板是一款适合提供云安全、网络安全、服务器管理。数据安全服务公司宣传网站模板下载。提示：本模板调用到谷歌字体库，可能会出现页面打开比较缓慢。
- 没检查回收站是否启用：
Get-ADOptionalFeature -Filter {Name -eq "Recycle Bin Feature"}返回EnabledScopes为空即未启用 - 批量删除时没加
-WhatIf预演，或没导出完整属性（特别是DistinguishedName和SID）本地存档 - 跳过冻结阶段，对“疑似陈旧”对象直接删除，结果发现是某部门刚部署的离线审计工作站
- 用
Remove-ADObject -Recursive删除计算机时，未确认该对象下无子对象（如嵌套组或托管服务账户），可能报错中断
清理流程必须分四步走，缺一不可
真实运维中，最常被跳过的不是技术操作，而是“通知”和“冻结”环节：
- 发现：用上文脚本生成报告，人工核对前 10 条，确认筛选逻辑合理
- 通知：邮件抄送资产管理员 + 所属部门 IT 接口人，附 CSV 清单和 14 天反馈期，明确“逾期未回复视为同意冻结”
-
冻结：对无异议对象执行
Disable-ADAccount，并移入专用 OU（如"OU=Stale-Computers-Disabled,DC=contoso,DC=com"） -
清理：冻结满 30 天后，再运行
Remove-ADComputer；全程记录操作日志，包含执行人、时间、DN、依据字段值
真正容易被忽略的是 OU 层级的保护设置——如果目标 OU 启用了“防止对象意外删除”，Remove-ADComputer 会静默失败，必须先用 Set-ADOrganizationalUnit 关闭 ProtectedFromAccidentalDeletion。
