14
Windwos 7 Dateien mit RUNAS unter anderem Nutzer austauschen
Guten Tag,
ich möchte eine dll-Datei im System32-Verzeichnis mit Hilfe einer Batch-Datei austauschen.
Es soll eine Datei im System32 -Verzeichnis ersetzt und neu registriert werden. Diese DLL-Datei liegt momentan auf dem Server.
Ich habe bereits versucht diese Arbeitsschritte zu trennen.
Zuerst soll die Datei vom Server nach lokal kopiert werden. Anschließend dann mit dem lokalen Administrator im System32-Verzeicnis ersetzt und neu registriert werden. Dieser Versuch sieht wie folgt aus:
in der Registrieren.bat steht folgender Inhalt:
Als Fehler erhalte ich folgende Meldung:
Die Datei lässt sich leider nicht ersetzen.
Merkwürdig dabei ist, wenn cih die Datei manuell vom Server ins System32 Verzeichnis kopiere funktioniert das problemlos, ich erhalte nur zwei Benutzerkontenabfragen.
Nun vermute ich, dass genau diese Benutezrkontenabfragen, das Ausführen der Batch-Datei verhindern.
Kennt jemand von euch dieses Problem und ggf. eine Lösung / work around?
Klar besteht die Möglichkeit, die Datei manuell zu ersetzen, da müsste ich jedoch an jeden PC im Netzwerk ran - den Aufwand will ich vermeiden!
thx
ich möchte eine dll-Datei im System32-Verzeichnis mit Hilfe einer Batch-Datei austauschen.
Es soll eine Datei im System32 -Verzeichnis ersetzt und neu registriert werden. Diese DLL-Datei liegt momentan auf dem Server.
Ich habe bereits versucht diese Arbeitsschritte zu trennen.
Zuerst soll die Datei vom Server nach lokal kopiert werden. Anschließend dann mit dem lokalen Administrator im System32-Verzeicnis ersetzt und neu registriert werden. Dieser Versuch sieht wie folgt aus:
1:)
copy \\SERVER\Verzeichnis\Datei.dll C:\Temp\Datei.dll
runas /user:administrator /savecred "\\SERVER\Verzeichniss\Registrieren.bat
pauseregsvr32 -u -s %SystemRoot%\System32\Datei.dll
del %SystemRoot%\System32\Datei.dll
copy C:\Temp\Datei.dll %SystemRoot%\System32\Datei.dll
regsvr32 -s %SystemRoot%\System32\Datei.dll
pause"997: Überlappender E/A-Vorgang wird verarbeitet" Merkwürdig dabei ist, wenn cih die Datei manuell vom Server ins System32 Verzeichnis kopiere funktioniert das problemlos, ich erhalte nur zwei Benutzerkontenabfragen.
Nun vermute ich, dass genau diese Benutezrkontenabfragen, das Ausführen der Batch-Datei verhindern.
Kennt jemand von euch dieses Problem und ggf. eine Lösung / work around?
Klar besteht die Möglichkeit, die Datei manuell zu ersetzen, da müsste ich jedoch an jeden PC im Netzwerk ran - den Aufwand will ich vermeiden!
thx
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: 139936
Url: https://administrator.de/contentid/139936
Ausgedruckt am: 22.11.2024 um 21:11 Uhr
14 Kommentare
Neuester Kommentar
Welches Windows 7 ist es genau? Home/Pro/Ultimate/32/64bit?
Hi.
Nimm ein Startskript. Das arbeitet ohne Kennwortübergabe mit dem Systemkonto und es interessiert sich auch nicht für die UAC-Abfragen.
Nimm ein Startskript. Das arbeitet ohne Kennwortübergabe mit dem Systemkonto und es interessiert sich auch nicht für die UAC-Abfragen.
Windows 7 Professional
Wo bekomm ich ein Startscript her bzw. wo richte ich das ein? steh grad auf dem Schlauch!
Wo bekomm ich ein Startscript her bzw. wo richte ich das ein? steh grad auf dem Schlauch!
EIn Domänenstartskript ist Teil einer GPO - falls Ihr eine Domäne einsetzt.
Also ich nutze bereits ein Startscript!
Dieses führt auch genau die oben aufgeführten Befehle aus, leider ohne erfolg!
Die UAC wird irgendwie nicht ignoriert und ich suche momentan nach einer Lösung!
was kann ich nun machen? Gibt es eine andere Lösung?
Dieses führt auch genau die oben aufgeführten Befehle aus, leider ohne erfolg!
Die UAC wird irgendwie nicht ignoriert und ich suche momentan nach einer Lösung!
was kann ich nun machen? Gibt es eine andere Lösung?
Nochmal die Frage ob 32 oder 64 Bit: bei einem 64Bit-System könnte es sein, das das OS meint es wäre eine anfrage von einer 32bit Applikation, dann wird die Anfrage die Datei zu ersetzen von Wow64 auf den syswow64 Ordner umgeleitet. Evtl. hängt es da dran ...
Es handelt sich um 32-Bit Windows 7 sowie Vista Rechner.
Bei den älteren XP Clients funktioniert, das oben beschriebene Script problemlos!
Bei den älteren XP Clients funktioniert, das oben beschriebene Script problemlos!
"Du nutzt kein Startskript, sonst ginge es" - mal ganz platt gesprochen. Kann es sein, das Du Startskripte mit Anmeldeskripten verwechselst?
@connor: das mit wow64 musst Du erklären - in welchem Fall wird da umgeleitet? Ganz bestimmt nicht.
@connor: das mit wow64 musst Du erklären - in welchem Fall wird da umgeleitet? Ganz bestimmt nicht.
Das kann gut möglich sein, dass ich Start und Anmeldescripte verwechsle!
Das Script, welches bei der DOMainanmeldung startet, wurde im AD beim Benutzer eingetragen.
Es läuft direkt nach der DOM-Anmeldung, sichtbar für den Nuter durch!
WO und WIE definiere ich ein Startscript?
Das Script, welches bei der DOMainanmeldung startet, wurde im AD beim Benutzer eingetragen.
Es läuft direkt nach der DOM-Anmeldung, sichtbar für den Nuter durch!
WO und WIE definiere ich ein Startscript?
Das im Benutzerobjekt eingetragene ist ein Anmeldeskript.
Was Du brauchst findet sich in einer (zu erstellenden) GPO im Bereich Computerkonfig - Windowseinstellungen - Skripte - Starten.
Was Du brauchst findet sich in einer (zu erstellenden) GPO im Bereich Computerkonfig - Windowseinstellungen - Skripte - Starten.
Zitat von @DerWoWusste:
@connor: das mit wow64 musst Du erklären - in welchem Fall wird da umgeleitet? Ganz bestimmt nicht.
Da er kein 64bit System verwendet, trifft es ja nicht zu, meine Vermutung war also falsch. War mir nur in den Sinn gekommen, da ich selber schonmal über eine ähnliche Situation gestolpert bin, etwas in System32 gesucht hatte, was aber in Syswow64 abgelegt wurde, das nur kurz ab Rande.@connor: das mit wow64 musst Du erklären - in welchem Fall wird da umgeleitet? Ganz bestimmt nicht.
@connor
schon richtig, aber dies trifft nicht bei Skripten zu, in denen explizit drinsteht "kopiere nach system32", Windows nimmt sich nicht einfach heraus, dann nach syswow64 zu kopieren.
schon richtig, aber dies trifft nicht bei Skripten zu, in denen explizit drinsteht "kopiere nach system32", Windows nimmt sich nicht einfach heraus, dann nach syswow64 zu kopieren.
ok, danke erstmal!
Das bedeutet, ich muss an jedem Arbeitplatz das gewünschte Script die die GPO eintragen?
oder kann ich nicht irgendwo am Server definieren, dass ebend dieses Script einmalig ausgeführt wird an allen Clients?
Wie werden in eurem Netzwerk Änderungen an DLL-Dateien ausgetauscht? Solch eine Änderung kann ja desöfteren mal auftreten!
Lgs
Das bedeutet, ich muss an jedem Arbeitplatz das gewünschte Script die die GPO eintragen?
oder kann ich nicht irgendwo am Server definieren, dass ebend dieses Script einmalig ausgeführt wird an allen Clients?
Wie werden in eurem Netzwerk Änderungen an DLL-Dateien ausgetauscht? Solch eine Änderung kann ja desöfteren mal auftreten!
Lgs
Eine Domänen-GPO richtet man nicht am Arbeitsplatz ein, sondern am Domänencontroller. Du kannst das Skript prüfen lassen, ob die dlls schon da sind und dann erst danach handeln.
Ich mach das über GPPs, siehe MS kb943729.
Ich mach das über GPPs, siehe MS kb943729.
