Freigeben über

Customizing Default users profile using CopyProfile

  • Artikel

Today’s blog is going to cover some issues around customizing default user profiles when deploying Windows. There are a number of resources available on the CopyProfile topic

  • 973289 How to customize the default local user profile for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2
  • The blog on the Deployment Guys website does a good job of describing the issues around the changes with this functionality.

I wanted to let add some additional points around this topic to help with your deployments:

  • The Copy Profile button in control panel, system, advanced system settings, Advanced, User Profiles, Settings, is greyed out on accounts to address issues found in the Shell when using this legacy method from NT4 days to overwrite the Default user profile so although this process appeared to work there were issues in Windows that were traced back to this process. Although not blocked in previous operating systems it was considered unsupported and was one of the reasons SP2 was modified to copy the administrator account customizations automatically instead of using the manual method of overwriting the default user profile
  • Microsoft-Windows-Shell-Setup\CopyProfile setting in unattend.xml is the only supported method for customizing default user
  • With this change not all customizations persist even when using CopyProfile
  • Since there are so many settings in the Shell we do not have a list of what persists and what is reset.
  • In order to determine what will persist we recommend testing of your specific scenario and the settings you are configuring
  • When a new user logs in many different components in Windows must execute some first run actions to prepare the user account. These first run actions can sometimes reset the customizations that were set prior to running sysprep
  • For those settings that do not persist you can check group policy to see if there is setting to control it. The Group Policy Settings Reference is a good place to look. There are some also some specific group policies for Start Menu and TaskBar here
  • If the CopyProfile process does not copy the setting then ultimately you must find some other method to configure the setting.
  • Many of the settings that are lost are related to the Start Menu and the Taskbar
    • At times Microsoft Customer Service and Support (CSS)is asked if there is a way to script changes to these but as this blog outlines there is limited programmatic access to them. Additional CSS does not help with authoring scripts.
    • There are supported methods for adding additional icons using steps outlined in this blog but it is difficult to remove icons without some type of custom scripting
  • The CopyProfile code copies the profile based on modified time.
    • If you have multiple accounts on the computer it is possible that some account other than the one that was customized may be copied. So to ensure that the customizations are copied from the correct account we recommend that the computer only have the local administrator account and customizations be configured in this account
    • You cannot use a domain account either because the CopyProfile process occurs later in the specialize phase and by then Sysprep has unjoined the machine from the domain and the profile is deleted
    • To check to see if the CopyProfile worked and what account it copied you can review the Windows\Panther\UnattendGC\Setupact.log and search for CopyProfile
    • For more information on this see the following KB article: https://support.microsoft.com/kb/2101557
  • Use of CopyProfile in reference build
    • When installing the OS initially do not specify CopyProfile=true in the autounattend.xml. Used during reference build can problems with themes, Aero, and other unknown issues
    • It should only be specified in the answer file you supply to sysprep.exe when creating a custom image
  • Use of CopyProfile with ConfigMgr
    • Since ConfigMgr runs in the system context when building an image it is not possible to use it to copy customizations to default user
    • One option is to use Microsoft Deployment Toolkit 2010 to build your reference image and then deploy that image with ConfigMgr
  • Use of CopyProfile with Terminal Servers
    • We would recommend using group policy to lock down or configure desktops vs using CopyProfile to configure user profiles.

How you use CopyProfile depends on how the image is created and how it is deployed. Some of the common scenarios are listed below

Manual build of image (not recommended)

If you are building the image manually you should follow these basic steps

  1. Install Windows. Note: Do not specify CopyProfile in unattend.xml
  2. Login as administrator. Note: Make sure other accounts do not exist
  3. Customize your settings
  4. Create c:\windows\system32\sysprep\unattend.xml that contains at minimum the entry for Microsoft-Windows-Shell-Setup\CopyProfile and set it to true. Sysprep by default looks for unattend.xml in the sysprep folder
  5. Run %windir%\system32\sysprep\sysprep.exe /generalize /oobe /shutdown

If you use ConfigMgr to deploy this image you do not need to do anything special in ConfigMgr to deploy it to get CopyProfile to work. So you do not need to modify any unattend settings in the task sequence

Use MDT 2010 to build the image and to deploy the image

