Custom Desktop Wallpaper not being applied during deployment to Surface Pro 3 RRS feed

  • Question

  • Hi all,

    Been having an issue with our Surface Pro 3 and Windows 10 ever since MDT 2013 Update 2 was installed a few weeks ago (might just be a coincidence). 

    No matter what I do, our custom desktop wallpaper is not being applied during the deployment. Instead, we'll be greeted with a solid black background, not even the default Hero Win10 wallpaper.

    Before Windows 10, we used to have a task in our Task Sequence called "Copy OEM Folder", which would copy our custom "img0.jpg" file from our Deployment Share to the right path (%windir%\Web\Wallpaper\Windows) while the OS was still offline. This worked fine, until Windows 10, where it would just show a solid black background instead of our company wallpaper.

    I tried many things back then, with no success. I ended up setting our company wallpaper as the background for the Administrator image of our custom image, which would then be copied over to every new user account on the computer through the "CopyProfile" function in the TS's Unattend.xml file. 

    This worked fine, until I created a new Win10 custom image from scratch and upgraded to MDT 2013 Update 2, and am now back to square one.

    Even though my captured image's Administrator account has our custom wallpaper set as background, the new profiles only have a solid black background. Note that this issue only happens with Surface Pro 3 tablets. If I take the image and deploy it to a VM or a desktop computer, it works fine.

    I have tried many things: 

    1. Re-enabling the "Copy OEM Folder" task in our TS: The file gets copied and replaces the default Hero wallpaper, yet the OS does not seem to recognize it as I am greeted with a black wallpaper. If I open the personalize menu, I see my custom wallpaper as the first and default one...if I click on it, then it works, but just for the current user.
    2. I read somewhere that by default, Windows 10 searches in "%windir%\Web\4K\Wallpaper\Windows" for an image file with the appropriate resolution (img0_2160x1440.jpg). I have thus taken our custom wallpaper, resized it to 2160x1440 (the default Surface Pro 3, named it "img0_2160.1440.jpg", made sure the size was small enough (40kb), and made sure it was deployed to the right path with our "Copy OEM folder" task: Nothing, still a solid black background.
    3. Tried #2 but I used different resolutions (aka, I replaced all the current wallpapers at "%windir%\Web\4K\Wallpaper\Windows" with our custom wallpaper, resized and renamed to all the resolutions in the folder) : Did not work
    4. Read on the web some guy was simply deleting and/or renaming the "%windir%\Web\4K\Wallpaper\Windows" folder to prevent Windows from looking into it: Did not work.
    5. In the Unattend.xml answer sheet, you can set your desktop background through the "DesktopBackground" settings in "7 oobeSystem > amd64_Microsoft-Windows-Shell-Setup_neutral > Themes". I copied our desktop wallpaper, "sidlee_background_big.jpg" to "%windir%\System32" folder, and set the DesktopBackground setting to "%windir%\System32\sidlee_background_big.jpg": Did not work, still a solid black background.

    Am I missing something here ? Some different access rights necessary for Windows 10 ?

    We want to avoid having to go the manual way of setting the wallpaper for each user OR having to set it up using a GPO, because we want our branding there yet not prevent the user from changing it themselves.

    Thanks in advance!

    Wednesday, May 25, 2016 7:41 PM

All replies

  • I had a similar issue with Group Policy applied wallpaper. I believe it had something to do with an image cache; the alternative wallpaper was not visible and the old image was still there even though the restrictions on changing the background were in effect and the new wallpaper was visible in the preview in the Personalization dialog. You might find your answer in the Prefetch folder; in my case it was enough to manually set the new image before applying the GPO.
    Thursday, June 16, 2016 3:34 PM