Parallels RAS in Azure

Parallels Remote Application Server (RAS) provides a centralized platform for delivering Windows applications and virtual desktops securely to users across different locations and devices.

When deployed on Microsoft Azure, Parallels RAS can take advantage of cloud scalability, geographic availability, integrated security services, centralized monitoring, and consumption-based infrastructure.

This guide walks through the main phases of deploying Parallels RAS in Azure, from initial planning and network design to application delivery, security validation, and production preparation.

Important: The resource names, IP ranges, credentials, software versions, and commands in this guide are examples. Validate them against your organization’s standards and the current Microsoft Azure and Parallels documentation. Never place production passwords directly in scripts or command history.

Prerequisites

Before beginning the deployment, confirm that the required permissions, licenses, and infrastructure decisions are in place.

Required permissions

The deployment team may require:

• Azure Subscription Owner or Contributor permissions
• Microsoft Entra ID Global Administrator permissions for identity integration
• Domain Administrator permissions when integrating with an on-premises Active Directory environment
• Access to DNS, certificate, firewall, and network-management systems

Apply least-privilege access wherever possible. Elevated roles should only be assigned for the period in which they are required.

Required licenses

Confirm that you have:

• An active Microsoft Azure subscription
• Sufficient Azure compute, networking, and storage quotas
• Parallels RAS licenses for the required number of concurrent users
• Appropriate Windows Server licenses or Azure Hybrid Benefit eligibility
• Microsoft Remote Desktop Services Client Access Licenses
• Any additional licenses required for Microsoft Entra ID, monitoring, backup, or security services

Planning checklist

Before creating resources, determine:

• Expected concurrent-user count
• Applications and desktops to be published
• Azure region and availability requirements
• IP addressing and subnet structure
• Identity and authentication model
• SSL certificate requirements
• User groups and access policies
• Backup and disaster-recovery requirements
• Monitoring and alerting standards
• Maintenance and implementation windows

Phase 1: Build the Azure Foundation

A production deployment should separate workloads logically so that networking, security, and application resources can be managed independently.

1. Create resource groups

Create dedicated resource groups for:

• Parallels RAS production workloads
• Networking resources
• Security services

Example:

az login az group create \ --name "rg-parallels-ras-prod" \ --location "East US 2" az group create \ --name "rg-parallels-ras-network" \ --location "East US 2" az group create \ --name "rg-parallels-ras-security" \ --location "East US 2"

Use your organization’s approved naming convention, tagging policy, region, and cost-management structure.

2. Design the virtual network

A hub-and-spoke topology provides a practical foundation for separating management, gateway, application, and data traffic.

The hub network can contain:

• Management subnet
• Gateway subnet
• Azure Firewall subnet
• DMZ subnet

The application spoke can contain:

• RDSH subnet
• Application subnet
• Data-services subnet

Example address plan:

Network segment

Example range

Hub virtual network

10.1.0.0/16

Gateway subnet

10.1.0.0/26

Azure Firewall subnet

10.1.0.64/26

Management subnet

10.1.1.0/24

DMZ subnet

10.1.2.0/24

Application virtual network

10.2.0.0/16

RDSH subnet

10.2.1.0/24

Application subnet

10.2.2.0/24

Data subnet

10.2.3.0/24

Create bidirectional peering between the hub and application networks. Enable only the access and forwarded-traffic options required by the final routing design.

3. Configure network security

Create separate Network Security Groups for:

• Management servers
• DMZ and gateway servers
• RDSH servers
• Application servers

Avoid exposing administrative ports directly to the internet. Restrict RDP access to approved management networks or, preferably, use Azure Bastion, privileged access workstations, just-in-time access, or another controlled administration method.

Rules should be based on the current Parallels RAS communication-port requirements. Document each allowed connection, its purpose, and its source and destination.

4. Deploy Azure Key Vault

Use Azure Key Vault to protect:

• TLS certificates
• Administrative secrets
• Application credentials
• Automation secrets
• Other sensitive deployment values

Enable soft delete and purge protection. Grant access through managed identities and role-based access control wherever possible.

Do not embed passwords or certificate secrets directly in deployment scripts.

Phase 2: Deploy the Parallels RAS Core Infrastructure

The core infrastructure includes the Parallels RAS control components and secure client gateways.

5. Deploy Parallels RAS control servers

For production resiliency, deploy at least two appropriately sized Windows Server virtual machines for the Parallels RAS management and control layer.

Recommended considerations include:

