10.10.2016, aktualisiert um 10:47:13 Uhr

40443

GPO Zugriff verweigert 0x80070005

Hallo zusammen,

seit unsere Daten auf dem Netz inkl. Freigaben auf ein neues Storage übertragen wurden erhalten alle Clients beim Start die Meldung 0x80070005 Zugriff verweigert. Die GPO kopiert Files auf den Client. Die Einstellungen sind in der GPO unter Computerkonfig. eingerichtet.

Die Domänencomputer, sowie AD Accounts haben Leseberechtigung auf den Share. Ich habe die Berechtigung des neuen Speichers mit dem alten verglichen, alle Berechtigungen sind identisch.

Jemand noch eine Idee?

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

Content-ID: 317391

Url: https://administrator.de/forum/gpo-zugriff-verweigert-0x80070005-317391.html

Ausgedruckt am: 30.04.2025 um 04:04 Uhr

29 Kommentare

Neuester Kommentar

Moin,
poste bitte den vollständigen Inhalt des Ereignis. Ich tippe im Vorfeld auf EventID 4098.

Gruß,
Dani

Das Computer "Wallpaper"-Einstellungselement im Gruppenrichtlinienobjekt "Default ALT Policy {F4025275-42CC-4571-98A0-38E33A35D66F}" wurde nicht übernommen, da ein Fehler mit Fehlercode "0x80070005 Zugriff verweigert" Dieser Fehler wurde unterdrückt. aufgetreten ist.

Event ID ist 4098 korrekt

Moin,
bitte poste die NTFS-Berechtigungen des neuen Shares.
Ich vermute es fehlt die Berechtigung "Authentifizierte Benutzer" mit Lesezugriff.

Gruß,
Dani

Hi Dani,

ich habe die authentifi. Benutzer hinzugefügt, 2 von 3 Meldungen erscheinen nicht mehr (Alle Daten liegen im gleichen Verzeichnis)

Authentifizierte Benutzer : Lesen/Ausführen/Ordnerinhalt anzeigen/Lesen
System: Vollzugriff
ALT_Mitarbeiter (Alle Mitarbeiter): Lesen/Ausführen/Ordnerinhalt anzeigen/Lesen
ALT_IT: Vollzugriff
Domänencomputer: Lesen/Ausführen/Ordnerinhalt anzeigen/Lesen
Administratoren: Vollzugriff
SERVER\Benutzer: Lesen/Ausführen/Ordnerinhalt anzeigen/Lesen

Moin,

2 von 3 Meldungen erscheinen nicht mehr (Alle Daten liegen im gleichen Verzeichnis)

was sagt die eine Meldung jetzt noch aus?

Gruß,
Dani

Nach merhmaligen Reboots meckert nun doch wieder bei allen 3 Files.

Die Meldung ist weiterhin die oben genannte.

Das hier beachtet ?
Sicherheitsfilterung neu erfunden - MS16-072

R.

Hallo ranger,

ist bereits so konfiguriert.

Mich macht es eben stutzig, dass es genau ab dem Tag als das neue Storage aktiv war nicht mehr funktioniert. Ich habe jetzt die Pfade zu den zu kopierenden Daten nochmal in der GPO gelöscht und neu eingefügt, keine Besserung.

Wie wurden die Daten migriert?
Was ist das für ein Storage?

Ich würde die ACLs auf die Daten nochmal anwenden bzw. Sicherheitsbeschreibungen mit chkdsk reparieren.

Die Daten wurden mit Total Commander übernommen. Das Storage ist ein FTS RX2540 M1

Ich hätte das eher mit Robocopy gemacht.

Hat das Teil den alten Servernamen oder einen neuen bekommen? Oder verwendet ihr vielleicht DFS?

Es ist alles gleich geblieben, lediglich der Partitionsbuchstabe hat sich von E auf F geändert

Hi,

Was ist das für ein "Element"? Eine GPP unter "Registrierung" mit dem Namen "Wallpaper"?

Oder ein Einstellung unter
Compterkonfiguration - Richtlinien - Admin. Vorlagen - Systemsteuerung - Anpassung ?

E.

In dem Fall eine Reg. Datei für den Corporate Wallpaper über Compkonf. - EInstellungen - Windows Einstellungen - Registrierung

OK. Diese soll also von einem Share auf die lokale Platte kopiert werden?

Erstell mal eine geplante Aufgabe, lass diese unter SYSTEM laufen und lass diese die Datei kopieren.
Funktioniert das nicht, dann gibts wohl ein Rechte-Problem.
Funktioniert das, dann stimmen die Rechte. Dann muss es irgendein Timing-Problem sein.

In dem Fall ja, bei Wallpaper (ich muss mich korrigieren) handelt es sich um eine .bmp die von einem Share lokal auf die Platte kopiert wird.

Edit: Per geplante Aufgabe gab es keinerlei Probleme. Die Aufgabe wurde erfolgreich verarbeitet.

