Create a Virtual Network Gateway

1. Next we will create the Virtual Network Gateway. The virtual network gateway will be responsible for sending and receiving data. This is the bridge between Azure and the on premise RRAS server.

2. Navigate to Virtual network gateways and click on Add. Name the gateway “S2SVPN-vNetGW“. For the virtual network select the existing one S2SVPN-vNet and select the gateway type as VPN, and leave VPN type to Route-based. For the public IP we will need to create one here. Click on choose a public IP address and click on Create New.
   

3. After the Virtual network gateways is created note down the public IP address. This is required for configuring the RRAS server later. You can get this by going here, Virtual network gateways > S2SVPN-vNetGW > S2SVPN-vNetGW-IP > Settings.

This will take approximately 30 to 45 minutes to provision the public IP address.

Create a Local Network Gateway

1. Now we need to create the local network gateway, this gateway will be configured with all of your on-premises network.

2. Go to Local network gateways and click on +Add. Give it any name, “S2SVPN-LocalNWGW“ and enter the public IP of your RRAS server, in the address space enter an IP range for your on-premises network, and select your Resource Group.
   

Citrix Vdi On Azure

Create the VPN connection

Now we need to create a connection in our local gateway. To do this navigate to the Settings > Connections and click on + Add. Name this “S2SVPN-vNetGW-Connection“.

The Connection type will default to Site-to-site (IPsec). Set the Virtual network gateway to “S2SVPN-vNetGW“. Set a Shared key (PSK) to be used and note it down somewhere it is required to configure the RRAS server.

The RRAS server configuration:

1. Configure the Windows Server 2012 R2 with two different networks internal and External. Configure the public IP address on external adopter and internal adapter as shown in the figure.

2. Install the RRAS Windows Role.
   

Citrix Cloud Azure Ad

Configuring the VPN in RRAS server

Citrix Cloud On Azure Account

1. Right click on the Network Interface, and select New Demand-dial Interface.
   

2. Give it any name and click Next
   

3. Choose VPN and click Next
   

4. Select IKEv2 Encryption here for the VPN Type and click Next

5. Enter Azure public IP and click Next. If you don’t know your Azure Public IP, go to your Virtual LAN Gateway, and see within the Essentials properties.
   

6. Enable Route IP packets on this interface and click Next.
   

7. Enter any user name and rest blank and click Next
   

8. Add the Static Route for your local network, 10.1.0.0/24, 255.255.255.0.
   

9. Right-click on the interface just created, and go to the Security settings. Select the use preshared key for authentication option, and now enter that PSK we used in Azure portal and click OK.

10. Now right click on the AzureARM-STSVPN connection and select connect. Then it will show as connected in RRAS as shown in the figure.
    

11. In Azure portal you should also see the connection status as Connected and also you should see the data flowing in and out of your connection.
    

12. Setup static route as shown in the following figure on RRAS server before it could communicate from on-premises to Azure.
    

Enable NAT on RRAS server

Without having NAT enabled none of the servers could reach the internet. The basic steps for enabling NAT on RRAS are as follows:

1. Right-click NAT, and then click New Interface.
2. Select the interface that connects to your private intranet, and then click OK.
3. Select Private interface connected to private network, and then click OK.
4. Right-click NAT, and then click New Interface again.
5. Select the interface that connects to the public Internet, and then click OK.
6. Select both Public interface connected to the Internet and Enable NAT on this interface, and then click OK.

Now spin up a new Azure VM on Azure Resource Manager and make sure you place it in the correct virtual network, then the VM should be able to communicate with your on-premises servers.

Step 2 – Create XenDesktop 7.11 Controller, VDA and StoreFont VMs in Azure

Provision 3 new VM instances in Azure Resource Manager for Controller, VDA and StoreFront server. Make sure to select the Virtual Network that is created in Step 1 when creating the VMs.

Follow these instructions to create virtual machines in Azure portal. https://azure.microsoft.com/en-gb/documentation/articles/virtual-machines-windows-tutorial/

Step 3 – Install XenDesktop 7.11

• Login to the Controller VM and join to the on-premises domain.
• Install the XenDesktop Controller and Studio.
• Add the Controller to the existing site by pointing to the on –premises XenDesktop Controller.

