Dektophintergrund per GPO funktioniert, jedoch nicht bei allen Usern

[rupyrup 0]

Hallo liebe Community,

 

ich bin ein wenig ratlos bei dem (eigentlich ja sehr leichten) Thema "Desktophintergrund per GPO setzen".

 

Ich habe eine entsprechende Gruppenrichtlinie auf unserem Firmen-DC (Windows Server 2012 R2) im GPO eingerichtet (und natürlich mit der entsprechenden OU, in der alle unsere O365-Domäneaccounts liegen, verknüpft).

Das klappt wunderbar bei fast allen Kollegen. Bei zwei Kollegen klappt es jedoch nicht. Dort wird anstatt des Bilds nur ein schwarze Hintergrund angezeigt. Zudem klappt es bei einem der beiden Kollegen komischer Weise partiell, manchmal kommt das Hintergrundbild zum Vorschein, dann verschwindet es aber auch direkt wieder. Alle Kollegen haben Windows 10 Professional (1803).

 

Folgende Varianten habe ich schon probiert, jede klappte wunderbar bis auf die beiden Problem-User:

1. Per GPO ein .jpg Desktophintergrundbild gesetzt, welches auf dem Server liegt (UNC-Pfad), entsprechend auch Active Desktop per GPO aktiviert
2. Per GPO ein .bmp Desktophintergrundbild gesetzt, welches auf dem Server liegt (UNC-Pfad) (zum Test, ob es am .jpg Bild oder Active Desktop liegen könnte)
3. Per GPO-Logon Skript unter Verwendung von Robocopy ein .bmp Desktophintergrundbild auf die Clients lokal kopiert und auf das lokale Verzeichnis in der GPO für das Desktophintergrundbild referenziert. (Zum Test ob es am Zugriff auf das Netzwerkbild liegen könnte)

 

Zusätzliche Fehlersuche hat ergeben:

• Überprüfung, ob alle GPOs übernommen wurden, habe ich bei jeder Methode über rsop.msc durchgeführt: die Richtlinien wurden immer einwandfrei (auch von den Problem-Usern) übernommen. An der Übernahme der GPOs kann es also nicht liegen.
• Bei der Variante mit lokaler Kopie des Bilds finde ich das Bild im entsprechenden Verzeichnis auch bei den Problem-Usern. An der Verfügbarkeit des Bilds kann es daher nicht liegen.

 

Zunächst dachte ich, dass es an der PC-Konfiguration der User liegen könnte. Allerdings haben wir vier neue, baugleiche Laptops angeschaft (Dell XPS 15). Ich habe alle vier Laptops in Betrieb genommen und mit der gleichen Software und Einstellungen ausgerüstet. Bei allen vier Laptops wird das Hintergrundbild übernommen. Nun hat sich jedoch einer der Problemu-User an einem der Laptops mit seinem Domäna-Account angemeldet, und das Problem taucht wieder auf. Kein Hintergrundbild. Derselbe User hatte das Problem vorher bereits auf einem Lenovo Y50, während ein anderer Nutzer bei seinem Lenovo Y50 keine Probleme hatte.

 

Ich bin kein Profi auf dem Gebiet, alles was hier steht habe ich mir erst in Foren angelesen. Deshalb bin ich ratlos, in welche Richtung ich nun mit der Fehlersuche weitermachen könnte? Es muss ja irgendwie an den Usereinstellungen liegen. Hat jemand eine Idee wo man mal sinnvoll auf Unterschiede gucken könnte? Auf den ersten Blick habe ich keine Unterschiede der User feststellen können (alle haben übrigens die selbe Berechtigungsstufe).

 

Freue mich über eure Ideen!

 

 

[Sunny61 807]

Habt ihr Roaming Profiles im Einsatz? Leg doch auf den Problem Clients für die Problem User ein neues Benutzerprofil an, rebooten, vor der Anmeldung 2 Minuten warten. Funktioniert es jetzt?

[daabm 1.366]

Nur so als Tipp: Beim Setzen des Bilds per GPO muss das Bild beim Erstellen des Profils (bzw. beim erstmaligen Anwenden der GPO, die das Bild setzt) vorhanden und zugreifbar sein, sonst landet ein schwarzes Bild im Cache. Und das bleibt da bis in alle Ewigkeit, wenn nicht ein neues Bild festgelegt wird (also nicht einfach die Bilddatei austauschen, sondern eine andere Datei festlegen!)...