• Availability Zones or an availability set
• Premium managed disks
• Accelerated networking, where supported
• Azure Backup protection
• Endpoint protection and vulnerability management
• Centralized logging
• No unnecessary public IP addresses

The source design uses Windows Server 2022 and general-purpose Azure virtual machine sizes. Actual sizing must reflect the expected user count, application workload, redundancy requirements, and Parallels guidance.

6. Install and configure Parallels RAS

On the primary server:

1. Install the current supported version of Parallels RAS.
2. Create the RAS farm.
3. Configure the primary Connection Broker and management components.
4. Apply the license.
5. Configure administrative access.
6. Validate required Windows Firewall rules.

On the secondary server:

1. Install the same Parallels RAS version.
2. Join it to the existing farm.
3. Configure the required high-availability role.
4. Confirm that both servers communicate correctly.
5. Test administrative access and component health.

Always obtain installation media from an official Parallels source and verify that the version is supported before deployment.

7. Deploy secure client gateways

Deploy at least two Parallels RAS Secure Client Gateway servers in the DMZ subnet.

Place the gateways behind an Azure Load Balancer or another supported load-balancing service. Configure:

• Front-end IP configuration
• Back-end pool
• HTTPS load-balancing rule
• Health probe
• Session-persistence settings, if required
• TLS certificates
• DNS records

Avoid assigning public IP addresses directly to individual gateway virtual machines unless the design specifically requires it.

8. Add the gateways to the RAS farm

From the Parallels RAS Console:

1. Open the Secure Client Gateway configuration.
2. Add each gateway server.
3. Associate the gateways with the correct public address and certificate.
4. Confirm their status and connectivity.
5. Test failover by removing one gateway from service.

Phase 3: Deploy the Application Infrastructure

9. Deploy RDSH capacity

Deploy the Remote Desktop Session Host servers in the application virtual network.

A virtual machine scale set or managed group of standardized virtual machines can simplify:

• Capacity expansion
• Image consistency
• Availability
• Automated deployment
• Lifecycle management

Start with a conservative minimum instance count and establish scaling limits based on tested capacity rather than assumptions.

10. Configure autoscaling

Autoscaling can help align session-host capacity with demand. Scaling decisions may consider:

• CPU utilization
• Memory consumption
• Active session count
• Disconnected session count
• Time-based business schedules
• Application-specific performance indicators

Avoid relying on CPU utilization alone. User density and application behaviour should be validated through load testing.

11. Configure the RDSH servers

Each session host should include:

• Remote Desktop Session Host role
• Current Windows updates
• Endpoint security tooling
• Monitoring agent
• Required business applications
• Parallels RAS agent
• Organization security baselines
• Profile-management components, where applicable

Use a standardized image or automated configuration process so that every server is built consistently.

12. Publish applications and desktops

In the Parallels RAS Console:

1. Add the RDSH servers or server group.
2. Verify that every agent reports a healthy status.
3. Create published applications or desktops.
4. Configure names, descriptions, icons, and startup parameters.
5. Assign access to approved user or security groups.
6. Set session, printing, clipboard, drive-mapping, and redirection policies.
7. Test the published resources with a non-administrative account.

Follow least-privilege principles and publish only the applications users require.

Phase 4: Configure Identity, Certificates, and Monitoring

13. Configure TLS certificates

Use a certificate issued by a trusted certificate authority for production access.

The certificate should:

• Match the public RAS service name
• Include the required subject alternative names
• Use an approved key length and signature algorithm
• Be stored securely
• Have a documented renewal process

Import the certificate into Azure Key Vault or another approved certificate-management platform, then deploy it securely to the required gateways.

Self-signed certificates may be suitable for isolated testing but should not be used for a public production service.

14. Integrate Microsoft Entra ID

Microsoft Entra ID integration can provide centralized identity and stronger access controls.

The configuration may include:

1. Registering an enterprise application
2. Defining the correct redirect URL
3. Configuring SAML authentication
4. Exchanging identity-provider metadata
5. Mapping required claims
6. Assigning approved users and groups
7. Enforcing multifactor authentication through Conditional Access
8. Testing authentication and sign-out behaviour

Validate the configuration with a limited pilot group before enabling it for all users.

15. Implement monitoring

Use Azure Monitor, Log Analytics, and Parallels RAS monitoring capabilities to track:

• Virtual machine availability
• CPU and memory consumption
• Disk performance
• Network latency
• Gateway health
• Connection Broker health
• User sessions
• Authentication failures
• Application-launch performance
• Scaling activity

