Issue: We Were Unable To Attach Your User Layer

Environment

• App Layering ELM 2003
• Windows 10 1909

Issue

Working recently with a customer deploying User Layers to enhance their existing App Layering deployment, we ran into a not-so-uncommon error, albeit one with a less common cause.

Users received the error “We were unable to attach your User Layer” during desktop launch as seen below.

The environment was pre-existing, and the ELM had been set up prior, and the network path set for repository files (JSON files, metadata, software updates, etc.) was previously set. The customer, however, wanted a different path to be used for their User Layers in order to use a different storage solution.

We had gone about creating the User Layer storage location configuration in the ELM, defined the user groups to apply to, and the path. it was set with a higher priority than the default location as shown.

The image was published, catalog created, and we were ready to test our User Layer setup for this particular customer. Unfortunately, out of the date, we were encountering errors on login, citing permissions issues accessing the share location. Stranger yet, the path listed was the network file share path location set in ELM’s “Settings and Configurations” pane. We had definitely published the image after creating the User Layer storage location.

We hit up CTX227272 to review the situation, and the RepositoryPath location in the image was indeed matching the SMB file share path from the ELM, and not our User Layer location. This isn’t all that clear in the CTX KB when using an alternative location for User Layers; one could interpret that the RepositoryPath could be the User Layer path we set earlier (needing to be set prior to creating the image lest we update the registry manually).

For fun, we did alter the registry path in the image and updated the Machine Catalog and it got us by. However, we later found out we really don’t want to mess with the registry key, it is in fact set correctly, and changing it to the direct path to the User Layer share would break any future use of Elastic Layers (they did not have this deployed presently), leaving us to continue troubleshooting the issue as our band-aid was not good form.

Resolution

One thing we’d forgotten to check was the permissions of the SMB file share path location used by the ELM itself. This is mentioned briefly in the “Set Up File Share” requirements section for the path (again, not the path for the User Layer share, but the path the ELM uses for its other functions).

The User Layer (and consequently Elastic Layer) configurations defined in ELM have their configurations stored in JSON files in that SMB file share as well. Users interfacing with the VDAs need read-only NTFS permissions to the share ELM’s SMB network file share. If they cannot access the share and read the JSON files at logon, User Layer will default to that SMB file share path. This is why we saw the path details we did. If we had share permission issues with the User Layer share (with read-only permissions set properly on the network file share), the logon error would reflect the User Layer share path instead, indicating the VDA was at least was able to read the JSON files under the user’s credential context.

Also worth noting, updating User Layer share path does NOT require re-provisioning the layered image (which again, could be interpreted in that manner from the KB), any changes to the JSON file resulting from changes we make to the User Layers share location in ELM, are picked up on next login.

So there you have it, a minor permissions issue was the cause, as the customer had not set this prior, as there had been no initial plans to use Elastic or User Layers when their original deployment was conducted. User (whoever is logging into the VDAs) read access granted to the ELM’s network share squared things away.

Special thanks to Tyler Benoit for the suggestion!