Set desktop background Windows 10 Registry

Ask a question
Quick access
  • Forums home
  • Browse forums users
  • FAQ
Search related threads

  • Remove From My Forums

Asked by:

  • 0
    Sign in to vote

    Hi Kate. Thank you for the info. I have to say that looks rather excessive to simply set the initial wallpaper but if there's no other way to do it now, we'll give it a try.

    The frustrating thing is this works fine if I use "CopyProfile" in our sysprep process where we set the wallpaper in the customized [administrator] account. This setting gets copied to the Default User profile and new users inherit the WallPaper setting just fine. [Of course the Start Menu is messed up now using CopyProfile in Build 1709, so we're stuck trying to find some other solution.]

    My solution is to simply directly edit the Default User profile hive and set the WallPaper key, but this registry key is not get inherited by new users that log in. I did verify the Default User registry key kept its' setting by running regedit after the computer comes up and I loaded the Default User profile hive and the WallPaper registry key is in fact still set in there, but for some reason new users are not inheriting this setting when they log in. Very frustrating.


    Monday, January 8, 2018 2:38 PM
  • 0
    Sign in to vote

    Hi JS2010. The article that Kate Li referenced is a similar process with taking ownership, resetting file permissions, and copying various files to replace existing files.

    However, I saw someone reference in the comments of that article that when they applied a new build, [i.e. - you have Windows 10 build 1703 and the Fall Creators Update build 1709 comes down and installs], that it overwrote those image files again, effectively canceling out what you've done.

    I'm curious if this is something that you have encountered, or if after applying a new build your custom 'default' image files remained in tact?

    [I also saw a few comments that this did not work on Surface Pro 3 tablets, which we have several Surface Pro tablets in our environment.]

    So I'm a little apprehensive that this is the correct way to do this.



    • Edited by KHHemmelman Monday, January 8, 2018 7:38 PM
    Monday, January 8, 2018 7:37 PM
  • 0
    Sign in to vote

    That would apply after the shell has started and although it would change the key, explorer would not redraw the desktop with the new wallpaper as a result until the next logon.

    It also assumes you're using the same wallpaper on all devices, with no consideration of different resolutions, aspect ratios etc.

    Tuesday, January 9, 2018 12:45 PM
  • 0
    Sign in to vote

    p.s. - The issue with the missing Universal Apps after deleting a profile is very similar to another problem we've encountered. When build 1709 came out and we tested applying it to existing computers running build 1703, guess what happened? Yep, all the Universal Windows apps were missing from the Start Menu after applying build 1709. [Needless to say, we aren't currently updating our 1703 computers with build 1709.]

    Tuesday, January 9, 2018 4:46 PM
  • 0
    Sign in to vote

    Hi Keith,

    I see you have various questions on configure user profile at once, not just the desktop. You say the copyprofile could be the right way to implement all of these things.

    I can feedback this issue on our platform.

    =============================================

    For the Desktop question, I have mentioned about the RunOnce registry key, you can refer to this guide to do so:

    //cmatskas.com/configure-a-runonce-task-on-windows/

    To set the key items, we can use this commands:

    Set-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\RunOnce" -Name '!changedesktop' -Value "c:\WINDOWS\system32\cmd.exe 'reg add 'HKEY_CURRENT_USER\Control Panel\Desktop' /v Wallpaper /t REG_SZ /d wallpaper_path /f'"

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact .

    Thursday, January 11, 2018 5:55 AM
  • 0
    Sign in to vote

    Hi Kate. Thank you for the info. In my effort to find an alternate way without using CopyProfile to provide all the default settings, etc. that we want users to inherit when they log in, I am testing a similar process, but instead of using the RunOnce registry key, I am using the .\Startup folder.

    I'm using basically a simply batch file to set various registry keys, one of which is the WallPaper. It does set this key when a new user logs in, but the user needs to in turn log off before the new WallPaper shows up. Thus, I think I've found another command to use after setting the WallPaper to 'redraw' the desktop and therefore the user doesn't have to logoff to get the initial Desktop WallPaper. It's not real clean since they initially see the generic Microsoft WallPaper, then this batch file runs as they login and the screen will update a few seconds later to display the updated WallPaper.

    I had first tried to set the WallPaper registry key in the "Default User Profile Registry hive". I figured setting this registry directly into the Default User hive would in turn automatically give any new user that logs in this registry key and they would immediately have the WallPaper since they should inherit this registry key from the Default User settings. But as Mike Sandells explained above, this registry key is getting overwritten by Windows when a user logs in. [If I use CopyProfile and set the registry WallPaper key, then this key does in fact come through and works fine.] So the end result is by not using CopyProfile and manually editing the Default User profile hive registry key, when a new user logs in, they apparently do initially inherit the WallPaper registry key, but Windows immediately wipse that key out as the new profile is getting generated, resetting it back to the generic Microsoft wallpaper. Thus, the reason I'm looking at another way to set the WallPaper when a new user logs in. This wouldn't be necessary if that registry key would not get wiped out.

    With regards to why I reference CopyProfile is the best way to provide these defaults settings, I believe this because quite honestly it is the easiest way to do this. We've been using CopyProfile for a long time and it works great to provide default settings, etc. when a user logs in. But I also say this because Microsoft themselves reference using CopyProfile as the way to do these things. All you have to do is reference the Windows System Image Manager documentation for the CopyProfile setting. I quote:

    "CopyProfile enables you to customize a user profile and use the customized profile as the default user profile. Windows uses the default user profile as a template to assign a profile to each new user."

    It's pretty clear to me why I would use CopyProfile to provide default settings! Like I said, CopyProfile has been working fine for us in Windows 10 since build 1511. We've used it in Build 1607 and 1703. But now when creating a clone image using Build 1709 and using CopyProfile, the Start Menu layout is NOT being copied over to a new user. Hence why I feel that Microsoft broke something regarding the Start Menu layout and/or CopyProfile in build 1709 and I would like Microsoft to fix things so using CopyProfile in Build 1709 [or future builds] works the same way it has in the past.

    Thursday, January 11, 2018 2:33 PM
  • 0
    Sign in to vote

    Hi Jose. I'm initially trying the below.

    - I've got a shortcut link [.lnk] in the Default User profile ".\Startup" folder.
    - When a new user logs in, they inherit this as part of their .\Startup folder.
    - This link runs a batch file stored on the C: drive that runs various REG commands to set various registry key settings to give users some default settings. [Some of which I did get from your site to save me time from having to find them myself. Thank you.]
    - The last command in the batch file is: rundll32.exe User32.dll,UpdatePerUserSystemParameters ,2 ,True
    - The batch file also has a command in it to delete that .lnk file from their profile.

    I admit I found that rundll32.exe command on the internet and can't explain it, but appears to be calling a similar routine your PowerShell script runs.

    The end result is a user logs in, this batch file runs and executes all the commands to give them some initial settings, including the WallPaper registry setting. Initially the user has the generic Windows wallpaper when they login, but when the batch file runs the last command, it does update the Desktop wallpaper with the one we wish to use. And since it deletes that .lnk, this batch file won't run again on subsequent logins by that user.

    I honestly am not comfortable with the process you use to take ownership, replace permissions, and then replace all the img.jpg files. My first thought is that when the next build comes out, Microsoft will just replace those files anyway. But if not, I should not have to hack & replace files that Microsoft protected like that and setting the WallPaper registry key for new users is a cleaner way for us.

    Still doing testing, but hopefully this will be a functional work around in the event Microsoft does not fix CopyProfile in the next build.

    Thursday, January 11, 2018 9:14 PM
  • 0
    Sign in to vote

    I'll keep that in mind if the command line doesn't work. I agree it's not a clean way to do it, but we have Microsoft to thank for that by breaking CopyProfile. It is possible at some point we could implement something that would prevent users from running scripts, so a PowerShell script may not work. Can't say that will happen, but it's a possibility so I'd be leary to use that now as a solution.

    Yeah, we wouldn't want to have to script and rewrite the image files to every computer after a feature update came out, so that's not an acceptable option for us.

    Honestly the best solution is for Microsoft to simply fix CopyProfile. It's been working great for us. But if they ignore fixing that, then the next best solution would be to simply let the Default User registry key setting for the WallPaper to come through to a new user profile and not re-write it with their default wallpaper path. [Can't understand why they do that.]

    We'll see what the next build brings and go from there.

    Thursday, January 11, 2018 10:29 PM

    Chủ Đề