Create actionable alerts with clear owners and escalation procedures. Avoid generating alerts that no team is responsible for reviewing.

Phase 5: Test and Validate the Environment

16. Test user connectivity

Test access from both internal and external networks.

Confirm that users can:

1. Reach the Parallels RAS portal or client endpoint.
2. Authenticate successfully.
3. Complete multifactor authentication.
4. View assigned applications and desktops.
5. Launch published resources.
6. Reconnect to existing sessions.
7. Sign out cleanly.

Include different devices, operating systems, browsers, and network conditions in the test plan.

17. Perform load and performance testing

Simulate realistic user activity before production launch.

Testing should measure:

• Login duration
• Application-launch time
• Session responsiveness
• CPU and memory consumption per user
• Storage latency
• Network utilization
• Scaling response time
• Gateway and broker performance

Use the results to establish a baseline and adjust virtual machine sizes, session density, and autoscaling thresholds.

18. Complete security validation

Confirm that:

• All servers have current security updates.
• Network Security Groups allow only required traffic.
• Administrative access is restricted.
• TLS certificates are trusted and correctly installed.
• Microsoft Entra ID authentication works as expected.
• Multifactor authentication is enforced.
• Audit logging is enabled.
• Secrets are protected in Azure Key Vault.
• Backup services are configured.
• Endpoint security is active.
• Public exposure is minimized.
• Vulnerability findings have been reviewed.

Phase 6: Prepare for Production

19. Configure backup and recovery

Protect the Parallels RAS infrastructure using Azure Backup or another approved backup platform.

The recovery plan should cover:

• RAS control servers
• Gateway configuration
• Session-host images
• Application packages
• Configuration exports
• Certificates and recovery procedures
• Supporting file and data services

Test recovery procedures before go-live. A successful backup job does not prove that the environment can be restored.

20. Prepare operational documentation

Create an operations manual containing:

• Architecture and network diagrams
• Resource and server inventory
• Configuration standards
• Backup and recovery procedures
• Monitoring and escalation processes
• Certificate-renewal procedures
• Scaling procedures
• User-access processes
• Maintenance schedules
• Troubleshooting guidance

Prepare separate documentation for administrators, service-desk teams, and end users.

21. Complete the go-live checklist

Before launch, verify that:

• Functional testing is complete.
• Performance baselines are documented.
• Security validation is complete.
• Backup and recovery have been tested.
• Monitoring and alerting are operational.
• User training is complete.
• Support teams have the required documentation.
• A rollback plan is approved.
• Stakeholders have received the launch communication.
• Post-launch monitoring responsibilities are assigned.

Common Troubleshooting Scenarios

Users cannot connect through the gateway

Check:

• DNS resolution
• Load-balancer health probes
• HTTPS and gateway port rules
• Network Security Group assignments
• Gateway service status
• TLS certificate validity
• Back-end connectivity to the RAS farm

Applications are slow

Review:

• Session-host CPU and memory usage
• Storage latency
• User density
• Autoscaling configuration
• Network latency
• User-profile performance
• Application dependencies
• Antivirus exclusions approved for the platform

Users cannot authenticate

Validate:

• Microsoft Entra ID enterprise-application configuration
• SAML metadata and claims
• User and group assignments
• Conditional Access policies
• Time synchronization
• Certificate validity
• Parallels RAS authentication settings

A service outage occurs

1. Check Azure Service Health.
2. Verify network connectivity.
3. Review load-balancer and gateway health.
4. Check Parallels RAS component status.
5. Review Azure and application logs.
6. Follow the documented escalation process.

A security incident occurs

1. Isolate affected systems.
2. Preserve logs and evidence.
3. Contact the security-response team.
4. Follow the approved incident-response process.
5. Document actions and findings.
6. Implement and validate corrective measures.

Final Thoughts

Deploying Parallels RAS on Azure requires more than installing the platform on a collection of virtual machines. A successful implementation depends on thoughtful network design, resilient control and gateway components, standardized session hosts, secure identity integration, tested scaling, centralized monitoring, and clear operational ownership.

By treating security, availability, performance, and recovery as design requirements from the beginning, organizations can build a Parallels RAS environment that delivers Windows applications and desktops securely while taking advantage of Azure’s flexibility and global cloud infrastructure.

XenTegra India can help organizations assess, design, deploy, secure, and optimize Parallels RAS environments on Microsoft Azure