The Deployment Guys

Helping to deploy your world automagically...

Configuring Default User Settings – Full Update for Windows 7 and Windows Server 2008 R2

Configuring Default User Settings – Full Update for Windows 7 and Windows Server 2008 R2

  • Comments 53
  • Likes

I have written several posts on this topic before.  However, changes were made to Windows 7 and Windows Server 2008 R2 that warrant a full revisit of this topic.

This post can can also be also be found on the Windows Springboard Series blog here.

Anyone who had been doing operating system deployments long enough has had to deal with configuring default settings for users that log on to the computer after the image is deployed. Some examples of these are folder settings, desktop wallpaper, and screen saver options. Most of these will be initial settings for user preferences that users will be able to change (unlike policies which are enforced). This is done so that users will have a consistent, known experience when logging on to any client computer for the first time.

This can be done in a number of ways.  Below are the methods I have seen or used with what I feel are pros and cons of each.

Implementing Default User Settings by modifying the Default User Profile

There are three main methods that have been used to configure the Default User profile.  Only one method (B) is now officially supported and I recommend that you use this method.

A. Manual or scripted copy of a configured profile over the Default User profile (unsupported)

The traditional solution for this (developed during the Windows NT Workstation days) was to configure the Administrator account (or another designated account) with the settings, then copy the Administrator (or designated account) user profile over the Default User profile.  This was previously documented in numerous Knowledge Base articles (which have now been deleted).  A tool called CopyProfile was even created to script this process during unattended installations of Windows XP.


However, there are problems with using this procedure.  It is very old procedure from NT4, when the shell was much simpler.  The shell is more complicated for Windows 2000 and higher.  This process will copy settings that should not be copied to the default user profile.  It may seem to work but you will find subtle problems.  Windows XP and later have made those subtle problems more visible.


Also, the Default User profile contains some single run actions that occur when the user logs in for the first time, which then setup that user by running those custom actions.  If you overwrite the Default User profile, those single run actions do not take place.

The manual profile copy process can cause issues such as:

  • Their list of most frequently run programs is not cleared
  • Whether the user has been introduced to the Start menu (will be set to TRUE for the source account, but should be FALSE for new users). Windows Explorer does some special things the first time you log on to introduce you to the Start menu and other new features.
  • Whether the user is an administrator (and should therefore see the Administrative Tools, etc).
  • The personalized name for “My Documents” will be incorrect. All users documents folders will be called “Administrator's Documents”.  This is documented in the Knowledge Base article “The Desktop.ini File Does Not Work Correctly When You Create a Custom Default Profile” (
  • The default download directory for IE will be set to the Administrator's Desktop folder.
  • The default Save and Open locations for some application with point to the Administrator's documents folder.
  • Windows 7 Libraries are broken.

Because of these issues, this process is no longer supported in Windows XP and all later operating systems.  Unfortunately, the ability to copy a profile over the Default User profile was not blocked in Windows XP, Windows Server 2003, Windows Vista, or Windows Server 2008.  This allowed many administrators to continue using the process and putting their Windows installations into an unsupported state.  To prevent this, Windows 7 and Windows Server 2008 R2 now block this scenario by having the Control Panel System applet gray out the option to overwrite the Default User profile.

At this time the only supported way to configure the the Default User profile using a copy of a configured profile is to use the next method described here, the automated profile copy associated with using Sysprep.

B. Automated profile copy with Sysprep (supported)

