In a project where WVD was involved, we needed to implement AADDS and FSlogix to the scenario. If you take a look to that scenario, it is pretty simple, but it hides some stones that we hit during the road, so I want to explain them in this post 😊
First of all, once you have deployed the AADDS, remember to check DNS settings in the VNet, it is necessary to put the DNS from the AADDS, otherwise won’t be possible to join VMs to the AADDS domain:

Once the AADDS instance was deployed it took turn for the golden image, as you probably know there is no problem to install all the programs and updates, but our stone here was once we deployed the language pack and the image was prepared, the sysprep was crashing, so we need to deep dive into the logs to solve the problem…

So the deployment begun to be fun, but after digging, we were able to solve by executing…
Remove-AppxPackage -Package Microsoft.LanguageExperiencePackes-ES_19041.17.51.0_neutral__8wekyb3d8bbwe -AllUsers
And then… boom!

Probably you will need to change your package in your case but is important to include the -allusers parameter.
Solved the golden image problem, it take turn to the deploy the host pool which process was straightforward. Our next stone was the storage account… ☹
Deploying the storage account into the AADDS was easy, but the problem was to give NTFS permission to the users, we were used to do that process in ADDS scenarios, so we know what to do, but with AADDS the procedure changes a bit…
So my piece of advice, would be to follow the instructions given in docs: Uso de Azure AD Domain Services para autorizar el acceso a los datos de archivo a través de SMB | Microsoft Docs

We were using the AAD credentials and we were stuck for a while until we read this in the documentation. Lesson learned, read documentation help.
Once you have entered to the storage account with your storage account key, you are able to give NTFS permission to the users (please follow instructions from docs xD)
Once we solved this, we were in position to configure FSLogix for the mobility of the profiles. For those who do not know FSLogix it allows to store both user profiles and applications on a centralized file share. This is extremely useful in virtual desktop environments, as the user’s profile does not have to be copied prior to boot. FSLogix will mount those profiles hosted on a file share and will make them appear local.
But again, once we have configured the entry in the VM registry:

We hit another stone… because we were logging into the WVD remote desktop and it didn’t create any profile on the Storage account, after digging and asking ourselves, we decided to go to FSLOgix logs located here: %ProgramData%\FSLogix\Logs. We checked the profile logs and found the following:
Configuration setting not found: SOFTWARE\FSLogix\Profiles\AttachVHDSDDL. Using default:
[17:33:52.257][tid:00000c4c.00000e74][INFO] Session configuration wrote (REG_SZ): SOFTWARE\FSLogix\Profiles\Sessions\S-1-5-21-1901185187-4119977032-3365905087-1004\AttachVHDSDDL = ‘D:AI(A;;GA;;;SY)(A;;GA;;;BA)(A;;GA;;;BU)(A;;GA;;;WD)(A;;GA;;;RC)(A;;GA;;;AC)S:(ML;;NW;;;LW)’
[17:33:52.273][tid:00000c4c.00000e74][INFO] Status set to 0: Success
[17:33:52.273][tid:00000c4c.00000e74][INFO] Reason set to 3: A local profile for this user exists on this system
[17:33:52.273][tid:00000c4c.00000e74][WARN: 00000003] Local profile already exists. Do nothing. (El sistema no puede encontrar la ruta especificada.)
Probably you will asking yourself what kind of error is that? It is simple, your local profile is messing with the network profile being created, so what we had to do is to remove the local profile. You can do that by going into advanced system settings and deleting the profile

We did that, and we tried again and booooooom! The profile was created in the storage account:

After doing that, we were in position to do all the test in WVD and then di all the steps to create and enterprise environment (optimization, monitoring, a “true” golden image, hide the power button, etc…).
Till nex time!
Thanks for the pointers, we’re configuring an environment similar to what you have described above. Our spoke DNS points to the AADDS server (in the hub), which has the the Azure DNS (168.63.129.16) configured as the conditional forwarder although we’re unable to connect to the share via the FQDN as it is resolving to the public IP address instead of the private address – Did you encounter anything like this?
LikeLike
As far as I can understand, you’re using private endpoint for the blob storage? If it’s this, you need to configure the Private DNS in Azure and also the DNS zones that points to your private endpoint for the blobstorage. If not it’s case, please, explain it a bit more 🙂
LikeLike