Now that we've created our file share and are protecting it from those unintentional deletes, as well as standard backup protection, and we've enabled our best performance, it's time to set up authentication. At the top, notice Active Directory is not configured. Let's click on that. There are two options here. On the left is a traditional Active Directory. AD would be either on-prem or in a VM in the cloud. And on the right is Azure Active Directory Domain Services. This is a Microsoft-managed Active Directory, and that may sound appealing, however, there are a lot of caveats with that approach. So if you're not currently using it, I would stick with Active Directory. Click the Setup.

As you can see, this is a four-step process to get the file share to use Active Directory authentication. Let's click on the first step, and this will open the Azure docs. On the right, click the link for option one in the download AZFilesHybrid module section. The second bullet is a link to download the PowerShell module. Click on the .zip file and save it to a local location on a domain-joined machine and extract the files.

Open PowerShell as an administrator. In your terminal, navigate to the same file location you extracted the files to. In my script on the right, I've set some variables at the top for our resource group name, storage account name, and domain name, and that one's just using a PowerShell environment variable. These will help you to execute the same script below each time this runs. Just change the variables for your next storage account, and you're good to go.

In the next section, we'll run one of the files we just extracted. This will copy the PowerShell module you downloaded to the appropriate place on your system, and the next command will import it. Now we can run the command to join our storage account to Active Directory. As you can see, this is going to use the variables that we listed above. In the command, there are also parameters for your domain account type, which I'll use a ComputerAccount for this, and optionally, you can specify which organizational unit you want your computer account to reside in. If you don't specify an OU, the default behavior is just a pick the same OU where your computer object exists that you're running the script on. I've already got an organizational unit set up for this, so I'll use that one.

In the terminal, we see everything ran successfully, and in Active Directory, we have a new computer object that's named for our storage account. Before we can access this file share, we need to add permissions to either a file share or the storage account. If you select the storage account, this will apply the same permissions to all of the file shares, and that's just what I'll do today. Back in our storage account in the Azure Portal, on the left, we can go to Access Control, at the top, click to add a role assignment. In the search box, type SMB. The role we need is called Storage File Data SMB Share Elevated Contributor. Select that and click Next. Click Select Members and search for your virtual desktop administrator user or group. Click Select at the bottom, and Review & Assign.

Now we want to add another permission, and this one will be for our FSLogix users. Click Add at the top. In the search box, type SMB. This time the role we need is called Storage File Data SMB Share Contributor. Click Next. Click Select Members and search for your virtual desktop users group. Select that. At the bottom, click Review & Assign. Now before we can mount the file share, we should verify that we can connect to it in case port 445 is blocked. Back in PowerShell, I have added a new command to our script, and this will test connectivity to the share. We have two parameters here. ComputerName is the fully qualified name of the storage account, which in this case is avdstorage01.file.core.windows.net. And we have the common TCP port, which is SMB, also known as port 445.

In our terminal, we see the public IP address of the storage account and the last line shows our test was successful. Now we can map our file share in the Windows File Explorer. Click the button at the top to map the drive. Select the drive letter you want, and I'll take the X drive. For the path, use the fully qualified name to the storage account, slash the share name. Click Okay. And you should now see your mapped drive. We now need to set the NTFS permissions. To do this, you will need to use the same user who you granted the elevated permissions right to. Right-click on the white space and select Properties. Notice that the size of the share properly shows 100 gigabytes. This is just another reminder to properly set the size of the share before you start bringing users into your environment. Click the Security tab at the top.

At the bottom, click the Advanced button. Notice that our WVD admin already has the permissions of full control, which is the elevated contributor role. Let's add our FSLogix users, and click Add. At the top, click to select a member, and notice that in the box of our location is our Active Directory domain. Type the name of your group, which for me, is WVD users, and click Check Name. It looks good, so click Okay. Their permissions here should have Modify, and it should be for this folder only. Click Okay.

Now above that, we have our creator owner permission. Click that, and select the Edit button. Change this permission from Full Control to Modify, and click Okay. Now we've configured our FSLogix file share to be Active Directory authenticated, giving our AVD admin full control over the file share as well as our AVD users being able to create their own subfolders and files, which is required for their user profile creations when they first log in.