App Layering (4.0 - 4.5) : The Enterprise Layer Manager (ELM) fails while publishing an image.

Error: "A failure occurred while importing the Layered Image. Failed scanning a directory for files"

Be aware that this article is specifically about NTFS attribute handling regarding files in the Microsoft.MicrosoftOfficeHub package.  The actual error message is telling you only that there was an error reading files from the Gold Image disk and writing them into a new filesystem.  In addition to this specific article, this could happen because the disk needs a CHKDSK, issues sizing the new layer VHD, or other NTFS compatibility issues.  It is always worthwhile to check the UniSysLibLog file to find out exactly where the import copy process failed.

Recommended Solution: This issue has now been fixed in versions 4.6+ of App Layering. The simplest way to resolve this issue is to upgrade the latest version of the App Layering appliance.



For historical purposes, here is the original fix for those who are still running versions 4.5 or earlier of the App Layering product:

This error is most frequently caused by Microsoft OfficeHub. The "Program Files\WindowsApps\Microsoft.MicrosoftOfficeHub" directory has a new type of reparse point that was recently invented by Microsoft, and ntfs-3g is currently unable to handle it. Thus, there is no way for the our Linux virtual appliance (App Layering ELM) to correctly recognize the files. So we'll need to remove them before working in App Layering. There is no negative effect to removing the OfficeHub files, as the files will be rebuilt automatically on end user desktops.

The fix needs to be executed in the Gold VM that we are trying to import.

Old Solution 1: PowerShell

On the OS layer, running the following two PowerShell commands (from command prompt as administrator) might be able to remove the folders without manually setting permissions and deleting them  Sometimes, manually deleting the folders can be a long and painful process. Make sure to run the PowerShell commands as the admin that originally created the image. It is possible that OfficeHub may already be staged for the original user, and will deny removal from the following script if that is the case.
 

powershell -command "& {Get-AppxPackage -name Microsoft.MicrosoftOfficeHub -AllUsers | remove-appxpackage}"

powershell -command "& {Get-AppxProvisionedPackage -online  | Where-Object {$_.DisplayName -like \"*Microsoft.MicrosoftOfficeHub*\"} | remove-AppxProvisionedPackage -online}

Old Solution 2: Manually changing the file permissions, and then deleting them

Check to make sure the files are located in the "Program Files\WindowsApps\Microsoft.MicrosoftOfficeHub" directory. The files will need to be deleted out of this folder, and typically you'll need to take ownership and change permissions in order to remove them.

Additionally, on Windows 10 Enterprise machines, you may also need to check and remove the OfficeHub directory from "\users\Administrator\appdata\local\packages\Microsoft"

Lastly, make sure Program Files/WindowsApps/Deleted/Microsoft.MicrosoftOfficeHub_17.8010.5926.0_x64__8wekyb3d8bbweb6a07f30-3c9c-4a53-867e-42e7a1f58db8* is empty.

_______________________________________________________________________________________________

In extreme cases, the $recycle.bin may also need to be completed deleted.

The following command will delete the $RECYCLE.BIN - then the OS will refresh and recreate it automatically, without any artifacts from OfficeHub.

RD /S /Q Drive-Letter:\$Recycle.bin

---

Problem Cause

Program Files\WindowsApps\Microsoft.MicrosoftOfficeHub are not able to be copied when importing a new Gold Image. The import fails if the Windows 10 gold has Windows Updates Including Feb 17, 2017 and newer.

The files located in the "Program Files\WindowsApps\Microsoft.MicrosoftOfficeHub" directory are not able to be copied by NTFS-3g

When trying to import Windows 10 Gold Image into Unidesk/Citrix App Layering (4.x), the task fails on trying to copy Folder: Windows\Microsoft.MicrosoftOfficeHub_17.7909.7600.0_x64

The root cause of this issue can also manifest itself during the import process: https://support.citrix.com/article/CTX226548