GPO Script mit Robocopy schlägt fehl

Hallo allerseits,

ich habe ein kleiens Problemchen, ich habe ein UpdateScript für ein Datenbankprogramm, welches ich per Maschinen Startscript auf dem AD eingebunden habe. Dort ist ein Roboycopybefehl der eine Synchonistion durchführen soll, lokal funktioniert das Ganze wunderbar. Der Rest des Scriptes funktioniert aber er kopiert halt nicht: Der fragliche Teil sieht in etwa so aus:

ROBOCOPY "\\xyz.verwalt-berlin.de\Daten\Austausch-Daten\xzz\INSTALL\Start" "C:\windows\Start" /PURGE /B /E /R:0 /ZB  

Als vernüpfte OU wurde Notebooks und Desktop aus gewählt. Die GPO ist aktiviert und auf erzwungen gestellt. Muss ich vielleicht noch irgendwas bei Filterung oder Delgierung machen? Ich krieg langsam graue Haare...

lg und danke i.V:

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 668352

Url: https://administrator.de/forum/gpo-script-mit-robocopy-schlaegt-fehl-668352.html

Ausgedruckt am: 22.12.2024 um 11:12 Uhr

18 Kommentare

Neuester Kommentar

Zitat von @casi4711:

Hallo allerseits,

ich habe ein kleiens Problemchen, ich habe ein UpdateScript für ein Datenbankprogramm, welches ich per Maschinen Startscript auf dem AD eingebunden habe. Dort ist ein Roboycopybefehl der eine Synchonistion durchführen soll, lokal funktioniert das Ganze wunderbar. Der Rest des Scriptes funktioniert aber er kopiert halt nicht: Der fragliche Teil sieht in etwa so aus:

ROBOCOPY "\\xyz.verwalt-berlin.de\Daten\Austausch-Daten\xzz\INSTALL\Start" "C:\windows\Start" /PURGE /B /E /R:0 /ZB  

Ich glaube ich würde als erstes mal eine Test Gruppe nehmen bevor ich etwas auf die Welt loslasse.
Dann würde ich in das Script noch so etwas wie ein Logging einbauen um zu sehen, warum was nicht funktioniert.
Und Maschinen Startscript kann manchmal fehlschlagen, weil einige Rechner es nicht ausführen können wenn noch keine Netzwerkverbindung besteht beim Start (hab nie rausgefunden warum es bei manchen im lokalen LAN geht und bei anderen nicht).

eigentlich ist das ein script was schon ewig läuft, wie du aber sagst, manchma ging es eben nicht, bei den meisten ging es in der Vergangenheit, mittlerweile ist es aber eben ganz oft so. Liegt es womögkich an irgendwelchen Client Einstellungen?

Moin,

Schonmal mit IP versucht statt FQDN? Im Zweifel ist es immer DNS

Grüße

du meinst jetzt die IP vom FIleserver als Quelle?

Genau, vllt löst der FQDN auf manchen clients nicht richtig auf.

Moin,

wirds ausgeführt? Log Datei? Windows Ordner braucht mehr als User Rechte. In welchen Kontext läuft das Skript? Wie ist die Fehlermeldung?

Moin,

schreibe mal eine eigene Logdatei, damit Du siehst, ob das Skript überhaupt ausgeführt wird.
Und für Robocopy dessen Loggingfunktionen aktivieren.

Dann solltest Du schnell sehen, in welchem Bereich es hakt.

Gruß

DivideByZero

Moin Nachbar @casi4711

ggf. muss man den Startpfad zu Robocopy.exe komplett angeben, damit er Robocopy.exe findet.

Kreuzberger

ok danke noch mal für die Hinweise, also ich wollte gerade die Logdate einbauen, nun bemerke ich dass er offensichtlich ein Problem mit den UNC Pfaden hat, dann werde ich es mal mit der IP versuchen

lg

verwalt-berlin.de

😆 Da brauchst du gar nicht erst weiter machen, das läuft dann aus Prinzip nicht, error by design!

Der Thread bestätigt mal wieder eindrucksvoll wieso ...

achja: und die jeweils sich anmeldenden USER müssen natürlich alle Rechte haben zumindest lesen auf dem quellpfad, und schreiben auf den Zielpfad.

Kreuzberger

So, das war erst mal eine gute Idee mit dem Log, er sagt folgendes:

2024/09/25 10:13:47 FEHLER 5 (0x00000005) Zugriff auf Quellverzeichnis \\xyz.verwalt-berlin.de\Freigaben\Austausch-Daten\xyz\INSTALL\AIPAugias\UPD\
Zugriff verweigert

Was heisst das aber nun für mich, vermutet habe ich das ja nun schon, komischerweise hat es ja in der Vergangenheit überwiedgend funktioniert, ich denke da hat MS mit irgendwelchen patches was geändert, anders kann ich mir das nicht erklären. Sollte ich dem Verzeichnis UPD noch spezielle oRDNER rechte verpassen, für System, DC whatever? Oder lieber als Userscript anstatt Maschinen Script?

lg und danke noch mal

@casi4711

wie ich bereits anmerkte, müssen die Schreib- und Leserechte vorhanden sein.
Ggf. gibts du den Ordner des Quellverzeichnisses zum lesen mal für alle frei und das auszuprobieren.

Kreuzberger

Immer beide Scripte vorhalten wäre nicht verkehrt. Wir deployen mit Choco die Software. Startup und Logon Scripte. Ggf. auch eine Arte Self-Service der unter dem \Benutzer-Gruppen dann irgendwas imer User Kontext tut. Lw neu verbinden, prüfungen, etc.

Würde bei solchen Konzepten schonmal Grundgerüst für beides festlegen. Dann fällt einen später weniger vor die Füße.

PEBKAC, der/die Computeraccount(s) der/des Clients muss Lese-Rechte auf den Share bekommen , sowohl auf die Freigabe als auch auf NTFS Ebene, denn Startskripte laufen mit SYSTEM Rechten des jeweiligen Computers ...