Note: I would recommend that if you are using MDT 2010 to upgrade to MDT 2010 Update 1 because there have been a number of fixes in the sysprep and capture task sequence. You must always re-created your sysprep and capture task sequence after installing update 1 in order to get these fixes.

Because MDT runs setup.exe to apply an image (instead of just using imagex to apply it) the following outlines the steps required

  1. In MDT 2010 Update 1 create a task sequence "Deploy Windows" to install Windows

  2. In MDT 2010 Update 1 create a task sequence based on the Sysprep and Capture Task. For more information on this see this blog

  3. Boot the Lite Touch image and choose the "Deploy Windows" Task Sequence. If prompted by lite touch wizard say NO to prompt to capture image

  4. After Windows is installed and you login as administrator make the changes to the shell you desire. Note: Microsoft would generally recommend that changes to the profile be done via automated fashion and not manually. See https://blogs.technet.com/b/deploymentguys/archive/2009/10/29/configuring-default-user-settings-full-update-for-windows-7-and-windows-server-2008-r2.aspx for more information.

  5. Map network drive to the MDT 2010 Update 1 DeploymentShare$.

  6. Run Scripts\Litetouch.wsf

  7. Run the Sysprep and capture task sequence. Note if you may run into issue with multiple connections you are likely still running MDT 2010. See this blog. This issue is resolved in MDT 2010 Update 1

  8. Import the captured image from DeploymentShare$\captures\image.wim.

  9. Create a task sequence "Deploy customized Windows image" to deploy the custom image you just imported

  10. In properties of the task sequence choose OS info tab

  11. Click edit unattend.xml

  12. Modify Microsoft-Windows-Shell-Setup under the Specialize phase and change CopyProfile to true

    image

  13. Click File, exit, and save changes

  14. Boot lite touch image and choose the "Deploy customized Windows image" task sequence

  15. To test create a new user and login as the user. Look for the changes you made. Note not all changes are carried over in this process. If a setting is not carried over you must find alternative means to make the change. Use group policy, scripts, or other means

Note: If you use MDT 2010 to capture the image it does not capture the Windows\Panther folder so if you were to deploy it manually using imagex, WDS, or some other manner then CopyProfile would not execute. It would be better to manually capture the image using imagex if you are not going to deploy it with MDT

Use MDT 2010 to build the image and capture it then use ConfigMgr to deploy the image

  1. Follow steps 1-7 above to create and capture your image

  2. Create a CopyProfile.xml in Windows System Image Manger that contains at least the following

    <?xml version="1.0" encoding="utf-8"?>
    <unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="specialize">
    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="<a href="https://schemas.microsoft.com/WMIConfig/2002/State"">https://schemas.microsoft.com/WMIConfig/2002/State"</a> xmlns:xsi="<a href="https://www.w3.org/2001/XMLSchema-instance"">https://www.w3.org/2001/XMLSchema-instance"</a>>
    <CopyProfile>true</CopyProfile>
    </component>
    </settings>
    <cpi:offlineImage cpi:source="catalog:c:\flat\install_windows 7 enterprise.clg" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
    </unattend>

    Note: I would not recommend copying/pasting the example since you need to account for different architectures.

  3. Create a package in ConfigMgr that contains the copyprofile.xml file created in Step 2.

  4. Import the image into ConfigMgr

  5. In the ConfigMgr console modify the “Use an unattended or sysprep answer file for custom installation” property in the Apply Operating system task. Specify the package created in Step 3 and the file created in Step 2.

image

If you use the ConfigMgr capture media to capture the image instead of MDT 2010 you should follow steps 2-5.

The benefit of specifying the unattend.xml in this manner is that the file is located outside the image and is easy to update or change.

Hopefully this helps to explain more around this issue and if a specific customization is not copied as part of the CopyProfile process I would encourage readers of this blog to post the exact setting that was lost. We would also need exact steps on how the setting was configured so we can evaluate the impact of this issue

Scott McArthur
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support