Refer to the KB article XenDesktop Controller in Azure Fails to Connect to an On-Premises Site/ VDAs Fails to Register to know more about fix the time sync issue.

Step 4 – Install VDA and create Master Image in Azure Resource Manager

• Login to VDA machine (no need to domain join if you are provisioning using MCS).
• Install the VDA software and point to the Controller in Azure as Delivery Controller.
• Follow the steps as explained in Creating Machine Catalog using Machine Creation Services Article to create master image.

Step 5 – Create Azure ARM Host Connection

• Navigate to Configuration > Hosting and click Add Connection and Resources from Actions.
• Follow the steps as explained in Connecting to Azure Resource Manager in XenApp/XenDesktop to create Azure ARM host connection

You will notice there are two hosting connections present in the Studio as shown in the figure.

Step 6 – Configuring XenDesktop Zones

In XenApp 7.11 you can configure Zones, which will allow you to run applications and desktops closer to user locations within a single XenApp site

1. Login to your on-premises XenDesktop Controller machine and open the Citrix Studio.

2. Navigate to Configuration > Zones and you will see the Primary Zone and the resources that already have in the site and the new Controller that you just build in the Azure Zone.

3. Rename the Primary Zone by clicking Edit button. Rename it to On-Premise Zone.
   

4. Click Create Zone from the Actions menu.

5. Enter the zone name and select the resources that you want to assign to the new zone.
   

6. Now the Studio should display two Zones.
   

Step 7 – Machine Catalog creation

Follow the steps as described in Creating Machine Catalog using Machine Creation Services Article and create MCS catalogs using Azure ARM.

Step 8 – Delivery Group Creation

1. Right click on the Delivery Group node and select Create Delivery Group
2. Choose the Machine Catalog that just created and enter the desired number of VMs to allocate to this Delivery Group and click next.
3. Select Apps and Desktops and click next.
4. Add the users to access the apps and desktops and click next.
5. Wait for VMs power on and registration process and select the applications you want to publish and click next.
6. Enter a friendly name and display name for the delivery group and click Finish.

Step 9 – NetScaler and StoreFront configuration

NetScaler Configuration: Refer to the NetScaler VPX Deployment with XenDesktop and XenApp on Microsoft Azure to deploy and configure the NetScaler in Azure.

StoreFront Configuration

1. Login to the StoreFront server in Azure and launch the StoreFront and click create a new deployment.

2. Name the store and click next.
   

3. Enter both delivery controller’s on-premises and Azure delivery controllers and click next.
   

4. Check Enable Remote Access and click Add under NetScaler Gateway Appliances.
   

5. Enter display name and NetScaler Gateway URL, Select Authentication and HDX routing from the drop down list and click next.
   

6. Enter the STA URL and click next.

7. Select Login type as Domain and enter the NetScaler gateway as callback URL and click Create.
   

8. Repeat same step and add the on-premises NetScaler gateway. Both NetScaler gateways will appear in the list of appliances. Click create.
   

9. Check user name and password and click Next.
   

10. Click create and the store will be configured. The authentication, stores, Receiver for web and NetScaler Gateways should all be configured and visible from the StoreFront UI.

Optimal Gateway Routing configuration

Optimal gateway routing enables you to route HDX connections to different XenDesktop Zones via different NetScaler Gateways. This means all launches for resources in the Azure Zone will be performed through the Azure NetScaler gateway even if the request for the resource came from another gateway such as on-premises gateway.

1. To configure optimal gateway routing, select the store and then select the Configure Store Settings actions in the right pane. Select Optimal HDX Routing and configure the gateways, Delivery controllers and Zones as shown in the figure.
   

2. Install Citrix Receiver on your external machine and navigate to the NetScaler Gateway in Azure. Login as user which has apps in both on-premises and Azure zones.
   

3. Two apps were created, Notepad and Command prompt. Notepad is running from the Azure zone and Command prompt from on-premises zone.
   

4. Launch notepad, it should launch from Azure zone.

Launch Command prompt, it should launch from on-premises zone. Verify using ipconfig and the IP address should get from on-premises network.

Additional Resources

