Jun 26, 2023, updated at 11:08:19 (UTC)

2301

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

Please also mark the comments that contributed to the solution of the article

Content-Key: 7653162511

Url: https://administrator.de/contentid/7653162511

Printed on: April 27, 2024 at 09:04 o'clock

14 Comments

Latest comment

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: powershell
Argumente: -EP Bypass -File "C:\script.ps1"

Zeppel

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

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ß

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
-EP Bypass arbeiten.

Programm: powershell
Argumente: -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ß

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

Zitat von @Klocki:
Geht das denn, das die GPO nur auf dem Terminalserver in Kraft tritt?

Ja klar. Loopback-Mode in der OU der Terminalserver oder wmi filter sind deine Freunde.
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.

Zitat 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.

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ß

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.

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

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ß

Zitat 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ß

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:

Zitat von @Klocki:
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:

Zitat von @Klocki:
Sondern die lokalen Richtlinien vom Terminal (Win+R gpedit.msc) überschreiben die Domain-Richtlinien.

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,

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)

Am ende des Tages funktioniert jetzt alles, das ist alles was Zählt.

Ja... Das ist wohl wahr

Gruß

German solved Question Windows Server Windows Tools