LastLogonDate is een geconverteerde versie van LastLogonTimestamp en wordt gerepliceerd tussen DC’s met een vertraging van maximaal 14 dagen. Aangezien je 30 dagen terug vraagt, is LastLogonDate geschikt als je de beperkingen begrijpt. Daarover later meer.

LastLogon wordt NIET gerepliceerd, maar bevat de daadwerkelijke laatste login van de gebruiker. Om daarnaar te zoeken moet je elke DC in je domein doorzoeken en de meest recente LastLogon selecteren, anders krijg je niet de werkelijke laatste login.

Nu, stel dat je LastLogonDate/Timestamp vraagt en controleert voor 30 dagen, omdat er een update vertraging van maximaal 14 dagen kan zijn, zou het tot 14 dagen ouder kunnen zijn dan de werkelijke laatste login. Dat betekent dat lastlogontimestamp 6/28 kan zijn, maar ze kunnen ingelogd zijn op zeg 7/5 en het heeft lastlogontimestamp niet bijgewerkt. Dus 30 dagen controleren op lastlogontimestamp betekent dat je eigenlijk controleert op gebruikers die tussen de 15 en 30 dagen niet ingelogd zijn geweest. Als je alleen wilt controleren op meer dan 30 dagen, kun je het op 45 dagen zetten en een aantal gebruikers missen die tussen de 30 en 44 dagen niet hebben ingelogd.

In komt Zoeken-ADAccount:

Wat gemakkelijker te gebruiken is, naar mijn mening. In gedachten houdend dat Search-ADAccount kijkt naar de lastlogonTimestamp die tot 14 dagen achter kan liggen. Maar, Search-ADAccount voegt 15 dagen toe aan wat je doorgeeft om rekening te houden met de vertraging. Dus als je wilt controleren op accounts die zeker de laatste 30 dagen niet hebben ingelogd, dan geef je 30 dagen door. Het controleert dan de lastlongontimestamp voor data ouder dan 45 dagen.

Hoe dan ook, wat je nu doet zal je niet de resultaten geven die je zoekt. Om lastlogon te blijven gebruiken, moet je elke DC controleren. Om over te schakelen op lastlogontimestamp (of search-adaccount), moet je accepteren dat gebruikers die voor het laatst hebben ingelogd tussen de 30 en 44 dagen al dan niet gemist worden.