Das Shutdown-Skript wird nicht ausgeführt, wenn die Workstation nicht mit dem Netzwerk verbunden ist


8

Ich muss jedes Mal, wenn ein System heruntergefahren wird, ein Batch-Skript ausführen, unabhängig davon, ob der Computer mit dem Netzwerk verbunden ist oder nicht. (Es sollte für die Frage keine Rolle spielen, aber das betreffende Skript löscht die Druckwarteschlange des Geräts.

Ich kann dieses Skript jedoch nicht ausführen, wenn der PC vom Netzwerk offline ist, wenn ich die folgende Methode verwende.

Ich könnte auch hinzufügen, dass auf dem fraglichen PC Windows 10 Pro x64 (Version 1809) ausgeführt wird. Auf dem Domänencontroller wird Windows Server 2008 R2 ausgeführt, und hier habe ich auch ausgeführt gpedit.msc.

Was ich bisher gemacht habe:

  • Erstellt ein Active Directory- Gruppenrichtlinienobjekt mit einem Skript zum Herunterfahren des Computers.
  • Das Skript wurde dem GPO-Ordner in SYSVOL hinzugefügt .
  • Bestätigt, dass dieses Gruppenrichtlinienobjekt tatsächlich auf die Festplatte der betreffenden Workstation heruntergeladen wurde und daher offline zugänglich sein sollte.
  • Die im Gruppenrichtlinienobjekt angegebenen Pfade sind relativ und nicht absolut.

Was ich passieren möchte:

  • Wenn der PC heruntergefahren wird, wird das ClearPrintQueue.batSkript ausgeführt, unabhängig davon, ob der PC derzeit über eine Netzwerkverbindung verfügt oder nicht.

Was passiert eigentlich:

  • Wenn der PC heruntergefahren wird, wird das ClearPrintQueue.batSkript nur ausgeführt, wenn der PC derzeit die SYSVOL- Freigabe über das Netzwerk erreichen kann.

Einzelheiten:

Ich habe ein Gruppenrichtlinienobjekt in der Domäne erstellt und es mit einer Test-Organisationseinheit verknüpft, die den betreffenden Computer enthält.

Ich habe das Gruppenrichtlinienobjekt bearbeitet und zu Computerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Skripts (Starten / Herunterfahren) -> Herunterfahren navigiert

Die Eigenschaften zum Herunterfahren wie folgt :

Eigenschaften zum Herunterfahren

Wenn Sie auf Dateien anzeigen ... klicken, wird der Explorer geöffnet, um den Ordner anzuzeigen\\example.com\SysVol\example.com\Policies\{1B61F884-9D14-4065-8265-F04FFDE41683}\Machine\Scripts\Shutdown

Der Inhalt dieses Ordners und der Datei ClearPrintQueue.bat lauten wie folgt:

PS C:\> Get-ChildItem "\\example.com\SysVol\example.com\Policies\{1B61F884-9D14-4065-8265-F04FFDE41683}\Machine\Scripts\Shutdown"


    Directory: \\example.com\SysVol\example.com\Policies\{1B61F884-9D14-4065-8265-F04FFDE41683}\Machine\Scripts\Shutdown


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       2019-04-23     15:00             71 ClearPrintQueue.bat


PS C:\> Get-Content "\\example.com\SysVol\example.com\Policies\{1B61F884-9D14-4065-8265-F04FFDE41683}\Machine\Scripts\Shutdown\ClearPrintQueue.bat"
net stop spooler
del %systemroot%\System32\spool\printers\* /Q /F /S
PS C:\>

Bei der Untersuchung eines lokalen PCs kann ich feststellen, dass das Skript tatsächlich in den lokalen Gruppenrichtlinienobjektspeicher des PCs kopiert wurde:

PS C:\> Get-ChildItem -Recurse -Force -File "C:\Windows\System32\GroupPolicy\DataStore\0\SysVol\example.com\Policies\{1B61F884-9D14-4065-8265-F04FFDE41683}"  


    Directory: C:\Windows\System32\GroupPolicy\DataStore\0\SysVol\example.com\Policies\{1B61F884-9D14-4065-8265-F04FFDE41683}                            


Mode                LastWriteTime         Length Name                           
----                -------------         ------ ----                           
-a----       2019-04-23     15:00             59 gpt.ini                        


    Directory: C:\Windows\System32\GroupPolicy\DataStore\0\SysVol\example.com\Policies\{1B61F884-9D14-4065-8265-F04FFDE41683}\Machine\Scripts            


Mode                LastWriteTime         Length Name                           
----                -------------         ------ ----                           
-a-h--       2019-04-23     15:00            118 scripts.ini                    


    Directory: C:\Windows\System32\GroupPolicy\DataStore\0\SysVol\example.com\Policies\{1B61F884-9D14-4065-8265-F04FFDE41683}\Machine\Scripts\Shutdown   


Mode                LastWriteTime         Length Name                           
----                -------------         ------ ----                           
-a----       2019-04-23     15:00             71 ClearPrintQueue.bat            


PS C:\>

Nachforschungen in scripts.iniund ClearPrintQueue.batauf der lokalen Festplatte des PCs finden wir:

PS C:\> Get-Content "C:\Windows\System32\GroupPolicy\DataStore\0\SysVol\example.com\Policies\{1B61F884-9D14-4065-8265-F04FFDE41683}\Machine\Scripts\scripts.ini"                                                                              

[Shutdown]                                                                      
0CmdLine=ClearPrintQueue.bat                                                    
0Parameters=                                                                    
PS C:\> Get-Content "C:\Windows\System32\GroupPolicy\DataStore\0\SysVol\example.com\Policies\{1B61F884-9D14-4065-8265-F04FFDE41683}\Machine\Scripts\Shutdown\ClearPrintQueue.bat"                                                             
net stop spooler                                                                
del %systemroot%\System32\spool\printers\* /Q /F /S                             
PS C:\>

Das heißt, der Computer verfügt über alles, was zum tatsächlichen Ausführen des Herunterfahrskripts erforderlich ist, ohne das Netzwerk zu erreichen. Ich habe jedoch festgestellt, dass das Skript nicht ausgeführt wird, wenn eine Netzwerkverbindung fehlt.

Weitere Untersuchungen mit einer Paketerfassung und WireShark scheinen weiterhin zu beweisen, dass der PC das Skript tatsächlich von der SYSVOL-Freigabe herunterzieht (warum! Es befindet sich genau dort auf der Festplatte ...). Die Zeitstempel entsprechen dem Zeitpunkt, zu dem der Computer heruntergefahren wurde .

Wireshark-Paketerfassung zeigt, wie das Skript beim Herunterfahren von der Festplatte heruntergezogen wird

Mögliche Problemumgehung:

Eine mögliche Problemumgehung, die ich noch nicht getestet habe, besteht darin, den absoluten Pfad des Skripts manuell anzugeben, C:\Windows\System32\GroupPolicy\DataStore\0\SysVol\example.com\Policies\{1B61F884-9D14-4065-8265-F04FFDE41683}\Machine\Scripts\Shutdown\ClearPrintQueue.batanstatt nur ClearPrintQueue.bateinen relativen Pfad anzugeben . Dies scheint jedoch sehr hackig zu sein und scheint nicht so zu sein, wie es "gemeint" ist, um zu funktionieren. Bevor ich diesen Weg gehe, würde ich gerne sehen, ob jemand eine bessere Idee hat.

Warum ich das überhaupt versuche:

Ich habe mobile Benutzer, die versehentlich auf dem falschen Drucker drucken möchten. Diese werden dann lokal auf jeder Workstation in die Warteschlange gestellt. Wenn der PC an den Standort angeschlossen wird, an dem sich dieser Drucker befindet, kommt eine Flut von Papier aus dem Drucker. Die VPN-Software wird auf der "Benutzer" -Ebene ausgeführt, und daher wird die VPN-Software möglicherweise nicht ausgeführt, wenn sie heruntergefahren werden muss.

Ich versuche, dies zu verringern, indem ich die Druckwarteschlange beim Herunterfahren lösche, damit alte Druckaufträge nicht für immer in der Warteschlange stehen.


Was ist, wenn Sie dieses Skript zu den lokalen Richtlinien hinzufügen ? ZB start -> run -> gpedit.msc?
Lenniey

@Lenniey Vielen Dank, aber die Verwendung lokaler Richtlinien ist in meiner Umgebung nicht praktikabel. Ich habe ungefähr 35 Computer, auf denen ich diese ausführen kann.
Per von Zweigbergk

Antworten:


9

Es ist beabsichtigt. Microsoft hat nie gesagt, dass die Start- / Herunterfahrskripts ausgeführt werden, wenn der Computer offline ist.

Der gefundene lokale Cache ist nicht für die Offline-Verarbeitung vorgesehen, sondern um zu vermeiden, dass die Clients die Domänencontroller überfordern. Weitere Details zu diesem bestimmten Punkt finden Sie hier: Gruppenrichtlinien-Kernprotokoll: Cache der Gruppenrichtlinienobjektversion

Darüber hinaus erfordert die Gruppenrichtlinien-Skripterweiterung , dass der Client die Quelle des Skripts überprüfen kann. Wie Sie in der folgenden Abbildung sehen können, ist der GP-Server (Domänencontroller) der Kern der Erweiterung für Gruppenrichtlinienskripte:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-gpscr/ms-gpscr_files/image001.png

Um Ihr Problem zu lösen, empfehle ich Ihnen, dies stattdessen zu versuchen:

Erstellen Sie eine geplante Aufgabe über die Gruppenrichtlinieneinstellungen ( Computer Configuration -> Preferences -> Control Panel -> Scheduled Tasks) und erstellen Sie eine New Scheduled Task (at Least Windows 7), konfigurieren Sie die auszuführende Aufgabe Systemund fügen Sie den folgenden Auslöser hinzu : On disconnect from user session.

Erstellen Sie dann eine weitere Voreinstellung ("Datei" anstelle von "Geplante Aufgabe"), um Ihr Skript in einen gesicherten lokalen Pfad auf den Computern zu kopieren (die Benutzer dürfen nicht in diese Datei schreiben können, um eine Eskalation von Berechtigungen zu vermeiden). Sie können die Datei auch mit etwas anderem kopieren, wenn Sie möchten. Vergessen Sie jedoch nicht, in der Voreinstellung für geplante Aufgaben darauf zu verweisen.


3
Es muss keine geplante Aufgabe sein. Sie können weiterhin ein Shutdown-Skript verwenden. Das Skript muss sich nur auf der lokalen Festplatte befinden und nicht im Gruppenrichtlinienobjekt.
Harry Johnston

2
Vielen Dank für die Links, sie erklären in der Tat, warum Gruppenrichtlinien das tun, was sie tun. Nach meinem Verständnis gibt es keinen guten Grund, ein Skript in einen Gruppenrichtlinienobjektordner zu legen. Wenn Sie es nach draußen stellen, wird es nicht mehr unnötig auf jede Workstation kopiert, und wenn Sie es nach innen stellen, hat dies keine Vorteile. Am Ende habe ich eine "Datei" im Gruppenrichtlinienobjekt verwendet, um das Skript explizit von einer Netzwerkfreigabe auf den Computer zu kopieren und es dann über einen absoluten Dateipfad auszuführen. Ich habe keine geplante Aufgabe verwendet. Danke auch für den Tipp zur Sicherheit.
Per von Zweigbergk
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.