In a previous post I covered how to manually create a Service Principal (App registration) for XenDesktop Essentials. (this also applies to the XenApp and XenDesktop Service)
If you recall, this is the identity that Citrix Cloud will be using when it performs machine lifecycle actions in your Azure Subscription.
Things with permissions can get a bit strange in Azure pretty quickly. One such area is Virtual Networks.
First of all, a Virtual Network exists within a Subscription. It can belong to any Resource Group for management, but can be used by any machines or services within the subscription.
Now, in the world of assumptions, this is all fine and easy if you grant the Service Principal account the Contributor role AND the resource group that your virtual network belongs to is within a resource group under that same subscription. You can take advantage of the inheritance.
This is not always the case. In fact, it might not be the case for you at all. You might be putting very tight controls on that Virtual Network to ensure it never gets messed up.
The minimum permissions that the Service Principal needs to your Virtual Network is the VM Contributor Role. This level of access is necessary for the automated provisioning and lifecycle of desktop or session workers.
If you have a need to grant access to your Virtual Network or want to constrain access to your virtual network, here is how.
Remove the inheritance at the Virtual Network Resource Group from the subscription if it is enabled.
Explicitly grant the App Registration the VM Contributor role on the Virtual Network where worker machines will be attached when provisioned.
You can find more about the permissions in this article that I authored: Manually granting Citrix Cloud Access to your Azure Subscription