Scheduled Task führt Script nicht aus
Hallo Zusammen
Ich habe ein kleines Script geschrieben, mit dem ich ein Programm installieren möchte:
Das Script kann ich ausführen und funktioniert ohne Probleme. Das Script ist dafür da, den Antivirus-Client nach dem Aufsetzen eines Systems über SCCM zu installieren, deswegen möchte ich es nicht als Startup- sondern als Loginscript ausführen, dafür benötige ich ein Scheduled Task:
Doch leider wird das Script nicht ausgeführt, sondern mit folgendem Fehler abgebrochen:
Folgende Schritte habe ich bereits versucht:
1.Als User "NT AUTHORIZATION\SYSTEM" Ausgeführt
2.Als User "BUILTIN\SYSTEM" Ausgeführt
3.Als User "BUILTIN\Administrator" Ausgeführt
4. Als User ".\Administrator" Ausgeführt
5. Die XML-Datei angepasst und <LogonType>InteractiveToken</LogonType> entfernt
6. Den Computer des Testclients aus der AD entfernt
7. Im Schedule "Nur einmal anwenden" angewählt
8. "Unabhängig von der Benutzeranmeldung ausführen" angewählt
Doch leider immer mit dem gleichen Ergebnis.
Wisst Ihr, was ich noch ändern könnte?
Besten Dank für eure Auskunft.
Ich habe ein kleines Script geschrieben, mit dem ich ein Programm installieren möchte:
IF EXIST "C:\Program Files (x86)\G Data\AVKClient\GdAgentUi.exe" (exit /b) ELSE (\\INF-DC-01\Austausch\Informatik\Software\GData\GDInstall.exe /@_QuietInstallation="true" /@SelectedLanguage="DE" /@HostName="RAUSE02" /@GroupName="RAUSE02")
Das Script kann ich ausführen und funktioniert ohne Probleme. Das Script ist dafür da, den Antivirus-Client nach dem Aufsetzen eines Systems über SCCM zu installieren, deswegen möchte ich es nicht als Startup- sondern als Loginscript ausführen, dafür benötige ich ein Scheduled Task:
Doch leider wird das Script nicht ausgeführt, sondern mit folgendem Fehler abgebrochen:
Folgende Schritte habe ich bereits versucht:
1.Als User "NT AUTHORIZATION\SYSTEM" Ausgeführt
2.Als User "BUILTIN\SYSTEM" Ausgeführt
3.Als User "BUILTIN\Administrator" Ausgeführt
4. Als User ".\Administrator" Ausgeführt
5. Die XML-Datei angepasst und <LogonType>InteractiveToken</LogonType> entfernt
6. Den Computer des Testclients aus der AD entfernt
7. Im Schedule "Nur einmal anwenden" angewählt
8. "Unabhängig von der Benutzeranmeldung ausführen" angewählt
Doch leider immer mit dem gleichen Ergebnis.
Wisst Ihr, was ich noch ändern könnte?
Besten Dank für eure Auskunft.
Please also mark the comments that contributed to the solution of the article
Content-ID: 394658
Url: https://administrator.de/contentid/394658
Printed on: October 5, 2024 at 02:10 o'clock
19 Comments
Latest comment
Zitat von @Hubert.N:
Vorsicht Falle: Auch mit System wirst Du ein Problem haben. Da magst Du zwar lokal alle Rechte der Welt haben - aber eben nur lokal. Auf einer anderen Maschine machst du mit dem lokalen (!) Systemaccount nichts.
Es sei denn, man hat ein AD und berechtigt das entsprechende Computer-Konto.Vorsicht Falle: Auch mit System wirst Du ein Problem haben. Da magst Du zwar lokal alle Rechte der Welt haben - aber eben nur lokal. Auf einer anderen Maschine machst du mit dem lokalen (!) Systemaccount nichts.
Zitat von @gabeBU:^^
Emeriks hat noch davon gesprochen, dass ich in der AD dem lokalen Konto noch Administrator-Rechte geben könnte.
Nein, davon hat er nicht gesprochen.
Lass Dich nicht ablenken.
@gabeBU wollte nur anmerken, dass ein Prozess, welcher unter Local System läuft, nicht auf andere Computer (deren Freigaben) zugreifen könne.
Ich habe angemerkt, dass das doch geht, wenn beide in einem AD sind. Dann kann man dem Konto von Computer A in einer Freigabe und im NTFS eines Computer B Rechte erteilen.
Du hast das Problem, dass Du einen Prozess beim Login starten willst, der unter einem anderen Konto läuft. Das kann man per Scheduled Task machen, aber nicht interaktiv.
Warum lässt Du das nicht einfach unbeaufsichtigt laufen? Dann kannst Du es auch als Startup-Script einstellen. Ich denke, das ist Dein eigentliches Problem.
@gabeBU wollte nur anmerken, dass ein Prozess, welcher unter Local System läuft, nicht auf andere Computer (deren Freigaben) zugreifen könne.
Ich habe angemerkt, dass das doch geht, wenn beide in einem AD sind. Dann kann man dem Konto von Computer A in einer Freigabe und im NTFS eines Computer B Rechte erteilen.
Du hast das Problem, dass Du einen Prozess beim Login starten willst, der unter einem anderen Konto läuft. Das kann man per Scheduled Task machen, aber nicht interaktiv.
Warum lässt Du das nicht einfach unbeaufsichtigt laufen? Dann kannst Du es auch als Startup-Script einstellen. Ich denke, das ist Dein eigentliches Problem.
Wie schon gesagt wurde...
Sowohl bei Freigabe- und NTFS-Rechten das/die ComputerKonten/(oder auch Gruppen) mit Leserechten hinzufügen dann kann auch das Skript das mit Systemrechten läuft auf den UNC-Pfad zugreifen.
Sowohl bei Freigabe- und NTFS-Rechten das/die ComputerKonten/(oder auch Gruppen) mit Leserechten hinzufügen dann kann auch das Skript das mit Systemrechten läuft auf den UNC-Pfad zugreifen.
Zitat von @gabeBU:
Ich möchte kein Startup-Script erstellen, weil ich die Befürchtung habe, dass es beim aufsetzen von Geräten per SCCM Probleme bereiten könnte.
Inwiefern?Ich möchte kein Startup-Script erstellen, weil ich die Befürchtung habe, dass es beim aufsetzen von Geräten per SCCM Probleme bereiten könnte.
Zitat von @gabeBU:
Ich könnte mir vorstellen, dass es ausgeführt wird, während das Betriebssystem noch am aufsetzen ist.
So lange das Ding nicht in die Domain gejoint ist passiert da gar nichts und eine Abfrage ob fertig oder nicht lässt sich ja im Skript leicht realisieren. Aber wozu man das nicht direkt über sein Software-Deployment erledigen lässt, stellt sich mir hier primär die Frage!Ich könnte mir vorstellen, dass es ausgeführt wird, während das Betriebssystem noch am aufsetzen ist.
Zitat von @gabeBU:
Ich könnte mir vorstellen, dass es ausgeführt wird, während das Betriebssystem noch am aufsetzen ist.
Einfach mal nachdenken.Ich könnte mir vorstellen, dass es ausgeführt wird, während das Betriebssystem noch am aufsetzen ist.
GPO's werden frühestens angewendet, wenn der Computer der Domäne beigetreten ist.
Man könnte diese GPO z.B. an eine bestimmte OU hängen und der Computer müsste nach der Installation erst in diese OU verschoben werden.
Oder man filtert die GPO über eine Gruppe und der Computer muss nach der Installation erst dieser Gruppe hinzugefügt werden.
Oder oder oder ....
Edit:
Oder man filtert die GPO über einen WMI-Filter und der Computer entspricht diesem Filter erst, wenn die Installation einen bestimmten Punkt erreicht hat.