Comments

  • Anonymous
    January 01, 2003
    This method works and if you need to make sure your systems are MS compliant, the sysprep method is below the non-sysprep method.   Non-Sysprep Method                                                                                                                                                       Create "Test" or "Setup" account       Make group policy changes           Computer Config > Administrative Templates > System > User Profiles >               Only Allow User Profiles = Enabled               Set Roaming Profile Path for all users logging onto this computer = Disabled               Prevent Roaming Profile changes from propagating to the server = Enabled       Customize the Test or Setup account       Enable built-in Administrator account       Log on as Administrator       Install RichCopy from Technet - robocopy may work also       Use Explorer to unhide system files and folders       Use RichCopy to copy the profile from the account used to implement customizations to "Default User"       Join machine to the domain       Reboot                                                                                                                                                     Log on domain user and all customizations should be applied to the users' profile   Sysprep Method - We may want to use this method because this method should be fully supported by MS       Login as the setup account       Enable Administrator Account       Log on as Administrator       Go to Manage Users                                                                                                                           Delete Setup account and any other accounts that have a profile folder and choose "delete files"       Make reg changes necessary to join Samba domain           3 .reg files located in root of ITS share = Win7-Hotfixes               Delete .reg files after applying them       Make group policy changes necessary for IMSA domain           Computer Config > Administrative Templates > System > User Profiles >               Only Allow User Profiles = Enabled               Set Roaming Profile Path for all users logging onto this computer = Disabled               Prevent Roaming Profile changes from propagating to the server = Enabled       Complete all customizations       Copy validated answer file to C: root       Go to windowssystem32sysprep       Right click while holding shift and choose "open command window here"       run "sysprep.exe /oobe /generalize /unattend:c:yourunattendfile.xml       Once the system reboots go through whatever portion of mini-setup your answer file dictates       Join machine to the domain       Log on as a domain user                                                                                                                   Basic look and feel customizations should have been applied from the local Defaul User profileRod Echols
  • Anonymous
    October 06, 2010
    Thanks for the info . . . much appreciated.
  • Anonymous
    October 06, 2010
    Thanks for the great post.. Correct me if I'm wrong but it appears that if IIS is enabled and ASP.net service/local account (Classic .NET AppPool) is created, during specialization stage, sysprep will kick off iissyspr.dll which updates the ntuser.dat file. Then copy profile task runs which in turn will use the Classic .NET AppPool account instead of the admin accounts because of latest timestamp.
  • Anonymous
    October 06, 2010
    btw- logs indicating the IIS Specialization is located c:windowsPanthersetupact.log and the shell unattend copy profile logs is located here c:windowsPantherUnattendGCsetupact.log. Based my findings from the datetime entry for those 2 logs files and the datetime stamp of the ntuser.dat file in the service account. Is there a workaround for this (other than removing IIS features and/or delete that account)?
  • Anonymous
    December 08, 2010
    I too am seeing this issue.  Did you find a workaround?I thought maybe a syprep provider could be written to touch the NTUSER.DAT hive under Administrator by executing under 'SysprepExternalProviders' in the registry.  It looks like these providers are run after the main providers.  I would be interested in another solution, aside from this (messy solution).
  • Anonymous
    February 08, 2011
    Great rundown. Thanks.As a matter of interest, i posted the following at the Sysintenals Forums:forum.sysinternals.com/forum_posts.asp
  • Anonymous
    February 16, 2011
    Ed Bott makes the following comment;"She [Gina Trapani] recommends that you disable UAC while you’re getting set up initially and installing programs. Not a good idea, as you’ll discover if you try it. User settings for some programs go in different places, depending on whether UAC is on or off. If you install with UAC off and then turn it back on, some of your programs might get confused."www.edbott.com/.../what-happens-when-those-tips-dont-workIf programs are installed by the built-in administrator, and then Sysprep is run with the CopyProfile setting set to true in unattend.xml, will this not result in a different default profile being created than if the programs had been installed by an admin running in Admin Approval Mode? That is, %localappdata%virtualstore will likely not have the same contents in each case. Are you aware of this causing problems?
  • Anonymous
    March 03, 2013
    how i can copy certain profile if i have many users profile on PC ?
  • Anonymous
    August 10, 2014
    Hello Mr. Scott, please answer this one question? Can I run sysprep without the "/generalize..." if I plan to go back to this .wim to make changes? I am doing a manual build and have run into many many errors - you see HANNAH all over the place....asking questions about sysprep - I found one gentleman suggesting not to generalize until you are ready to deploy,,,,do not generalize while making changes to your install in audit mode...
    is this something I can try - stuck for weeks now!
    Please help this HANNAH in need!
    Thank you.
    HANNAH