I am trying to get the LastLogon details for Users in AD, complete with the name of the workstation they used to do so.
For some reason Microsoft do not consider that sort of information all that important
I can use get-aduser to find the ‘LastLogon’ for each user. As MS do not replicate that, I have to do so on every Domain Controller (19 of them including Branch Offices) and find the most recent value from those.
Then I can search the EventLogs with get-eventlog and get the ‘TimeGenerated’ values - then try to match the two results to find which event corresponds to the ‘LastLogon’.
Then I can parse the ‘Message’ field of the Event to find the IP address of the workstation used.
Then I can resolve that with DNS to get the hostname of the workstation.
Unfortunately, for some reason, the value of ‘LastLogon’ in the User ID in AD is stored with as much as 7 decimal places of seconds - whereas the ‘TimeGenerated’ value in the EventLog is only stored in full seconds - both on the same Domain Controller.
Why?
Also, the Eventlog seems to record about a dozen 4624 (logon) entries at more or less the same moment (probably as each drive letter is mapped to different volumes on the SAN). How am I supposed to identify which one of these corresponds to the ‘LastLogon’ if they are all logged as integer values when exact same entries (or one of them) are stored in AD with full precision (i.e. as Real values)? This has to be the same data - so why are they stored to differing levels of precision?
This is indeed a tricky bit. You can look at the lastLogonTimestamp attribute, which replicates, although it does so in a low-priority mode, which means there’s some significant lag. You’re right in that Microsoft really hasn’t enabled this kind of tracking for who-logged-in-where - it just wasn’t part of Windows’ original philosophy and it’s hard to retrofit, it seems.
MS also seems to have come up with a different way of storing dates everyplace they do it.
But the “why” is probably not all that important, because you and I can’t do anything about it! This is an area that a lot of ISVs have invested a lot of time in - many of them using client-side agents to provide this kind of logging. In fact, that’s something you might consider. Write a little logon script that just logs the current date, time, username, and computer name in a local file, perhaps appending it to keep a local log. I bet it’d be a lot easier to just go collect those logs than to do all the runaround you’re currently doing. Would that be an option?
It just seems wrong to have to do that when the data is already stored - just not in a consistent (and thus comparable) format.
Would you suggest storing that information on the Workstations or the Domain Controllers prior to collation please?
BTW - completely irrelevant side question - how do you add smiley faces on posts here please. I can only use ones for which I can remember the relevant punctuation. So I can do and but not (unless that is the correct format to use of course. Just a guess based on BBCode).
If all my clients were on a single LAN, I’d have the files written to a single file share. Easy collection.
Otherwise, I’d probably have them written to a share on each DC. However, I’d have to remember that a client could log on to multiple DCs, so I’d need to be prepared to merge files or something.
You also have to account for offline logons (laptops off the network). So maybe either don’t write, or write locally always and plan to collect.
You have to think about the scenarios your environment has.
)
(unless that is the correct format to use of course. Just a guess based on BBCode).