[rupyrup 0]

Am 4.1.2019 um 19:45 schrieb Sunny61:

Habt ihr Roaming Profiles im Einsatz? Leg doch auf den Problem Clients für die Problem User ein neues Benutzerprofil an, rebooten, vor der Anmeldung 2 Minuten warten. Funktioniert es jetzt?

Danke für deine Rückmeldung, Sunny!

Nein, es sind keine Roaming Profiles. Jeder Kollege hat einen festen Laptop, daher haben wir dies nicht eingestellt. Die Useraccounts sind alle O365-Accounts.

Da über die Accounts der E-Mail Empfang und die Software Lizenzen laufen, kann ich leider keine neuen Benutzeraccounts für die Kollegen einrichten.

Trotzdem vielen Dank für deine Idee!

[NorbertFe 2.061]

Du sollst ja keinen neuen Account sondern ein neues Profil erstellen.

[rupyrup 0]

Am 5.1.2019 um 17:37 schrieb daabm:

Nur so als Tipp: Beim Setzen des Bilds per GPO muss das Bild beim Erstellen des Profils (bzw. beim erstmaligen Anwenden der GPO, die das Bild setzt) vorhanden und zugreifbar sein, sonst landet ein schwarzes Bild im Cache. Und das bleibt da bis in alle Ewigkeit, wenn nicht ein neues Bild festgelegt wird (also nicht einfach die Bilddatei austauschen, sondern eine andere Datei festlegen!)...

Hallo daabm, danke für deine Antwort!

Hier könnte das Problem stecken! Manche der Clients sind bei der Anmeldung nicht mit dem AD verbunden. Evtl. wurde die GPO aktualisiert, aber bei der erstmaligen Anwendung der GPO nach neuem Login, konnte das Bild nicht geladen werden, da keine Verbindung zum DC aktiv war. --> Schwarzes Bild im Cache.

Du sagst also, ich sollte das einzubindende Hintergrundbild einfach mal umbenennen? Bisher hatte ich Hintergrund.jpg bzw Hintergrund.bmp verwendet. Ich teste mal eine andere Bezeichnung dafür aus und melde mich mit dem Ergebnis!

 

vor 4 Minuten schrieb NorbertFe:

Du sollst ja keinen neuen Account sondern ein neues Profil erstellen.

Also auf dem AD ein neues Nutzerprofil? Und dann das alte löschen? Puh... wenn da irgendwas schief geht, können meine Kollegen nicht bei ihren Kunden arbeiten... Ich schaue mir die Idee mal an und teste das am Wochendende  

bearbeitet 7. Januar 2019 von rupyrup

[daabm 1.366]

Du sollst dafür sorgen, daß bei jeder Benutzeranmeldung die Bilddatei zugreifbar ist. War sie das einmal nicht, implementiere ein kleines Skript, das den dämlichen Cache löscht - Google sagt Dir, was genau zu löschen ist.

Normalerweise empfehle ich, die Bilddatei im Computerkontext oder per Deployment lokal auf den Client zu kopieren und dann im Userkontext diesen lokalen Pfad zu verwenden. Klappt immer.

[Sunny61 807]

vor 12 Stunden schrieb rupyrup:

Also auf dem AD ein neues Nutzerprofil? Und dann das alte löschen? Puh... wenn da irgendwas schief geht, können meine Kollegen nicht bei ihren Kunden arbeiten... Ich schaue mir die Idee mal an und teste das am Wochendende  

Nein, im AD gibt es kein Profil, nur einen Account. Schau doch auf einem Client hier nach: C:\Users\DeinUsername > alles was da drin ist, ist dein Profil. Verstehst Du jetzt? Ansonsten solltest du den zuständigen Admin fragen.

[rupyrup 0]

Am 7.1.2019 um 22:48 schrieb Sunny61:

Nein, im AD gibt es kein Profil, nur einen Account. Schau doch auf einem Client hier nach: C:\Users\DeinUsername > alles was da drin ist, ist dein Profil. Verstehst Du jetzt? Ansonsten solltest du den zuständigen Admin fragen.

Hi Sunny, okay, verstehe. Auf den Clients das Profil löschen, damit es neu eingestellt wird. Das ginge zwar, aber die Kollegen haben sonst relativ viel Freiraum bei der Profilgestaltung, daher ist dies nicht der beste Weg für mich. Die Idee von daabm geht ja eigentlich in die gleiche Richtung, nur, dass er gezielt den Cache für das Desktopbild löschen würde. Das werd ich erstmal ausprobieren. Danke für deine Erläuterung! PS: Ich bin leider der zuständige Admin  sind zu klein für einen Vollzeit-Admin, daher muss ich dafür herhalten...