First introduced in Windows XP Service Pack 2 (, Minisetup was modified so that it will copy customizations from the local administrator account to the default user profile.  All subsequent versions of Windows will also do this with the proper entries in the answer file.  This process was designed to avoid the problems with method A and is already automated. 

I won’t dwell on how the automated profile copy is used since it is documented in several Knowledge Base articles:

How to customize the default local user profile when you prepare an image of Windows Vista, Windows Server 2008, Windows XP, or Windows Server 2003

How to customize default user profiles in Windows 7

However this process does have a drawback.  It does not propagate all settings to Default User and there is no known documentation as to what will and will not be propagated.  It also can be difficult to determine if a setting did not carry over to a new user because it was considered inappropriate (i.e. not copied to Default User by design) or is being reset by Minisetup/Specialize or first logon processes.

One final important point to remember is the difference in behavior between Windows XP/Windows Server 2003 and Windows Vista and higher with respect to when the answer file setting must be present for the automated profile copy to occur.  On Windows XP and Windows Server 2003, if you want to change the behavior of the automated profile copy, the UpdateServerProfileDirectory entry must be present in Sysprep.inf when Sysprep is run.  This is because the profile copy happens when Sysprep is run on Windows XP and Windows Server 2003.  The exact opposite is true for Windows Vista and higher.  The CopyProfile setting must be set to True in the final answer file that is present when the OS restarts after Sysprep (Specialize phase) or the answer file used when Setup is used to deploy the custom image.  This setting does not necessarily have to be present in the answer file used during the image build when Sysprep is run (Generalize phase).  This is because the profile copy for Windows Vista and higher happens only during the Specialize phase.  So if you are using a deployment tool like ConfigMgr or MDT that may modify/replace the Unattend.xml, make sure that CopyProfile is configured in the answer file used for deployment.

C. Targeted changes to the Default User Registry hive and profile folders

I used to use this method in the before the automated profile copy existed.  I can be useful when only a small number of targeted changes are required.  It can be described as follows:

1. Identify the needed Registry changes.  Then use a tool like Reg.exe or KiXtart to load the Default User hive into a temporary location into the Registry, write only the needed settings, and then unload the hive.  The Knowledge Base article “How to run a logon script one time when a new user logs on” ( shows how to do this manually.  This can be scripted for an unattended installation using Reg.exe as shown in this example (these lines may wrap due to page width):

:: ***** Configure Default User
:: *** Load Default User hive
reg load "hku\Test" "%USERPROFILE%\..\Default User\NTUSER.DAT"
:: *** Disable Desktop Cleanup
reg add "hku\Test\Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\CleanupWiz" /v NoRun /t REG_DWORD /d 1 /f
:: *** Unload Default User hive
reg unload "hku\Test"

2. Copy only needed files or shortcuts to the Default User profile folder.

This has the advantage that all changes to Default User are known and predictable.  However, this requires that all changes be reduced to “scriptable” items (i.e. Registry or file system changes, no manual configuration). 

To get this method to work properly on various service pack versions of Windows XP or Windows Server 2003 you have to disable the automated profile copy.  In some cases you have to either install the hotfix from this KB article: or set UpdateServerProfileDirectory=0 in Sysprep.inf.  Which service packs versions have the automated profile copy enabled by default are documented in KB959753.  In Windows Vista and higher the automated profile copy is disabled by default.  You would then do the Default User hive registry edits before Sysprep runs.

This method can also be used to make changes to the Default User profile for machines that are already deployed in production.

You should exercise caution using this method.  Try to keep all changes limited to only the individual Registry or file system changes needed for a particular desired result (e.g., a Windows or application setting).  Do not do wholesale export and import of Registry keys or folder trees.  This can potentially lead to the same problems as a manual profile copy.  You can use a tool like Sysinternals Process Monitor to identify the individual changes.

Implementing Default User Settings by Using Scripts or Group Policy

The following methods are not for configuring the Default user Profile directly.  However, they can be used to achieve the same effect (configuring settings the first time a new user logs on).  And they have the added advantage of potentially being centrally managed.

D. Local logon script in the RunOnce Registry key

This is documented in “How to run a logon script one time when a new user logs on” (  This manual process can be scripted with reg.exe.

There are several advantages to using a script in the default user RunOnce key.  It completely avoids Sysprep, CopyProfile, Minisetup/Specialize, or first logon processes effects.  Also, if after deployment the default initial user settings need to changed, only the script file needs to be updated (instead of having to script a load/unload of the default user hive and fixing multiple settings).   Finally, it is easy to “reset” a user’s setting to the defaults because the script can be kept up to date and present on every box through software distribution or Computer Startup Scripts.  This method also requires that all changes be reduced to “scriptable” items.

E. Local or Domain GPO logon script

A Group Policy logon script can be used to set “default settings” once by having the script set a flag after it first runs (perhaps an HKCU Registry entry) that it will look for and exit if found on subsequent runs.  A Domain logon script has the added benefit of being centrally managed.  This method also has the same advantages as method D.  This method also requires that all changes be reduced to “scriptable” items.

F. Group Policy Preferences

Group Policy preferences first shipped as part of the Group Policy Management Console (GPMC) in Windows Server 2008.  GP preferences consist of more than 20 Group Policy extensions that expand the range of configurable settings within a Group Policy object (GPO). Many of these extensions can configure settings that are commonly configured as default settings in a desktop image. Unlike policies, GP preferences can be changed by the user in most cases. Also, GP preferences can be configured to “apply once and do not reapply”. This allows them to behave exactly like initial default settings configured in an image but has the benefit of being centrally managed and updated.

GP preferences cover many of the areas where default settings are usually configured such as:

  • Environment Variables
  • Files
  • Folders
  • INI File Settings
  • Registry
  • Shortcuts
  • ODBC Data Sources
  • Folder Options
  • Internet Settings
  • Local Users and Groups
  • Network Options
  • Power Options
  • Regional Options
  • Scheduled Tasks
  • Start Menu

The main disadvantages GP preferences are that it requires either Windows Server 2008, Windows Server 2008 R2, the Remote Server Administration Tools (RSAT) update for Windows Vista with Service Pack 1 or higher, or the RSAT update for Windows 7 to manage them and client-side extensions (CSEs) have to be installed for Windows Vista RTM, Windows XP with Service Pack 2, and Windows Server 2003 with Service Pack 1 or higher.  For those still managing Windows 2000 images, you will have to use one of the previous methods mentioned since GP preferences will not work on Windows 2000.

I believe that GP preferences will likely be the best way to manage this going forward. Simply create GPOs using GP preferences, target them as needed, install the CSEs into the image(s) as needed, and you no longer need to worry about configuring these settings in the client image(s).

For information about Group Policy preferences see the following web resources:

Group Policy Preferences Overview

Group Policy Preferences Frequently Asked Questions (FAQ)

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo a Senior Consultant with Microsoft Services, U.S. East Region.

  • Is there anyway to use <CopyProfile> without generalizing the image? We're currently using the standard WIM and don't actually create a unique image but rather customize around the standard WIM.

  • John,

    Just about the only thing you could try in this case is to mount install.wim, modify the Default User profile using method C, and then unmount/commit the changes.

    Michael Murgolo

  • Michael,

    For years in XP/2003 I handled the Default User profiles by performing scripted (unattend.txt) installations. I applied standard registry files (HKCU/HKLM) during the T-12 (cmdlines.txt) stage. Creating these registry files was easy using tools like regmon and regshot on development systems. I had about 60 small reg files that I recursively applied from a folder in the $oem$ directory using regedit /s.

    This cmdlines.txt method worked wonderfully for me. This method is extremely easy to maintain. It was much easier than having to script a hundred registry entries using reg.exe pointing to temporarly mounted Default User hive.

    Is there any similar method available to me in Windows 7/Vista that maybe is not well known?

  • Dan,

    When building a custom image, there is no reason you cannot use .reg file instead of reg.exe command.  I like using reg.exe because each operation is atomic and loggable and reg.exe gives better information on errors.

    If you are using the automated profile copy, simply apply the .reg files as you have been, but do it in the full OS when logged on as the built-in Administrator.

    If you do not want to use the profile copy and want to use method C, then place your regedit commands between the "reg load" and "reg unload" and change the path in the .reg files to point to the loaded Default User hive.

    There is really nothing equivalent to XP unattended setup in Vista and higher.  Setup for Vista and higher applies a WIM with an already "installed" OS and then modifies it based on setup options selected.

    Michael Murgolo

  • For windows 7, add a new problem with themes.   If you copy over the default user, the background and theme reverts to black.  You have to do a runonce hack and have it run c:\windows\themes\aero.theme (or whatever theme) at user's first login.

  • If there was ever the need for a tool that allowed us to 'create' a default user profile from a template.....

    When will microsoft produce a set of tools that allow is to manage the user profiles more simply?

    Youre right about one thing. The shell is a lot more complex now. And the plumbing is a mess, frankly. Trying to manage them through registry hacks is *so* labourious

    If Microsoft insist that they know best for us, and they know the do's and dont's, then give us a set of tools that takes the effort out of it for end users and make it less of an onerous, laborious and error pone task.

    How about it guys?

  • Sysprep /generalise is not a solution to this.

    I can see that it benefits microsoft in that it reduces you support calls, possibly

    But its not a solution that benefits customers in any way.

    I'm not prepared to generalise every machine in my organisation when i want to make a change to the defaul profile.

  • I don't think anyone from Microsoft will ever read these comments but here goes.

    Using the copyto function in XP does not carry the user permissions or name to the user profile. Therefore the "A" method is not correct. I have done this method from windows 2000 and it works fine, that's why the copyto was created.

    I guess we are just users and Microsoft can do as they like, but we are the ones who have to distribute to 2000+ student machines.

    If you are taking away a known feature of deployment give us the real reason, was it too hard, did you forget, is there no enough competition?

    With every new version it just gets harder, and my users pay my salary not Microsoft.

  • jaydee - I agree that we could provide better tools for doing this.  We realize that the profile copy associated with Syprep is convenient for image build/deployment.  And that it’s not so convenient for updating deployed machines or creating a network profile.  Being in our Consulting organization, I am constantly pushing our product teams to make improvements and provide better tools precisely because I work with our customers to accomplish many of the same things that you are.  However, whether a tool or improvement gets made or not depends on a lot of factors including development resources, priority, customer impact, testing required, etc.

    Chris - Someone from Microsoft (other than me) will read these comments.  I was actually asked to do this update by several people in our Support and Windows organizations.  The will be looking at the feedback and factor it into their decision making about current and future product and tools.

    Michael Murgolo

  • Nothing is said as far as 08 R1/R2 (RDS) is concerned. Why?

    Aside that, what is this obsession with "Default User"? Even in my client/server engagements that thoght was far off. With RDS, however, there is an another picture. See, the Windows fandango is just the supporting engine (JEOS) to deliver applications.

    To be in a supported state, am I, in the knowing, supposed to be leveled down by the lowest determinator? This is no way good information. This sucks hairy legs of the leftover bones of "thanksgiving".

  • I've used method A for several years with Win 2k and Win XP (skipped Vista altogether) with excellent results. So far, with win 7, I've spent hours and hours reading about it and only read complaints on how microsoft  left us all in dark. The windows 7 commercials cleraly state that microsoft LISTENED. My question is, to whom? Not to us, who have to deploy images to hundreds/thousands of users.

    I absolutely agree with  Chris Thomas.

    Microsoft, please READ and LISTEN!

  • So Microsoft admits that Automated profile copy with Sysprep (supported) "does not propagate all settings to Default User and there is no known documentation as to what will and will not be propagated."

    My question is, when will this documentaion be available to the masses so we can stop spinning our wheels modifying settings for the default user profile that "was considered inappropriate  (i.e. not copied to Default User by design)"

    In my opinion the primary benifit of Microsoft operating systems has always been it's open and highly customizable nature. When Microsoft starts considering customaizations innappropriate we may as well be running on a Mac.

    Additionally I agree with the others that generalizing the image to modify the default user profile is a poor solution.

  • Echoing the comment above, I've also used method A for years. I just started working with WIndows 7 and have spent hours likewise reading nothing but complaints. The lack of a workable method for configuring the default user profile is a deal breaker for me  I hope that Microsoft will correct this error but no Windows 7 until then.

  • same thing for me. this is a deal breaker. I can find no supportable way to set program preferences for many non microsoft products.

    microsoft - wake up.

  • With regards to method "A"...Why no create a local user with the same permissions as your default user in the field then customize that profile and copyto default user profile?

    Wouldnt this be simplier and alleviate the problem of local admin attributes being duplicated for all users?