Powershell Logon Script nur mit Einschränkungen...?

[fraenki 0]

Hi,

 

ich nutze ein Powershell Script als Logon Script für Windows 10 und das funktioniert soweit ganz gut. Nur wird folgender Code "nicht korrekt" ausgeführt:

$wmifoo = Get-WMIObject -query "Select * From Win32_LogicalDisk Where DriveType = 4"
foreach ($foo in $wmifoo) {
    echo "debug: $foo.DeviceID" >> $($configuration.log)
}

Nicht korrekt heißt in diesem Fall: es werden keine Netzlaufwerke gefunden, wenn dieser Code im Logon Script ausgeführt wird.

Wenn ich den selben Code unter dem selben Benutzer ganz normal in der Powershell Console ausführe, dann werden hingegen die Netzlaufwerke korrekt angezeigt.

 

Mache ich da einen Noob-Fehler oder muss irgendeine Sicherheitseinstellung dafür angepasst werden?

 

 

Vielen Dank!

 

Ciao

- fraenki

 

 

[testperson 1.677]

Hi,

 

läuft das Script als Computer Start-Up Script oder als User Logon Script? Ich tippe einfach mal darauf, dass die Netzlaufwerke zur Laufzeit noch gar nicht verbunden sind ;) Oder verbindest du die Laufwerke vorher im Script?

Was soll denn später das Ergebnis des Script sein? Evtl. gibt es da ja auch Alternativen.

 

In der Power-Shell würde ich eher mit Out-File in Dateien schreiben und nicht mit "echo".

 

Gruß

Jan

[fraenki 0]

Hi Jan,

danke für deine Antwort! :)
 

läuft das Script als Computer Start-Up Script oder als User Logon Script?

Es handelt sich um ein User Logon Script.
 

Ich tippe einfach mal darauf, dass die Netzlaufwerke zur Laufzeit noch gar nicht verbunden sind ;) Oder verbindest du die Laufwerke vorher im Script?

Die Laufwerke sind in meinem Test bereits vorhanden, da ich sie als persistente Netzlaufwerke hinzugefügt habe.

Wenn ich statt Powershell das User Logon Script in VB schreibe, dann findet das Script auch die Netzlaufwerke mit folgendem Code:
 

Set objNet = CreateObject("WScript.Network")
Set Drives = objNet.EnumNetworkDrives
For i = 0 to Drives.Count - 1 Step 2
    WScript.Echo "Drive " & Drives.Item(i) & " = " & Drives.Item(i+1)
Next

Dieser VB Code kann die Daten korrekt auslesen, selbst wenn er als User Logon Script läuft.
Nur mit Powershell als User Logon Script will dies bei mir nicht funktionieren. Das ist auch der Grund, warum ich im ursprünglichen Post eine Einschränkung oder Sicherheitseinstellung als Ursache vermutet habe...
 

Was soll denn später das Ergebnis des Script sein? Evtl. gibt es da ja auch Alternativen.

Das User Logon Script prüft, ob alle benötigten Netzlaufwerke eingebunden sind. Wenn dies nicht der Fall ist, dann fragt es den User nach seinem Passwort für das NAS (unterscheidet sich vom Login Passwort) und bindet die Netzlaufwerke danach persistent ein.

Bzgl. Alternativen: Ich habe nur Windows 10 Pro Rechner und keinen Windows Server... mit einem VB Logon Script funktioniert es zwar prinzipiell, aber das kann keine Eingabefelder maskieren, sodass das Benutzerpasswort im Klartext sichtbar wäre. (Ja, ich kenne die "Lösungen" von Drittanbietern, um diese Funktion in VB einzubauen, aber die sind hier ungeeignet.) Deshalb Powershell...


Ciao
- fraenki

[testperson 1.677]

Hi,

 

um welches NAS handelt es sich denn? Kann das evtl. einen LDAP Server mit zentraler Userverwaltung bereitstellen?

Hat jeder User einen eigenen NAS-Benutzer oder ist es ein allgemeiner NAS User, der von allen zur Anmeldung am NAS genutzt wird?

 

Gruß

Jan

[blub 115]

Hi,

Kannst du das Skript mal versuchen als Task zu starten?

 

GPO -> User Configuration -> Preferences -> Scheduled Tasks 

New -> Scheduled Task -> ... General -> Action: Create  ->.... Triggers: At logon, Delay: 30 Seconds

 

blub

[Schweizerin 1]

Die Laufwerke sind in meinem Test bereits vorhanden, da ich sie als persistente Netzlaufwerke hinzugefügt habe.

 

Weißt du, dass sie bei Ausführung des Scripts vorhanden sind oder glaubst du dass es so ist? Dass das per VB funktioniert muss nichts sagen. Persistent heißt nicht, dass die Laufwerke schon von Anfang an da sind, sondern dass sie jedes Mal eingebunden werden. Das braucht aber trotzdem Zeit. Macht doch mal in deinem Script eine Prüfung in der Art wie

 

net use > %temp%\test.log

 

