Dateien mit Intelligenz per GPO ins Programmverzeichnis

Hallo zusammen,

ich muss unternehmensweit Dateien ersetzen. Allerdings nicht einfach stumpf ersetzen, sondern mit einer Abfrage, ob die Datei in der Quelle (Netzlaufwerk) sich vom Inhalt von der im Ziel (C:\Program Files (x86)\Ordner) unterscheidet und wenn ja, ob die in der Quelle neuer ist. Allerdings scheitere ich gerade daran, dass der normale User keine Dateien unter C:\Program Files (x86)\ verändern darf.

Hat hier jemand einen Ansatz für mich?

Danke

VG

Erwin

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

Content-ID: 349357

Url: https://administrator.de/forum/dateien-mit-intelligenz-per-gpo-ins-programmverzeichnis-349357.html

Ausgedruckt am: 26.12.2024 um 12:12 Uhr

14 Kommentare

Neuester Kommentar

Servus,

Allerdings scheitere ich gerade daran, dass der normale User keine Dateien unter C:\Program Files (x86)\ verändern darf.

Hat hier jemand einen Ansatz für mich?

Datei per GPO kopieren - Zugriff Verweigert

Hi,
GPO mit Computer Startupscript.
Ne einfache CMD-Datei.

xcopy \\server\freigabe\quelldatei "C:\Program Files (x86)\Ordner\" /D /Y

/D bewirkt "nur wenn neuer"

E.

Moing Mr Count,

der Beitrag war auch von mir :P
Aber leider kommt das in diesem Fall nicht zum Tragen, da mir hier die "Intelligenz" fehlt. Da werden nur stumpf die Dateien kopiert.

VG
Erwin

Moing Emeriks,

GPO mit Computer Startupscript habe ich bereits eingerichtet, allerdings nutze ich ein PowerShell Skript mit folgender Zeile:
Copy-Item -Path "$SourcePath\$File1" -Destination "$DestinationPath\$File1" -Force

$SourcePath = Netzwerkpfad
$DestinationPath = C:\Program Files (x86)\Ordner

Aber funktionieren tut es leider nicht :'(

VG
Erwin

Aber funktionieren tut es leider nicht

Das ist jetzt eine hochklassige Fehlerbeschreibung!
Was passiert? Was passiert nicht?

Wenn Du da mit "-force" kopierst, dann wird sie immer überschrieben, egal ob neuer oder nicht.
Der Weg mit XCOPY funktioniert. XCOPY kannst Du auch aus PS aufrufen.

ich vergleiche im skript an einer früheren stelle den hash und das letzte änderungsdatum der dateien. so wird sichergestellt, dass die datei wirklich nur ersetzt wird, wenn sich etwas geändert hat und die datei auch neuer ist. daher ist der schalter -force schon so ok.

es passiert nichts ... ich bekomme die meldung "Zugriff verweigert" wenn er versucht die Datei nach C:\Program Files (x86)\Ordner zu kopieren.

Das Script läuft im Computer-Kontext. Also benötigt das Computer-Konto Lese-Rechte für die zu kopierende Datei. Hast Du das berücksichtigt?

Also du schreibst, dass du Probleme hast, die Dateien zu kopieren... (Zugriff verweigert)

Allerdings scheitere ich gerade daran, dass der normale User keine Dateien unter C:\Program Files (x86)\ verändern darf.
Hat hier jemand einen Ansatz für mich?

Das wird, soweit ich das durchgelesen habe, in deinem anderen Beitrag (den ich verlinkt habe und der als "gelöst" markiert ist) gelöst.

Dann sagst du, dass dir die "Intelligenz" dahinter fehlt, da so nur stumpf Dateien kopiert werden...
Im nächsten Posting sagst du aber, dass du in deinem Script schon vorher die Dateien vergleichst...

Was denn nun?

Oder hat mein Hirn schon FREITAG?
Kann auch sein, da wir ja Wiesnzeit haben...

Aaaaaalso, ich glaub ich fang nochmal von Anfang an an und erkläre auch den Eigentlichen Hintergrund .... es ist so:

wir haben ein Programm das für Updates ein paar DLL-Files austauschen und diese anschließend registrieren muss (nicht normal über Windows, sonder über ein zusätzlich vom Hersteller eigenes entwickeltes "Update"-Tool. Die DLLs legen wir zentral in einem Netzlaufwerk ab und tauschen diese dann je nach dem durch neuere Versionen aus. Ich müsste es jetzt realisieren, dass z. B. im Logonskript folgendes geprüft bzw. ausgeführt wird:
1. Prüfe, gibt es das Zielverzeichnis am Client überhaupt
2. Wenn ja, vergleiche HASH und letztes Änderungsdatum mit den Dateien im Netzlaufwerk
3. Sollten die Dateien von einander abweichen und in der Quelle (Netzlaufwerk) neuer sein, dann tausche diese aus
4. führe das Tool vom Hersteller aus und registriere damit die übertragenen DLLs (Syntax wäre: C:\Program Files (x86)\Ordner\tool.exe PATH:C:\Program Files (x86)\Ordner\ FILE:File1.dll

Hilft das weiter?

Kann auch sein, dass mein Hirn es auch einfach grade nicht auf die Kette bringt, sich richtig auszudrücken :P

VG
Erwin

Das hatte ich schon so verstanden. Ist ja alltägliches.
Ich kann mich nur wiederholen. Nimm einfach das xcopy mit Schalter /D.
Selbst wenn die Datei dabei nicht kopiert wird, weil sie am Client schon aktuell ist, würde es doch nichts schaden, wenn anschließend die Registrierung der DLL noch einmal läuft, oder?
Also

Tür zu? - Nein. - Mach sie zu!
Tür zu? - Ja. - Mach sie zu!

Das Ergebis ist beide Male das selbe. Ich muss also nicht erst fragen, ob sie zu ist, sondern kann einfach anweisen: Mach sie zu!

xcopy \\server\freigabe\File1.dll "C:\Program Files (x86)\Ordner\" /D /Y  
"C:\Program Files (x86)\Ordner\tool.exe" PATH:"C:\Program Files (x86)\Ordner\ FILE:File1.dll"  

das verstehe ich schon, wobei mir das etwas primitiv ist. Hab es jetzt aber trotzdem mal probiert und bekommen, obwohl der ausführende User auf den Netzwerkpfad berechtigt ist die Fehlermeldung: Ungültige Laufwerkangabe

das verstehe ich schon, wobei mir das etwas primitiv ist.

Du bist wohl kein Pragmatiker?

Hab es jetzt aber trotzdem mal probiert und bekommen, obwohl der ausführende User auf den Netzwerkpfad berechtigt ist die Fehlermeldung: Ungültige Laufwerkangabe

Wieso User? Es soll doch vom Computer ausgeführt werden?
Wenn Du das aber als User testen willst, dann muss die Batch voll eleviert ("als Administrator") ausgeführt werden.

Edit:

Ungültige Laufwerkangabe

Du verwendest dabei hoffentlich keine verbundenen Netzlaufwerke? Wenn doch: Nimm UNC-Pfade!

ich teste das Skript manuell, später soll es als Computer ausgeführt werden.
Beim Test habe ich UNC-Pfade verwendet und die CMD als Admin ausgeführt.

Naja, es soll nicht nur funktionieren, sondern auch ne Gewisse Qualität haben.