PS Logonscript wird die gesammte Sitzungsdauer ausgeführt und sperrt Datei

Hallo zusammen,

ich hab ein Problem mit einem PS Script. Dieses soll von allen Nutzern Loginnamen und Uhrzeit per Anmeldescript protokollieren und in eine XML schreiben.

Wenn ich das ganze manuell ausführe funktioniert das auch wunderbar.
Aber wenn ich das per GPO als Loginscript verteile dann wird nur die Person geloggt die sich an einem Tag als erstes anmeldet.
Das Protokollieren funktioniert dann solange nicht bis die Person sich wieder am Rechner abmeldet.

Ich hab schon mal geprüft ob der Zugriff auf die Datei nicht möglich ist und siehe da, ja das ist so.

Beim manuellen ausführen des Scripts während es wohl per GPO bei einem anderen Nutzer noch aktiv ist erhalte ich folgende Fehlermeldung:

Ausnahme beim Aufrufen von "Save" mit 1 Argument(en):  "Der Zugriff auf den Pfad "\\server-da\scripts$\login-2019-06-06.xml" wurde verweigert."  
In Zeile:45 Zeichen:41
+ $xml.Save("\\server-da\scripts$\login-$(get-date -format "yyyy-MM-dd").xml")  
+                                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) , MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException
 
Fehler beim Aufrufen der Methode, da [System.Xml.XmlDocument] keine Methode mit dem Namen "close" enthält.  
In Zeile:46 Zeichen:1
+ $xml.close()
+ ~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (close:String) , RuntimeException
    + FullyQualifiedErrorId : MethodNotFound

Das Script sieht wie folgt aus:

while($(test-path \\server-da\scripts$\login-locked.txt)) {

# Schleife pausiert solange login-locked.txt existiert.

}

New-Item -ItemType "file" -Path '\\server-da\scripts$\login-locked.txt'  

# Datei einlesen
if(!$(test-path \\server-da\scripts$\login-$(get-date -format "yyyy-MM-dd").xml)) {  

    [xml]$xml = '<?xml version="1.0" encoding="UTF-8"?> <DATEN><HEAD>Mitarbeiterlogin</HEAD></DATEN>'  

}
else {
    
    [xml]$xml = get-content \\server-da\scripts$\login-$(get-date -format "yyyy-MM-dd").xml  

}
# Neuen Datensatz erzeugen
$new_ds = $xml.CreateElement("Datensatz")  

# Neuen Anzeigename erzeugen
$new_name = $xml.CreateElement("Mitarbeiter")  
$new_name.InnerText = ([adsisearcher]"(SamAccountName=$env:USERNAME)").FindOne().Properties.displayname  

# Neuen Mitarbeiter erzeugen
$new_login = $xml.CreateElement("Loginname")  
# Mitarbeiter mit Loginnamen füllen
$new_login.set_innerText($env:USERNAME)

# Neues Datum erzeugen
$new_date = $xml.CreateElement("Uhrzeit")  
# Datum mit aktueller Zeit füllen
$new_date.set_InnerText($(get-date -format "HH:mm"))  

# Daten an Datensatz anhängen
$new_ds.AppendChild($new_name)
$new_ds.AppendChild($new_login)
$new_ds.AppendChild($new_date)

# Datensatz in die Datei einfügen
$xml.daten.AppendChild($new_ds)
# Datei speichern
$xml.Save("\\server-da\scripts$\login-$(get-date -format "yyyy-MM-dd").xml")  

remove-item -Path '\\server-da\scripts$\login-locked.txt'  

Wie bringe ich das Script nun dazu nicht dauerhaft weiterzulaufen wenn es per GPO als Logonscript genutzt wird?
Exit hab ich schon versucht und das scheint grundsätzlich bei Logonscripts wohl nicht zu funktionieren.

Dachte ja zuerst das wäre mit so etwas wie einem $.xml.Close() erledigt, das gibt es aber nicht in PS.
Wie kann ich entweder das ganze Script beenden, oder die Datei wieder freigeben, oder am besten beides?
Hat jemand vielleicht eine Idee?

Danke schon mal.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 459149

Url: https://administrator.de/contentid/459149

Ausgedruckt am: 22.11.2024 um 20:11 Uhr

4 Kommentare

Neuester Kommentar

Moin,

da ist die Frage ja wieder. Ich hatte nämlich schon geantwortet.

Ich vermute eher ein Rechteproblem. Was gibt

get-acl 2019-06-06.xml

zurück, wenn Du die Datei per Logon-Skript anlegen lässt?

hth

Erik

Sorry ja beim vorherigen Thread gab es ein kleines Problem, musste den deshalb nochmal anlegen ;)

An die ACL hab ich jetzt gar nicht gedacht, da das Script ja nur nicht läuft wenn es per Loginscript eingebunden ist.
Verstehe in dem Fall nicht ganz warum das dann nicht auftritt wenn ich das manuell ausführe (auch auf verschiedenen Accounts).

Aber grundsätzlich könntest du mit ACL Recht haben.

ACL:

Path: login-2019-06-06.xml

Owner: Domain\depot2

Access: Domain\admin Allow FullControl...

Hab das gerade nochmal manuell geprüft.

Du hast definitiv Recht, ich hatte zwar das Script manuell über mehrere Accounts geprüft, jedoch waren das beides Administratoraccounts die Zugriff auf die Datei haben.

Andere Nutzer haben keinen Zugriff.