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

Moin moin, wir haben kürzlich einer frisch verheirateten Kollegin ein neues Kürzel für die Anmeldung verpasst, z.B. von KrzALT zu KrzNEU. Hierbei haben wir einfach in dem MMC Snap-In "Active Directory-Benutzer und -Computer" den Benutzeranmeldenamen (auch Prä-2000) abgehändert. Hat auch soweit funktioniert, lediglich auf dem Dateiserver wird bei den Berechtigungen zum Profil noch "KrzALT" angezeigt (normalerweise sollte hier ja der Name und nicht das Kürzel stehen). Zwar funktioniert der Zugriff aufs Profilverzeichnis, langfristig befürchte ich hier aber einige Verwirrungen und bin mir auch nicht sicher, ob es sich vielleicht um eine später vielleicht fatale Fehlfunktion handelt. Über Anregungen zur Behebung dieses Anzeigefehlers wäre ich von daher sehr dankbar. Gruß

Ich muss mich korrigieren. Zwar kann ich die Besitzrechte nicht übernehmen, aber als lokaler Admin vorhandene Leserechte auf Vollzugriff ausweiten. :shock: :eek: Man lernt nie aus... Bloß - warum ist das so?? [Edit] Erst denken, dann schreiben. Lag natürlich daran, dass der Testuser auch Besitzer der Verzeichnisse war. Ist das bei dir auch der Fall?

Habe meinen AD User (Mitglied in Domänen-Benutzer) in die lokale Admingruppe hinzugefügt. Dabei konnte ich deinen oben beschriebenen Sachverhalt nicht nachvollziehen. Weder konnte ich mir Berechtigungen auf ein Verzeichnis geben, wo der User überhaupt keine Rechte besaß (Register "Sicherheit" wurde gar nicht angezeigt), noch konnte ich Rechte auf einem Verzeichnis übernehmen, auf dem der Test User lediglich Leserechte hatte ("Sie besitzen nicht die Berechtigung, die Besitzrechte zu übernehmen" o.ä.). Das ganze natürlich mit Dateien auf einem Fileserver. Habs zwar nicht ausprobiert, aber ich gehe davon aus, dass der Testuser auf dem lokalen Computer alle NTFS Rechte übernehmen kann. Ich nehme an, deine Problematik hängt mit dem Weg der eingeschränkten Gruppen zusammen. Da fehlt mir allerdings das Wissen zu.

Ok die Funktion hatte ich gerade nicht vor Augen, deswegen bin ich davon ausgegangen, dass Du mit eingeschränkten Gruppen = Verweigerungen im Dateisystem meinst. Dementsprechend kann ich dir dann noch nicht tiefergehend weiterhelfen, weil ich die genaue Funktionsweise nicht kenne. Nichts desto trotz scheinen deine User Domänen-weite Adminrechte zu haben, als lokale Admins dürften sie eigentlich auf dem Fileserver keine Rechte haben.

Reicht es nicht, wenn du den Usern lokale Adminrechte vergibst? Meines Erachtens sollten die User dann nicht mehr die Möglichkeit haben, auf dem Fileserver Besitzrechte zu übernehmen.

Hallo, wir haben an allen Clients ein Netzlaufwerk K:, in dem die Dateien der Mitarbeiter organisiert sind. Dieses verweist auf \\fileserver\dateien\ . FILESERVER ist ein Windows 2003 Server mit SP1. Wenn ich nun direkt in K: eine Verknüpfung auf z.B. K:\verzeichnis\unterverzeichnis anlege und einigen Usern Berechtigungen auf diese Verknüpfung gebe, funktioniert das in soweit, als das alle anderen User kein Symbol mehr für die Verknüpfung angezeigt bekommen, und diese bei einem Doppelklick transparent wird (wie nach "Ausschneiden"). Lösche ich die .lnk Datei als nicht-berechtigter User, klappt das aber leider tadellos - obwohl ich genau das vermeiden wollte. Unter den "effektiven Berechtigungen" hatte der löschende User zuvor definitiv kein Recht. Witzigerweise klappt das Löschen selbst dann noch, wenn ich "Löschen" der Gruppe "Jeder" verweigere. Spiele ich das ganze allerdings lokal auf Windows XP SP2 durch, funktionieren die Berechtigungen einwandfrei. Kann das an Windows 2003 liegen? Oder hat jemand da eine andere Erklärung für? Ich weiß nicht warum - aber ich zweifel gerade an meinem Verstand.

Hallo, wollte nur noch einmal kurz Rückmeldung geben. Ein alter Vorschlag von mir hat nun doch endlich gehör gefunden. Es wird nun eine lokale Anmeldung genutzt und der Benutzer meldet sich an einem Terminalserver an. Das Problem ist somit - wenn auch auf einem anderen Wege - gelöst, deshalb auch keine weiteren Nachforschungen im Sicherheitsprotokoll.

Elster 2006-2007 verschiebt offenbar auch illegal DLLs. KB925902 verhindert Start von ElsterFormular 2006-2007 | Vorgezogenes Update von Microsoft für AN... | heise security news-Foren KB935448 schafft allerdings offensichtlich Abhilfe.

Danke für die Tipps. Mal sehen, wann ich das Notebook das nächste mal in die Finger bekomme. Werde es dann gleich überprüfen.

Start > Ausführen > gpedit.msc Das gilt dann allerdings ersteinmal global für alle Benutzer dieses Rechners. Du könntest anschließend per NTFS ACL den Zugriff auf die Datei, in der die lokalen Gruppenrichtlinien gespeichert sind nur für Hauptbenutzer zu erlauben. Wichtig ist, dass der Administrator natürlich zum Ändern Zugriff braucht. Hierzu ggf. einfach ein zweites Admin-Konto anlegen, welches Zugriff auf diese Datei hat - natürlich gelten hier dann auch wieder die definierten Richtlinien.