It replicates normally just like any other attribute, it just isn’t updated all of the time.
I go bonkers every time I see someone trying to explain it doesn’t replicate all of the time (more accurately people say it only replicates every 14 days). That is because it is completely wrong… It replicates just like any other attribute when it is updated. How often that replication is done is completely based on your replication topology, not some arbitrary setting in the DS.
So repeat after me 10 times…
lastLogonTimeStamp does INDEED replicate, it just isn’t updated all that often.
So the question is, when does it get updated?
I have looked into this a little, I recall some of it. It isn’t something I keep memorized as it really isn’t that exciting, if you are hanging on the attributes value to the daily interval, you really aren’t using it right. Think of this of being within a week, not being within a day, even if you modify the update frequency. Note that with Longhorn and RODCs, this attribute’s value is less useful since RODCs can’t replicate any attributes, not even lastLogonTimeStamp which means that the attribute will only be updated when an auth request has to be chained to a Full DC – i.e. when first used or anytime the password cache value needs to be updated.
So here we go…
o The lastLogonTimeStamp is driven by the lastLogon attribute. If an authentication occurs that doesn’t update lastLogon, there is no chance it will update lastLogonTimeStamp. Basically after lastLogon is updated, the system checks to see if the interval since the last update to lastLogonTimeStamp is sufficient to force it to be updated now. So for example, successful simple binds DO NOT update this set of attributes unless the last authentication failed. Don’t believe me, try it yourself, maybe it changed, I doubt it. The idea behind simple binds is to make them as lightweight and fast as possible, writing to the DS is neither lightweight nor all that fast relatively speaking.
[UPDATE: I have found that with S4U this is no longer the case. S4U will update the lastLogonTimeStamp value without touching lastLogon.]
o The default interval between updates is 14 days. However there is a swing period involved that changes how often the updates really occur.
o The swing period is up to minus five days. So the realistic period is 9-14 days between updates to the lastLogonTimeStamp. The swing period is randomly calculated. I do recall at one point doing a good number of tests and found that 10 days seemed to be pretty popular for the update frequency. So much so that for a long time I considered that to be the true value.
o The update frequency can be changed by modifying the NC Head Attribute called msDS-LogonTimeSyncInterval
o This attribute is specified in days. The minimum value on AD is 1 day, the minimum value on ADAM is 0 days [See http://blog.joeware.net/2006/06/22/420/] which means update the attribute for every successful authentication. The max value of this attribute comes out to be 274 years. Good luck testing that last. Would love to help but I have other plans that day.
o If the value of msDS-LogonTimeSyncInterval is set to less than 5 days (i.e. the random swing period), the swing period will not be used.
Now before you get all giddy and go and change the NC Head attribute on all of your domains, keep in mind that MSFT set it to a default of 14 days with a random swing period for a reason….. In larger environments this can cause ***A LOT*** of churn and replication traffic and it likely doesn’t have enough value to do so. If you need last logon tracking that is that granular, set up a logon script to update a database or send an email or something. Seriously.
joe
I’ve seen many posts concerning the use of scripts and your utility, OLDCMP to remove unused accounts. My problem is that I have remote users using Cisco VPN client to establish a connection to our internal network and their user and computer lastlogon properties don’t appear to be updated. How can I get these VPN users/computers to update their lastlogon attribute?
No way that I know of. This is a common problem, occurs with many VPN clients as well as cluster accounts and any machines that people have just turned off password changes on. Password changes are not required for computers like they are for users, it is entirely up to the machine if it wants to change the password or not.
Thanks for the fast reply. So do you have any suggestions on how to truly determine if a user account is being used within an AD environment? Or is that just a pipe dream?
Lifecycle management is a process problem, not technical.
You need to come up with a process to mark every object in the directory that is created on behalf of some app/person/whatever and have a way to revalidate the need on some frequency (monthly, quarterly, yearly, bi-annually, whatever) and then enforce it.
Some companies do this by adding new attributes to the top class and then populating them on all managed lifecycle objects and coming up with the background processes to keep everything current and if something goes out of currency, it gets smoked.
It is a problem I would love to work on but no time to really dedicate to it. It can definitely be helped by technical solutions but it is at its core a process problem.
There are no magic bullets.
Hi Joe,
We have to run a report every month for all domain users with their 2 attributes that are : LastLogon and lastlogontimestamp.
But this time I have noticed that all lastlogontimestamp is not same on all DCs . Moreover users I have checked are those which have not logged in for past 3 months.
Also difference in lastlogontimestamp is more tham 2 months in some cases which ideally shd not be more than 14 days (as per microsoft).
Kindly look into the above issue and help resolving this.
Note: except above issue rest is seems to be fine as far as replication is concerned. Specailly I checked schema partition replication among DC and it is fine.
Yogesh Malhotra