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:
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Wallpapers\Images - This key contains ID2 and ID3 which in turn contain a long key of data; Windows sees these as pointing to the D: drive.
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Wallpapers\knownfolders\0\Windows Wallpapers\MergeFolders\%SystemRoot%\web\wallpapers\windows
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.