Colleagues of mine in the UK hit a issue in a engagement when using MDT 2010 to create a Windows 7 reference image and then deploying that reference image with MDT 2010 in a separate task sequence. From speaking to a number of people the issue they were seeing seems to be common…
When a target machine has been deployed using the reference image a user chooses Personalize and then chooses Desktop Background. The Picture Location contains all the expected folders (Windows Desktop Backgrounds, Pictures Library, Top Rated Photos, Solid Colours), however, the picture location also contains a folder called “Windows”. When the user selects “Windows” they are prompted to insert a disc into drive D:
Originally, we thought this was symptomatic to the target machines only as we weren’t seeing the behaviour on the reference machine. However, if you stop the reference machine build before Sysprep/WIM capture, you then see the same symptoms. The reference machine is writing the default background (Windows Harmony) to the registry as a known folder for the picture location. On deeper investigation it becomes apparent that certain registry keys are being written:
This behaviour is ONLY seen when CopyProfile is set to True in the unattend.xml file used to create the reference image. The D: path and the wallpaper becomes apparent when the reference image is deployed to target machines.
The resolution for this issue seems simple (and is) but took time to identify – and it was that CopyProfile was not set in the deployment unattend.xml. As Michael Murgolo’s post identified – in Windows 7, the process of copying the profile to the default user does not take place until the image is starting up – therefore – as Michael points out, 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 reference image.
The moral of this story is to ensure that CopyProfile is set to True (if you want to translate customisations to all users) in your MDT unattend.xml file that is used to deploy your reference image. If you have the CopyProfile set in your reference build unattend.xml file (the file used in your image engineering process) and you find that the aero theme does not apply correctly, then ensure that the CopyProfile setting is removed in the reference build unattend.xml (I'm grateful to Nas001 for his comments on this matter)
This post was contributed by Richard Smith, David Sanders and Lynne Doherty - Consultants with Microsoft Services, UK.
I recently had a ticket open with Microsoft for Windows 7 because the Aero theme was not getting set correctly. The fix for that issue was to remove the CopyProfile setting from my build image and only specify it in my deployment image. I wanted to point this out because the last statement in the article is misleading. According to Microsoft Tech Support, the CopyProfile setting should not be set during the build process.
Yes, I concur that CopyProfile=True should not be used during the image build. For example, when I was building a Vista image for a customer they had a requirement to have no default RSS feeds in the image. I had configured everything correctly but they kept appearing. It turned out that because I had CopyProfile=True during the image build, the RSS feeds from the Administrator’s profile in install.wim were being applied to Default User. So when the Administrator’s profile was recreated at the start of the build, the feeds were there.
This is a good example of why people are asking for the restoration of the ability to copy a customized profile over the default user profile the way it could be done in XP.
we did not use CopyProfile=True when built up reference computer. however, we still see this issue after the image is deployed. A bit of strange.