none
Win 10 Unattend.xml CopyProfile = true, breaks search bar

    Question

  • Hey all,

    I’ve created a Win10 enterprise VM to capture for a master image. I log into audit mode, make some changes, install some software, run windows updates, and pin / customize start screen.

    I open up WSIM create an answer file with

    <CopyProfile>true</CopyProfile>

     

    sysprep and point to the unattend.

    VM boot, and capture with dism in pxe.

    I then deploy the captured image with SCCM 2012 R2 SP1, making sure to add the same unattend.xml file under the “use an unattended…file” option in the task sequence under apply os.

    Once the OS is deployed everything looks great changes have all been copied from admin profile, except the search bar looks to be broken. Can’t click or type, looks like a place holder. Hit windows key start to type, no response.

    I don’t know what else to try, I’ve kept everything stripped down no other options in unattend file and no other settings during TS except for domain join. Even the Administrator account after OSD has broken search bar too. 

    Any ideas?


    • Edited by Kman462 Tuesday, August 11, 2015 4:46 PM
    Monday, August 10, 2015 10:50 PM

All replies

  • I'm having the same problem. The issue is <CopyProfile>true</CopyProfile>. If take it out the problem goes away. Haven't found a fix for it yet.

    Tuesday, August 11, 2015 7:41 AM
  • After further testing, the copyprofile true does work, as long as I don't run windows updates before I sysprep. I'm not sure if it's something with new the CU update that just came out. But running WU even through PowerShell WUpdate module, it breaks the search bar after OSD... So that sucks. Boooo! CU: KB3081436

    Update:

    After more testing, CopyProfile only works for me as long as the CU isn't applied. On my test image I've run copyprofile and avoided updates. After deployment and a new AD account is created on the machine, that user account wont have the broken search bar problem. If I then run updates on that same account the search bar will still work. However, when I logon with another user account after the CU has been applied, the search bar for that new profile is broken.


    • Edited by Kman462 Thursday, August 13, 2015 3:27 PM
    Tuesday, August 11, 2015 4:59 PM
  • Hi,

    Not sure if it's a known issue, since I have no such environment to test in my working scope.

    Please help to collect following log files, and upload to a shared OneDrive folder and post back the link for our research:

    smsts.log

    C:\WINDOWS\PANTHER\setupact.log
    C:\WINDOWS\PANTHER\setuperr.log


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Wednesday, August 19, 2015 10:03 AM
    Moderator
  • Sure that'd be great.

    http://1drv.ms/1Ln5leG

    Thursday, August 20, 2015 5:12 PM
  • Same problem. I also noticed it after I applied the latest CU. Prior copy profile worked fine.
    Friday, August 21, 2015 7:05 PM
  • Also noticed when trying to save something to the Desktop on a new profile I'm met with an error stating:

    "Location is Not available, C:\Users\Administrator\Desktop is not accessible Access is denied."

    Almost seems like new profiles haven't fully cut ties with the Admin one that's being used as the default profile template.

    For me CopyProfile true is really messing up my Win10 image. It worked great in 7 and 8.1. Hope it's fixed sometime soon.

    Friday, August 21, 2015 10:47 PM
  • I too am having the same problems.  Copy Profile is on, and it's seriously breaking both search and the quick link for Administrator.  Pretty ridiculous given this is a RTM OS.....

    Anyone else have any working fixes?

    Monday, August 24, 2015 11:02 PM
  • I see where Hussam Dabit says if he removes the CopyProfile line from his answer file the problem goes away, but your next post references the CU: KB3081436.  Can we confirm that the CU doesn't cause this problem on its own, without using CopyProfile?  I'm spinning up a test VM now, and will see what I can learn.
    Wednesday, August 26, 2015 1:08 PM
  • I've tried only applying a CU before sysprep.

    Only applying a CU with DIMS after .wim is created.

    Only applying a CU after OSD.

    I've also run the unattend with copyprofile during sysprep, and tried without the unattned during sysprep; only during OSD.

    My experience this far is if I have copyprofile true set, everything works well until a CU is applied at any stage. Then newly created accounts suffer the broken search bar. 

    In all the combinations so far it's been: CopyProfile + CU = broken search bar on new account.

      

    Wednesday, August 26, 2015 5:37 PM
  • I'm experiencing the same exact thing! We applied that CU in the image to avoid having users experience the headache of applying that update (since it required some kind of reghack to fix it) and now the CopyProfile flag makes the search taskbar and start menu broken. :( If I apply my image with no unattend file stipulated in my Apply OS task, everything works. Hoping this is fixed soon.

    Michael B Courville

    Friday, September 11, 2015 3:57 PM
  • It seems I may be running into the same issue.  Does anyone have any idea if this bug in Windows 10 will ever be fixed by Microsoft?  Using the CopyProfile is fairly important to us.
    Friday, September 25, 2015 2:21 PM
  • I also have the same problem.  My reference image is 10240 never connected to the internet.  No updates.  The captured syspreped image using copyprofile appears to be fine except for search and Cortana.  If I do not use CopyProfile everything is fine.  
    Saturday, September 26, 2015 8:52 PM
  • Also noticed when trying to save something to the Desktop on a new profile I'm met with an error stating:

    "Location is Not available, C:\Users\Administrator\Desktop is not accessible Access is denied."

    Almost seems like new profiles haven't fully cut ties with the Admin one that's being used as the default profile template.

    For me CopyProfile true is really messing up my Win10 image. It worked great in 7 and 8.1. Hope it's fixed sometime soon.

    Still experiencing this problem.

    There's no place like 127.0.0.1

    Monday, October 05, 2015 7:00 PM
  • I've just found this thread while pursuing the same issue.  I'd installed on WUs and used the CopyProfile=true setting in my unattend sysprep file.  No search on deployment.
    Wednesday, October 07, 2015 2:06 PM
  • We are facing the same issue here.
    Wednesday, October 07, 2015 4:53 PM
  • Same issue here. Looking to deploy Windows 10 very, very soon. I'm starting to look into alternate ways of setting up a "Default Profile" that does not involve copy profile in any way.

    Most of the Window settings such as show file extensions, show menus etc. are no problem as they can be set with policies and preferences. The issue for us in an Educational environment is setting default preferences within 3rd party apps.

    Is anyone else looking into alternatives other than Copy Profile?

    Wednesday, October 07, 2015 5:45 PM
  • Hi all.

    I've been experiencing the same issue here. I do have the "CopyProfile=True" setting in my unattended file.

    I'm going to rebuild my image however I will not perform any MS updates on it for now. I'll just do those via SCCM and see if it makes a difference.

    BTW - I don't see KB3081436 listed in SCCM as available anymore.

    ----------------------------------------------

    UPDATE as of 10/8/15 @ 2:34pm EST 

    ----------------------------------------------

    I removed two Microsoft Updates on an affected system - KB3093266 and KB3081449. After rebooting, the Search and Cortana options worked fine. I then allowed these two updates to be installed again and both Search and Cortana are STILL working.



    Thursday, October 08, 2015 2:18 PM
  • I removed KB3093266 & KB3081449 from my image before sysprep / capture. After OSD I logon and search bar is working. I run updates and both KBs come back down. Reboot, logon with the same account and search bar is still working. However, "quick access" - Desktop shortcut still points to "Administrators" desktop, so that's still broken. But worst of all, when I logon as a new user with the updates applied, the search bar is broken again, it ends up with the same bug.  


    • Edited by Kman462 Friday, October 09, 2015 1:23 AM
    Friday, October 09, 2015 1:22 AM
  • I found another question about CopyProfile.

    Windows 10 has a new feature: Quick access on the left top of File Explorer, and Audit mode has it also. However we use CopyProfile in sysprep then reboot to OOBE and register a new account, the "Desktop" shortcut of quick access remains the admin's. This will confuse end user cause they will click it and show error.

    If we remove this "Desktop" shortcut under Audit then sysprep, there will no more be any Desktop shortcut on the left top of File Explorer.


    Vannes Yang


    • Edited by Vannes Wednesday, October 14, 2015 7:01 AM
    Wednesday, October 14, 2015 7:00 AM
  • I've sysprepped and captured a Windows 10 Education x64 image on a VM and deployed it to a test machine with SCCM2012R2SP1 using CopyProfile=True. If I log in with a domain user account, most of my customizations to the default user profile are there, AND the search bar is functioning normally. My image contains KB3093266 & KB3081449 which are installed as a part of the MDT task sequence. So there must be some other factors causing the search bar not to work, in my environment these updates are not at fault.

    The only problem I can verify is that Quick access Desktop-shortcut is broken and points to the Administrator's desktop.

    This is definitely an issue that Microsoft needs to take a closer look at.

    Friday, October 16, 2015 9:19 AM
  • I've also seen where the start menu or whatever it's called doesn't work at all after a copyprofile.

    Friday, October 16, 2015 5:40 PM
  • I concur. Seems only one bug is present for me at this point with the Quick Access menu. Would be easy to fix if I could load the hive and edit the location to %USERNAME% but alas, the QA menu appears to be programmatic now rather than some reg key or else stored by some other method. I have found no way to edit the QA menu offline.

    Other than that, I am not seeing any other issues with copyprofile. Patiently waiting for a fix from MS.

    Friday, October 16, 2015 8:51 PM
  • We too have come across this issue, at first I thought it was because I was configuring the profile and that was confusing Windows, but turns it is just using copyprofile that breaks profiles.

     I documented everything I have tried to prove it is an issue with Windows and nothing I am doing wrong, I created the post below before I discovered this one.

    https://social.technet.microsoft.com/Forums/en-US/db2d6f8d-f909-4191-a870-70846bc15135/windows-10-roaming-profile-issue?forum=win10itprogeneral

    Monday, October 19, 2015 1:59 PM
  • I have this same issue - but it was different updates that broke it for me.  After an install, I did updates and did not get the ones mentioned here.  Search was working for new users, but as soon as I ran updates, it broke.

    After testing, I had to remove Security Updates 3097617 and 3105216.  With those gone, search starts working again.

    Thursday, October 29, 2015 2:26 PM
  • Shouldn't have to remove updates or not use "copyprofile" in order to search in Windows.. 

    Michael B Courville

    Friday, October 30, 2015 8:24 PM
  • Bump.

     Come on Microsoft, this is holding back our deployment of Windows 10, and I'm sure others will be avoiding an enterprise deployment until this is sorted.

    Monday, November 16, 2015 1:15 PM
  • Yup, dead in the water over here.
    Monday, November 16, 2015 2:56 PM
  • Has anybody tried the newest 1511 build? I'm downloading the ISO now so I can build a new reference image and test.
    Monday, November 16, 2015 8:47 PM
  • I have just started the download, I will give a go and post results here.

    Not holding my breath though!

    Tuesday, November 17, 2015 2:46 PM
  • I just built a clone image using the build 1511 (10586) ISO and CopyProfile appears to still have problems.

    The Search bar seems to work, but the Quick Access - Desktop link is still broken and incorrectly points to the built in Administrator account.

    Also, in the Start Menu, when I open All Apps - Windows System and attempt to 'right click' on Control Panel because I want to pin it, the popup menu does NOT come up AND the Start Menu now freezes and becomes unresponsive until I click randomly and attempt to do other things.  Then the Start Menu seems to free itself up but I absolutely cannot right click on the Control Panel inside the Start Menu.  (I could left click and run it, but I should be able to right click and pin it.)

    I didn't bother trying anything else because as far as I'm concerned, the CopyProfile function is still broken.

    Tuesday, November 17, 2015 8:15 PM
  • I can also verify that I am having the same issue with the Quick Access - Desktop link where it points to the administrator account. I am using sysprep while under audit mode logged in as administrator.

    Wednesday, November 18, 2015 4:28 AM
  • Just tested on the latest build 1511, and from initial testing it actually seems to work.

    I can confirm the Quick Access - Desktop still points to Administrator, but this isn't too much of a problem for me as we don't allow access to the desktop anyway so I will probably just remove the link.

     I don't have any problems pinning the control panel to the start menu, that works fine for me, but the fact that the start menu does not roam is still the big issue for us as our staff need to have roaming start menus.

     As far as copyprofile goes though, it is working enough for me, I am impressed Microsoft!


    Wednesday, November 18, 2015 9:11 AM
  • Has anyone experienced the issue of having Copy Profile set to True and also trying to set a customized Start Menu with the LayoutModification.xml file? If Copy Profile is set to True the Start Menu modifications do not set but if Copy Profile is set to False the Start Menu modifications work. Using MDT 2013.
    Wednesday, November 18, 2015 4:16 PM
  • I did some testing with 1511 as well. The search option and Store seem to work fine now, but one thing I noticed was specific to Edge and IE11. After I toggle copy profile to true, whenever I try to navigate to www.box.com (and this could affect other sites) I get weird pauses and non-responsive errors while it tries to load. The same site(s) work fine in Firefox and Chrome. And, if I toggle copy profile back to false and try a fresh profile, that same site loads fine on Edge and IE11. Our organization heavily uses Box, so it was a obvious test choice for us. I'm guessing there is something in the user registry hive that might be causing it.

    Can anyone else confirm this on build 1511?

    Thursday, November 19, 2015 1:09 PM
  • I've just tested on my test system and www.box.com seems to work fine on both Edge and IE so not sure whats happening there. What are you doing to the default profile? I had issues with Windows 8 when I removed some stuff I shouldn't have! With Windows 10 I log in as administrator, delete any local accounts, configure everything I want, then sysprep with copyprofile.

    As for the layoutmodification.xml, we don't use that so can't help you there, sorry.

    Thursday, November 19, 2015 2:52 PM
  • In my testing i have also encountered this issue have not yet tested with build 1511 however I have found that although copyprofile breaks start and search etc. Once you complete OOBE everything works normally 
    • Edited by n.snook Thursday, November 19, 2015 5:00 PM
    Thursday, November 19, 2015 4:37 PM
  • I'm not doing anything special really:

    * Clean Windows 10 Enterprise x64 build 1511 install (continuous build)

    * Boot to sysprep audit mode at OOBE screen (CTRL+SHIFT+F3)

    * Copy over an unattend XML file with only a section pertaining to the copy profile (true) - special/Windows Shell Setup

    <?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>

    * Then sysprep and specify that file and let it reboot

    After I create a regular user, logon, and test box.com on Edge and IE11. Edge now works, but I keep getting this weird pause/non-responsiveness from box.com and even cnn.com on IE11 - especially if you try to click around on the page. 

    If CopyProfile is set to false or I don't specify an unattend file, it works fine.

    Unless we received a bad copy of the newest enterprise ISO file....

    Friday, November 20, 2015 5:48 PM
  • According to Johan Arwidmark in a recent youtube comment, some builds of Windows 10 don't work correctly with CopyProfile.

    https://www.youtube.com/watch?v=3tR7gdBRxp8

    DeploymentArtist -- "CopyProfile was broken in Windows 10 Build 10240, I haven't tried yesterdays release of v1511 (Build 10586)."


    • Edited by JS2010 Friday, November 20, 2015 8:07 PM
    Friday, November 20, 2015 7:40 PM
  • Using Build 10586, I've tried CopyProfile with my unattended. I didn't reference it during sysprep but during OSD with SCCM. The start/search bar is no longer broken after performing any CU updates (for now), and newly created accounts after CU updates maintain a working start/search. However, the "Quick Access" "Desktop" shortcut is still pointing back to the auditmode Admin account and causes an error message on any account. I've removed the quick access desktop shortcut from my master image to avoid any error messages for now. So, it's better (workable even) but it's still not quite right. 

    Tuesday, November 24, 2015 5:41 PM
  • The same.

    Any update?

    Friday, December 11, 2015 6:23 PM
  • Removed Pinned Desktop from Quick Access to workaround that.  

    Setup Win10 the way you like, defer upgrades as that will cause issues during sysprep. Regardless that we can "make" it work; however, we don't want upgrade junk on our master image, correct? This will just cause further headache down the road when attempting to remove default Apps/Provisioned apps via Powershell. Prior to Sysprep using copyprofile true in your unattend.xml; AFTER all programs are installed under the profile you are copying, take a gander at %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu in File Explorer

    Now open another file explorer window to C:\ProgramData\Microsoft\Windows\Start Menu

    Compare the shortcuts that are missing in C:\ProgramData\Microsoft\Windows\Start Menu and the subdirectories.

    If you cut and paste those shortcuts from the respective path of your admin (sysprep) profile to the respective path of ProgramData, you will sleep much better at night.  You can verify the shortcuts still work by clicking on them from the start menu.

    Now run sysprep with copyprofile "true". Tons of stuff will work. Including your start menu with your customized tiles.


    Wednesday, December 16, 2015 1:06 AM
  • Any solution with sysprep copyprofile for windows 10 by Microsoft, not tricks?
    Monday, December 28, 2015 7:51 PM
  • While it greatly irritates me that MS did this without providing us an instruction set (I believe this is likely to be already well documented by them, and that they probably intend a different method for default profile creation), I find your workaround for the issue that we are experiencing to be quite brilliant in its simplicity and efficiency. 

    HOWEVER, I'm having difficulty wrapping my head around the following concept: 

    "defer upgrades as that will cause issues during sysprep. Regardless that we can "make" it work; however, we don't want upgrade junk on our master image, correct?"

    For well over 10 years, on at least a dozen projects, I have always worked with teams that favor performing all desired updates and installations PRIOR to sysprep and imaging for the key purpose that it saves valuable scalable deployment time. Windows 10 has its own oddities for said updates, including the massive file download, which will make network overhead to handle a large scale deploy-then-update into a fairly large headache in the immediate. Also, having only a clean master image seems to me not that far a time savings from the old RIS process. So I would welcome further discussion of this point in the hopes that it may enlighten me to the benefits of your "don't update" practice. And, yes, I would be quite pleased to hear that I've misunderstood.

    m2k


    Tuesday, December 29, 2015 5:48 PM
  • m2k,

    " have always worked with teams that favor performing all desired updates and installations PRIOR to sysprep and imaging for the key purpose that it saves valuable scalable deployment time"

    Absolutely patch and UPDATE (not upgrade) the image!   I'm with you 100%!  There is an option to "defer upgrades" under advanced options in Windows Update in Win10.  New builds install as an upgrade of the OS, not update.  Sysprep will fail if an upgrade gets pulled down prior to sysprep unless the previous OS is deleted (hidden folder included).  That is what I was referring to when I mentioned deferring upgrades.  Deferring upgrades doesn't affect security updates.  I would NEVER recommend deferring updates.

    Wednesday, December 30, 2015 6:20 PM
  • The initial OS install was disconnected from the network until "defer upgrades" was checked under advanced options in Windows Update.  Then, update as you wish.

    We also wanted to permanently remove some of the baked-in apps as they will serve no purpose in our environment.

    In order to prevent Windows Store from updating apps, unplug the from the network before uninstalling apps via powershell and running sysprep

    Import-Module Appx
    Import-Module Dism

    The command below lists all packages that were published by Microsoft and installed by any user of our reference vm.  Since we are about to sysprep our reference machine we can assume the reference user account no longer requires the package...well most of them depending on where you work.

    Get-AppxPackage -AllUser | Where PublisherId -eq 8wekyb3d8bbwe | Format-List -Property PackageFullName,PackageUserInformation

    To list manually provsioned apps that belong to other publishers (ie Skype)

    Get-AppxPackage -AllUser | Format-List -Property PackageFullName,PackageUserInformation

    Get List of Provisoned Apps:

    Get-AppxProvisionedPackage -Online | Select PackageName

    PackageName
    -----------
    Microsoft.3DBuilder_10.9.6.0_neutral_~_8wekyb3d8bbwe
    Microsoft.BingFinance_4.7.118.0_neutral_~_8wekyb3d8bbwe
    Microsoft.BingNews_4.7.118.0_neutral_~_8wekyb3d8bbwe
    Microsoft.BingSports_4.7.130.0_neutral_~_8wekyb3d8bbwe
    Microsoft.BingWeather_4.7.118.0_neutral_~_8wekyb3d8bbwe
    Microsoft.Getstarted_2.5.6.0_neutral_~_8wekyb3d8bbwe
    Microsoft.MicrosoftOfficeHub_2015.6508.23761.0_neutral_~_8wekyb3d8bbwe
    Microsoft.MicrosoftSolitaireCollection_3.5.11021.0_neutral_~_8wekyb3d8bbwe
    Microsoft.Office.OneNote_2015.6366.15841.0_neutral_~_8wekyb3d8bbwe
    Microsoft.People_2015.1201.2033.0_neutral_~_8wekyb3d8bbwe
    Microsoft.SkypeApp_3.2.1.0_neutral_~_kzf8qxf38zg5c
    Microsoft.Windows.Photos_2015.1208.11230.0_neutral_~_8wekyb3d8bbwe
    Microsoft.WindowsAlarms_2015.1161.20.0_neutral_~_8wekyb3d8bbwe
    Microsoft.WindowsCalculator_2015.1204.20.0_neutral_~_8wekyb3d8bbwe
    Microsoft.WindowsCamera_2015.1211.10.0_neutral_~_8wekyb3d8bbwe
    microsoft.windowscommunicationsapps_2015.6515.64021.0_neutral_~_8wekyb3d8bbwe
    Microsoft.WindowsMaps_4.12.11000.0_neutral_~_8wekyb3d8bbwe
    Microsoft.WindowsSoundRecorder_2015.1117.110.0_neutral_~_8wekyb3d8bbwe
    Microsoft.WindowsStore_2015.2323.4.0_neutral_~_8wekyb3d8bbwe
    Microsoft.XboxApp_2015.1209.230.0_neutral_~_8wekyb3d8bbwe
    Microsoft.ZuneMusic_2019.6.15131.0_neutral_~_8wekyb3d8bbwe
    Microsoft.ZuneVideo_2019.6.15731.0_neutral_~_8wekyb3d8bbwe

    We will keep 3DBuilder, Photos, Calculator, Soundrecorder, and Store

    Remove AppxPackage installed under Current User First.  If we don't remove apps under current user AND provisioning, sysprep WILL fail.

    Remove-AppxPackage -Package Microsoft.BingFinance_4.7.118.0_neutral_~_8wekyb3d8bbwe
    Remove-AppxPackage -Package Microsoft.BingNews_4.7.118.0_neutral_~_8wekyb3d8bbwe
    Remove-AppxPackage -Package Microsoft.BingSports_4.7.130.0_neutral_~_8wekyb3d8bbwe
    Remove-AppxPackage -Package Microsoft.BingWeather_4.7.118.0_neutral_~_8wekyb3d8bbwe
    Remove-AppxPackage -Package Microsoft.Getstarted_2.5.6.0_neutral_~_8wekyb3d8bbwe
    Remove-AppxPackage -Package Microsoft.MicrosoftOfficeHub_2015.6508.23761.0_neutral_~_8wekyb3d8bbwe
    Remove-AppxPackage -Package Microsoft.MicrosoftSolitaireCollection_3.5.11021.0_neutral_~_8wekyb3d8bbwe
    Remove-AppxPackage -Package Microsoft.Office.OneNote_2015.6366.15841.0_neutral_~_8wekyb3d8bbwe
    Remove-AppxPackage -Package Microsoft.People_2015.1201.2033.0_neutral_~_8wekyb3d8bbwe
    Remove-AppxPackage -Package Microsoft.SkypeApp_3.2.1.0_neutral_~_kzf8qxf38zg5c
    Remove-AppxPackage -Package Microsoft.WindowsAlarms_2015.1161.20.0_neutral_~_8wekyb3d8bbwe
    Remove-AppxPackage -Package Microsoft.WindowsCamera_2015.1211.10.0_neutral_~_8wekyb3d8bbwe
    Remove-AppxPackage -Package microsoft.windowscommunicationsapps_2015.6515.64021.0_neutral_~_8wekyb3d8bbwe
    Remove-AppxPackage -Package Microsoft.WindowsMaps_4.12.11000.0_neutral_~_8wekyb3d8bbwe
    Remove-AppxPackage -Package Microsoft.XboxApp_2015.1209.230.0_neutral_~_8wekyb3d8bbwe
    Remove-AppxPackage -Package Microsoft.ZuneMusic_2019.6.15131.0_neutral_~_8wekyb3d8bbwe
    Remove-AppxPackage -Package Microsoft.ZuneVideo_2019.6.15731.0_neutral_~_8wekyb3d8bbwe

    Remove provisioning:

    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.BingFinance_4.7.118.0_neutral_~_8wekyb3d8bbwe
    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.BingNews_4.7.118.0_neutral_~_8wekyb3d8bbwe
    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.BingSports_4.7.130.0_neutral_~_8wekyb3d8bbwe
    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.BingWeather_4.7.118.0_neutral_~_8wekyb3d8bbwe
    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.Getstarted_2.5.6.0_neutral_~_8wekyb3d8bbwe
    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.MicrosoftOfficeHub_2015.6508.23761.0_neutral_~_8wekyb3d8bbwe
    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.MicrosoftSolitaireCollection_3.5.11021.0_neutral_~_8wekyb3d8bbwe
    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.Office.OneNote_2015.6366.15841.0_neutral_~_8wekyb3d8bbwe
    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.People_2015.1201.2033.0_neutral_~_8wekyb3d8bbwe
    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.SkypeApp_3.2.1.0_neutral_~_kzf8qxf38zg5c
    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.WindowsAlarms_2015.1161.20.0_neutral_~_8wekyb3d8bbwe
    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.WindowsCamera_2015.1211.10.0_neutral_~_8wekyb3d8bbwe
    Remove-AppXProvisionedPackage -Online -PackageName microsoft.windowscommunicationsapps_2015.6515.64021.0_neutral_~_8wekyb3d8bbwe
    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.WindowsMaps_4.12.11000.0_neutral_~_8wekyb3d8bbwe
    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.XboxApp_2015.1209.230.0_neutral_~_8wekyb3d8bbwe
    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.ZuneMusic_2019.6.15131.0_neutral_~_8wekyb3d8bbwe
    Remove-AppXProvisionedPackage -Online -PackageName Microsoft.ZuneVideo_2019.6.15731.0_neutral_~_8wekyb3d8bbwe

    Get-AppxPackage -AllUser | Where PublisherId -eq 8wekyb3d8bbwe | Format-List -Property PackageFullName,PackageUserInformation

    Get-AppxProvisionedPackage -Online | Select PackageName

    Our image is rock solid and functions as expected.

    Wednesday, December 30, 2015 6:37 PM
  • I didn't have this problem with 10240, but encountered this issue when upgrading to 10586. If I reimage my Surface with 10240, run the updater to 10586, all new local users can not use the Start Menu, Surfaces don't join domain here. If I had a user account before upgrading then that will continue to work.

    Once I took out the CopyProfile from the unattend, I can upgrade to 10586 and create new users.

    How silly is that? And from this thread it looks like it is an issue that MS has not addressed. Now what are we supposed to do if we can't CopyProfile in unattend or do the ancient way of copying the user profile to default user?

    Wednesday, December 30, 2015 7:07 PM
  • Do you use the USMT? 

    We were able to use various work-arounds to fix the start/search in the image, and new profiles would work but any profile created by loadstate would re-introduce the problem.

    Of course, removing the CopyProfile allows everything to work.

    Wednesday, December 30, 2015 8:16 PM
  • Okay, these issues were reported in August.  It's now one day from 2016, and the issues are still happening.

    When is this going to be resolved?  If we can't get some service, I might as well cancel our service agreements with Microsoft because they're not doing us much good.

    Just to recap:

    • Issues with Start and Cortana/search after Sysprep with CopyProfile enabled
    • Issues with Start and Cortana/search after Sysprep for profiles that were created before Sysprep was run (a setup that is often necessary for our public/kiosk computers)
    • Problems with the "Quick access" area of File Explorer with new profiles when CopyProfile was enabled

    Someone from Microsoft needs to address these issues.  I'm tired of this s**t.  I'm tired of using work-arounds to make Windows 10 usable, I'm tired of finding all the problems that Microsoft should have found itself, and I'm tired of trying to diagnose said problems.

    These three issues are real issues.  They are not mere inconveniences.  It's time for someone from Microsoft to speak up.

    Oh, and for the record: don't dare ask anyone to "report this in the Feedback app."  It's been reported in the Feedback at least since June.  Again, I'm getting really frustrated.  Are you guys planning on killing off Windows 10 like you did Windows 8?  Because that seems to be what's happening here.
    • Edited by Jason.C.F Thursday, December 31, 2015 12:20 AM
    Thursday, December 31, 2015 12:17 AM
  • We have this problem too.  I install Windows, make a local user account, and then Sysprep/generalize with COPYPROFILE enabled.  Search and Start are broken after this.

    When will Microsoft fix this?
    Tuesday, January 05, 2016 2:06 AM
  • I've got a 10586 build with no updates.

    I see that copyprofile=true works fine (except the quick access desktop issue) if I sysprep my image and then reboot the machine. The admin profile is copied to the default user successfully. I confirm this by checking the c:\windows\panther\unattendgc\setupact.log file and it has the following line

    "[Shell Unattend] CopyProfileDirectory from C:\Users\Administrator succeeded."

    When I use SCCM to deploy the same sysprepped image and configure the task sequence step to use the unattend.xml with copyprofile=true I see the same issues (start menu, search and quick access desktop) others report. In the c:\windows\panther\unattendgc\setupact.log file it now says

    "[Shell Unattend] CopyProfileDirectory from C:\Windows\system32\Config\systemprofile succeeded."

    This is NOT the profile I want copied... I need the Administrator profile copied.

    What are you guys seeing in c:\windows\panther\unattendgc\setupact.log file CopyProfileDirectory section??? success, error, fail etc?


    Tuesday, January 05, 2016 5:08 PM
  • Hello,

    When you run Sysprep with copyprofile settings, the profile copied is one that Sysprep was run under.

    SCCM runs under a System context rather than a user context which is why you had that profile copied.


    Thanks, Darrell Gorter [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, January 05, 2016 7:00 PM
  • to clarify ... i ran sysprep as the administrator. then captured the image. then imported it into sccm.

    I assume you mean sysprep continues under SCCM with the system context... which would explain why the system profile gets copied instead.

    I think I'm the only one running it in sccm while still experiencing the same issues (broken start menu, search etc), so I wonder what error others are seeing in those logs.

    I didnt have this issue in SCCM with WIN7,8 or 8.1   

    Running the latest SCCM 2012 R2 SP1 CU1





    Tuesday, January 05, 2016 7:56 PM
  • Hello,

    There was a change to Sysprep in Windows 8.1, I believe, to use the profile that Sysprep was run under.  There were issues with how it worked with prior releases as to which profile would be copied, it was not always easy to identify the profile copied so you wouldn't have see it in Windows 7 or Windows 8.

    Checking to see if this is the actual issue with breaking the start menu.


    Thanks, Darrell Gorter [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, January 05, 2016 10:32 PM
  • Darrell, are Microsoft engineers aware of the issues identified in this thread?  They are 100% reproducible every single time and were reported in the Feedback app nearly a year ago, but there has been no public acknowledgement that these issues are being worked on.

    Can you please just find out if this issue is worked on by Microsoft?

    Wednesday, January 06, 2016 2:29 AM
  • Hello,

    The initial issue with Search not working after using Copyprofile was fixed in the November update, this was tested and validated.

    Now it appears that are some other scenarios that may not have addressed all those.


    Thanks, Darrell Gorter [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, January 06, 2016 5:32 PM
  • Yes the issues seemed to have been addressed (search/start menu working) when I'm NOT using SCCM. But the copyprofile issues still exists when using SCCM.

    As mentioned... c:\windows\panther\unattendgc\setupact.log file indicates which profile is being copied during the copyprofile step. Hopefully someone can confirm what they are seeing in this log when it works or fails.

    During SCCM the systemprofile is copied instead of admin profile which breaks start menu/search. 

    Darrell,

    you mentioned something about Win8.1 profile issues before. Was there a workaround or some update that resolved that issue that I can possibly try for WIN10?

    Wednesday, January 06, 2016 6:04 PM
  • Darrell, would it be best at this point for me to create a new thread with the bugs listed that definitely exist and how to reproduce?
    Thursday, January 07, 2016 2:38 AM
  • I see the same problem when deploying 1511 via SCCM.

    Jason/da1Nonly,

    My log shows that the correct profile is being copied "[Shell Unattend] CopyProfileDirectory from C:\Users\Administrator succeeded." but the Start Menu and search bars are still broken (neither is clickable for any user who logs in). And of course there is still the issue with the desktop link that everyone knows about by now. I'm about to do my first tests without CopyProfile and I'll let you know how it goes.

    Darrell,

    What scenario was actually fixed in 1511? OSD via SCCM is a pretty basic deployment scenario and for that to not have been validated is hilariously sad.

    Thursday, January 07, 2016 3:42 PM
  • Hello da1Nonly_jsa,

    There wasn't an issue with Win8.1 profiles, what I mentioned was a change in Windows 8.1 as to which profile was copied when running Sysprep.  This was not a reported issue in Windows 8.1 so there wasn't a workaround.


    Thanks, Darrell Gorter [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, January 07, 2016 5:44 PM
  • Hello Jason,

    That would probably be good, there may be more than one issue listed, don't want to miss any or the issues that may get lost in longer threads.


    Thanks, Darrell Gorter [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, January 07, 2016 5:46 PM
  • Hello Caf83,

    The issue fixed was the failure of search after running Sysprep with the use of copyprofile.  This was fixed( at least outside of use of SCCM), but it appears that with the use of SCCM it still happens, that is being looked into.


    Thanks, Darrell Gorter [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, January 07, 2016 5:49 PM
  • Actually there were issues reported in these forums with the change to the windows 8.1 profile copying.  I'm not sure if it was "officially" reported though.

    But I tried the 8.1 workaround posted in another thread Windows 8.1 Copyprofile Issue (SCCM 2012R2 MDT 2013) (ie run sysprep manually instead of using the SCCM capture iso, and import image into sccm after capturing wim).

    This resolved the copyprofile issue in SCCM OSD for me. It seems the images I was creating using SCCM build and capture tasks or SCCM media were importing into SCCM as OS Version 6.2.10586.0 or 6.2.10240.0 (ie. WIN8) 

    Trying the workaround suggested in the link above ... I was able to import an image that shows an OS Version of 10.0.10586.0  This image worked with copyprofile enabled and copied the admin profile NOT the systemprofile to the default user for me. without any start/search bar issues.

    I'm going through all the components in SCCM again to ensure that all things were updated correctly to support WIN10 integration. (adk 10 etc) It seems the build/capture maybe tagging the OS version incorrectly in the wims.

    EDIT:

    all components in sccm have been updated to use the 10586 adk.

    It seems the copyprofile breaks in SCCM only when I use the capturecd to pull the wim. But if I manually sysprep and pull the wim to import into SCCM the copyprofile works.

    Thursday, January 07, 2016 7:04 PM
  • Did you change anything else (updates, unattend, etc.) before it worked or were the only differences the manual sysprep and capture?

    I have always done my sysprep and capture process manually and my imported OS version is the correct one yet I still have problems with the start menu.

    Edit: I figured out my problem. It was stupid.

    During deployment with SCCM the system is being joined to the domain and a group policy was being applied which happened to disable the Windows Firewall service. If that service isn't running then AppX packages are prevented from installing and that's why none of them (start, search, action center, etc.) were available when a new user was logged in.

    • Edited by Caf83 Monday, January 11, 2016 3:52 PM Solution found
    Thursday, January 07, 2016 9:31 PM
  • Please provide a link to the new thread for those of us following along at home. Thank you!
    Tuesday, January 12, 2016 10:25 PM
  • I would like to post that perhaps the Search/Cortana bar fix in the November update may not be completely fixed.

    We currently do not use SCCM/MDT to create or deploy our clone images.  We do use the CopyProfile function in sysprep.

    Prior to the November update, using CopyProfile in sysprep caused the Start Menu to not open, Search/Cortana bar not to open, none of the modern apps would run, couldn't open the Notification system tray app.  Basically the computer wasn't usable.

    After the November update, it did appear these things were fixed.  (Well, all except the 'Desktop' shortcut in Quick Access still pointing to the inaccessible "Administrator" account desktop.)

    I've been creating our clones since the November update and verifying they work on our various model computers these past 2 months.  (p.s. - I HATE that hardware drivers are forcibly installed via Windows Updates.)  Everything appeared to be working great.  However, on a few occasions, these exact issues of the Start Menu not opening, etc. would randomly popup out of nowhere on a computer previously functioning fine.  A simple reboot corrected the issue and we kind of just scratched our heads.  But yesterday, we had a computer completely break and nothing could recover it.

    All the computers are running the exact same clone image and for the most part, everything was going great.  But on this computer yesterday, the Start Menu just stopped working, Search/Cortana wouldn't open, couldn't open the Store or Notifications, etc.  The EXACT same problem we had to deal with for months in the beta and initial release of Windows 10!  On this computer we had to re-image it to get it to function.  This computer ran fine for about 4 hours and it was in the afternoon that it stopped working.  We couldn't determine what caused the problem.  After reimaging the computer with the exact same image, it's been running fine for a few days now, so we are stumped.

    After the November update, I was quite confident about deploying Windows 10 with our images.  But after yesterday, my confidence is broken that we can deploy Windows 10 in our environment.  The previous few instances of the Start Menu not working and requiring a reboot to fix it and now with this computer completely broken yesterday, I simply don't trust that this problem is completely solved.  If it has happened randomly already a few times in our limited testing, how many times will it happen if we deploy to hundreds or thousands of computers?  How can we put this on all those machines knowing this problem may be waiting for some mysterious event to occur and pop up?

    We are at a point where we don't even know how to troubleshoot this problem anymore and I can't properly express my frustration with Windows 10 and using the CopyProfile function.  Without the ability to use CopyProfile, what is the point of deploying Windows 10 in an enterprise environment?

    I wished I had some info I could post to help figure out what is happening, because nothing is more frustrating than troubleshooting a problem with nothing other than "it broke", but we don't know what caused this.  Does anyone have any ideas of what we can try to troubleshoot this?  If the solution is to not use CopyProfile, then as far as I'm concerned, that's telling us not to use Windows 10.

    One final item.  Browsing through Event View - Application log, I find an event from the source ESENT that is of interest.  It is an error with an event id of 494.  This event is referencing "taskhostw (4408) WebCacheLocal: Database recovery failed with error 1216 because it encountered reverences to a database, 'C:\Users\Administrator\AppData\Local\Microsoft\Windows\WebCache\WebCacheV01.dat', which is no longer present."  Take note that it is referencing the "Administrator" account folder!  When we customize the profile, we are doing it logged in as the Administrator account.  So it seems CopyProfile is having an issue here too as it should not carry over a reference to that account.  I doubt this is the cause of the Start Menu issue, etc. because this event shows up on computers currently running ok, but it does make me wonder if CopyProfile brought over this invalid reference, what else did CopyProfile mess up?

    Wednesday, January 13, 2016 2:25 PM
  • can we rule out updates? safe to assume that all these machines with this cloned image received the same win updates? 

    can we also rule out user profiles corruption issues? any user (new or previously cached) now logging into a broken machine all see the start menu issue once it breaks?

    This is very troublesome as I'm assuming that the November update should work now that I've found a workaround to get it to work in SCCM ... but if the endstate image will still randomly break the start menu/search on any pc down the road with no possible fix then I'd be hesitant to deploy this.

    Wednesday, January 13, 2016 3:06 PM
  • da1Nonly_jsa, there were hardware updates that always load after we drop the image, but I can't say if other updates loaded. However, even if they did, we put the exact same clone back onto the exact same computer and it's been running fine for 2 days now.  If updates caused this, it would have happened already as we told it to check for updates (as we normally do) after putting our clone image on the computer.

    For the profile, I do not believe it is profile corruption.  We do not use roaming profiles in our environment and the local profile was newly created.  In fact the user never actually logged off prior to the Start Menu breaking.  The computer was setup in the morning and they used it in the morning and remained logged in.  Whey they unlocked the computer in the afternoon, the Start Menu was broke.  I know that's not a definitive test, but I would lean towards saying the profile wasn't corrupted.

    I have to say seeing this issue pop up again out of nowhere after the November update surprise me.  We have just begun wider testing with Windows 10, so I guess if it had to happen, now is a good time, but considering Windows 10 has been a finalized product for some time now, I'm wondering at what point do we close our eyes and move forward to using Windows 10 in a production environment.

    It seems a few others here have referenced a similar issue using SCCM/MDT, and CopyProfile which is of interest to us as we plan to move to that environment eventually to create our clone images.  What is most frustrating is that prior to the November update, the CopyProfile problem happened almost every time instantly on first login.  After the update, we've seen it 1 time now, though our testing was previously limited.  But we can't really even troubleshoot something like this if it only happens once.  I'd like to ignore that it happened, because as I said, things were working quite well since the November update, but unfortunately we can't ignore that it happened.  We potentially could not use CopyProfile, but that is very undesirable to us, even though we may not have a choice if this occurs more as we expand testing.


    • Edited by KHHemmelman Wednesday, January 13, 2016 8:03 PM
    Wednesday, January 13, 2016 8:02 PM
  • Make no mistake: Windows 10 is absolutely a disaster.  I'm actually okay with the interface, but there is so much broken.  There are way too many bugs, especially stuff that matters to IT professionals and support departments.

    CopyProfile is obviously broken, as documented by this thread.

    Start and search are also broken for roaming profiles.  ROAMING PROFILES.  That's not a crazy, hacky technology.  A lot of places use roaming profiles, and it's a Microsoft technology.

    Start and search are also broken if you create a user account before running Sysprep.  Many places need that functionality because not every computer is an employee computer where an individual logs into it.

    Example: we have thousands of student/kiosk computers that have a generic local user account, and these computers have many customized settings that don't carry well with CopyProfile because CopyProfile literally does an exact copy; for third-party programs (and even some Microsoft stuff), CopyProfile won't, for example, change C:\Users\Administrator to the %HOMEPATH% variable in settings files and registry settings.  So, if you need to customize settings in, say, Photoshop for a a kiosk computer, it's important that the account be created before Sysprep is run.  That way, you can make all your Photoshop settings changes and know that they will still work in that local user account after Sysprep runs.

    But right now, this functionality is broken.

    What's worse is that many of these problems have been reported to Microsoft's Feedback app since before Windows 10 was released in July, and not only has Microsoft not fixed the issues, but Microsoft has not even hinted that they are being worked on.  So I don't know if I am wasting my breath here or what.  I wish I knew because if I knew this wasn't being worked on, I'd start looking for alternatives to Windows to transition my organization to by 2020 (when Windows 7 support ends).

    Thursday, January 14, 2016 1:13 AM
  • I have had this exact same issue on Enterprise 1151. Turning Protected mode off resolves the issue but is by no means a fix. You can also add the un-responsive site to the trusted sites list and leave protected mode on. Very disappointing.
    Friday, January 29, 2016 4:16 PM
  • We're having the same problem occur when attempting to make an image for our 200+ public computers. Any local account created before running Sysprep is doing this. Any accounts created after running Sysprep seem to be fine. We don't use SCCM, just ran Sysprep and captured a WIM using DISM.

    We're hoping to deploy this image over summer, but we'd like to have a bunch of testing done by our staff beforehand, so hopefully Microsoft will get this resolved quickly. 

    Monday, February 01, 2016 2:17 AM
  • Yup, just tested it. same problem here when we add <CopyProfile>true</CopyProfile> .XML file to the SCCM TS. MS windows version 10.0.10240.

    Thursday, February 11, 2016 11:22 PM
  • gmartin0813,

    Exact same issue? Did you read the post? This is a post about Copy Profile / Roaming Profile start menu and search not working. Yes, there was some peppering of additional issues, but please don't call your issue the "exact same" unless you are going to address it. Does you solution address the start menu or cortana search in any way? Probably not considering your fix is a browser "feature".

    I hate to see that you are having issues, but you can use various other browsers.  (You don't even specify which is being used, IE11 or Edge).  This actual topic is a major, major sticking point and should be the focus of this thread.  For all you folks talking browser issue, create a new post.  This one is too valuable to have it hijacked.

    Apologies for the rant, but I just spent 20 minutes of my day reading every single post, and this one just doesn't fit in the level of detail, or the topic at hand.

    For something on topic, I have seen some Start Menu craziness when working with Mandatory Roaming Profiles.  I have not been using Copy Profile at all, but still, it all centers around using a shared profile of some sort that wasn't originally permissioned by that user.

    Thanks to all the early adopters out there plugging away.  You are paving a road to the future, as frustrating as it may be.

    -LvilleSystemsJockey

    Friday, February 26, 2016 4:05 PM
  • blake.boman,

    Might I ask, why do you need a local profile in the sysprepped image?  Not on the domain?  I would maybe try USMT to pickup the profile from a running machine, then lay it down after the image in an automated process.  The tool is simple to use. 

    Interesting enlightenment.  We now have 3 or 5 different scenarios of Start Menu failures.  SysPrep seems to be the common denominator.

    -Lville


    Friday, February 26, 2016 4:13 PM
  • We probably don't "need" it, but we prefer to have it. In Windows 10, there are some things you can't customize under the Administrator profile that we would like to change (default location in the Weather live tile, Microsoft Edge settings, etc.), so we instead create a local account and customize that, then run sysprep under that account. Regardless, it's a problem either way.

    The November Update build fixed the issue we were having with the Start Menu not working after running sysprep, however we have had some other issues when using that. The shortcuts in the Quick Access pane in Explorer default to the user profile of the user that ran sysprep, so if sysprep was run under Administrator and you logged in using a different user account after sysprep, clicking on the Quick Access links result in a permission denied error. This is fixed by having a batch script run at the first login of any account and then deleting itself:

    echo Y | del %appdata%\microsoft\windows\recent\automaticdestinations\*
    del %0

    We saved the batch file to "C:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\quickaccess_fix.cmd"

    We've also run into another problem where CopyProfile only seems to work "sometimes" -- what we do is sysprep the image, then use a hard drive duplicator to duplicate that to multiple drives. We've deployed that same image to about 8 computers we are testing with, and on about half of them the desktop shortcuts and Start Menu changes we've made do not get copied over to the Default User profile.

    Just putting all of this here to document the problems we've encountered...


    • Edited by blake.boman Wednesday, March 16, 2016 2:26 PM
    Wednesday, March 16, 2016 2:23 PM
  • To Microsoft: where are we in fixing this?
    Friday, March 18, 2016 7:31 PM
  • Has anyone used the latest Windows 10 1511_updated_feb_2016 image? Are there fixes in it?
    Wednesday, March 30, 2016 12:34 PM
  • I would like to know the answer as well as Microsoft fixed the copy profile issue in Windows 10 1511_updated_feb_2016?

    Does anyone know?

    Thursday, March 31, 2016 12:33 PM
  • for me this image (Windows 10 1511_updated_feb_2016) is working with CopyProfile. Have now tried with and without using audit mode, both works. Please someone confirm
    Tuesday, April 05, 2016 4:28 PM
  • I just tried the CopyProfile using the following instructions from TenForums.

    http://www.tenforums.com/tutorials/2110-default-user-profile-customize-windows-10-a.html

    After running updates, the problem still persist.  Has anyone else validated?  I am eager for a resolution as most.  I have resorted to Group Policy, registry changes and scripts.

    Thanks

    Friday, April 08, 2016 3:47 AM
  • Also noticed when trying to save something to the Desktop on a new profile I'm met with an error stating:

    "Location is Not available, C:\Users\Administrator\Desktop is not accessible Access is denied."

    Almost seems like new profiles haven't fully cut ties with the Admin one that's being used as the default profile template.

    For me CopyProfile true is really messing up my Win10 image. It worked great in 7 and 8.1. Hope it's fixed sometime soon.

    Check this out 

    https://blogs.technet.microsoft.com/askcore/2015/12/21/users-cant-access-the-desktop-and-other-resources-through-quick-access-in-windows-10/

    There is also this which is worth checking out

    https://blogs.msdn.microsoft.com/beanexpert/2016/04/07/copyprofile-ie11-crash-windows-10/

    We are also seeing an issue where when we use copyprofile we hear a "ding" like a warning box has popped up as the machine is "Preparing Desktop" it then takes a lot longer than Windows 7 did to login.

    Wednesday, April 27, 2016 12:48 PM
  • 1511 Feb updates did not fix the issue for me.

    Just tried a simple copy the Default on Windows 10 TP Enterprise Build 14332 and Start Menu and Search work fine. This build is quite responsive.
    NOTE: This build 14332 is .V6

    Now it's time to try it with CopyProfile.xml in Audit Mode. Will report back.

    Monday, May 09, 2016 3:14 AM
  • Tested CopyProfile.xml in Audit Mode, Search and Start work fine. Haven't had any issues in that yet.
    Tuesday, May 10, 2016 4:52 AM
  • Hello folks!

    The data of the 29th July is coming and we want to migrate our infrastructure to Windows 10 for free. That's why I'm trying to do a Windows 10 syspreped image with customized parameters using the copy profile option.

    First of all, I'm using the following ISO to create my SYSPREP: SW_DVD5_Win_Pro_10_1511_64BIT_English_MLF_X20-82416.

    When booting in Audit Mode, I immediately do all the updates to have an up-to-date Windows 10 installation. Once it's done, after rebooting, I have activated the "Defer upgrades" option.

    Then I'm doing all the changes I need (modification of background, IE welcome page, scheduled tasks, etc) and then I created my sysprep with an unattend XML file which has the "Copy Profile" parameter set to "True".

    After deploying I noticed:
    - Problems with the "Desktop" icon in the "Quick Access" section which tries to go in the "Administrator" account (which is disabled after deployment).

    - Problems with IE which freezes when accessing several websites.

    I absolutely need to find workarounds for this and I already found these articles:
    https://blogs.msdn.microsoft.com/beanexpert/2016/04/07/copyprofile-ie11-crash-windows-10/ for IE problem
    https://blogs.technet.microsoft.com/askcore/2015/12/21/users-cant-access-the-desktop-and-other-resources-through-quick-access-in-windows-10/ for "Desktop" icon problem

    However, I think that it's not easy to solve!

    Can you help me? Are there any news about these problems? Did the last Windows Updates resolve these bugs?

    Regards!
    Wednesday, June 01, 2016 2:29 PM
  • I did some testing with 1511 as well. The search option and Store seem to work fine now, but one thing I noticed was specific to Edge and IE11. After I toggle copy profile to true, whenever I try to navigate to www.box.com (and this could affect other sites) I get weird pauses and non-responsive errors while it tries to load. The same site(s) work fine in Firefox and Chrome. And, if I toggle copy profile back to false and try a fresh profile, that same site loads fine on Edge and IE11. Our organization heavily uses Box, so it was a obvious test choice for us. I'm guessing there is something in the user registry hive that might be causing it.

    Can anyone else confirm this on build 1511?

    i'm noticing this same thing w/build 1511 and support.microsoft.com in IE11 and Edge too. same exact behavior and does not occur when i have copyprofile = no.  i'm about to put in an official microsoft ticket and will post my results of that ticket. i bet its a bug like the GUI not showing the proper KMS key if you also install Office 2016 with a KMS client key. ;)


    Paid IT Geek; mobile/desktops/deployments

    Wednesday, July 27, 2016 10:17 PM
  • This issue has RETURNED for Win10 1703, aka Creators Update.  CopyProfile worked fine in 1607 (Anniversary), but now on 1703 I customized the Administrator profile in Audit Mode and tried sysprepping it both before installing any updates (10.0.15063.0) and after installing the latest Cumulative Update (10.0.15063.13), and it made no difference.  When CopyProfile was specified in the unattend file, Search was completely broken after booting the image (I could type in the box and select what types of content to search for, but no results of any kind ever showed up), and when I omitted CopyProfile, Search worked just fine after deployment. Has anyone else noticed this and perhaps found a fix?

    On a side note, the issue about the broken Desktop icon in Quick Access when using CopyProfile has been fixed in 1703, but this feels like one step forward and two steps back.


    • Edited by jphughan Tuesday, April 11, 2017 4:29 AM
    Monday, April 10, 2017 7:48 PM
  • This issue has RETURNED for Win10 1703, aka Creators Update.  CopyProfile worked fine in 1607 (Anniversary), but now on 1703 I customized the Administrator profile in Audit Mode and tried sysprepping it both before installing any updates (10.0.15063.0) and after installing the latest Cumulative Update (10.0.15063.13), and it made no difference.  When CopyProfile was specified in the unattend file, Search was completely broken after booting the image (I could type in the box and select what types of content to search for, but no results of any kind ever showed up), and when I omitted CopyProfile, Search worked just fine after deployment. Has anyone else noticed this and perhaps found a fix?

    On a side note, the issue about the broken Desktop icon in Quick Access when using CopyProfile has been fixed in 1703, but this feels like one step forward and two steps back.


    It's an issue when capturing an image using the Build n Cap / Capture ISO from SCCM. If you manually capture the image using imagex, with the copyprofile unattend.xml - it works. Totally a pain. I just had this issue (start menu and Right-click Personalize) with Win10 1607 :-(
    Friday, April 14, 2017 3:50 AM
  • This issue has RETURNED for Win10 1703, aka Creators Update.  CopyProfile worked fine in 1607 (Anniversary), but now on 1703 I customized the Administrator profile in Audit Mode and tried sysprepping it both before installing any updates (10.0.15063.0) and after installing the latest Cumulative Update (10.0.15063.13), and it made no difference.  When CopyProfile was specified in the unattend file, Search was completely broken after booting the image (I could type in the box and select what types of content to search for, but no results of any kind ever showed up), and when I omitted CopyProfile, Search worked just fine after deployment. Has anyone else noticed this and perhaps found a fix?

    On a side note, the issue about the broken Desktop icon in Quick Access when using CopyProfile has been fixed in 1703, but this feels like one step forward and two steps back.


    It's an issue when capturing an image using the Build n Cap / Capture ISO from SCCM. If you manually capture the image using imagex, with the copyprofile unattend.xml - it works. Totally a pain. I just had this issue (start menu and Right-click Personalize) with Win10 1607 :-(

    I don't think that's the whole story. I'm currently using DISM from the Win10 1703 Setup environment to capture the image, then using Imagex to set the edition flag so it can be redeployed through Windows Setup and I'm still getting this issue, but it also occurs if I just sysprep my image and reboot that same system to let it go through the unattend steps in-place, without ever capturing and redeploying elsewhere. If it matters, my unattend file creates 2 users, skips all OOBE, and automatically logs on.
    • Edited by jphughan Friday, April 14, 2017 2:19 PM
    Friday, April 14, 2017 2:17 PM
  • Same here with Creators Update 1703 - clean MSDN iso, Win 10 Pro installed on VM, I've made some tweaks in audit mode (without any connected network), cleaned Start Menu from adv.crap and so, syspreped with /reboot /oobe (for experiment, without needs to capture an ISO) and after 1st logon of any new user (created in oobe or after from settings) - troubles with Search and bug with Edge still present (cannot add any new Search Provider or clean browser's cache). 

    Haven't seen any of this in previous 1607 Anniversary Update, Audit-Sysprep-CopyProfile works in that build like a charm

    Friday, April 28, 2017 1:08 PM
  • Anniversary Update doesn't work for me....

    Tried both capturing with MDT bld 8443 and manually running sysprep and then importing wim file. Tried both setting copyprofile during the manual sysprep process - /unattend:filename.xml and setting copyprofile in the unattend file in MDT.

    Issue is any customizations to the Start Menu get lost. I remove copyprofile and it works fine (but all the profile customizations obviously then get lost).

    Windows 10 is easily the worst OS since XP for deployment. Period.

    Friday, July 14, 2017 3:01 PM
  • I'm afraid of using copyprofile.

    For the start menu, you can export an xml file in powershell, then import it for all new users:

    # import start menu

    # run with powershell -file scriptname.ps1

    # to create xml file: # export-startlayout -path startmenu.xml -verbose import-startlayout -layoutpath startmenu.xml -mountpath c:\ -verbose if ( -not $? ) { exit 1 }

    Pin apps to the Taskbar in Windows 10 1607 with Group Policy

    https://4sysops.com/archives/pin-apps-to-the-taskbar-in-windows-10-1607-with-group-policy/

    EDIT:

    For taskbar pins, you have to put in the xml for it by hand.

    • Edited by JS2010 Friday, July 14, 2017 6:57 PM
    Friday, July 14, 2017 3:19 PM
  • All of which doesn't work if you use copyprofile ;)

    Someone else mentioned that MS re-released the volume license disc for Anniversary update - bld 1607.1. So I tried that as well but again, copyprofile breaks any Start Menu customizations.

    I defy anyone to get a customized Start Menu using MDT and CopyProfile=true working.

    Update: Ok, I got it working. I had to add the following line to the batch file which copies and imports the StartLayout...

    rmdir C:\Users\Default\AppData\Local\TileDataLayer /q /s

    • Edited by PondoS Tuesday, July 25, 2017 8:25 PM
    Monday, July 24, 2017 8:11 PM
  • i have several problems after deploying windows 10 pro with mdt to a client and after logging in with a domain account. Windows 10 is version 1703. All kind of webcache event errors and edge is not working, services takes a long time to start and several other apps not starting.

    This is when i log in with a domain account after deploying. Right after deploying when administrator is logged in there is no problem.

    Can this be solved yet?


    freddie

    Tuesday, September 05, 2017 9:51 AM
  • Check Event Viewer for ESENT logs.  Bet you have a bunch advising the it cannot access C:\Users\Administrator\Local\Micrsoft\Windows\Webcache.

    If you give "everyone" full access to the Administrator profile - the problem will go away.  But that is only a work around, not a fix.

    Trying to solve it myself.  

    Wednesday, September 20, 2017 5:20 PM
  • Hello

    what Windows buid? 1703 or 1607?

    have you tried 1709?

    Friday, November 24, 2017 7:13 PM
  • I'm also facing the same problems

    Now, with 1709.

    Any solutions?

    Thursday, December 14, 2017 10:19 AM