Answered Windows 7 - Modifying the Default User's Profile

  • Wednesday, June 30, 2010 1:28 PM
     
     

    I've read everything I can find related to useing CopyProfile = true.  There's a lot of conflicting information (this IS the Internet, after all), about what to do with the Unattend.xml and how it needs to be configured.

    I am making a few changes to my administrator's profile, desktop wallpaper, screen saver, and then saving the theme, and I want to make these a part of the default user profile.  I can't make it work with MDT 2010/SCCM 2007.

    I have created an unattend.xml that includes sets enabled CopyProfile and tried the following (not necessarily in this order):  I have tried copying this file to the hard drive before capturing the reference PC because I read that somewhere.  I have used the same unattend.xml as part of the Apply Operating System step in my deployment task sequence.

    I would like to make this work, just on principle,  but I AM reaching a point where I am open to suggestions about another method for deploying a desktop theme as part of my OS deployment.  (FYI - I'm not a fan of GPO for this sort of thing.  In my environment, exceptions are the rule.)

Answers

  • Thursday, July 01, 2010 1:07 PM
     
     Answered

    The other thing that I'd mention to you here is that even if you do EVERYTHING right, CopyProfile does not copy every setting that you might have configured.

    Unfortunately there are some holes in the process.  Before you say it has failed, I'd be certain to know exactly what settings you're trying to move from one profile to another.

    As for "other" ways of doing this...  I can tell you that when I was doing some testing that I did get this working, but that was by building the entire Image outside of SCCM.  If you can Sysprep and Capture the machine on your own (manually or scripted) and specify the XML file that you want it to use when you Sysprep the machine, then that Sysprep XML file will get cached and used when the system comes back up.

    Then if you Deploy the WIM file you made in the previous step...you'll get the profile settings moved over (again those that can move). 

    I know there are many staunch advocates of the "Build and Capture" TS in SCCM...and I am as well...but if you want a different method, I know it will work if you Sysprep your image outside of SCCM and then make you WIM outside as well.

     

     


    Mike...
    • Marked As Answer by JT65 Wednesday, July 28, 2010 3:30 PM
    •  
  • Wednesday, July 28, 2010 3:28 PM
     
     Answered

    Microsoft told me to follow the advice that everyone else has been giving me: Perform the profile changes, sysprep, and capture outside of SCCM.  While I find it ridiculous, I can't argue with the results.

    There's a blog for this on the "Ask the Core Team" site, but no link I can find on Google actually produces a document.  Here's what I did:

    1.  Update MDT 2010 to MDT 2010 Update 1

    2.  Install the OS, sysprep the system, and capture the image via MDT Deployment Workbench (NOT via SCCM!)

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

         2.2.  In MDT 2010 Update 1 create a task sequence based on the Sysprep and Capture task.

         2.3.  Boot the Lite Touch image and choose the "Deploy Windows" task sequence.  If prompted by teh Lite Touch wizard say NO to prompt to capture image.

         2.4.  After Widnows is installed and you login as administrator, make the changes to the shell you desire.

         2.5.  Map a network drive to the MDT 2010 UPdate 1 deployment share.

         2.6.  Run (from the deployment share) ...scripts\Litetouch.wsf

         2.7.  Run the Sysprep and Capture task sequence

    3.  Copy the captures image to where ever you store OS packages for SCCM

    4.  Create a task sequence for deploying the image.  Add the appropriate .XML file (see below  ) to the Apply Operating System step.

    These are the .XML files that Microsoft provided to me:

    CopyProfilex86.xml

    <?xml version="1.0" encoding="utf-8"?>
    <unattend xmlns="urn:schemas-microsoft-com:unattend">
        <settings pass="specialize">
            <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <CopyProfile>true</CopyProfile>
            </component>
        </settings>
    </unattend>

    CopyProfilex64.xml

    <?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="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <CopyProfile>true</CopyProfile>
            </component>
        </settings>
    </unattend>

     

     

    • Marked As Answer by JT65 Wednesday, July 28, 2010 3:29 PM
    •  

All Replies

  • Wednesday, June 30, 2010 2:02 PM
    Moderator
     
     
  • Wednesday, June 30, 2010 5:47 PM
     
     

    I have tried it as part of my deployment, but still no joy.

    I have modified my Apply Operating System Image step to use my answer file, but my user desktops on my newly deployed computers are not reflecting the changes.

    I don't an anything useful from my smsts.log file.  I'm going to increase my log file sizes and strip my task sequence down to the bare necessities to see if I can get something sysprep related.

    Just for giggles, here is my answer file:

    <?xml version="1.0" encoding="utf-8"?>
    <unattend xmlns="urn:schemas-microsoft-com:unattend">
        <settings pass="generalize">
            <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <DoNotCleanTaskBar>true</DoNotCleanTaskBar>
                <SkipRearm>1</SkipRearm>
            </component>
        </settings>
        <settings pass="specialize">
            <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
                <CopyProfile>true</CopyProfile>
                <DoNotCleanTaskBar>true</DoNotCleanTaskBar>
            </component>
        </settings>
    </unattend>

     

  • Wednesday, June 30, 2010 6:28 PM
     
     

    This was a huge pain, but here is what worked for me...

    1. Create your default profile with whatever settings you want (don't use the administrator account, you need someone else to log into).
    2. When finished, log in as Administrator, and in folder options, you want to view all hidden, and OS files.  If you don't see everything, the profile copy won't work.
    3. Delete everything in c:\users\default
    4. Copy the new default profile to c:\users\default
    5. You can then sysprep at this point.
    6. Once you come back up, and a user logs in for the first time, you will need to make sure to change several registry keys in

      HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

    7. From #6, make sure to change anything in the registry that says c:\users\(username you used) to c:\users\(the logged in user name)
  • Wednesday, June 30, 2010 7:12 PM
     
     

    Here's what I believe to be relevant from my smsts.log:

    Updated security on object C:\Windows\panther\unattend\unattend.xml. ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Successfully copied configuration file C:\_SMSTaskSequence\Packages\DAL0017A\x86CopyDefaultUnattend.xml to C:\Windows\panther\unattend\unattend.xml ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Entering ReleaseSource() for C:\_SMSTaskSequence\Packages\DAL0017A ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    reference count 1 for the source C:\_SMSTaskSequence\Packages\DAL0017A before releasing ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Delete source directory C:\_SMSTaskSequence\Packages\DAL0017A ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Released the resolved source C:\_SMSTaskSequence\Packages\DAL0017A ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Setting %SystemRoot% to "C:\Windows" ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Loading existing answer file "C:\Windows\panther\unattend\unattend.xml" ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    FALSE, HRESULT=80220001 (e:\nts_sms_fre\sms\framework\osdcore\smiinterface.cpp,498) ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Failed to deserialize settings (0x80220001) ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    pPassObj->fromXml( m_spSettingsEngine, m_spTargetInfo, sXml ), HRESULT=80220001 (e:\nts_sms_fre\sms\framework\osdcore\smiinterface.cpp,1070) ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    fromXml( oDoc ), HRESULT=80220001 (e:\nts_sms_fre\sms\framework\osdcore\smiinterface.cpp,963) ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Failed to load existing answer file "C:\Windows\panther\unattend\unattend.xml" ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Getting namespace "Microsoft-Windows-Deployment" for architecture "x86" ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Getting namespace "Microsoft-Windows-Shell-Setup" for architecture "x86" ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Getting namespace "Microsoft-Windows-International-Core" for architecture "x86" ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Writing configuration information to C:\Windows\panther\unattend\unattend.xml ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Successfully saved configuration information to C:\Windows\panther\unattend\unattend.xml ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Image installation completed sucessfully. ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Closing image file C:\_SMSTaskSequence\Packages\DAL0017C\HCI_Custom_Windows7_x86_1.2.wim ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Entering ReleaseSource() for C:\_SMSTaskSequence\Packages\DAL0017C ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    reference count 1 for the source C:\_SMSTaskSequence\Packages\DAL0017C before releasing ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Released the resolved source C:\_SMSTaskSequence\Packages\DAL0017C ApplyOperatingSystem 6/30/2010 4:36:00 PM 1304 (0x0518)
    Process completed with exit code 0 TSManager 6/30/2010 4:36:00 PM 1968 (0x07B0)
    !--------------------------------------------------------------------------------------------! TSManager 6/30/2010 4:36:00 PM 1968 (0x07B0)
    Successfully complete the action (Apply Operating System) with the exit win32 code 0 TSManager 6/30/2010 4:36:00 PM 1968 (0x07B0)

  • Thursday, July 01, 2010 5:32 AM
     
     

    Look at this blog if it helps you ?

     http://www.irongeek.com/i.php?page=security/windows-7-copy-default-profile

     

    Eswar


    KonetiE
  • Thursday, July 01, 2010 1:07 PM
     
     Answered

    The other thing that I'd mention to you here is that even if you do EVERYTHING right, CopyProfile does not copy every setting that you might have configured.

    Unfortunately there are some holes in the process.  Before you say it has failed, I'd be certain to know exactly what settings you're trying to move from one profile to another.

    As for "other" ways of doing this...  I can tell you that when I was doing some testing that I did get this working, but that was by building the entire Image outside of SCCM.  If you can Sysprep and Capture the machine on your own (manually or scripted) and specify the XML file that you want it to use when you Sysprep the machine, then that Sysprep XML file will get cached and used when the system comes back up.

    Then if you Deploy the WIM file you made in the previous step...you'll get the profile settings moved over (again those that can move). 

    I know there are many staunch advocates of the "Build and Capture" TS in SCCM...and I am as well...but if you want a different method, I know it will work if you Sysprep your image outside of SCCM and then make you WIM outside as well.

     

     


    Mike...
    • Marked As Answer by JT65 Wednesday, July 28, 2010 3:30 PM
    •  
  • Thursday, July 01, 2010 1:11 PM
     
     

    This was a huge pain, but here is what worked for me...

    1. Create your default profile with whatever settings you want (don't use the administrator account, you need someone else to log into).
    2. When finished, log in as Administrator, and in folder options, you want to view all hidden, and OS files.  If you don't see everything, the profile copy won't work.
    3. Delete everything in c:\users\default
    4. Copy the new default profile to c:\users\default
    5. You can then sysprep at this point.
    6. Once you come back up, and a user logs in for the first time, you will need to make sure to change several registry keys in

      HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

    7. From #6, make sure to change anything in the registry that says c:\users\(username you used) to c:\users\(the logged in user name)

    What part of this solution is "doing it in SCCM"?  Also...  There are much easier ways to do this without resorting to what might be called the Windows XP method... 

     


    Mike...
  • Thursday, July 01, 2010 1:44 PM
     
     

    I had read that the process is not bulletproof, but nothing that really explains what will and will not get transferred.

    All I'm really doing to setting the wallpaper and screen saver and then saving the settings as a theme.

  • Thursday, July 01, 2010 1:50 PM
     
     Proposed Answer
    Because there are known issues with the CopyProfile method (mine is set to off for a reason).  In my days working with SMS and SCCM, I have learned that sometimes the best way to do things is to think outside the product.  But, I simply will no longer post solutions to people's questions if these are the types of responses I get.
    • Proposed As Answer by ScottMSFT Friday, July 23, 2010 8:47 PM
    •  
  • Thursday, July 01, 2010 2:09 PM
     
     
    Because there are known issues with the CopyProfile method (mine is set to off for a reason).  In my days working with SMS and SCCM, I have learned that sometimes the best way to do things is to think outside the product.  But, I simply will no longer post solutions to people's questions if these are the types of responses I get.


    I'm not telling you not to post...I'm just saying that your "solution" is not one that I'd recommend to anyone else. 

    I'd guess you don't belive in it all that much either since the slightest critique has you abandoning it. 

    Do what you want to do...there's room for all opinions here, but that does not mean that everyone is automatically going to agree with every opinion that comes along....mine included.

     


    Mike...
  • Thursday, July 01, 2010 2:32 PM
     
     

    Opinions are always welcome. 

    You know what they say about opinions.  They're like...well, everybody's got one,and they all stink.

    There are a number of people who don't agree with my dislike of Group Policies, but they just don't work well in my environment.

  • Thursday, July 01, 2010 4:18 PM
    Moderator
     
     
    just to rule out any possible mistakes, are you deploying windows 7 x86 ? (because your xml file is pointing to x86)

    My step by step SCCM Guides
    I'm on Twitter > ncbrady
  • Thursday, July 01, 2010 5:38 PM
     
     

    I am installing Windows 7 x86, but let's back up a step so I can verify for myself that I'm following the correct process; I'm just fouling it up somehow.  The process (as I understand it) is:

    1.  Install Windows 7 (x86)

    2.  Make the desired changes to the Administrator's profile.

    3.  Capture the reference PC.

    4.  Deploy the new image with the Apply Operating System step configured to use my .XML file (the same one I posted previously).

    Am I understanding this correctly?

    For what it's worth, this .XML file is I trimmed down version of of .XML file created when I created the Settings package via the Create Microsoft Deployment Task Sequence.  I used this as my model and simply removed what I didn't need and added what I thought I did.

  • Thursday, July 01, 2010 7:02 PM
     
     

    So how are you doing Steps 1 and 2?  Manually or using SCCM?

    I ask because I don't see a step for Sysprep anywhere in there and I'm just wondering if that is part of your SCCM TS (as it generally is by default) or if you're doing something else.

     


    Mike...
  • Thursday, July 01, 2010 7:07 PM
     
     

    Step 1 is via SCCM.  I have tried two different images.  One installed from the Install.wim that I copied straight off the Windows 7 Enterprise CD, and via a custom .WIM that is simply the Install.wim re-captured so that the OS will install to the C: drive instead of D:.

    Step 2 I'm doing manually.  I simply log in as the administrator, copy my background files and screen saver, make the necessary changes to the desktop, modify the registry to enable OEMBackup, and configure the screen saver for when no one is logged in.

  • Thursday, July 01, 2010 7:19 PM
     
     

    Sysprep is being handled via the Prepare OS step in my Capture TS (right?...I've got my fingers cross that I haven't just said something stupid).

    Since we're on the subject, let's see if we can clear something up for me.  The CopyProfile is supposed to be executed when the OS is deployed, right?  If so, is that because it is part of the 'Specialize' pass?  With "Generalize" being run to remove machine specific settings.  Do I have that right?

  • Friday, July 02, 2010 2:08 PM
     
     

    Yes, the Prepare OS step is the one that runs Sysprep for you...

    One of the challenges when you do Prepare OS in W7 is that you don't get to specify an XML file that you want Sysprep to use...  I say challenges, because if you could tell it which XML file to use when you Sysprep the machine...then that XML file gets cached and will be used when the computer comes back up.

    So, instead of being able to tell it to use the XML file when you run Sysprep, you have to specify for it to use the XML file when you deploy the image.

    The XML file does need to be available (whether cached or pointed to) when the OS is deployed...that is correct...and that is specifically different than how it worked in Windows XP.  Here's my favorite blog post on the subject:

    http://blogs.technet.com/b/deploymentguys/archive/2009/10/29/configuring-default-user-settings-full-update-for-windows-7-and-windows-server-2008-r2.aspx

     


    Mike...
  • Friday, July 02, 2010 5:31 PM
     
     

    Do I care about the .XML file that gets used during the Prepare OS process?  At least as far as my administrator's profile and the default user's profile?

    I've read The Deployment Guy's port on this subject.  I think the process I'm using is what they descibe in the Automated Profile Copy with Sysprep section.  BTW - I think the Microsoft link included in this post, http://support.microsoft.com/?id=973289, is too vague to be of any use.  If you go down the rabbit hole of the links this MS article contains, you get all of the information you need to figure it out for yourself which section the CopyProfile should belong...but I digress.

     I moved the CopyProfile to the deployment stage because of YOUR (Mike Normand, that is), post in this thread (http://social.technet.microsoft.com/Forums/en-US/configmgrosd/thread/815a7326-ef61-488f-9d8f-1a57b42884bf/).  I was spinning my wheels trying to make it work during the capture process before that.  You saved me a lot of experimenting with that little tid bit.

    On the one hand, I'm relieved that I am following the correct process, but I'm miffed that I haven't been able to make it work.

  • Friday, July 02, 2010 5:36 PM
     
     

    I just read this in another post http://social.technet.microsoft.com/Forums/en/configmgrosd/thread/ffccdfbf-77a7-4167-a762-64cbc64c841f:

    "I can't explain why it works but it did. I used the same unattend.xml in my capture as my deploy TS and it worked perfectly. Now if someone from MS will get off thier backside and document some of these common admin tasks, we can make better use of our time."

    Is this true?  If so, it answers my question about whether or not I should care about the unattend.xml file used during the capture process.

    This is the next post in the same thread:

    Iremember asking our MS rep awhile back as to why it had to be done this way and is response was "that's how its supposed to be done." The thing is, I didn't have to do this with every image I created, so I just figured it was something I was doing related to sysprep.

    Here's the weird thing, I only have to do this on my enterprise images, not my professional ones. Go figure.

    I'm installed Windows 7 Enterprise.  Before I try this, I'm not 100% clear about the unattend.xml file that will be used during the capture.  Do I simply modify the file in the Custom Files package?  Or do I need to copy an unattend.xml file with everything I'll need in it to the SysPrep folder on the reference PC?

    • Edited by JT65 Sunday, July 25, 2010 1:29 PM
    •  
  • Friday, July 02, 2010 7:40 PM
     
     

    The right answer to your question is that you shouldn't have to care...  Aside from the fact that it's not exactly easy to tell ConfigMgr to use a differnet XML file when it runs Sysprep, it's supposed to be designed to work without that being necessary.

    Now, obviously if they are saying that they needed to do that in order to get it to work...well, I'm not going to argue against that...

    I did say yesterday that you could get it to work if you stepped outside of ConfigMgr and Sysprep'd and Captured the machine on your own and told it the XML file to use.

    Everyone is right though...this is certainly a heck of a lot more complex than it should be for something that is a rather common activity.  Every place that I've ever worked and every image that I've ever made, managers have wanted something tweaked in the Default User profile.  Seems like that should have been given a litlte more weight when they were working up W7.  In other words...don't get me started on my Taskbar rant...

     


    Mike...
  • Tuesday, July 13, 2010 7:55 PM
     
     

    I finally broke down and contacted Microsoft, but I'm still not out of the woods.

    At this point, I have created a new .WIM (oddly enough, the process that Microsoft provided to me has me doing all of this OUTSIDE MDT and SCCM) that has the wallpaper and screen saver I want. 

    If I add a new user to my reference machine (this is AFTER the images has been captured), the new user gets the appropriate wallpaper/screen saver.  When I turn around and deploy this captured image, these settings are lost.  Every new user gets the default Windows 7 wallpaper.

    This would indicate that the problem is (and possibly always was) with my deployment process, right?

  • Wednesday, July 14, 2010 6:01 PM
     
     

    This article, http://support.microsoft.com/kb/2101557, indicates that I should be able to see evidence of the CopyProfile process in the setupact.log file. 

    Does anyone know if this would still be true if the sysprep was performed during an SCCM-based deployment?

    I have a seupact.log, but it's in a different path (C:\Windows\System32\Sysprep\Pather), than listed in the article.  It also does not have the string "CopyProfile" anywhere in it.  I don't know if this is because it's NOT preforming the CopyProfile function, or if I'm just not looking in the right place.

  • Wednesday, July 14, 2010 7:49 PM
     
     

    Perhaps...

    Are you sure that the Package which includes your Unattend.xml file is up to date and that it has been pushed out to your Distribution Point...?

    If  you didn't do that, then it could either be using an old one w/o the CopyProfile command in it or it is using a default one.

     


    Mike...
  • Wednesday, July 14, 2010 8:35 PM
     
     
    I am fairly certain, but I have been doing a lot of tweaking lately.  I will update my distribution point for both my OS image and my Custom Settings Files package and try again tomorrow...just in case.
  • Monday, July 19, 2010 7:17 PM
     
     

    I attempted to re-image after updating my distribution point, but no change.

    My issues has been escalated, or at least handed off, to someone else.  I'm waiting to hear back.

  • Wednesday, July 28, 2010 3:28 PM
     
     Answered

    Microsoft told me to follow the advice that everyone else has been giving me: Perform the profile changes, sysprep, and capture outside of SCCM.  While I find it ridiculous, I can't argue with the results.

    There's a blog for this on the "Ask the Core Team" site, but no link I can find on Google actually produces a document.  Here's what I did:

    1.  Update MDT 2010 to MDT 2010 Update 1

    2.  Install the OS, sysprep the system, and capture the image via MDT Deployment Workbench (NOT via SCCM!)

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

         2.2.  In MDT 2010 Update 1 create a task sequence based on the Sysprep and Capture task.

         2.3.  Boot the Lite Touch image and choose the "Deploy Windows" task sequence.  If prompted by teh Lite Touch wizard say NO to prompt to capture image.

         2.4.  After Widnows is installed and you login as administrator, make the changes to the shell you desire.

         2.5.  Map a network drive to the MDT 2010 UPdate 1 deployment share.

         2.6.  Run (from the deployment share) ...scripts\Litetouch.wsf

         2.7.  Run the Sysprep and Capture task sequence

    3.  Copy the captures image to where ever you store OS packages for SCCM

    4.  Create a task sequence for deploying the image.  Add the appropriate .XML file (see below  ) to the Apply Operating System step.

    These are the .XML files that Microsoft provided to me:

    CopyProfilex86.xml

    <?xml version="1.0" encoding="utf-8"?>
    <unattend xmlns="urn:schemas-microsoft-com:unattend">
        <settings pass="specialize">
            <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <CopyProfile>true</CopyProfile>
            </component>
        </settings>
    </unattend>

    CopyProfilex64.xml

    <?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="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <CopyProfile>true</CopyProfile>
            </component>
        </settings>
    </unattend>

     

     

    • Marked As Answer by JT65 Wednesday, July 28, 2010 3:29 PM
    •  
  • Thursday, July 29, 2010 6:09 PM
     
     

    JT65

    thanks for your work, i just tested the steps you provided and it works perfect. This is the most clean way to deal with win7 default profile so far.

     

    thank you,

    AR