Brief introduction of main components
Anyware Connector (CAC or AWC):
This virtual machine is normally called as “connector”. It operates in authentication and entitlement for remote workstation access. This is the core component, and all traffics will flow through it. We could have one or multiple connectors depending on the architecture.
Connector = connector manager + connector broker + security gateway
Anyware manager (AWM):
This component can be hosted on a virtual machine or running as a service. It provides a web UI to let administrators configure, manage and monitor brokering of remote workstations.
Domain Controller (DC):
Active directory is running on this component. It is used to store authentication data of agents and workstations. Connector VM will retrieve user auth and machine list from DC.
- It is very important to read through corresponding README files before deploying any architectures.
- Before making any deployment, it will be good to learn some basic knowledge about Terraform and Azure Service Principle.
- I recommand start with trying: Terrafrom script for Single Connector.
- To deploy/test our terraform deployments, we only need to edit “deploy.sh” for creating service principle and edit “terraform.tfvars” for assigning variable values.
- There are some required variables in “terraform.tfvars”, please make sure the properly value is assigned for each of them:
- application_id
- aad_client_secret
- resource_group_name (it is optional but highly recommended)
- ad_domain_users_list_file (it is optional but highly recommended. This csv file is used to register users info into local DC)
- pcoip_registration_code
- Follow the instructions from README file to start deployment.
Name conflict when you run “deploy.sh”:
Make sure you only run deploy script one time. If you want to generate a new service principle, you will need to delete the previous one from Azure portal and re-run the script again.
Time out when you run “deploy.sh”:
Check from Azure portal to make sure there is no service principle created; then, re-run the script.
Time out during “terraform apply”:
The deployment process is expected to take approximately 30-45 minutes. It is important to note that if you don't interact with the Azure portal during the deployment, the Azure Cloud Shell (ACS) session may time out. In such cases, the deployment process will not continue once you reconnect to the ACS. You will need to delete the created resource group manually from the Azure portal and reconnect to ACS. Then, you must manually run the following two commands before applying the Terraform script again from the beginning to initiate a fresh deployment.
- export ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv)
- export ARM_TENANT_ID=$(az account show --query homeTenantId --output tsv)
Error about missing subscription_id and tenant_id in azurerm block during “terraform apply”:
If the user manually or accidentally exits the current ACS session before the architecture successfully deployed, they need to manually execute the above two commands when a new ACS session starts (Make sure you already have a service principle).
The Admin Console enables you to create deployments, connectors and remote workstations all within a single console and from a single interface (UI). You can find the tutorial about CAS manager from following link: Overview - AWM
Link for CAS manager as service: Anyware Manager
The following link provides the sequence diagram about how a PCoIP session is established and how the broker works: PCoIP Brokered Connections
From this diagram, you could understand how components collaborate with each other when an agent makes the connection to his allocated VM through PCoIP client. You also can find the flow chart from the following link: What are HP Anyware Products
These two diagrams are illustrating the same process in different ways. By combining the understanding from both diagrams, it will be easier for you to comprehend how a PCoIP session is established.
Depending on the operating system of the virtual machine, you will need to download different connectors. Connector could be running on Ubuntu or Rocky 8. It is important to understand the difference between ‘CAC’ and ‘AWC’. The main differences between these two connectors lie in their installation and configuration processes.
Difference between Anyware Connector on Ubuntu and RHEL/Rocky Linux - HP Anyware Manager
For Ubuntu (CAC): The installer is downloaded as a ‘tar.gz’ file. We call this connector as ‘CAC’ which stands for Cloud Access Connector. Installing Connector on Ubuntu
For Rocky 8: We need to install the Connector RPM. Note: there are some pre-request packages need to be installed. We call this connector as ‘AWC’ which stands for Anyware Connector. Installing the Connector on RHEL/Rocky Linux
The terraform code is mainly consisted by two parts: deployments and modules.
Deployments:
The "Deployments" directory serves as the main entry point for our architectures. You should select a specific deployment from this folder. Once you have chosen a deployment, you will need to assign values to variables in the "terraform.tfvars" file according to your specific requirements.
The "domain_users_list.csv" file contains the list of agents that you intend to create. This file likely includes information such as first name, last name, username, password, and role. Note: the passwords must have at least 3 of the requirements: UPPERCASE letter; lowercase letter; number; special character. Otherwise, by default, the user will be disabled in the Domain Controller.
The "main.tf" file serves as the entry point that invokes the corresponding modules. These modules are responsible for establishing Azure resources and setting up virtual machines based on the defined configuration.
modules:
The "Modules" directory contains Terraform scripts for creating every component, including “AWM”, “DC”, “CAC”, “network”, workstations, and so on.
These scripts not only create the necessary resources but also perform provisioning for each virtual machine. Provisioning Scripts are shell scripts that are used to set up the virtual machines. They handle tasks such as configuring services and installing packages. These scripts ensure that the virtual machines are properly configured and ready to perform their intended functions within the infrastructure.
-
By default, SSH and RDP access are allowed for your current ACS IP. Once you have completed the deployment, you can directly SSH into the connector VM through the current ACS session. However, if you exit the current ACS session and open another session, you won't be able to SSH into the connector because the IP of ACS changes each time the session is reconnected. Therefore, to SSH into the connector in this scenario, you will need to manually add an inbound rule to your network security group (NSG) to allow traffic to port 22 from your IP. As per the policy, you can only allow traffic from a specific IP rather than allowing it from anywhere. After adding the inbound rule, you can open the command prompt on your device and SSH into the connector.
-
Same for using RDP. if you want to login to DC through RDP, you will need to manually add an inbound rule to your nsg.
-
If you have challenging questions about the Anyware connector/manager, you can use the following command on your connector VM to create a support bundle and seek assistance from the connector/manager team:
anyware-connector diagnose --support-bundle
- When you want to delete your current deployment from Azure, I recommend directly deleting the resource group from the Azure portal instead of using the "terraform destroy" command. This approach is faster and safer, as the command may not be able to completely delete everything due to errors.