Writing this post to let you know about few imp resources that gets created in Horizon cloud on Azure once the pod is deployed, images are published, assignments are created and desktops are provisioned.

Jumpbox:

For any operations like pod / uag’s deploy or delete, jump box will get deployed in Azure portal and get deleted once given task is completed. It will be provisioned with vm name as vmw-hcs-<pod id>-jumpbox, this will be created in a new resource group vmw-hcs-<pod id>-jumpbox. This will be deployed in management subnet with (Standard F2 size * – this can changed in future).

Note: Pod id can be fetched from Admin console > pod properties section.

Here are list of other resources that will be part of resources group once jumpbox is deployed.

Smart node Resource Group:

Node manager appliances will be deployed in separate resource group : vmw-hcs-<pod id> and will have diff resources as given below:

• Key valut: One key vault will be deployed per pod.
• AV Set: One AVset will be deployed per pod and if HA is enabled, both node manager appliances will be part of this AV Set, otherwise only one.
• Node VM: 1 vm will be created in HA is disabled, otherwise 2 vm’s will be created. node vm names will be like vmw-hcs-<pod id>-<pod version>-node-1 and if secondary appliance is there then it will be as vmw-hcs-<pod id>-<pod version>-node-2.
• Network interface: Node managers will be assigned to two network interfaces i.e., management and tenant
• Database: If the pod is cluster enabled, then the postgres resource willexist with name as vmw-hcs-<pod id>-<pod version>-postgres
• NSG: Two NSG’s will be created i.e., one for management and other for tenant
• LB: One LB will be created and node manager appliances will be part of backend pools.

UAG Resource Group :

UAG’s will be deployed in separate resource group in Azure subscription with naming convention as: vmw-hcs-<pod id>-uag, All UAG’s will be part of this RG – irrespective of internal for external.

• Availability Set: One AV set will be deployed for external and one for internal.
• Disk: 1 Disk will be created per UAG.
• Load balancer: One LB will be created for external and internal, and uag’s will be part of backend pools.
• Network interface: 3 network interfaces (DMZ, management, tenant) will be created per UAG and 4 such pairs exists. 2 will be mapped to blue uag’s and 2 for green uag’s (future purpose). Since the upgrades in HcoA are blue – green approach, this green interfaces will be used during the migration.
• NSG: 3 NSG rules will be created each for tenant, management and DMZ.
• virtual machine:  2 UAG vm’s will be created with naming pattern as vmw-hcs-<pod id>- {1, 2, 3, 4}. If the pod has internal UAG’s then additional 2 will be deployed.

Resource Groups for assignments (pool):

Every assignment that is created in Admin console, will be part of a resource group with name as vmw-hcs-<pod id>-pool-<pool id>. Each server in assignment will have 3 resources (vm , network interface, disk) + 1 NSG. If the vm is deployed with public ip enabled then additional resource will be part of same resource group. For demo, I have deployed 1 farm vm to be part of the assignment as shown below, so there is only 1 set of resources. If I had 10 servers in farm then totally there would be 31 resources. This differs in case of floating assignments.

Resource Group of Images: 

All the images will be part of this resource group which will have naming pattern as: vmw-hcs-<pod id> – base-vms. If new images are imported / uploaded from file share, then automatically they will be part of this resource group.

Thanks for reading..