LastLogonDate er en konverteret version af LastLogonTimestamp og replikeres mellem DC’er med op til 14 dages forsinkelse. Da du forespørger 30 dage tilbage, er LastLogonDate passende, hvis du forstår begrænsningerne. Mere om det senere.

LastLogon replikeres IKKE, men indeholder brugerens faktiske sidste login. For at forespørge i forhold til dette skal du forespørge alle DC’er i dit domæne og vælge den seneste LastLogon, ellers får du faktisk ikke deres faktiske sidste logon.

Sig nu, at du forespørger LastLogonDate/Timestamp og kontrollerer for 30 dage, da der kan være en opdateringsforsinkelse på op til 14 dage, kan det læse op til 14 dage ældre end deres faktiske sidste logon. Det betyder, at lastlogontimestamp kunne være 6/28, men de kan have logget på sige 7/5 og det ikke har opdateret lastlogontimestamp. Så at kontrollere for 30 dage i forhold til lastlogontimestamp betyder, at du i virkeligheden kontrollerer for brugere, der ikke har logget ind fra 15 til 30 dage. Hvis du kun vil kontrollere for mere end 30 dage, kan du indstille den til 45 dage og gå glip af nogle brugere, der ikke har logget ind fra 30 til 44 dage.

In kommer Search-ADAccount:

Hvilket er nemmere at bruge, efter min mening. Husk på, at Search-ADAccount ser på lastlogonTimestamp, der kan være opdateret op til 14 dage bagud. Men Search-ADAccount tilføjer 15 dage til det, du giver den, for at tage højde for forsinkelsen. Så hvis du ønsker at tjekke efter konti, som bestemt ikke har logget ind i de sidste 30 dage, skal du give den 30 dage. Derefter kontrollerer den lastlongontimestamp for datoer, der er ældre end 45 dage.

Uanset hvad, så vil det, du gør, ikke give dig de resultater, du er ude efter. Hvis du fortsat vil bruge lastlogon, skal du kontrollere hver DC. Hvis du vil skifte til lastlogontimestamp (eller search-adaccount), er du nødt til at acceptere, at brugere, der sidst har logget ind fra 30 til 44 dage, måske eller måske ikke bliver overset.