When and how often to run script for accessing FSLogix profile container?

Iron Contributor

I am reposting this question that I originally asked at https://docs.microsoft.com/en-us/answers/questions/299540/when-and-how-often-to-run-script-for-acces...because they told me to check with the product team. Hopefully I'm in the right place.

 

I am trying to create a WVD host pool that will contain multiple VMs based on a golden image. The users in this host pool should have access to FSLogix profiles that are stored in Azure files.

At https://docs.microsoft.com/en-us/azure/virtual-desktop/create-profile-container-adds#get-the-storage..., there are a series of commands that must be run to provide the correct user access from the VM to the share that houses the profile. I am thinking that I'll have to configure a startup script on my golden image so that any session host created from the image will run that whole series of commands each time it boots.

 

Am I thinking about this correctly or is there a better approach?

6 Replies
The best way to approach this is by:
1. Domain-joining your Storage-Account with the profiles File Share (easy with AADDS = flip a switch or via the manual script on an on-prem AD connected server)
2. Set the permissions on the file share (SMB contributor for users)
3. via a Domain-joined server connect to the share and set NTFS permissions (needs SMB elevated contributor rights on the share in order to be able to set NTFS)
4. Now your users can access the path (for example \\yourprofiles.file.core.windows.net\profiles) without having to provide an access key if they are Synced with AzureAD and have the SMB Contributor permissions on the share.
5. Now; either bake in the correct profile-path in the registry on the golden image: hklm\software\fslogix\profiles\VHDlocations (together with all the other settings like Enabled = 1, overwrite existing profiles, etc...)

or better: get the ADMX file from the FSlogix installer zip file and use the group policy settings to set the VHDlocation and all the other settings

@YannickJanssens1986 

1. For domain-joining the storage account, I have already set Identity-based access for files shares to Enabled for AADDS. But I haven't joined the storage account to AD DS. My ultimate goal is to eliminate on-prem AD (which isn't really on-prem anyway, it's on a cloud server not hosted by MS). Is enabling AADDS sufficient, if I don't plan to access the FSLogix share from an on-prem-domain-joined machine?
2. I have assigned the Storage File Data SMB Share Contributor role on the file share in Azure Files to my WVD users group. The members of AAD DC Administrators are not members of the WVD users group, though. Must I give an AADDS admin the SMB contributor role?
3. So far, I don't have any server VMs in Azure, just the WVD setup. I've been logging into a WVD session host using an AADDS admin account and setting the permissions that way. Will this work? See also #2 re: what role the AADDS admin needs.
4. I will try that once I get 1-3 figured out.
5a. I am only aware of two required registry settings: Enabled and VHDLocations (see https://docs.microsoft.com/en-us/azure/virtual-desktop/create-host-pools-user-profile#configure-the-...). What other settings are required?
5b. I haven't fiddled with group policy in AADDS yet. As mentioned above, I have no server VMs. But that seems to be a prerequisite (https://docs.microsoft.com/en-us/azure/active-directory-domain-services/manage-group-policy). I can create one ... but is that a requirement or can the group policy be managed via an add-on to a WVD Win10 session host?

@David Schrag 

When you deployed the AADDS service you created a new AD Forest (with it's DNS root being something like contoso.onmicrosoft.com). That's forest is of course separate from your other on-prem Domain. I am assuming that you joined your WVD-hosts to that AADDS Domain so let's disregard the on-prem domain for now.

 


@David Schrag wrote:

1. For domain-joining the storage account, I have already set Identity-based access for files shares to Enabled for AADDS. But I haven't joined the storage account to AD DS. ?


If you've flipped this switch then the Storage Account is already joined to the AADDS domain:

YannickJanssens1986_0-1615532771746.png

You can check this by installing RSAT tooling on one of your hosts and using the Active Directory Users and Computers snap-in. The storage account should appear as a computer object there. That's also how you can create policies for your AADDS domain by using the Group Policy tool. Check here for into about the FSLogix GPO:

https://docs.microsoft.com/en-us/fslogix/use-group-policy-templates-ht

 

With regards to FSlogix registory settings; check this page:

https://docs.microsoft.com/en-us/fslogix/configure-profile-container-tutorial#configure-profile-cont...

(Additionally I'd also set the VolumeType key to VHDX.)

 

Also pay attention to the local FSlogix Profile Include and Exclude group. By default \everyone is given an FSlogix profile. You should probably place your administrators in the exclude group in case something is wrong (for example you can't access the share) so that you aren't locked out of your VM due to profile issues.

 


@David Schrag wrote:

2. I have assigned the Storage File Data SMB Share Contributor role on the file share in Azure Files to my WVD users group. The members of AAD DC Administrators are not members of the WVD users group, though. Must I give an AADDS admin the SMB contributor role?

 


Yes. Or give them the SMB Elevated Contributor role so they can also change NTFS permissions. Use SMB Contributor for your regular users that just need modify permissions in order to write to their profile.

 


@David Schrag wrote:

3. So far, I don't have any server VMs in Azure, just the WVD setup. I've been logging into a WVD session host using an AADDS admin account and setting the permissions that way. Will this work? See also #2 re: what role the AADDS admin needs.

That's fine since the WVD hosts are domain joined.  wrt to role: Again, this doesn't come into play when you are mapping the share using the access key. You only do that during the initial setup when you are setting the NTFS permissions. Afterwards you can browse the share without using the access key and then those roles are checked.

 

 

@YannickJanssens1986 The storage account is actually a User listed under AzureFilesConfig in ADUC:

 

AzureFilesInADUC.png

Does that indicate something is wrong?

No that's fine. Basically when you domain join a Storage Account to a regular Domain Controller using the scripts you have the option to create a computer account or a service account. When using AADDS it seems it will always create a Service Account.

So that verifies that your storage account is correctly AD joined.

To answer the original question: You only have to run the script one time per profile container. Once the permissions on the share are set, they're set. Neither the golden image nor any session hosts require a drive letter mapped. Users will connect to the share via an SMB path, and this path can be controlled through a GPO in AADDS rather than a local group policy on the session host(s).