Wenn das negativ verläuft würde ich mir mal die GPOs anschauen, von denen die eine irgendwie "Auf das Netzwerk warten" heißt und die andere "Run scripts synchronously". Siehe auch:

 

http://www.gruppenrichtlinien.de/artikel/fast-logon-schnelles-anmelden-asynchrones-startverhalten-ehemals-faq-36/

[fraenki 0]

Danke für die vielen Antworten! :)
Zunächst die gute Nachricht: Das Problem ist gelöst.
Nun aber die schlechte Nachricht: Die Ursache ist unklar.

Wie wurde das Problem gelöst? Ich habe den entsprechenden Windows-Benutzer gelöscht und neu eingerichtet (ich hatte ja nichts zu verlieren). Und plötzlich hat das Powershell User Logon Script Netzlaufwerke gefunden, konnte fehlende Netzlaufwerke persistent mounten, usw.

Offenbar haben meine vielen Tests irgendetwas bei diesem Benutzer kaputt gemacht. In der Registry konnte ich z.B. unter HKCU\Network die Netzlaufwerke sehen, aber trotzdem waren sie für das User Logon Script "unsichtbar". Das galt inzwischen übrigens für *alle* Logon Scripte, also auch für die VB-Variante, die ja mal funktioniert hatte...

Alles sehr merkwürdig, aber jetzt funktioniert es zum Glück. Einen Benutzer zu löschen und neu einzurichten kann in Zukunft natürlich nicht die erste Wahl sein...

Nachfolgend antworte ich noch auf eure Vorschläge/Nachfragen.
 

Kannst du das Skript mal versuchen als Task zu starten?

GPO -> User Configuration -> Preferences -> Scheduled Tasks
New -> Scheduled Task -> ... General -> Action: Create ->.... Triggers: At logon, Delay: 30 Seconds

Diese Einstellung finde ich hier nicht im Editor für lokale Gruppenrichtlinien unter Windows 10 Pro. Gibt es das nur im Windows Server oder suche ich an der falschen Stelle?
Ich habe aber mal ausprobiert, ob es einen Unterschied macht, wenn ich "Start-Sleep -s 30" in mein Powershell Script einbaue – leider nicht, die Netzlaufwerke wurden dann zwar erst später gesucht, aber konnten trotzdem nicht gefunden werden.
 

Weißt du, dass sie bei Ausführung des Scripts vorhanden sind oder glaubst du dass es so ist? Dass das per VB funktioniert muss nichts sagen. Persistent heißt nicht, dass die Laufwerke schon von Anfang an da sind, sondern dass sie jedes Mal eingebunden werden. Das braucht aber trotzdem Zeit. Macht doch mal in deinem Script eine Prüfung in der Art wie

net use > %temp%\test.log

Danke, das waren gute Anregungen. Im Powershell-Script konnte "net use" auch keine Netzlaufwerke sehen. Dann habe ich aus lauter Verzweiflung nochmal mein (als funktionierend bekanntes) VB-Script herausgekramt und – siehe da – auch damit hat es nicht mehr funktioniert. Das hat mich auf die richtige Spur geführt (siehe oben)...
 

um welches NAS handelt es sich denn? Kann das evtl. einen LDAP Server mit zentraler Userverwaltung bereitstellen?
Hat jeder User einen eigenen NAS-Benutzer oder ist es ein allgemeiner NAS User, der von allen zur Anmeldung am NAS genutzt wird?

Hier kommt FreeNAS zum Einsatz (also effektiv Samba für die Windows-Clients). Eine zentrale Userverwaltung gibt es bereits, das FreeNAS/Samba ist an einen LDAP-Server angebunden. Nur wird der bewusst nicht für die Windows-Clients verwendet.


Ciao
- fraenki

bearbeitet 22. Juni 2016 von fraenki

[fraenki 0]

Hallo nochmal,

 

das Problem ist in ähnlicher Form wieder bei einem anderen Benutzer aufgetaucht. Diesmal habe ich die Ursache gefunden... die Benutzeraccounts werden hier (automatisch) so eingerichtet, dass sie nur Mitglied der Gruppe "Hauptbenutzer" sind. Offenbar funktionieren die User Logon Scripts aber nur dann vollständig, wenn der Benutzer auch Mitglied der Gruppe "Benutzer" ist.

 

Das macht auch tatsächlich Sinn, denn gemäß diesem Artikel von Microsoft hat die Gruppe "Hauptbenutzer" "No default user rights", wohingegen die Gruppe "Benutzer" über die offenbar benötigten Berechtigungen verfügt: "perform common tasks, such as running applications, using local and network printers".

 

 

Ciao

- fraenki

 

PS: In Windows 10 gibt es die Gruppe "Hauptbenutzer" eigentlich nicht mehr, aber bei einem Upgrade von einer früheren Windows-Version bleibt diese Gruppe erhalten (in der Beschreibung der Gruppe steht dann ein Hinweis bezüglich Rückwärtskompatibilität).

bearbeitet 23. Juni 2016 von fraenki