14
Aufgabenplanung führt PowerShell Script nicht aus
Moin Zusammen,
ich habe einen PowerShell Script, dieses liegt unter: "C:\Scripts\OutlookNoCachedMode.ps1"
Das Script funktioniert so wie es soll, bloß wenn die Aufgabenplanung das Script ausführt passiert nichts mit den Registry Keys. Trotzdem Ist die die Aufgabenplanung der Meinung, dass sie Aufgabe / Aktion abgeschlossen hat.
Ich habe schon Folgendes ausprobiert.
-Den absoluten PowerShell Pfad angegeben (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe)
-Die Argumente -command C:\Scripts\OutlookNoCachedMode.ps1 und -file C:\Scripts\OutlookNoCachedMode.ps1 , sowohl mit als auch ohne Anführungszeichen
-Starten in C:\Scripts und Starten in C:\Windows\System32\WindowsPowerShell\v1.0 und Feld leer
-Eine .bat Datei die das Script aufruft (Hat so Funktioniert)
-Eine .cmd Datei die das Script aufruft. (Hat so Funktioniert)
-Ausführen als Lokaler Admin, Domänen Admin, und SYSTEM User
Screenshots von der Aufgabe habe ich Beigefügt.
Da ich am Ende von meinem IT-Latein angelangt bin, dachte ich mir, ich frage mal hier nach.
Grüße
~Leon
ich habe einen PowerShell Script, dieses liegt unter: "C:\Scripts\OutlookNoCachedMode.ps1"
Das Script funktioniert so wie es soll, bloß wenn die Aufgabenplanung das Script ausführt passiert nichts mit den Registry Keys. Trotzdem Ist die die Aufgabenplanung der Meinung, dass sie Aufgabe / Aktion abgeschlossen hat.
Ich habe schon Folgendes ausprobiert.
-Den absoluten PowerShell Pfad angegeben (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe)
-Die Argumente -command C:\Scripts\OutlookNoCachedMode.ps1 und -file C:\Scripts\OutlookNoCachedMode.ps1 , sowohl mit als auch ohne Anführungszeichen
-Starten in C:\Scripts und Starten in C:\Windows\System32\WindowsPowerShell\v1.0 und Feld leer
-Eine .bat Datei die das Script aufruft (Hat so Funktioniert)
-Eine .cmd Datei die das Script aufruft. (Hat so Funktioniert)
-Ausführen als Lokaler Admin, Domänen Admin, und SYSTEM User
Screenshots von der Aufgabe habe ich Beigefügt.
Da ich am Ende von meinem IT-Latein angelangt bin, dachte ich mir, ich frage mal hier nach.
Grüße
~Leon
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: 7653162511
Url: https://administrator.de/forum/aufgabenplanung-fuehrt-powershell-script-nicht-aus-7653162511.html
Ausgedruckt am: 22.12.2024 um 10:12 Uhr
14 Kommentare
Neuester Kommentar
Moin.
Täglich grüßt das Murmeltier. Wie immer bei sowas:
Start-Transcript ins Skript einbauen und die Ausgaben des Scripts loggen lassen, dann musst du nicht raten was im Skript schief läuft wenn es über den Tasskplaner läuft!
ExecutionPolicy beachten! In der Aufgabenplanung deshalb immer mit dem Parameter
Zeppel
Täglich grüßt das Murmeltier. Wie immer bei sowas:
Start-Transcript ins Skript einbauen und die Ausgaben des Scripts loggen lassen, dann musst du nicht raten was im Skript schief läuft wenn es über den Tasskplaner läuft!
ExecutionPolicy beachten! In der Aufgabenplanung deshalb immer mit dem Parameter
-EP Bypass arbeiten.Programm:
Argumente:
powershellArgumente:
-EP Bypass -File "C:\script.ps1"Zeppel
2
Ich hatte auch mal so einen Spezialfall,
gelöst hatte ich es indem ich einen Batch (*.bat) per Aufgabenplanung startete, welcher die Powershell (*.ps1) ausführte, lief dann tadellos.
Batch erstellen
gelöst hatte ich es indem ich einen Batch (*.bat) per Aufgabenplanung startete, welcher die Powershell (*.ps1) ausführte, lief dann tadellos.
Batch erstellen
powershell.exe "C:\pfad_eingeben\Scriptname.ps1" 
Moin
mich irritiert die grundsätzliche Herangehensweise. Den Cache schaltet man ganz einfach mit einer Gruppenrichtlinie ab.
Gruß
mich irritiert die grundsätzliche Herangehensweise. Den Cache schaltet man ganz einfach mit einer Gruppenrichtlinie ab.
Gruß
Zitat von @7426148943:
Moin.
Täglich grüßt das Murmeltier. Wie immer bei sowas:
Start-Transcript ins Skript einbauen und die Ausgaben des Scripts loggen lassen, dann musst du nicht raten was im Skript schief läuft wenn es über den Tasskplaner läuft!
ExecutionPolicy beachten! In der Aufgabenplanung deshalb immer mit dem Parameter
Zeppel
Moin.
Täglich grüßt das Murmeltier. Wie immer bei sowas:
Start-Transcript ins Skript einbauen und die Ausgaben des Scripts loggen lassen, dann musst du nicht raten was im Skript schief läuft wenn es über den Tasskplaner läuft!
ExecutionPolicy beachten! In der Aufgabenplanung deshalb immer mit dem Parameter
-EP Bypass arbeiten.Programm:
Argumente:
powershellArgumente:
-EP Bypass -File "C:\script.ps1"Zeppel
Das hat mich schonmal weitergebracht er schmeißt nämlich folgende Meldung für beide Keys die er Ändern soll.
"New-ItemProperty : Der Pfad "HKCU:\SOFTWARE\Policies\Microsoft\office\15.0\outlook\cached mode" kann nicht gefunden werden, da er nicht vorhanden ist."
Uund.
"New-ItemProperty : Der Pfad "HKCU:\SOFTWARE\Policies\Microsoft\office\15.0\outlook\cached mode" kann nicht gefunden werden, da er nicht vorhanden ist."
Und
Zitat von @Hubert.N:
Moin
mich irritiert die grundsätzliche Herangehensweise. Den Cache schaltet man ganz einfach mit einer Gruppenrichtlinie ab.
Gruß
Moin
mich irritiert die grundsätzliche Herangehensweise. Den Cache schaltet man ganz einfach mit einer Gruppenrichtlinie ab.
Gruß
Geht das denn, das die GPO nur auf dem Terminalserver in Kraft tritt?
Auf den eigenen Fat Clients der User sollte Outlook sich weiterhin idealerweise die Mails ziehen.
Vielen Dank schonmal für die ersten Ideen.
~Leon
Ja klar. Loopback-Mode in der OU der Terminalserver oder wmi filter sind deine Freunde.
https://www.gruppenrichtlinien.de/artikel/loopbackverarbeitungsmodus-loo ...
Da aber der GPO Vorschlag dafür sowieso besser ist mach es direkt per GPO und lass den Schwachfug mit dem Skript für so eine Lapalie.
https://www.gruppenrichtlinien.de/artikel/loopbackverarbeitungsmodus-loo ...
New-ItemProperty : Der Pfad "HKCU:\SOFTWARE\Policies\Microsoft\office\15.0\outlook\cached mode" kann nicht gefunden werden, da er nicht vorhanden ist."
Das würde auch nur klappen wenn der Task als der User ausgeführt wird der sich anmeldet. Des weiteren müsstest du den Key erst mal anlegen bevor du ihn änderst oder da was rein schreibst 😉.Da aber der GPO Vorschlag dafür sowieso besser ist mach es direkt per GPO und lass den Schwachfug mit dem Skript für so eine Lapalie.
1Zitat von @Klocki:
Geht das denn, das die GPO nur auf dem Terminalserver in Kraft tritt?
Auf den eigenen Fat Clients der User sollte Outlook sich weiterhin idealerweise die Mails ziehen.
Geht das denn, das die GPO nur auf dem Terminalserver in Kraft tritt?
Auf den eigenen Fat Clients der User sollte Outlook sich weiterhin idealerweise die Mails ziehen.
Ja sicher geht das. Du aktivierst für den Terminalserver in der Computerrichtlinie die Loopbackverarbeitung und kannst dann die entsprechende Benutzerrichtlinie festlegen, die dann auch nur auf dem Terminalserver angewendet wird. Das ist Standard, wenn man einen RDP-Server in Betrieb nimmt.
Dass sich der Terminalserver in einer eigenen OU befindet, ist wohl obligatorisch. Aber selbst wenn nicht, ließe sich das auch noch über Sicherheitszuordnungen regeln.
Gruß
1
Natürlich sind diese Keys beim Systemuser nicht vorhanden.
Im Screenshot steht <Folgendes Benutzerkonto verwenden: System>, also wird es im Systemkontext ausgeführt.
Um es im User Kontext laufen zu lassen, muß man eine Gruppe eintragen, die die entsprechenden User beinhaltet, z.B. die lokale Gruppe der User.
Aber die anderen haben auch recht, sinnvoller wäre eine Gruppenrichtlinie dafür.
Im Screenshot steht <Folgendes Benutzerkonto verwenden: System>, also wird es im Systemkontext ausgeführt.
Um es im User Kontext laufen zu lassen, muß man eine Gruppe eintragen, die die entsprechenden User beinhaltet, z.B. die lokale Gruppe der User.
Aber die anderen haben auch recht, sinnvoller wäre eine Gruppenrichtlinie dafür.
Eine Rückmeldung Richtung Feierabend.
Ich habe die Loopback Verarbeitung auf dem Terminalserver aktiviert und ein gpupdate /force durchgeführt.
Dann habe ich mit den Microsoft Office GPO Vorlagen Hier die Vorlagen eine GPO erstellt und unter der Delegierung den Computer Hinzugefügt.
Und es scheint zu funktionieren, es taucht keine .ost Datei in Appdata auf.
Ich habe Screenshots der GPO mal angehängt, falls irgendwem da noch ein Fehler auffällt, gerne anmerken
Vielen Dank für die große und vor allem schnelle Hilfe.
Ihr rettet mir echt damit den Hintern in meiner Ausbildung.
Grüße und einen Schönen Feierabend
~Leon
Ich habe die Loopback Verarbeitung auf dem Terminalserver aktiviert und ein gpupdate /force durchgeführt.
Dann habe ich mit den Microsoft Office GPO Vorlagen Hier die Vorlagen eine GPO erstellt und unter der Delegierung den Computer Hinzugefügt.
Und es scheint zu funktionieren, es taucht keine .ost Datei in Appdata auf.
Ich habe Screenshots der GPO mal angehängt, falls irgendwem da noch ein Fehler auffällt, gerne anmerken
Vielen Dank für die große und vor allem schnelle Hilfe.
Ihr rettet mir echt damit den Hintern in meiner Ausbildung.
Grüße und einen Schönen Feierabend
~Leon
Das ist schön 
Ich bin allerdings ein wenig verwirrt, denn damit eine GPO durch Benutzer verarbeitet werden kann, müssen diese die Richtlinie eigentlich auch lesen können.
Gruß
Ich bin allerdings ein wenig verwirrt, denn damit eine GPO durch Benutzer verarbeitet werden kann, müssen diese die Richtlinie eigentlich auch lesen können.
Gruß
1Zitat von @Hubert.N:
Das ist schön
Ich bin allerdings ein wenig verwirrt, denn damit eine GPO durch Benutzer verarbeitet werden kann, müssen diese die Richtlinie eigentlich auch lesen können.
Gruß
Das ist schön
Ich bin allerdings ein wenig verwirrt, denn damit eine GPO durch Benutzer verarbeitet werden kann, müssen diese die Richtlinie eigentlich auch lesen können.
Gruß
Stimmt. Ich hatte gestern einen sehr groben Denkfehler gemacht, weil mein Kopf zum Schluss nur noch Matsche war.
Ich hatte den Loopbackmodus nämlich nicht ganz verstanden. Ich hatte gedacht (wieso auch immer), dass die Computerrichtlinien die Benutzerrichtlinien überschreiben, aber das ist ja nicht der Fall. Sondern die lokalen Richtlinien vom Terminal (Win+R gpedit.msc) überschreiben die Domain-Richtlinien. Nachdem Heute beim erneuten ruhigen Rangehen der Geistesblitz kam, habe ich die Vorlage von oben auf dem Terminal eingefügt, alles Lokal eingestellt, eben die Altlasten auf dem Domain-Controller entfernt und dann hat es auch funktioniert.
Wie gesagt noch einmal vielen Dank für eure Hilfe, ich finde es sehr nett, dass erfahrenere Leute in solchen Foren wie diesem ihre Erfahrung auch gerne teilen.
Speziellen dank gehen an @Hubert.N und @7426148943 ihr wart eine riesen Hilfe.
Grüße
~Leon
Danke
Noch mal ein Hinweis:
Das stimmt so nicht. Domänenrichtlinien überschreiben die lokalen Richtlinien. Nur so macht das ja auch Sinn. Sonst könnte ja irgendwer mit lokalen Adminrechten die Domainpolicys außer Kraft setzen.
Noch mal ein Hinweis:
Zitat von @Klocki:
Sondern die lokalen Richtlinien vom Terminal (Win+R gpedit.msc) überschreiben die Domain-Richtlinien.
Sondern die lokalen Richtlinien vom Terminal (Win+R gpedit.msc) überschreiben die Domain-Richtlinien.
Das stimmt so nicht. Domänenrichtlinien überschreiben die lokalen Richtlinien. Nur so macht das ja auch Sinn. Sonst könnte ja irgendwer mit lokalen Adminrechten die Domainpolicys außer Kraft setzen.
Zitat von @Hubert.N:
Danke
Noch mal ein Hinweis:
Das stimmt so nicht. Domänenrichtlinien überschreiben die lokalen Richtlinien. Nur so macht das ja auch Sinn. Sonst könnte ja irgendwer mit lokalen Adminrechten die Domainpolicys außer Kraft setzen.
Danke
Noch mal ein Hinweis:
Zitat von @Klocki:
Sondern die lokalen Richtlinien vom Terminal (Win+R gpedit.msc) überschreiben die Domain-Richtlinien.
Sondern die lokalen Richtlinien vom Terminal (Win+R gpedit.msc) überschreiben die Domain-Richtlinien.
Das stimmt so nicht. Domänenrichtlinien überschreiben die lokalen Richtlinien. Nur so macht das ja auch Sinn. Sonst könnte ja irgendwer mit lokalen Adminrechten die Domainpolicys außer Kraft setzen.
Aber im Loopbackmodus doch nicht oder?
Bei der Beschreibung der Richtlinie steht ja:
"'Ersetzen'" gibt an, dass die in den Gruppenrichtlinienobjekten für diesen Computer festgelegten Benutzereinstellungen die Benutzereinstellungen ersetzen, die normalerweise auf den Benutzer angewendet werden."
und
"'Zusammenführen' gibt an, dass die in den Gruppenrichtlinienobjekten für diesen Computer festgelegten Benutzereinstellungen und die normalerweise angewendeten Benutzereinstellungen kombiniert werden. Falls die Einstellungen in Konflikt stehen, setzen die Benutzereinstellungen in den Gruppenrichtlinien des Computers die normalen Einstellungen des Benutzers außer Kraft."
Am ende des Tages funktioniert jetzt alles, das ist alles was Zählt.
Moin,
Gruß,
Dani
Bei der Beschreibung der Richtlinie steht ja:
da es im Kontext eines Active Directorys ausgeführt wird, bezieht sich dies auch nur auf dessen Gruppenrichtlinien.Am ende des Tages funktioniert jetzt alles, das ist alles was Zählt.
Am Ende des Tages sollte man verstehen, was man getan und weshalb man das getan hat. Anderenfalls kann bei der nächsten Änderung an den Gruppenrichtlinien zur Seiteneffekten kommen, die man nicht vorhergesehen hat und damit auch nicht versteht.Gruß,
Dani
Nicht ganz. Ohne jetzt zu sehr ins Detail gehen zu wollen:
- in Domänenrichtlinien gesetzte Einstellungen überschreiben entsprechenden Einstellungen in den lokalen Richtlinien.
- innerhalb der Domäne werden die Richtlinien von oben nach unten durch die OUs verarbeitet
- bei mehreren Richtlinien auf einer OU hat die die in der Verarbeitungsreihenfolge an Stelle 1 höchste Priorität ("Eins gewinnt...")
Bei der Loopbackverarbeitung ist der Unterschied zwischen "Ersetzen" und "Zusammenführen", dass im Fall von "Ersetzen" die sonst für den Benutzer gesetzten Richtlinien nicht mehr verarbeitet werden. Beim "Zusammenführen" werden diese Richtlinien nach wie vor angewendet. Danach werden aber noch einmal die beim Computerobjekt gesetzten Benutzerrichtlinien angewendet (und überschreiben dann ggf. andere sonst gesetzte Benutzerrichtlinien)
Ja... Das ist wohl wahr
Gruß
- in Domänenrichtlinien gesetzte Einstellungen überschreiben entsprechenden Einstellungen in den lokalen Richtlinien.
- innerhalb der Domäne werden die Richtlinien von oben nach unten durch die OUs verarbeitet
- bei mehreren Richtlinien auf einer OU hat die die in der Verarbeitungsreihenfolge an Stelle 1 höchste Priorität ("Eins gewinnt...")
Bei der Loopbackverarbeitung ist der Unterschied zwischen "Ersetzen" und "Zusammenführen", dass im Fall von "Ersetzen" die sonst für den Benutzer gesetzten Richtlinien nicht mehr verarbeitet werden. Beim "Zusammenführen" werden diese Richtlinien nach wie vor angewendet. Danach werden aber noch einmal die beim Computerobjekt gesetzten Benutzerrichtlinien angewendet (und überschreiben dann ggf. andere sonst gesetzte Benutzerrichtlinien)
Am ende des Tages funktioniert jetzt alles, das ist alles was Zählt.
Ja... Das ist wohl wahr
Gruß
