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.
Tom,
Unfortunately, that will not help. The issues will occur when manually copying any user profile over default user. These profiles have already been "personalized" for that user
Michael Murgolo
We even used "A" method during years. The "B" method (sysprep) make us loose a lot of time during sysprep process for each PC we build with Win 7 comparing to XP (if we choose Win 7).
Why Microsoft didn't provide a new tool as CopyProfile with all the problems corrected that the same thing as sysprep. I hope it will come soon.
Why Microsoft do not imagine how our work is now so difficult to build unattend installation since Vista in enterprises !!!
Denis.
Denis,
Even if we provided a CopyProfile tool for Windows Vista and higher, it does not mean you can clone Windows without using Sysprep. If you do, you are creating unsupported installations of Windows. Yes the Specialize process in Windows Vista and higher is somehat longer than Mini-Setup in Windows XP. However, if you have an automated deployment process and deploy during off hours that extra time impacts no one.
Can someone from the "Deployment Guys" create a video or document that talks about creating the Default User when using MDT 2010 in conjunction with SCCM 2007 SP2? It would be a great help to all of us.
I have about 3500 computers to manage and setting them up with a default profile helps keeping them the same. Windows 7 has made it very hard to set up a standard. Without a standard default the users have to log on and answer all the first launch questions. Not only does Microsoft subject us to these questions but also a lot of other software suppliers require you to answer questions on first launch. Since we are a school our profiles are not retained on the computer. We use Deep Freeze to clear anything that was done on a computer with a restart. Every time a user logs on they have to answer all the questions again. Once set up in a default profile these set up questions can be answered once and never have to be answer again. I set up 30 Apple computers this summer and they have the ability to manage the default settings remotely. Microsoft needs to make this available also or even set up a default login so it can be configured and then all other users attach to that modified default profile. I like Windows 7 but DO NOT LIKE not being able to modify the default profile. One side note, I have not found an easy way to have a default local shared printer installed for a user without copying the default profile. We have about 1000 different printers for different classroom and coming up with a way to have these printers be the default printer for all uses is not possible without copying the default profile.
Microsoft please listen to the people complaining about this problem. If you do not come up with a way to easily modify deployment of Windows 7 will suffer. This problem could be used against Microsoft with negative publicity.
An example of how to setup 1000 printers for users to attach to. Use Group Policy Preferences with item level targeting to have a default printer applied to user. Since the computers don't move around as much as people do, I would probably apply based on computer and create new AD Groups for each printer in you organization, and add the location to the description. That's 1000 new AD printer groups. Then add to each printer AD group the computers that you want to default to that printer. Now go into GPMC (Group Policy Management Console) running on a Windows 7 box, you will create one group policy with all of the printers and have this applied at the top of your AD, or you could set one per OU. This is all dependent on how you AD is organized. Go into Computer Configuration, Preferences, Control Panel Settings, Printers, right-click - select New TCP/IP Printer, select Action 'Replace', then add all of the printer information that you should already have in your environment in the 'General' tab as well as the 'Port Settings' tab, now for the good stuff...Select the 'Common' tab, check the box "Item-level targeting" then click on 'Targeting' button, now select the 'New Item', then 'Security Group', nwo choose the AD group that you created earlier for this printer. Test this, then add more printers...
I couldn't agree more with what Warren said. I manage about 900 lab and classroom computers for a University. We also use Deep Freeze to restore the state of the systems on each reboot. More often than not, our students just want to log on quickly and check something online or print out a paper. The last thing they want to have to do each time is choose their preferred Internet Explorer settings or be introduced to the Start menu. Also our instructors depend on us to configure the programs they use to teach their classes in specific ways on each computer. They can't take 10 minutes of every class to once again configure whatever program they are using. Eliminating these first use configuration settings for new users is a huge part of the reason why the copy profile option is so important to those of us who manage computer labs. We have learned how to delete recent documents and redirect the default download locations before copying the profile. (or to configure this through group policy) I can't even begin to express how much I do not want to have to figure out how to manually alter the first run behavior for new users for over 100 third party applications just so we can move to Windows 7. Please, please come up with some sort of viable solution for computer lab managers, Microsoft.
I use, and will continue to use method A.
Until Microsoft provides me a user profile customizer or more fine-grained group policies I'm afraid I, nor many of my peers, can follow your advice.
Make it for Windows 7. Say it's an awesome feature and reason to upgrade to Windows 7. I'm shocked about reading this backstep in ability for Windows 7. Suddenly Windows XP doesn't look so old.
Why can't Microsoft resolve the few issues of overwriting the default user profile instead of making thousands of admins jump through hundreds of hoops each, just to fix the giant mess of a default profile with many annoying obstructions to end-user productivity?
It seems to me that we are paying the salary of the developers by our purchases of Windows licenses.
A solution to this issue should be “front burner” with the deployment folks.
No wonder people want to vote with their feet, or delay or defeat the deployment.
Murgolom. I just wanted to say, reference to your statement "whether a tool or improvement gets made or not depends on a lot of factors including development resources, priority, customer impact, testing required, etc..."
This might seem a bit off topic but i really dont understand why or why development resources are thrown into something like the "Active Directory Administrative Console" and no development resources are available for a toolset for user profile management.
Theres nothing in ADAC that you cant already do through the regular ADMINPAK or RSAT tools.
I'm not attacking you, of course, Murgolom. I know you dont make these decisions. But it underscores the lack of credibility to microsofts priorities as you stated them -"development resources, priority, customer impact, testing required...".
The world doesnt need a 'tarted up' version of dsa.msc. However it BADLY needs a set of tools for user profile management. Because right now we have nothing.
jaydee,
I don't claim to know the inner working of the Windows product group. However, just because you may not need the Active Directory Administrative Console or some other Windows feature does not mean that this was not a requested feature or something developed to address additional customer scenarios, use cases, supportability issues, etc. One man's trash is another man's treasure. :-)
I understand your frustration that we have hard blocked an old method that is no longer supported, but I would submit that you do not have "nothing".
I spend nearly all of my time assisting our customer with deployment of Windows. Part of that includes automated image builds with customized Default User profiles. I use the Microsoft Deployment Toolkit to automate the process, script all custom user settings, and use the method B above to propgate these setting to Default User. I have used this process with great success with some of our largest enterprise customers.
This method does require some up front engineering but once done has many benfits. These include repeatability, consistancy ,easy of deployment, etc. Please give this a try before simply writing it off.
For already deployed machines, method C could be used to modify the Default User profile in conjuction with Computer Startup Scripts or a software distribution tool like System Center Configuration Manager.
Finally, consider moving to more centally managed methods of controlling user settings like Group Policy Prefernces. This can help you get out of the business of managing the local Default User profile altogether for domain-joined machines.
I have to say for those asking for a solution if MS was truely interested in desktop deployment we would not have MDT for a start.
Michael, of course we do every single one of those things. WDS, MDT, WAIK, GPO's GPP's registry scripts hacks and tweaks.... I dont want to create the impression that we're technologically inept!
You're oversimplyfying. Deloyments are easy - everything nice and shiny and new. But things dont stay that way, and managing lifecycles is a bit more difficult than you make out
I dont want to go into specifics here, but you know theres a big difference between saying you can script 'everything' and the work involved in actually doing it, maintaining such things and ensuring uniformity consitency, and checking if things get run in the same way if we're onsite or of site on a VPN, etc...
User profiles are a huge challenge. Nobody should underestimate the problems that come from them even when they are properly managed. Look at some of the comments from people - mainly working in education or another niche areas. I dont think you can argue against the points they are making. They really are crying out for a better way to manage profiles generally on an ongoing basis without resorting to generalising, imaging, hacking, or otherwise getting bogged down by something that could so easily be managed through 'templates' and decent toolset to apply them - preferably one that doesnt involves generalising a machine to do it.
Anyway - you work for Consulting, so you totally I KNOW you know what I'm saying. You said as much in an earlier post.
This is WAY more difficult than it ought to be.
I was not implying that you or anyone else is technologically inept. I was simply pointing out that perhaps you were oversimplifying by claiming to have "nothing" at your disposal to manage profiles. They may not be perfect and they may not work they way they did in the past but you can certainly be successful when using them.
Also, I don't believe I said that deployments were "easy". I state that this will require up front engineering. The customers that I work with that are most successful with managing the user experince in the long run are those that commit to doing this type of engineeing effort. Once they develop the processes for achieving this level of automation, they find that their costs for changing and maintaining it in the future are actually less than before they undertook the effort.
These customers find themselves higher along the road to an optimized intrastructure in the desktop space after such an effort. (http://www.microsoft.com/infrastructure/about/default.aspx).
Mike,
The overwhelming consensus for the forums i'm reading is that there are a heck of a lot of peolpe who disagree with Microsofts idea of user profile management - myself included - and all for reasons that I totally understand
Some admins may just want to log on as a template user, load their profile, make it look right from the 'inside', log off, and then apply it. Whether that be applying it to the default user profile, or as the basis for a mandatory or roaming profile, or for some other purpose. That method has a kind of immediacy thats difficult to achieve through other means.
I hear a lots of people saying the same thing. They dont want to recreate something that they could do visually in 10 minutes, with a bunch of stuff that will take them considerably longer.
I dont see how adopting such an approach takes those people away from the optimised infrastructure you mention. The end result is be the same. They get the user profiles configured the way they want. One way is easier for the customer, one way is harder. Harder in this case doesnt really mean better.
Of course, it does require that MS write some better tool to facilitate that, and that brings us back to your point about development resources. And for that to happen MS have to think its a whorthwile and useful endeavour.
But its looking to me like I'm flogging a dead horse by pressing this point. MS it seems have already decreed whats best for us. I know when I'm beaten.
But I hope that MS continues to read the feedback in its own forums and keep a much more open mind on this subject than it appears its doing right now.