downloadWhy can't I download this file?What is being announced?
Citrix is announcing that we are focusing our public cloud integration and engineering efforts on our Citrix Virtual Apps and Desktops service to ensure the best performance and compatibility with vendors like Azure, AWS, and GCP. Therefore, we are announcing the official deprecation and end-of-support for cloud-hosted workloads (VDAs) in our Current Release (CR) of Citrix Virtual Apps and Desktops starting with Citrix Virtual Apps and Desktops 2003.
A site running on Citrix Virtual Apps and Desktops 2003 or higher with workloads in public clouds will be an unsupported configuration.
Customers leveraging public clouds for workloads are encouraged to migrate their environment to Citrix Virtual Apps and Desktops service in Citrix Cloud, or remain on the 1912 Long Term Service Release (LTSR) which includes up to 5 years of mainstream support.
Who does this impact?
The changes apply only to Citrix Virtual Apps and Desktops customers deploying our Current Release (CR) offering of Virtual Apps and Desktops 2003 and future CR releases.
Customers running Citrix Virtual Apps and Desktops service in Citrix Cloud and customers following our Long Term Service Release (LTSR) deployment track are not impacted by this announcement.
Citrix Virtual Apps and Desktops 1912 LTSR will continue to support public cloud workloads.
Note that older versions who had Cloud support, such as 7.15 LTSR will not be affected.
Why is Citrix making this change?
The pace of change in public cloud providers is frequent. With Citrix Virtual Apps and Desktops service, Citrix can adjust the service to rapidly accommodate changes in our public cloud integration points without requiring the customer to execute rapid upgrades.
This delivers the best experience for our customers and the most value for their user community.
What should customers do as a result of this announcement?
Customers who typically upgrade to the latest Current Release and leverage cloud workloads have two options:

• Remain on the Citrix Virtual Apps and Desktops 1912 release, which has full support for public cloud providers. As an LTSR release, 1912 will not receive new feature updates, but has a support lifecycle of 5+ years and is regularly updated with security patches and fixes through Cumulative Updates.

• Migrate to Citrix Virtual Apps and Desktops service. The Citrix Virtual Apps and Desktops service offers full support for public cloud and on-premises workloads and the latest integration enhancements.

The Citrix Virtual Apps and Desktops service is regularly updated with the latest integration and performance optimizations with our key public cloud vendors, including Azure, AWS, and GCP. Reference the release matrix for more information.
How is this change enforced in CVAD 2003?
There is no technical enforcement in Citrix Virtual Apps and Desktops 2003; however, a Citrix Virtual Apps and Desktops 2003 site with public cloud workloads will be treated as an unsupported configuration. A future Current Release will enforce this change.
To ensure continuity, we recommended that customers with workloads in public clouds do not upgrade to CVAD 2003 and instead remain on CVAD 1912 or move to the Citrix Virtual Apps and Desktops service.

IsVMWare Cloud on AWSsupported in Citrix Virtual Apps and Desktops 2003 onward?

No, VMWare Cloud on AWS is a public cloud component. Customers who wish to use VMWare Cloud on AWS should use the Citrix Virtual Apps and Desktops Service, or remain on LTSR 1912.

When will Citrix technically enforce this change?
Citrix plans to remove cloud-hosted workload functionality in a future Current Release. These upcoming changes will include multiple enforcement mechanisms including changes in meta-installer, Studio and VDA registration processes.
Are Controllers running in a public cloud supported with on-premises workloads?
When product enforcement is in place, it will focus on VDA workloads and does not impact controllers. A customer may run their Citrix Virtual Apps and Desktops infrastructure in public clouds and connect to on-prem workloads if they choose.
Can you run a 2003 Current Release VDA with a 1912 LTSR Controller?
The LTSR program requires all baseline components to be on the LTSR version. Using 1912 Controllers to provision CR VDAs in public clouds is not supported. Reference the LTSR FAQ for more information.
This forward-looking indication of plans for products is preliminary and all future release dates are tentative and are subject to change.
The development, release and timing of any features or functionality described for our products remains at our sole discretion and are subject to change without notice or consultation. The information provided is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making purchasing decisions or incorporated into any contract.