Ich habe den Ordner nochmal komplett neu angelegt + Berechtigung erneut vergeben, leider keine Besserung..

Edit: Per geplante Aufgabe gab es keinerlei Probleme. Die Aufgabe wurde erfolgreich verarbeitet.

So, das kannst abhaken. An den Berechtigungen liegt es nicht. (Ich gehe davon aus, dass der Task tatsächlich unter SYSTEM ausgeführt wurde.)

Ich würde jetzt die Debug-Protokollierung für GPO aktivieren und dann das Logfile auswerten. Wie z.B. hier beschrieben.

Der Task lief unter System. Ich habe zum Test die Dateien direkt auf den DC gelegt wo auch die Startskripte liegen, hier werden sie ohne Probleme gezogen obwohl der Ordner auf dem DC weniger Berechtigungen hat.

Ich werde mal die Protokollierung anschauen und melde mich zurück. Danke

In der Auswerung kann ich unter Group Policy Files zumindest keinen Fehler erkennen. Er sagt aber auch an anderer Stelle wo die Software Installation liegen die per GPO verteilt werden "success" obwohl er diese komplett ignoriert beim booten (laut gpresult werden sie aber gezogen)

Außer unter folgendem Punkt:

Er sagt aber auch an anderer Stelle wo die Software Installation liegen die per GPO verteilt werden "success" obwohl er diese komplett ignoriert beim booten (laut gpresult werden sie aber gezogen)

Das wird aber am "Hetz-Boot" von Win10 liegen. Das kann man abschalten.

Lass doch mal testweise das Script, welches Du im Task-Manager verwendet hast, als Computer-Startup-Script laufen (per GPO). Geht das?
(Fehler loggen in Textdatei, damit Du das auswerten kannst)

Copyscript habe ich jetzt als Startup laufen (Computerkonfig) lassen. Keine Fehlermeldung im Ereignislog. Die GPO wurde jedoch nicht angewandt, da die Daten nicht kopiert wurden. Wenn ich die Daten in ein anderes Verzeichnis lege wo deutlich weniger Berechtigungen und auch diverse Gruppen wie auth. Benutzer und Domänencomputer nicht vorhanden sind funktioniert es..

Und dieses andere Verzeichnis ist auf dem selben Server?

Edit: Die Freigabe-Berechtigungen hast Du aber auch kontrolliert?

Ja z.B. Softwareinstallationen liegen auf dem gleichen Server in einem anderen Verzeichnis, hier sind die Zugriffe 1zu1 eingerichtet. Einziger unterschied, dass der Softwareordner eine Freigabe hat aber nur aus Usability Gründen. Der Ordner mit den Wallpaper hatte zuvor auch keine Freigabe.

Gruß

dass der Softwareordner eine Freigabe hat aber nur aus Usability Gründen. Der Ordner mit den Wallpaper hatte zuvor auch keine Freigabe.

Natürlich brauchst Du eine Freigabe oder gehst Du sonst über die C$,D$...-Freigaben? Oder liegen die Dateien im SYSVOL? Oder wie jetzt?
Oder meinst Du ein extra Freigabe, also unterhalb einer anderen?

Zum Verständnis: Der Ordner "Files" in dem die Wallpaper liegen liegt unterhalb einer Freigabe, ist somit erreichbar, besitzt aber keine _eigene_ explizite eigene Freigabe auf den Ordner Files.

Aber auf den Software-Ordner greifst Du über eine eigene Freigabe zu, welche der Freigabe des "Files"-Ordner untergeordnet ist. Falls ja - gut dass Du das erwähnst.

Ich kann mir einfach nichts anders mehr vorstellen:
- Freigabe-Berechtigungen nicht ausreichend
- NTFS-Berechtigungen nicht ausreichend
- Schreibfehler im Pfad?
- $-Zeichen im Pfad bei versteckter Freigabe vergessen?
- Offline-Dateien für diese Freigabe aktiviert --> Im Zusammenhang mit GPO unbedingt vermeiden!
- Den "Hetzboot" hast Du deaktiviert? --> Gruppenrichtlinien unter Computerkonfiguration greifen unter Windows 8 und Windows 8.1 nicht

Steht eigentlich im Log des Servers mit der Freigabe irgendwas, warum er den Zugriff verweigert?

Ich habe das Problem jetzt anders gelöst. Ich habe den Ordner Files mit unter die bereits funktioniere Freigabe der Softwareverteilung gepackt was für das Management auch mehr Sinn macht da ich so alles an einem Ort habe. Jetzt funktioniert es ohne Probleme.

Vielen Dank emeriks für deine Vorschläge!

gelöstFrage Microsoft Windows Server

Mehr von xbast1x

Automatischer Export Outlook Kalenderxbast1x - 4 Kommentare

Windows 10 Logonskript greift nichtxbast1x - 22 Kommentare

Windows 10 Ordner schließen sich automatischxbast1x - 5 Kommentare

Outlook 2013 stürzt nach Windows 10 Upgrade abxbast1x - 5 Kommentare

Heiß diskutiert