Am 7.1.2019 um 22:08 schrieb daabm:

Du sollst dafür sorgen, daß bei jeder Benutzeranmeldung die Bilddatei zugreifbar ist. War sie das einmal nicht, implementiere ein kleines Skript, das den dämlichen Cache löscht - Google sagt Dir, was genau zu löschen ist.

Normalerweise empfehle ich, die Bilddatei im Computerkontext oder per Deployment lokal auf den Client zu kopieren und dann im Userkontext diesen lokalen Pfad zu verwenden. Klappt immer.

Das Bild ist ja mittlerweile per Robocopy auf allen Clients lokal verfügbar. Finde diesen Ansatz mittlerweile auch besser anstatt einen Link auf ein Serverbild zu nutzen. Ich werde mich daher jetzt mal um das Script kümmern um den Cache zu leeren und zudem das neue Hintergrundbild anders nennen. Danke für die Idee!

[Sunny61 807]

vor einer Stunde schrieb rupyrup:

Am 7.1.2019 um 22:48 schrieb Sunny61:

Nein, im AD gibt es kein Profil, nur einen Account. Schau doch auf einem Client hier nach: C:\Users\DeinUsername > alles was da drin ist, ist dein Profil. Verstehst Du jetzt? Ansonsten solltest du den zuständigen Admin fragen.

Hi Sunny, okay, verstehe. Auf den Clients das Profil löschen, damit es neu eingestellt wird. Das ginge zwar, aber die Kollegen haben sonst relativ viel Freiraum bei der Profilgestaltung, daher ist dies nicht der beste Weg für mich. Die Idee von daabm geht ja eigentlich in die gleiche Richtung, nur, dass er gezielt den Cache für das Desktopbild löschen würde. Das werd ich erstmal ausprobieren. Danke für deine Erläuterung! PS: Ich bin leider der zuständige Admin  sind zu klein für einen Vollzeit-Admin, daher muss ich dafür herhalten...

Du musst das Profil auch nicht unbedingt löschen, man kann es auch umbenennen. Einfach aus C:\Users\Username C:\Users\_Username machen und jetzt noch aus der Registry löschen:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList Unterhalb von ProfileList die SIDs durchklicken, bis Du auf der rechten Seite den gewünschten Eintrag des Users findest. Den Teil auf der linken Seite dann löschen und neu starten. Wenn sich der User jetzt anmeldet, bekommt er ein jungfräuliches Profil. Diesen Vorgang muss man wissen um Probleme mit lokalen Profilen auf die Schliche zu kommen.

 

[daabm 1.366]

Löschen geht schneller als umbenennen. In einer Firma haben persönliche Daten im Profil eh nix verloren

Und der Schlüssel zu allem ist tatsächlich, daß alle per GPO gesetzten Bilder (Logon, Sperrbildschirm, Hintergrund) in dem Moment tatsächlich zugreifbar sein müssen, in dem die GPO erstmals zieht. Sonst landet in allen Fällen Schwarz im Cache. Das hat MSFT echt verbockt...

[Sunny61 807]

vor 11 Stunden schrieb daabm:

Löschen geht schneller als umbenennen. In einer Firma haben persönliche Daten im Profil eh nix verloren

 

Das stimmt so natürlich, es gibt immer noch Ausnahmen. :)

[rupyrup 0]

Was bei einem Kollegen jetzt geholfen hat ohne das gesamte Profil zu löschen, war, den Cache und die Registry zu bereinigen, sprich:

 

Das aktuell gezogene Hintergrundbild zu löschen: C:\Users\%User%\AppData\Roaming\Microsoft\Windows\Themes --> "TranscodedWallpaper" löschen (Das ist denke ich auch die Cache-Datei, auf die daabm sich bezogen hat.

 

Zusätzlich die Pfade, die Windows gespeichert hat (max 5 Stück) in der Registry (regedit) bereinigen:

--> Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Wallpapers --> und da dann die entsprechenden Einträge mit den Pfaden zu Wallpapers löschen.

 

Beim zweiten Kollegen habe ich es noch nicht probiert, hoffe auch hier auf Erfolg.

 

Danke für euren Support und die Hinweise, die mich zu dieser Lösung geführt haben!