I am running a very short script to simply print out all users and their last logon time:

get-aduser -filter * -property * |ft name, lastlogondate

I noticed only a small handful of users have a logon date value while the vast majority it is blank. These are active users logging in every day. It is my understanding that lastlogondate is some sort of powershell alias that converts the 'lastlogontimestamp' user attribute value from a large integer into a readable date. I had success with this query in the past and again it works fine for some users. I went into ADSIedit and found that all users have a value in lastlogontimestamp. Despite this, if I directly query that value I still get blank in PS for each user in question:

get-aduser -filter * -property * |ft name, lastlogontimestamp

This behavior is true on all 3 DCs in the domain. I am baffled. This is part of a larger script that reports and acts on user accounts who haven't logged in longer than X days and has been running fine on a quarterly basis until today. In running it today I noticed that very few users were appearing on the report as being stale, so in troubleshooting I included the most basic query to see what it would do. The blank time stamp being returned in powershell is definitely wrong and why so few users show up on my report as stale (script excludes blank logon values), but I don't know why the value in PS is blank while the value in ADSI editor for the specific user is definitely populated. This is true of several other attributes like 'logoncount' as well, and only for those affected users (majority) while the few users that are working properly have no descrepencies between ADSI attribute and what PS shows at all.

All 3 DCs in this example are 2012 R2 and I noticed this behavior also happens on user accounts in a smaller mixed domain we have (2008 and 2012 DCs) but went unnoticed because hardly any users reside there so it isn't that much of a focus.

One other important thing, if I run this PS command against computer accounts Get-ADcomputer instead of Get-ADuser I have no such issues, all Computers report a lastlogondate correctly with no blanks.

Any help before I call Microsoft?

  • Is this strange behavior consistent across all Domain Controllers? You can use the -Server parameter to target a specific DC – Mathias R. Jessen Apr 22 '14 at 20:17
  • Yes I was unable to get the -server command to work but I manually ran the query on each DC and checked ADSIedit on each DC and the behavior is consistent. – Frustrated_IT_guy Apr 22 '14 at 20:37
  • As a test I created a single brand new test user. Logged on to server in domain as that test user to create a timestamp. Verified the ADSI attribute is there on the DC for lastlogontimestamp. I then run a Powershell query like this: get-aduser -filter 'name -like "testIT"' -property * |ft name, lastlogondate and the lastlogondate is blank – Frustrated_IT_guy Apr 22 '14 at 20:52
  • If you use dsquery from the same prompt, do you get the same results as from Get-ADUser or the same info you see in ADSIEdit? Try dsquery * -limit 0 -filter "objectClass=user" -attr name lastLogonTimestamp. – Adi Inbar Apr 22 '14 at 20:52
  • Adi I ran your command and it returns the correct lastlogontimestamp values for all the COMPUTER ACCOUNTS but shows blank values for the affected users (ie some users do have values, most do not) so it is consistent with get-aduser in that it is wrong according to the values in ADSIedit for most users. – Frustrated_IT_guy Apr 22 '14 at 20:56

Adi was right, it is some sort of permissions issue. I actually resolved this just now when a coworker ran the query and got proper results, however he used his own login account. Im addition he "ran as administrator" to elevate the PS console. When I did this it worked correctly. I have no idea how I never had to do this in the past, and also I am a domain admin and therefore local admin on the DCs, but whatever. It now works using elevated PS prompt. For the record I went into ADSIedit with my regular using account and did not launch elevated session.....Strange but I'll take it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.