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.
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.
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:
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.
First introduced in Windows XP Service Pack 2 (http://support.microsoft.com/?id=887816), 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 http://support.microsoft.com/?id=959753 How to customize default user profiles in Windows 7 http://support.microsoft.com/?id=973289
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 http://support.microsoft.com/?id=959753
How to customize default user profiles in Windows 7 http://support.microsoft.com/?id=973289
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.
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” (http://support.microsoft.com/?id=284193) 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: http://support.microsoft.com/?kbid=887816 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.
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.
This is documented in “How to run a logon script one time when a new user logs on” (http://support.microsoft.com/?id=284193). 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.
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.
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:
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
http://www.microsoft.com/downloads/details.aspx?FamilyID=42e30e3f-6f01-4610-9d6e-f6e0fb7a0790
Group Policy Preferences Frequently Asked Questions (FAQ)
http://technet.microsoft.com/en-us/windowsserver/grouppolicy/cc817590.aspx
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.
Hi Mike,
Let me start with some <hugs> for you! :) The first two paragraphs of your Jan 28th post are superb. It's really good to know to what extent you can reply to comments. This removes a whole lot of frustration from posters and creates patients and understanding. May this attiude spread throughout MS and I crown you the Ghostcrawler of MS (this is a genuine compliment if soomewhat stange on the face of it. I leave yout o find out why :) )
So....just a couple of responses...
"I was constantly visiting desktops repeatedly for many tasks" - This is something I don;t do. I understand it was what helped to inspire you and therefore is personal to you and your not necessarily saying this is the general answer to our posts. However, I do know scriptiing to a point and I do know it is easy to create templates and reuse old code, but this has gone a bit off topic really. Even once configured, Sysprep still takes ~10 minutes longer to perform its task than the original method - this is the crux of the problem, oh and the learning time required to setup Sysprep in the first place if you are not yet a scripter. Scritping has its place, but I doubt it's really necessary in building profiles to the deploy using automated scripts/sever apps.
"repeatedly performing manual operations on them, then automation WILL in the long run save you time and money." - I agree, and we do as much as we can using automation techniques (not always script based...there are some nice UI tools out there that take a miniscule amount of time compared to the scripting equivalent). However there is a hell of a lot you cannot do with scripts. 99% of all third party applications and utilities cannot be manipulated by script and even if you could, it is very unlikely you'd ever find out the full process that an application makes when changes are made (modification to files, reg keys, databases, connections, etc, etc).
Scripting is good for manipulating specific things built into windows. Unfortunately profiles massively bridge the gap between windows and third party apps. It is neither soley managing the athetics and operation of windows, nor is it soley managing the athetics and operation of third party apps. Scripts won't work here in developing a default (standard) profile. All changes related to third party apps have to be done manually. If you're someone like me who has a lot of base images to distribute to 100's/1000's of PC's, you want this manual portion of your job to consume as little time as possible. Syspreping a base image only increases that time when the previous tool worked without fail (for me 5 years so far) as long as you followed some simple rules. 1) Only us the User profile tool to delete or copy profiles 2) In all cases where you can, use an application itself to make the necessary changes (i.e. run app, make changes to the way the application functions, close app) to the profile you are using that will later be copied to the default. If at all possible, do not manually edit the files/regkeys in this profile unless it is a matter of life and death...IT wise! :P
I swear if MS followed the above method of support for the profile copy tool, all would be wonderful and life would be good again. If somebody moaned about the tool and you simply asked, "did you do any copy/editing of the profile that didn't use the tool or an actual application?" 99% of the time they'd reply, "yeah I did" and you'd just say "don't then" and copy in the related KB article which says "do this and don;t do this".
What actually drives me on this crusade is that no one has actually managed to put in a response saying....oh btw, the tool was great, but sysprep is better. Giving concise examples and how to recreate such improvements. This leads me to fear they don't exist and all profile copying in sysprep does is waste time (money to your managers when you arguing against Win 7 implementation)
Ug, I'm beginning to rant again. Time stop :P But seriously Mike, huge thumbs up from that last post...some of your coleagues on official support and technical forums could learn bucket loads from that one post (and findong out who Ghostcrawler and colleagues are) :)
BTW - Sorry for spelling, writing this in a rush without speel chek! (don't fall for it!)
Cheers,
Matt
As I see this discussion is going nowhere, then what about getting a default profile via Group Policy.
I am looking for adm templates that lock down the start menu/desktop/taskbar and allow me to customize what I want to appear/not appear in the start menu and taskbar for the default user.
Does Microsoft have a repository of adm templates to accomplish the same thing as a default profile? Could Microsoft at least tell us which registry entries define the start menu and taskbar.
How can I customize a default profile via group policy for laptops? "Run Once" settings, perhaps?
@Daniel,
I am NOT going to introduce Vista to my users. I prefer to have no more than two Microsoft operating systems to support at the same time. I have XP users and a couple of 7 users. That is enough.
3rd party tools may conflict with Group Policy settings. What 3rd party alternatives to Windows Steady State are schools using? I have heard of Deep Freeze, but are there any others?
I am looking forward to Microsoft to address my concerns in my February 1st post.
@James,
Microsoft (nor we) can recommend any 3rd party alternatives for SteadyState, and this is also not the forum to discuss it.
With regards to your Feb 1 post (which you posted only 24 hours ago by the way), you should bear in mind that we run this blog in our spare time, outside of work hours and when we are not on site with customers. As such, any replies to comments on one of our blog posts by us can take a while to be responded to, and we don't respond to all of them (there are just far too many).
If you have key specific issues that need addressing urgently, you should consider contacting your local Microsoft representative who may be able to help you quicker.
Any ADM templates that Microsoft has, are published on the website, we have no hidden repository that we could provide to you. If an ADM file does not cover everything you need, remember that you could always create your own, which is not too complicated a task but would provide a perfect fit for modifying the registry keys you need.
The best way (in my opinion) to personalise the initial user configuration on Windows is to use the very steps detailed by Mike in this post (and also his earlier posts on this subject). Mike has worked on this topic for way too many years, and this post is the fruit of his work and experience. I doubt you will find a better way to do it.
Finally, remember that from Windows Vista onwards you can also use "Group Policy Preferences" as well as GPOs to configure the user experience.
Daniel
Daniel,
Thanks for the update. Sorry, I did now know that this website was an unpaid, fun project. I was under the false impression that Microsoft was paying you.
To bypass the whole argument about copying a profile to the default user, I would like to customize all of the default desktop settings via GPO. All my questions are centered around this goal.
I would like to make my own custom .adm templates to import into my GPO, but in order to do that, I need to know the Windows 7 registry entries for the start menu, desktop, and taskbar. Would anyone know where in regedit these settings reside? How would I find out?
Thanks again for your help. No rush, though.
Just bring back the ability to set up the 'local default user profile', by the simple 'copy to' method.
WE CAN'T DO OUR JOBS WITHOUT THIS FUNCTION, and anything i can offer using windows 7, is by comparison to XP a REALLY REALLY BAD JOB.
JUST FIX IT !!
From the section regarding Automated profile copy with Sysprep (supported) "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."
Quite frankly, this is unacceptable for an enterprise environment. What I need for my company is a method of modifying default user profiles both during image creation and after deployment that will provide consistent results.
Gary,
I agree that this should be documented. However, that does not mean that the results are inconsistent. It means that you have to test first to see if the process results in your settings are propagated or preserved. You may not be able to predict which settings work this way but it will happen consistently every time.
Yes, this does mean additional testing during the image build. And some settings may have to be implemented using methods D, E, or F. But I have not found it to be a major impediment to using this process.
Michael Murgolo