LastLogonDate är en konverterad version av LastLogonTimestamp och replikeras mellan DC:er med upp till 14 dagars fördröjning. Eftersom du frågar 30 dagar bakåt i tiden är LastLogonDate lämplig om du förstår begränsningarna. Mer om det senare.

LastLogon replikeras INTE, utan innehåller användarens faktiska senaste inloggning. För att fråga mot detta måste du fråga varje DC i din domän och välja den senaste LastLogon, annars får du inte den faktiska senaste inloggningen.

Säg nu att du frågar efter LastLogonDate/Timestamp och kontrollerar i 30 dagar, eftersom det kan finnas en uppdateringsfördröjning på upp till 14 dagar, kan den vara upp till 14 dagar äldre än den faktiska senaste inloggningen. Det betyder att lastlogontimestamp kan vara 6/28, men de kan ha loggat in till exempel 7/5 utan att lastlogontimestamp har uppdaterats. Att kontrollera 30 dagar mot lastlogontimestamp innebär alltså att du egentligen kontrollerar användare som inte har loggat in mellan 15 och 30 dagar. Om du vill kontrollera endast för mer än 30 dagar kan du ställa in den på 45 dagar och missa några användare som inte har loggat in mellan 30 och 44 dagar.

In kommer Search-ADAccount:

Vad är lättare att använda, enligt min åsikt. Tänk på att Search-ADAccount tittar på lastlogonTimestamp som kan uppdateras upp till 14 dagar efter. Men Search-ADAccount lägger till 15 dagar till det du ger den för att ta hänsyn till förseningen. Så om du vill kontrollera konton som definitivt inte har loggat in de senaste 30 dagarna, ger du den 30 dagar. Den kontrollerar sedan lastlongontimestamp för datum som är äldre än 45 dagar.

Oavsett detta kommer det du gör inte att ge dig de resultat du är ute efter. Om du vill fortsätta att använda lastlogon måste du kontrollera varje DC. Om du byter till lastlogontimestamp (eller search-adaccount) måste du acceptera att användare som senast har loggat in mellan 30 och 44 dagar kanske eller kanske inte missas.