Copyprofile, IE11 crash on Windows 10


Hi everyone!

Today I would like to talk about an issue I faced recently. I think many of our customers are still using the "CopyProfile" setting available in the answer file (unattend.xml) to copy the built-in administrator profile to the default profile. That way, when a new user is created on that machine, it will get all the customization done on the administrator profile.

Before explaining how to solve that issue, I strongly recommend avoiding using CopyProfile and doing all the customization during the deployment using task sequences for instance.

Symptom

The recent issue I faced is IE11 (with Protected mode enabled) crashing continuously on Windows 10 computers where CopyProfile has been used.

Reason

The reason for those crashed has been identified and it appears that after running sysprep with copyprofile setting enabled, all of the Low Mandatory Level ACL of "%userprofile%\AppData\LocalLow" folder are missing.

Workaround

There's 2 solutions whether you have already deployed computers using copyprofile or if you want to solve that issue proactively on not yet deployed computers.

For already deployed computers

Deploy through script under the user context the following command line to add the missing permissions:

icacls %userprofile%\appdata\locallow /setintegritylevel (OI)(CI)L

icacls %userprofile%\appdata\locallow\microsoft /setintegritylevel (OI)(CI)L

icacls "%userprofile%\appdata\locallow\microsoft\Internet Explorer" /setintegritylevel (OI)(CI)L

For computers not yet deployed

For computers which are not yet deployed, we can solve that issue editing the master image. After having captured your master image, delete the following folder:

C:\Users\Default\AppData\LocalLow

You can also do that during the final image deployment within a MDT/SCCM task sequence. To do that, you just need to be aware that the RD (rmdir) command line cannot delete hidden folder. In our case, "Default" and "AppData" folders are both hidden. To automate the deletion of the LocalLow folder, we need to unhide, delete then hide again the concerned folders.

Here is a sample script to delete LocalLow folder:

ATTRIB -H "C:\Users\Default"
ATTRIB -H "C:\Users\Default\AppData"
rd /Q /S "C:\Users\Default\AppData\LocalLow"
ATTRIB +H "C:\Users\Default\AppData"
ATTRIB +H "C:\Users\Default"

Hope it will help solving the IE crash issues on computers where CopyProfile has been used 🙂

Good Windows 10 deployment to everyone!!

Comments (6)
  1. Elily says:

    Hi everyone!

    I mounted my master image and followed the steps to delete the LocalLow folder and solve the IE issue but there’s no LocalLow folder under my Default profile. Yes, I’ve already enabled the “Hidden Ítems” checkbox and still misssing.

    What else can I do? I need to use the CopyProfile because I have a lot of customizations that I’m not able to define on the deployment process.

    Thank you.

    1. Did you mean you mounted the master image and didn’t find the locallow folder?
      Probably the issue is that the copyprofile hasn’t been executed yet (the profile copy is done during the deployment phase and not the capture phase). Thus, I guess the locallow folder from the administrator account is still not yet copied to the default profile. What I strongly recommend is to use the script in your deployment task sequence (or in a setupcomplete.cmd) to delete the locallow folder before a new user is created.

  2. Dave says:

    Why is this not fixed? CopyProfile is necessary.

  3. Kyle says:

    I can confirm the command line for computers not deployed yet is running and working correctly….but it is not solving my issue. Same crashes from IE over and over.

    1. Hi Kyle! Based on my experience, every customer I met having that IE crashed could solve their issue running those commands. Basically IE crash because some permissions are missing on the IE Sandbox folder. To see if it’s still related to a permission issue, could disable in IE the protected mode and test again on the same site which made your IE crash?
      Usually, even without running the commands I presented in this article, just disabling IE Protected Mode solve the issue (not really since IE Protected Mode is more than recommended). But at least, it can help differentiate issues.

  4. JayKno says:

    Thanks, this worked like a charm.

Comments are closed.

Skip to main content