Wurzelzwerg

Wer lesen kann... Genau das gleiche Problem doch nicht, sondern nur zu Neustart-faul. Habe zwar einen Test mit Neustart durchgeführt, da hats aber wohl aus anderen Gründen nicht geklappt. In folgender Konstellation klappt es bei uns: GPO mit *.domain.local = 1 in "Liste der Site zu Zonenzuordnung". GPUPDATE /Target:User auf dem Client, anschließend Neustart explorer.exe (ein Tag warten, bis der User sich neu angemeldet hat, sollte dementsprechend auch reichen ;) ) Einen Unterschied, ob per Explorer oder Ausführen und da per UNC oder Netzwerkbuchstabe (via .bat) aufgerufen, habe ich nicht festgestellt. Relevant war nur, ob DNS oder Netbios Name aufgerufen bzw. gemappt wurde. Wir verwenden allerdings auch IE8. Nur in einer Konstellation war ohne GPO in der Wurzel des via Netbios gemappten Netzlaufwerkes die Zone Internet, in den Unterordnern aber wieder Lokales Intranet :confused: Wieauchimmer, viel zu viel Zeit versenkt, aber nun gehts.

Und auch von mir noch einmal die Frage, ob es schon etwas neues gibt. Gleiches Problem, und nirgendwo eine brauchbare Lösung gefunden. Lokal einzeln bei jedem User geht, ist aber nicht handlebar. Prä-Windows 2000 Domänennamen für DFS-Aufruf verwenden geht (meist (!)) auch, aber die SID's der Besitzer werden nicht aufgelöst. Auch nicht sonderlich vertrauenserweckend. Knackpunkt ist meines Erachtens die nicht funktionierende Einstellung "Liste der Site zu Zonenzuweisungen". Viele Grüße

Wahrscheinlich sollte man dann eher von Backup-to-Network als to-Disk sprechen. Der Weg der Daten müsste in Deiner Konstellation meines erachtens so aussehen: NAS (Sicherung) ----> DC (BE Server) ----> NAS (B2D) Da wiederum wundert es mich nicht, dass die Sicherung langsam ist. Interessant wäre die Frage, wie [edit: schnell] NAS und DC untereinander angebunden sind. Kannst Du den BE Server auf dem NAS aufsetzen?

Speicherst du die B2D Daten nun auf dem DC oder NAS? Wäre es der NAS, wundert es mich nicht, das die Geschwindigkeit gering ist, da die Daten ja nochmals übers Netz gehen. Oder bauen die Remote Agents eine direkte Verbindung zwischen zu sicherndem Server und dem Speicherziel auf?

Moin moin, bin gerade dabei, ein MSI Paket für die unternehmensweite Verteilung der neuesten Java Runtime Environment 5 zu schnüren. Leider wurden die JREs bisher in beliebiger Version manuell auf den Rechnern installiert. Da alte, unsichere Versionen durch Neuinstallationen (in diesem Fall meine MSI) nicht entfernt werden, m.E. aber noch angesprochen werden können, grübel ich nun schon einige Zeit über die Möglichkeit, alle JREs außer meine verteilte entfernen zu können. Bisher ist mir nur die Möglichkeit eingefallen, alle alten JRE Programmpfade per Skript von der Festplatte zu löschen, was ich allerdings für keine charmanete Lösung halte. Daher meine Frage Ist es tatsächlich notwendig, alte JRE's zu entfernen? Wie seit ihr in so einem Fall vorgegangen? Vielleicht stand ja der ein oder andere schon vor dem selben Problem und kann mir einen kleinen Tipp geben.

Kann doch nicht Wahrstein! Dank Patchday den Server neu gestartet und seit dem läufts. Irgendwie scheint der Server irgendwo sowieso einen Schuss wegzuhaben. :suspect:

