我正在运行一个非常简短的脚本，简单地打印出所有用户及其上次登录时间：
get-aduser -filter * -property * |ft 名称，上次登录日期
我注意到只有少数用户有登录日期值，而绝大多数用户都是空白的。这些是每天登录的活跃用户。据我了解，lastlogondate 是某种 powershell 别名，它将“lastlogontimestamp”用户属性值从大整数转换为可读日期。我过去曾成功执行过此查询，并且它对某些用户来说仍然很有效。我进入 ADSIedit 发现所有用户的 lastlogontimestamp 中都有一个值。尽管如此，如果我直接查询该值，PS 中每个相关用户的值仍然为空白：
get-aduser -filter * -property * |ft 名称，上次登录时间戳
此行为在域中的所有 3 个 DC 上都是正确的。我感到很困惑。这是一个较大脚本的一部分，该脚本报告并处理未登录超过 X 天的用户帐户，并且直到今天为止一直按季度正常运行。今天在运行它时，我注意到报告中出现的用户很少，因此在故障排除中，我包含了最基本的查询来查看它会做什么。powershell 返回的空白时间戳肯定是错误的，为什么我的报告中出现的用户很少（脚本不包括空白登录值），但我不知道为什么 PS 中的值为空白，而特定用户的 ADSI 编辑器中的值肯定是填充的。其他几个属性（如“logoncount”）也是如此，并且只适用于受影响的用户（大多数），而正常工作的少数用户的 ADSI 属性和 PS 显示的值之间没有任何差异。
此示例中的所有 3 个 DC 均为 2012 R2，我注意到这种行为也发生在我们拥有的一个较小的混合域 (2008 和 2012 DC) 中的用户帐户上，但由于几乎没有用户驻留在那里，所以没有引起注意，因此并不是那么受关注。
还有一件重要的事情，如果我针对计算机帐户 Get-ADcomputer 而不是 Get-ADuser 运行此 PS 命令，则不会出现此类问题，所有计算机都会正确报告上次登录日期且没有空白。
在我致电微软之前有什么帮助吗？
答案1
Adi 是对的，这是某种权限问题。实际上，我刚刚解决了这个问题，当时一位同事运行查询并获得了正确的结果，但他使用了自己的登录帐户。此外，他“以管理员身份运行”以提升 PS 控制台。当我这样做时，它正常工作。我不知道过去我为什么从来不用这样做，而且我是域管理员，因此是 DC 上的本地管理员，但无论如何。它现在使用提升的 PS 提示工作。记录一下，我使用我的常规使用帐户进入 ADSIedit，并没有启动提升的会话.....奇怪，但我会接受它。
答案2
对于使用以下项的 Azure 存储帐户，情况也是如此：加入-AzStorageAccountForAuth，它在 AD 中创建一个计算机对象，但从未登录，因此没有 LastLogonTimestamp。