Jump to content

Silentfan

Abgemeldet
  • Gesamte Inhalte

    53
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

10 Neutral

Profile Fields

  • Member Title
    Newbie
  1. Das ganze nennt sich File System Redirection. Wie ich das aber temporär deaktivieren kann, weiß ich nicht. Wow64DisableWow64FsRedirection Function (Windows) Ich müsste es ja irgendwie in mein Batch file bekommen etc.
  2. Hi, danke erstmal. Das VBS-Script funkioniert zwar, aber das tut mein xcopy auch. (wenn die Batch manuell ausgeführt wird) Mit der Software-Verteilung wandern die Dateien aber nach wie vor in \SysWOW64 und nicht in \System32. Ich lasse die Batch mit dem gleichen Account verteilen, mit welchem es bei manueller Ausführung funktioniert. Noch einer eine Idee? Das ist irgendwie dieser 64 Bit Kompatibilätsmodus. Kann ich den nicht temporär deaktivieren? Gruß
  3. mit abschließendem Backslash klappt es leider auch nicht. :( Hat noch jemand eine einfache Lösung? Gerne hier posten, vielen Dank.
  4. Also die batch wird über die Software-Verteilung mit einem Domänen-Admin ausgeführt oder System-Account, weiß gerade nicht. Problem hab ich gefunden! Es handelt sich um ein 64 Bit W2k3, die batch wird erfolgreich ausgeführt, jedoch werden die Datein in \SysWOW64 kopiert und nicht in \System32. Wie gesagt, Ordner 2,3 & 4 geht! Wie bringe ich meinem Script bei, dass er tatsächlich in System32 kopieren soll? Danke
  5. Hallo zusammen, ich mache folgendes mit einer Batch: xcopy /i /e /o /c /y /x /r /q "Ordner 1\*.*" "%windir%\System32" xcopy /i /e /o /c /y /x /r /q "Ordner 2\*.*" "%windir%\System32\spool\prtprocs\x64" xcopy /i /e /o /c /y /x /r /q "Ordner 3\*.*" "%windir%\System32\spool\drivers\x64" xcopy /i /e /o /c /y /x /r /q "Ordner 4\*.*" "%windir%\System32\spool\drivers\x64\3" Ordner 2, 3 & 4 werden erfolgreich kopiert. Order 1 mit System32 als Ziel jedoch nicht. Woran kann das liegen? Vielen Dank. Die Batch wird mit einem Domänen-Admin ausgeführt. Gruß
  6. Mach ich, aber um das herauszufinden, werde ich wohl keine Zeit haben. Mit Autostart bei deiner Lösung meinst du wahrscheinlich Active Setup? Ich suche gerade nach einem Beispiel, wie sowas ausschauen muss. Hier muss ja ein neuer Schlüssel erstellt werden: HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components Und dann entsprechend dort ein reg.file ausführen, was vorher natürlich mittels cmdlines.txt z.B. ins Windows Verzeichnis kopiert werden muss. Ich such gerade per Google nach nem Beispiel, wie das genau aussehen muss. edit: 1) reg Datei beim XP-Script in %windir" mitgeben 2) einfach einen Schlüssen erstellen (GUID kann ausgesucht werden) HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components 2) REG_SZ "StubPath" erstellen 3) Füllen mit Regedit /s /c "%windir%\name.reg" So sollte es schon gehen, muss ich noch testen.
  7. @Dukel & zahni Ja, das ginge wohl, aber Anforderung ist das schon im Unattended XP-Script zu realisieren. @jaksa Gute Idee. Aber wieso werden nicht alle berücksichtigt? Liegt sogar im selben SChlüssel und ist auch ein reg_sz (FontSmoothing z.B.) Ich muss morgen nochmal paar Tests machen, was übernommen wird und was nicht.
  8. Hatte meinen Beitrag schon nach 30-60 Sekunden editiert, du hast natürlich Recht. Vielen Dank. – Hi, muss doch nochmal was dazu sagen: Unsere cmdlines.txt, wird während dem XP Setup bei Minute 12, 13 eingespielt / ausgeführt und diese Registry-Schlüssel /Einstellungen wandern definitiv noch in die ntuser.dat, da wir dort viele Einstellungen mitgeben, die nicht Standard sind. Neue User auf dem PC erhalten diese auch. Daher funktioniert das schon soweit. Macht auch Sinn, da der System Account zudem Zeitpunkt der User ist. Die Frage ist jetzt nur noch, wieso manche gewisse Einstellungen nicht greifen. Man könnte jetzt sagen, dass ich vielleicht die falschen SChlüssel rausgesucht habe. Ist aber nicht so, denn wenn ich das Reg File manuell importiere ist das gewünschte Ergebnis sofort da. Ich habe irgendwie also die Vermutung dass es mit diesen Domänen-Accounts zusammenhängt, irgendeine Policy vielleicht o. ä. im AD, wie auch immer. Werde morgen nochmal ganz andere User probieren etc.
  9. Mh also die Software-Verteilung importiert die Schlüssel in HKEY_CURRENT_USER\ und Sie führt alles mit dem Account "System" aus. .aber so wie ich verstanden werden von dort keine Einstellungen gezogen. Ich les den Artikel mal, danke.
  10. Hallo zusammen, folgende Situation: Ich gebe dem Windows XP über die Software-Verteilung (cmdlines.txt) verschiedene Schlüssel mit. Z.B. PowerCFG Profil, oder Effekte wie "FontSmoothing" etc. Diese Keys bzw. Werte landen dann unter [HKEY_USERS\.DEFAULT........ Wenn sich nun ein ganzer Domänen-Benutzer an der Maschine anmeldet (lokales Profil wird erstellt), welcher noch nie an dem PC angemeldet war, dann zieht er nicht die Werte aus HKEY_USERS\.DEFAULT Beispiel: [HKEY_USERS\.DEFAULT\Control Panel\Desktop"] "FontSmoothing"="0" Bei dem Account ist dann unter CURRENT USER für FontSmooting 2 eingetragen. Normalerweise zieht doch ein neuer Account, welcher das erste mal auf dem PC erstellt wird, die EInstellungen von HKEY_USERS\.DEFAULT? Wieso hier nicht? Kann es sein, dass da irgendwelche Einstellungen im Active Directory greifen, Vorlagen oder sowas. Ist ja immerhin ein Domänen Account. Habs noch nicht mit einem lokalen probiert. Hab mich auch noch nicht an den Admin fürs AD gewandt, das wäre der nächste Schritt. Wollte das hier schonmal erfragen.. Vielen Dank
  11. Habe nun eine Lösung gefunden: An SMS 2003 advertised package stops responding, and the package does not automatically install an MUI on a client computer Trotzdem danke
  12. Hi Esta, ja, hat er. Ich denke mal, das Problem liegt daran, dass das MUI Pack mit dem Konto "System" ausgeführt wird bei der Verteilung, obwohl ich den Domänen Admin mitgebe. Gruß
  13. Hallo, es geht um das MUI Pack für XP. Basis ist ein XP SP3 Englisch. Ich installiere das MUI Pack für 3 Sprachen nach und definiere Deutsch als Standard. Nach dem Neustart funktioniert auch alles. Solange ich also das MUI Pack per Hand installiere ist alles in Ordnung. Das mach ich mit einem Domänen-Admin-Account. Über folgendes batch-script funktioniert es auch: echo off msiexcec /i muisetup.exe /i 0407 0XXXX 0XXXX /d 0407 /r /s exit Sobald ich das MUI Pack aber mit dem batch-script über unsere Software-Verteilung ausrolle funktioniert es nicht. Das Script läuft nicht durch bzw. die Verteilung bleibt dort hängen. Der Prozess muisetup.exe wird zwar ausgeführt, es passiert aber einige Stunden einfach gar nichts. Als Ausführungsaccount steht "System", obwohl ich in der Software-Verteilung dem Paket den Domänen-Admin-Benutzer mitgeben (mit dem die manuelle Ausführung des batches auch funktioniert) Hat jemand eine Idee? An den Rechten kann es also nicht liegen! Rein theoretisch, würde sich das MUI Pack mit dem User "System" installieren lassen? Irgendwelche Ideen? Danke & Gruß
×
×
  • Neu erstellen...