我不一定会信任Get-ADUser -LDAPFilter "(&(objectCategory=Person)(objectClass=User)(lockoutTime>=1))" -Properties LockedOut，因为它也不会为我返回可靠的结果，但是，此时，我也无法直接联系我的PDCe。为了获得最佳结果，您可能希望直接定位PDC仿真器，因为它始终具有有关整个域中帐户锁定的最新信息。
这就是我要保证的，您在这里看到的是复制的延迟：
...帐户锁定已紧急复制到主域控制器（PDC）仿真器角色所有者，然后紧急复制到以下内容：
•与PDC仿真器位于同一站点的同一域中的域控制器。
•与处理帐户锁定的域控制器位于同一站点的同一域中的域控制器。
•位于同一域中的域控制器，该域控制器位于已配置为允许与包含PDC模拟器的站点或处理了帐户锁定的站点之间的站点之间（因此，紧急复制）更改通知。这些站点包括包含在与包含PDC仿真器的站点相同的站点链接中，或与包含处理帐户锁定的域控制器的站点相同的站点链接中的任何站点。
此外，当在除PDC仿真器以外的域控制器上验证失败时，将在PDC仿真器上重试验证。因此，如果达到了尝试错误密码的阈值，则PDC模拟器会在处理失败密码尝试的域控制器之前锁定帐户。有关PDC模拟器角色所有者如何管理密码更改和帐户锁定的更多信息，请参见本书中的“管理灵活的单主机操作”。
因此Search-ADAccount -LockedOut -Server DC-PDCE，请尝试看看您的结果是否更好。
此外，围绕lockoutTime属性构建查询时，还需要考虑以下其他事项：
仅当成功登录帐户后，才会重置此属性值。这意味着该值可能不为零，但该帐户未被锁定。若要准确确定该帐户是否被锁定，必须将Lockout-Duration添加到该时间，并将结果与当前时间进行比较，并考虑本地时区和夏时制时间。
编辑：通过逆向工程Microsoft.ActiveDirectory.Management.dll，我可以告诉您，Search-ADAccount -LockedOut在我看来可以产生相当可靠的结果，并运行以下代码：
else if ((bool) this._paramSet.LockedOut)
{
list.Add(ADAccountFactory<ADAccount>.AttributeTable[cmdletSessionInfo.ConnectedADServerType]["AccountLockoutTime"].InvokeToSearcherConverter(ADOPathUtil.CreateFilterClause(ADOperator.Ge, "AccountLockoutTime", (object) 1), cmdletSessionInfo));
this.OutputFilterFunction = new ADGetCmdletBase<SearchADAccountParameterSet, ADAccountFactory<ADAccount>, ADAccount>.OutputFilterDelegate(this.FilterIsLockedOut);
}
if (list.Count > 0)
this.OutputSearchResults(list.Count != 1 ? ADOPathUtil.CreateAndClause(list.ToArray()) : list[0]);
else
this.OutputSearchResults((IADOPathNode) null);
因此，似乎也Search-ADAccount -LockedOut正在查看AccountLockoutTime属性！
编辑更多内容以求公义： Richard Mueller，Dir。服务MVP这样说：
您不能使用userAccountControl属性来识别被锁定的用户。为此记录了一些userAccountControl，但未使用它。
我可以这样验证：
PS C:\Users\ryan> $(Search-ADAccount -LockedOut).Count
11
PS C:\Users\ryan> $(Get-ADUser -LDAPFilter "(&(objectCategory=User)(userAccountControl:1.2.840.113556.1.4.803:=16))").Count
0
最后，我想在有关该主题的博客文章上结束，该主题解释了为什么lockoutTime>=1采用最佳解决方案，但这只是故事的一部分。您需要进一步过滤列表，以仅包括过去的lockoutTime大于$（您的域锁定持续时间）分钟的用户。