So, ich habe noch mal ein bißchen getestet. Prinzipiell funktioniert die Batch Datei auch per Task-Aufruf auf dem Windows Server 2003 - allerdings nicht in dem Verzeichnis E:\FreigabeLaufwerk\_Temp. Zur Erinnerung: Rufe ich genau die selbe Batch Datei direkt in der cmd auf, funktioniert alles. Bisher war DOMAIN\Administrator (auch lt. effektiver Berechtigung) wie folgt berechtigt: DOMAIN\Administrator --> ist Mitglied in # Domänen-Admins --> ist Mitglied in ## LW-O_Temp_Vollzugriff <-- hat Vollzugriff auf E:\FreigabeLaufwerk\_Temp CACLS Ausgabe von E:\FreigabeLaufwerk\_Temp: E:\FreigabeLaufwerk\_Temp DOMAIN\LW-O_Temp_Aendern:(OI)(CI)(Beschränkter Zugriff:) DELETE READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_DELETE_CHILD FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES DOMAIN\LW-O_Temp_Vollzugriff:(OI)(CI)F Nun habe ich DOMAIN\Administrator direkt Vollzugriff auf E:\FreigabeLaufwerk\_Temp gegeben. Ergebnis: Der DEL Befehl funktioniert auch bei Aufruf, XCOPY aber nach wie vor nicht. Wie kann das nun sein, dass per Task die - meines Erachtens nach obigen Schema korrekte - Berechtigung verweigert wird, per direktem Aufruf die Batch Befehle aber zugreifen dürfen? Sollte es etwa ein Bug sein? :suspect:

Lt. "Access is denied" error message when you run a batch job on a Windows Server 2003-based computer kann es ja schon Unterschiede geben. Aber demnach nicht für Administratoren. Und ich weiß bis jetzt nicht, warum da trotzdem der Zugriff verweigert wird. Aber vielleicht habe ich da ja auch einen falschen Ansatz.

Hallo, benutzt du WSUS 2 oder 3? Zumindest bei 2 kannst du in der Updategenehmigung ein definitives Datum zur Installation festlegen. Ferner kannst du per Richtlinie festlegen, dass Updates z.B. täglich um 0:00 Uhr installiert werden sollen. Bedenke aber, dass die Clients standardmäßig nur rund alle 22 Stunden nach Updates schauen - auch der lässt sich per Policy auf m.E. bis zu 1 Std. runterstellen (ich habe z.B. für die Testgruppe 6 Stunden eingestellt, damits notfalls auch mal schneller geht). Wo nicht gesucht wurde kann auch kein Update gefunden und dementsprechend auch nicht installiert werden. Wenn du wuauclt /detectnow auf dem Client eingibst, werden die Updates direkt gesucht.

Hallo zahni, Laufwerk E: ist die Festplattenpartition. Habe es auch per gemappten Laufwerk O: (da E:\FreigabeLaufwerk\ unser Office Laufwerk O: ist) und auch direkt per UNC probiert, es bleibt allerdings bei dem Problem. Zumal File Monitor auch diverse SUCCESS Zugriffe von xcopy.exe z.B. auf dem Pfad wo das Script selbst liegt (ebenfalls E:) anzeigt.

Hallo, ja, Dein Ergebnis entspricht dem erwarteten. Ich gehe nicht davon aus, dass die Datei in Benutzung ist (zumal eine .TXT ja - meines Erachtens nach - wohl sowieso eher selten geblockt wird). Gerade weil es ja immer dann funktioniert, wenn ich die Batch-Datei selbst ausführe, aber dann nicht, wenn sie als Task läuft (hier auch über manuelles ausführen, an der Uhrzeit kanns also auch nicht liegen). Auf welchem Betriebssystem hast Du das per Task getestet? Ich habe festgestellt, dass es auf XP wunderbar läuft. Nur auf Windows Server 2003 Standard Edition nicht, aber genau dieser ist unser Fileserver und dort soll es ausgeführt werden.

