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

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

Unidesk 2.x/3.x: The CachePoint Appliance fails while creating a desktop.

• Error: "Failed to copy folders recursively"

​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.

* Update: This issue can also be caused by apps that use invalid windows file names.  One example is CON.<anything>.  CON is a reserved file name. In one case, CygWin was used to install a package which included /cygwin64/usr/share/avogadro/crystals/zeolites/CON.cif. The ELM will fail to copy this file because it is not a valid name. The only current solution is to delete the file.

For historical purposes, here is the original fix for those who are still using 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 our Linux virtual appliance (App Layering ELM) to correctly recognize these files. So we will need to remove them before working in App Layering. There is no negative effect to removing the OfficeHub files, as these files will be rebuilt automatically on end-user desktops.

The fix needs to be done in the VM or layer where the problem files are present. If the error occurs while publishing a VM (App Layering versions 4.x) or during desktop creation (versions 2/3.x), or while editing/creating layers, then you will need to execute the fix on the specific layer that is causing the issue. Usually, the problem is in the OS layer, so you would need to execute the solution on a new version of the OS layer. However, it is also possible that the offending files are on an application layer or the platform layer, so you may need to experiment to determine which layers the files are located on. If you cannot find them in file explorer for any of the layers, you should open a Technical Support case, and one of our engineers will be able to make that determination.

Solution 1: PowerShell

On the OS layer, running the following two PowerShell commands (from the 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}

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

Make sure that 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

The files located in the "Program Files\WindowsApps\Microsoft.MicrosoftOfficeHub" directory are not able to be copied by NTFS-3g. The publishing process may fail if any of the layers have Windows Updates Including Feb 17, 2017, or newer.

When publishing an image template from App Layering 4.x, the following error appears: "App Layering fails to publish "A failure occurred while publishing the Layered Image: Failed scanning a directory for files.”

 The root cause of this issue can also manifest itself during the import process. Refer to CTX222733 - Unable to Import Windows 10 Gold Image into App Layering ELM: "Failed scanning a directory for files".