19
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.
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: 394658
Url: https://administrator.de/contentid/394658
Ausgedruckt am: 22.11.2024 um 13:11 Uhr
19 Kommentare
Neuester Kommentar
Hi,
da Du offensichtlich ein deutsches Windows hast, wäre NT-AUTORITÄT\SYSTEM korrekt. Aber das kannst Du einfacher haben, indem Du einfach über den Button "Benutzer oder Gruppe ..." gehst und dort "SYSTEM" eingibst, den Namen auflösen lässt und bestätigen.
E.
da Du offensichtlich ein deutsches Windows hast, wäre NT-AUTORITÄT\SYSTEM korrekt. Aber das kannst Du einfacher haben, indem Du einfach über den Button "Benutzer oder Gruppe ..." gehst und dort "SYSTEM" eingibst, den Namen auflösen lässt und bestätigen.
E.
- sondern als Loginscript ausführen, dafür benötige ich ein Scheduled Task:
Warum nicht ein "echtes" Loginscipt?
Moin 
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.
Gruß
Hubert
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.
Gruß
Hubert
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.
Hallo Emeriks
Ja, ich habe es auch direkt über die Suche eingegben. Ich habe es nur auf Englisch geschrieben, damit man weiss, was ich meine. Die Ausdrücke wurden aber in deutsch gespeichert.
Weil ich Administrator-Rechte benötige, um das Programm zu installieren. Soweit ich es recherchiert habe gibt es keine Möglichkeit, ein Login-Script direkt als Administrator auszuführen wenn man keine Administrator-Rechte hat, aber falls es möglich ist, würde ich es tun.
Ja, ich habe es auch direkt über die Suche eingegben. Ich habe es nur auf Englisch geschrieben, damit man weiss, was ich meine. Die Ausdrücke wurden aber in deutsch gespeichert.
Weil ich Administrator-Rechte benötige, um das Programm zu installieren. Soweit ich es recherchiert habe gibt es keine Möglichkeit, ein Login-Script direkt als Administrator auszuführen wenn man keine Administrator-Rechte hat, aber falls es möglich ist, würde ich es tun.
Hi,
Das hier sagt uns was?
No mapping between account names and security IDs was done -> 0x80070534
Was sagt der Hersteller des Produktes was Du installieren willst dazu?
BFF
Das hier sagt uns was?
No mapping between account names and security IDs was done -> 0x80070534
Was sagt der Hersteller des Produktes was Du installieren willst dazu?
BFF
Ich habe den Hersteller kontaktiert und sie teilten mir mit, dass Sie von der Fehlermeldung noch nie was gehört hätten und dass es ein Rechteproblem sein müsste.
Emeriks hat noch davon gesprochen, dass ich in der AD dem lokalen Konto noch Administrator-Rechte geben könnte. Wie wäre das möglich?
Bzw. habe ich nun auch dem Benutzer, mit dem ich teste lokale-Administratorrechte geben, aber das hat das Problem immernoch nicht gelöst.
Emeriks hat noch davon gesprochen, dass ich in der AD dem lokalen Konto noch Administrator-Rechte geben könnte. Wie wäre das möglich?
Bzw. habe ich nun auch dem Benutzer, mit dem ich teste lokale-Administratorrechte geben, aber das hat das Problem immernoch nicht gelöst.
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.
Okay, von was hast du denn gesprochen?
Okay, aber du hast doch gesagt
Wie genau könnte ich denn da die rechte Setzen?
Wie genau könnte ich denn da die rechte Setzen?
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.
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.
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.
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.
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.
Zitat von @137846:
Aber wozu man das nicht direkt über sein Software-Deployment erledigen lässt, stellt sich mir hier primär die Frage!
Ja, diese Frage habe ich mir auch schon gestellt ...Aber wozu man das nicht direkt über sein Software-Deployment erledigen lässt, stellt sich mir hier primär die Frage!