Moin, habe folgende Batch Datei, um regelmäßig per Task das Verzeichnis E:\FreigabeLaufwerk\_Temp zu löschen und anschließend eine Text-Datei dort wieder reinzukopieren. @ECHO off REM ### Variablendeklaration ### REM # Zu löschendes Verzeichnis # SET delpfad=E:\FreigabeLaufwerk\_Temp REM # Pfad der Scriptdatei # SET scriptpfad=E:\FreigabeLaufwerk\IT\Betrieb\Config\Del_L-_Temp REM # Logdatei # SET logdatei="%scriptpfad%\del-script_L-temp.log" SET errorlogdatei="%scriptpfad%\del-script_L-temp_error.log" REM # Hinweisdatei # SET txtdatei="%scriptpfad%\Achtung! Bitte lesen! L”schung dieser Dateien.txt" ECHO . ECHO . ECHO Dieses Script loescht alle Dateien im Verzeichnis %delpfad% und kopiert anschliessend die Datei %txtdatei% ECHO . ECHO . REM ### Beginne Logdatei ### ECHO %DATE% %TIME% >> %logdatei% ECHO %DATE% %TIME% >> %errorlogdatei% REM ### Löschen aller Dateien im Löschpfad ### ECHO Loesche alle Dateien in %delpfad% ECHO Loesche alle Dateien in %delpfad% >> %logdatei% ECHO . ECHO . DEL /F /S /Q "%delpfad%\*.*" >> %logdatei% 2>> %errorlogdatei% ECHO Errorlevel %errorlevel% >> %logdatei% REM ### Kopiere Hinweisdatei ### ECHO Kopiere %txtdatei% nach %delpfad% ECHO Kopiere %txtdatei% nach %delpfad% >> %logdatei% ECHO . ECHO . xcopy %txtdatei% "%delpfad%\" /I /Y >> %logdatei% 2>> %errorlogdatei% ECHO Errorlevel %errorlevel% >> %logdatei% Funktioniert perfekt, solange ich die Batch Datei selbst - eingeloggt als DOMAIN\Administrator - ausführe. Richte ich allerdings einen Task ein, der diese Batch-Datei ausführen soll, wird keine Datei gelöscht und auch die Textdatei nicht kopiert. Der im Task eingetragene Benutzer ist ebenfalls DOMAIN\Administrator. Folgendes spuken die Logs aus: [edit: Funktioniert auf Windows 2003 Server nicht per Task - auf XP gehts. Frage bleibt aber bestehen, weil die Batch-Datei auf 2003 laufen muss] 12.07.2007 14:36:17,61 Loesche alle Dateien in E:\FreigabeLaufwerk\_Temp Errorlevel 1 Kopiere "E:\FreigabeLaufwerk\IT\Betrieb\Config\Del_L-_Temp\Achtung! Bitte lesen! L”schung dieser Dateien.txt" nach E:\FreigabeLaufwerk\_Temp 0 Datei(en) kopiert Errorlevel 4 12.07.2007 14:36:17,62 Zugriff verweigert Fehler beim Erstellen der Datei - Eine Datei kann nicht erstellt werden, wenn sie bereits vorhanden ist. Verzeichnis kann nicht erstellt werden - E:\FreigabeLaufwerk\_Temp Hierbei stammt "Zugriff verweigert" vom del Befehl, der Rest müsste xcopy sein. Sysinternals File Monitor sagt: 14:17:07 xcopy.exe:3116 OPEN E:\FreigabeLaufwerk\_Temp\ ACCESS DENIED DOMAIN\Administrator 14:17:07 xcopy.exe:3116 OPEN E:\FreigabeLaufwerk\_Temp\ ACCESS DENIED DOMAIN\Administrator 14:17:07 xcopy.exe:3116 OPEN E:\FreigabeLaufwerk\ ACCESS DENIED DOMAIN\Administrator Der einzig halbwegs brauchbare Treffer in Google [MS KB] hat mich dazu gebracht, mal auf E:\FreigabeLaufwerk\_Temp\ "BATCH" Vollzugriff zu geben - gebracht hats leider nichts. Jemand 'ne Idee?

Nur interessehalber: Lag es jetzt an den fehlenden Zielgruppen? Error: forced install timer expired for scheduled install Wenn die Genehmigung "Installieren" für "Unassigned Computers" sowieso nicht greift, bräuchte ich ja zukünftig gar nicht mehr jede Gruppe einzeln genehmigen :eek:

Ich nehme an, dass "Displayname" in der deutschen MMC Konsole gleich "Anzeigename" ist? Ja, dieser wurde geändert und war nie "KrzALT", sondern "Vorname Nachname, Firma". Angezeigt wird hier jetzt aber eben KrzALT. (Und in Klammern dahinter DOMAIN\KrzALT, was Du wohl mit UPN meintest). BTW, der Fileserver ist ein Windows 2003 Server mit SP1

Nimm die PCs mal aus der Target Group unassiged Computers in eine definierte Zielgruppe rein. Ich bin mir nicht sicher, ob das genehmigen von Updates in diese Gruppe überhaupt möglich ist. Siehe z.B. auch Error: forced install timer expired for scheduled install