(Ein anderes) Problem beim rekursiven PowerShell-Ordner zum Kopieren / Einfügen. PowerShell App Deployment Toolkit und SCCM

589
user001

fühle mich, als würde ich lachen / weinen, weil ich weiß, dass ich etwas Dummes / offensichtlich Unrichtiges mache.

Ich verwende SCCM und PSADT, um das Folgende zu versuchen. Es funktioniert einwandfrei, wenn ich UNC im Zielordner ausführen und das Skript ausführen würde. Das Folgende geschieht jedoch, wenn es in SCCM bereitgestellt wird

Ich habe jede Variation des Unteren ausprobiert, die mir einfällt. Ich versuche, ein Verzeichnis von einer vernetzten VM auf einen lokalen Client zu verschieben, aber ich kann anscheinend nur das leere Verzeichnis selbst kopieren

Beispiele für das, was ich versucht habe, sind

If (!(Test-Path("C:\Target\"))) { New-Item -ItemType directory -Path "C:\Target" Copy-Item -Path "$dirFiles\Target\*" -Destination "C:\Target\" -Recurse -Force -Verbose }

UND

 If (!(Test-Path("C:\Target\"))) {  Copy-Item -Path "$dirFiles\Target" -Destination "C:\" -Recurse -Force -Verbose }

Und alles dazwischen fällt mir ein. Jedes Mal bekomme ich einfach den leeren Ordner erstellt, aber keinen Inhalt

0
Ich habe das Ziel um "$ dirTarget" erhöht und es hat funktioniert. Kann SCCM nicht um zwei Stufen nach unten gehen oder hätte ich das Skript immer so gehabt? user001 vor 6 Jahren 0
Es ist unklar, was Sie versuchen "Ich verwende SCCM und PSADT, um Folgendes zu versuchen." und wie Ihr aktueller Code aussieht. Derzeit ist Ihre Variable "$ dirFiles" nicht definiert. Seth vor 6 Jahren 0
Es ist Teil eines viel größeren Toolkits, das für jede andere App korrekt aufgerufen wird. Es definiert die Variablen korrekt (ich kann bei lokaler Ausführung und bei allen anderen bereitgestellten Apps darauf zugreifen). Ich kann sehen, dass der Ordner im Zielverzeichnis erstellt wird, aber er ist leer, die Rekursion dauert nicht user001 vor 6 Jahren 0

1 Antwort auf die Frage

0
Pres

Klingt nach einem Berechtigungsproblem. Wenn Sie von SCCM aus laufen, würde ich vermuten, dass Sie die Vorabversion von Run Script verwenden. Dadurch wird das Skript als lokales Systemkonto des Computers ausgeführt, das wahrscheinlich nicht über die richtigen NTFS-Berechtigungen für Ihre Netzwerkfreigabe verfügt.

Wenn Sie sich in einer Domäne befinden: Zum schnellen (schmutzigen & unsicheren - diese Änderung sofort nach dem Test rückgängig machen!). Erteilen Sie Domänencomputern Lesezugriff auf den Ordner $ dirFiles \ target und alle untergeordneten Objekte. Wenn es funktioniert, müssen Sie entweder Folgendes ermitteln:

  • Wie Sie Zugriffsberechtigungen für lokale Systemkonten strukturieren möchten
  • Gibt an, ob das Skript in ein Paket oder eine Anwendung umgewandelt und stattdessen als angemeldeter Benutzer ausgeführt werden soll.

Die Paketoption ist sicherer, aber etwas langatmiger.

Viel Glück

Verwandte Probleme