Forum Discussion
David Schrag
Mar 08, 2021Iron Contributor
Assigning permissions when using Azure Files for FSLogix Profiles in WVD
My goal is to use a share in Azure Files to house the FSLogix profiles for users in a Windows Virtual Desktop (WVD) environment that is part of an Azure Active Directory Domain Services (AADDS) domai...
David Schrag
Mar 18, 2021Iron Contributor
YannickJanssens1986 My FSLogix profiles still aren't working right. I am seeing event log errors during login that indicated access rights problems connecting to the FSLogix share. So I tried to review and modify the permissions by mapping a drive through file explorer while logged in as an AADDS domain admin. I can view the permissions but I can't modify them. I get "Failed to enumerate objects in the container." The owner of the mapped drive is shown as SYSTEM. I tried to take ownership, but got the same "failed to enumerate" error. So maybe once the share's permissions are set using the access key they can no longer be modified by a user account through the GUI?
In any case, I'm not sure what the permissions for standard users are supposed to look like. Apart from some duplication of users and groups here, is this right, particularly with respect to the "applies to" column?
Perhaps I should start over with a new share and set the permissions with the GUI instead of the command line, but I don't have guidance for doing it that way.
YannickJanssens1986
Mar 18, 2021Brass Contributor
Your user needs to have SMB Elevated Contributor RBAC role on the share if you want to change permissions or connect using the Access key (you'll operate under SYSTEM then).
Does the group WVD Users have SMB Contributor RBAC role on the share?
Try verifying access before logging on through WVD. Try running Powershell as one of those users (via 'Run as Different User' context menu option) and then mapping the drive like 'New-PSDrive -Name Z -PSProvider FileSystem -Root "\\xxx.file.core.windows.net\share" -Persist'
Does the group WVD Users have SMB Contributor RBAC role on the share?
Try verifying access before logging on through WVD. Try running Powershell as one of those users (via 'Run as Different User' context menu option) and then mapping the drive like 'New-PSDrive -Name Z -PSProvider FileSystem -Root "\\xxx.file.core.windows.net\share" -Persist'
- David SchragMar 19, 2021Iron ContributorI assigned permissions at the storage account level and they are inherited down to the share. Is that OK? My WVD Users group has SMB Share Contributor permissions, and my AAD DC Administrators group has SMB Share Elevated Contributor permissions. The wvdsetup account, which I was using to produce the screen shot in the last post and which is unable to adjust permissions, is a member of AAD DC Administrators and WVD Users.
I had no problem creating folders or text files on the share as a member of WVD Users once I logged in, so at some basic level the permissions are working OK. But profile creation isn't working. I was thinking perhaps that the problem was because the Modify rights to the share were "This folder only," instead of "This folder, subfolders, and files." That's what I was going to test if I had been able to change the permissions on the share, but I wasn't able to while using the wvdsetup account and File Explorer. But according to https://docs.microsoft.com/en-us/fslogix/fslogix-storage-config-ht?WT.mc_id=Portal-Microsoft_Azure_Support, the way it's set now should be fine.
I don't actually have a mechanism for anyone to log in other than WVD. I have no other VMs in Azure.- David SchragMar 19, 2021Iron ContributorI think I might have found the problem. To make sure I got the name right, I had been copying \\xxx.file.core.windows.net\share from one screen on my computer into various places in the WVD environment. I think I had been copying and pasting a hidden character as part of that process. In group policy, I rewrote the profile container location by hand, and it seems to be working better. More testing needed, but this looks promising.
- David SchragApr 02, 2021Iron Contributor
Confirmed -- one or more hidden special characters were preventing the GPO from executing properly on login.