8
PS: Vergleich von Datum AccountExpirationDate und Get-date schlägt fehl
Moin zusammen,
ich habe ein Skript mit dem ich mir eine Usergruppe aus dem AD hole. anschließend prüfe ich, welche Accounts abgelaufen sind. Das klappt nur nicht und ich komme nicht auf den Fehler.
Ich bekomme auch alle User raus, schaffe es aber nicht, dass der Vergleich passt. Hier die Kontrollausgabe
Bei der Ausgabe (zum prüfen) sieht das Datum von AccountExpirationDate immer noch falsch aus, weshalb vermutlich der Vergleich nicht klappt. Ich habe mir auch schon einen Wolf gesucht und versucht anders zu formatieren, aber irgend wie komme ich nicht weiter. Vermutlich ist das ganz trival ... aber ich bekomme es aktuell nicht hin.
Hat jemand eine Idee was ich falsch mache?
Thx
Nagus
ich habe ein Skript mit dem ich mir eine Usergruppe aus dem AD hole. anschließend prüfe ich, welche Accounts abgelaufen sind. Das klappt nur nicht und ich komme nicht auf den Fehler.
$user = get-aduser -filter * -properties * | select name, SamAccountName, displayname, mail, AccountExpirationDate, LastLogonDate, ProfilePath, PasswordLastSet, Manager
$extern = @()
$intern = @()
$DelExt = @()
# Hole alle Externen aus dem AD
foreach($u in $user){
$extern +=(Get-ADUser $u.SamAccountName -Properties * | Where{$u.DisplayName -like "*extern*"})| select name, displayname, mail, AccountExpirationDate, LastLogonDate, ProfilePath, PasswordLastSet, Manager
#$intern +=(Get-ADUser $u.SamAccountName -Properties * | Where{$u.DisplayName -notlike "*extern*"})| select name, displayname, AccountExpirationDate, LastLogonDate
}
foreach($e in $extern)
{
$ACCDate = (get-date $e.AccountExpirationDate -Format dd.MM.yyyy)
$chkDate = Get-Date -format dd.MM.yyyy ((Get-Date).adddays(-90))
if($ACCDate -le $chkDate)
{
$DelExt += $e
write-host "Wahr: $($e.name) ACC-DATE:$($e.AccountExpirationDate) CHKDATE: $($ChkDate)"
}
else
{
write-host "Falsch: $($e.name) ACC-DATE:$($e.AccountExpirationDate) CHKDATE: $($ChkDate)"
}
}
Ich bekomme auch alle User raus, schaffe es aber nicht, dass der Vergleich passt. Hier die Kontrollausgabe
Wahr: USENAME1 ACC-DATE:04/01/2022 00:00:00 CHKDATE: 01.07.2021
Falsch: USERNAME2 ACC-DATE:11/30/2021 00:00:00 CHKDATE: 01.07.2021Bei der Ausgabe (zum prüfen) sieht das Datum von AccountExpirationDate immer noch falsch aus, weshalb vermutlich der Vergleich nicht klappt. Ich habe mir auch schon einen Wolf gesucht und versucht anders zu formatieren, aber irgend wie komme ich nicht weiter. Vermutlich ist das ganz trival ... aber ich bekomme es aktuell nicht hin.
Hat jemand eine Idee was ich falsch mache?
Thx
Nagus
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1323626175
Url: https://administrator.de/forum/ps-vergleich-von-datum-accountexpirationdate-und-get-date-schlaegt-fehl-1323626175.html
Ausgedruckt am: 31.12.2024 um 09:12 Uhr
8 Kommentare
Neuester Kommentar
Zitat von @Nagus:
$ACCDate = (get-date $e.AccountExpirationDate -Format dd.MM.yyyy)
$chkDate = Get-Date -format dd.MM.yyyy ((Get-Date).adddays(-90))
if($ACCDate -le $chkDate)
{
$DelExt += $e
write-host "Wahr: $($e.name) ACC-DATE:$($e.AccountExpirationDate) CHKDATE: $($ChkDate)"
}
else
{
write-host "Falsch: $($e.name) ACC-DATE:$($e.AccountExpirationDate) CHKDATE: $($ChkDate)"
}
Ich bekomme auch alle User raus, schaffe es aber nicht, dass der Vergleich passt. Hier die Kontrollausgabe
Wahr: USENAME1 ACC-DATE:04/01/2022 00:00:00 CHKDATE: 01.07.2021
Falsch: USERNAME2 ACC-DATE:11/30/2021 00:00:00 CHKDATE: 01.07.2021Bei der Ausgabe (zum prüfen) sieht das Datum von AccountExpirationDate immer noch falsch aus, weshalb vermutlich der Vergleich nicht klappt. Ich habe mir auch schon einen Wolf gesucht und versucht anders zu formatieren, aber irgend wie komme ich nicht weiter. Vermutlich ist das ganz trival ... aber ich bekomme es aktuell nicht hin.
Es werden keine Date oder DateTime Werte miteinander verglichen, sondern Strings.
Zitat von @mbehrens:
Es werden keine Date oder DateTime Werte miteinander verglichen, sondern Strings.
Eben, und des weiteren wird nicht auf $null Werte geprüft, denn die Eigenschaft AccountExpirationDate kann auch leer sein.Es werden keine Date oder DateTime Werte miteinander verglichen, sondern Strings.
Eben, und des weiteren wird nicht auf $null Werte geprüft, denn die Eigenschaft AccountExpirationDate kann auch leer sein.
Das ist aktuell mein kleinstes Problem.Es werden keine Date oder DateTime Werte miteinander verglichen, sondern Strings.
Und wie kann ich das lösen? Ich verstehe das aktuell nicht ...Zitat von @Nagus:
Gehört aber mit dazu Eben, und des weiteren wird nicht auf $null Werte geprüft, denn die Eigenschaft AccountExpirationDate kann auch leer sein.
Das ist aktuell mein kleinstes Problem.
.Und wie kann ich das lösen? Ich verstehe das aktuell nicht ...
AccountExpirationDate ist schon vom Typ DateTime , eine Umwandlung mit Get-Date ist also vollkommen überflüssig.Guckst du ...
Get-ADUser -Filter * -Properties AccountExpirationDate | ?{$_.AccountExpirationDate -ne $null -and $_.AccountExpirationDate -lt (get-date).AddDays(-90)}
hmm ... okay das wars ...
Bin davon ausgegangen dass ich das Format anpassen muss, weil AccountExpirationDate mit Uhrzeit und Amerikanisches Format ist. Daher wollte ich es auf das normale Datum und Europäische Format umstellen.
Die Prüfung auf Null beim AccountExpirationDate brauche ich übrigens aus zwei gründen nicht:
1. Vom Prozess darf es für Externe nicht leer sein
2. Es ist dann kleiner als das Chkdate und erschenit in der Auswertung
Danke für die Hilfe!
Bin davon ausgegangen dass ich das Format anpassen muss, weil AccountExpirationDate mit Uhrzeit und Amerikanisches Format ist. Daher wollte ich es auf das normale Datum und Europäische Format umstellen.
Die Prüfung auf Null beim AccountExpirationDate brauche ich übrigens aus zwei gründen nicht:
1. Vom Prozess darf es für Externe nicht leer sein
2. Es ist dann kleiner als das Chkdate und erschenit in der Auswertung
Danke für die Hilfe!
Zitat von @Nagus:
hmm ... okay das wars ...
Bin davon ausgegangen dass ich das Format anpassen muss, weil AccountExpirationDate mit Uhrzeit und Amerikanisches Format ist.
Das kommt wenn man DateTime-Objekte unformatiert direkt in einem String ausgibt, dann formatiert die Powershell das Datum per Default amerikanisch.hmm ... okay das wars ...
Bin davon ausgegangen dass ich das Format anpassen muss, weil AccountExpirationDate mit Uhrzeit und Amerikanisches Format ist.
Die Prüfung auf Null beim AccountExpirationDate brauche ich übrigens aus zwei gründen nicht:
1. Vom Prozess darf es für Externe nicht leer sein
Auch wenn das so sein sollte nimmt man als guter Programmierer das niemals einfach so an sondern prüft auch ob es tatsächlich so ist, denn auch Menschen machen Fehler!1. Vom Prozess darf es für Externe nicht leer sein
Das kommt wenn man DateTime-Objekte unformatiert direkt in einem String ausgibt, dann formatiert die Powershell das Datum per Default amerikanisch.
Wie kann ich das anders übernehmen. Was mich aber wundert ist, dass im CSV Export das Datum wieder Europäisch ist
Auch wenn das so sein sollte nimmt man als guter Programmierer das niemals einfach so an sondern prüft auch ob es tatsächlich so ist, denn auch Menschen machen Fehler!
hab nie behauptet, dass ich ein guter Programmierer sei 
Ich muss das ganze eh manuell prüfen und dann sehe ich die ohne Ablaufdatum auch gleich
Zitat von @Nagus:
Wie kann ich das anders übernehmen.
Indem du es explizit als String formatiert ausgibst dann nimmt die Powershell die CurrentCulture der aktuellen Powershell Session.Das kommt wenn man DateTime-Objekte unformatiert direkt in einem String ausgibt, dann formatiert die Powershell das Datum per Default amerikanisch.
Wie kann ich das anders übernehmen.
write-host "Datum: $($datumsvariable.toString('G'))" Was mich aber wundert ist, dass im CSV Export das Datum wieder Europäisch ist
Das ist normal, weil ein CSV-Export etwas anderes ist und die Powershell für DateTime Objekte die String-Umwandlung nach der CurrentCulture vornimmt.hab nie behauptet, dass ich ein guter Programmierer sei
Aber du kannst es werden. Eigentlich sollte man immer das Ziel haben etwas nachhaltig und zuverlässig zu machen. Warum haben wir die ganzen Sicherheitslücken wohl, weil viele beim Coden einfach zu wenig Sorgfalt walten lassen.
