Cloud-hosted Citrix Components with On-prem non-Microsoft DNS

As public cloud technologies have evolved over the last few years, companies have begun to take the “cloud-first” approach more seriously. Citrix Consulting has been thoroughly involved in helping

make cloud-hosted Citrix initiatives a reality. While nearly all environment components can function on a cloud platform, a dependency that customers continue to operate on-premise is DNS. We’ve seen several instances of customers leveraging the Azure DHCP service with on-premises non-Microsoft DNS to provide host name resolution for cloud-hosted resources. The purpose of this article is to walk through a solution developed in the field for configuring Azure-hosted Citrix components to leverage on-premise non-Microsoft DNS.

In this scenario above, the Azure DHCP service and on-premise DNS servers do not have a defined communication channel for populating DNS entries. This is an issue because Citrix components rely on DNS for proper communication and functionality. The challenge is especially relevant with the Virtual Delivery Agents (VDAs), because:

  • There is a significant amount of communication between the Cloud Connectors and VDAs for registration and brokering
  • All XenApp/XenDesktop components are consumers of DNS. In other words, these components (including the Machine Creation Services [MCS] process) are not proactively sending hostname/IP address information to DNS servers for entry creation. Therefore, Citrix relies on DNS functioning properly rather than influencing it directly.

In order to tackle this challenge, we considered various potential solutions, including:

  • Bridging communication from Azure DHCP to the on-premises non-Microsoft DNS servers
  • Leveraging built-in Microsoft dynamic DNS capabilities
  • Deploying non-Microsoft DNS servers in Azure (dependent on vendor’s capabilities and leading practices)
  • Developing a custom script that uses Azure API calls to force the Citrix MCS service to distribute DNS records

Ultimately, we ended up choosing the dynamic DNS solution because of deployment simplicity and scalability estimates. For a refresher on dynamic DNS according to Microsoft documentation, “Domain-joined Windows clients register their IP addresses with the domain controller by using secure DDNS. The domain-join process sets the primary DNS suffix on the client and creates and maintains the trust relationship.” Beyond domain controllers, this built-in service can also be applied in the case being examined.

The following outlines an example of the Microsoft dynamic DNS solution that has been configured and tested using Azure DHCP with on-premise Infoblox DNS. This solution allows each VM to dynamically push its own DNS entry to the on-premises Infoblox appliance(s) and is comprised of the following high-level steps summarized below:

  1. Configure firewall ports for Dynamic DNS
  2. Configure Infoblox for Dynamic DNS
  3. Create Startup Script to modify NIC settings of MCS machines

DISCLAIMER: All configurations outlined in this blog should be reviewed with your Security and DNS teams and tested following your standard change control process prior to implementation into production.

First, the appropriate firewall rules are required in order to allow communication from the VDA network to the network of the on-premise DNS server. For dynamic DNS, open the standard UDP/TCP 53 ports to the on-premise client.

Next, configure the Infoblox appliance to specify which machines will be permitted to update their own DNS entries. This may be set in various ways. Infoblox’s Secure Dynamic Update allows update delegation by IP address, subnet, Transaction Signature (TSIG), or simply allowing all addresses/networks to perform updates. In the case of VDAs, entering a VDA subnet(s) can provide a method for delegating permission for dynamic updates while preventing application to extraneous machines. For Infoblox, specify the subnet(s) allowed to update their DNS entries via the management console by navigating to the desired domain and selecting “Zones“, “Updates“, “Allow updates from“, and then adding the VDA subnet under “Allow permissions for“.

Finally, configuration is required on each VDA in order to initiate the DNS population broadcast. Two settings need to be applied within the machines’ IPv4 Advanced DNS settings: check “Use this connection’s DNS suffix in DNS registration” and then add the desired domain suffix either first in the list of appended suffixes or in the “DNS suffix for this connection” field (Microsoft documentation is helpful for decoding what each field and check box means in this tab). Figure 1 provides a visual representation of the two required settings that must be configured.

Figure 1: Example configuration for dynamic DNS updates

When testing these settings on MCS-created VDAs, we learned that these settings did not persist when updating the master image because they are tied to machine NICs. In order to configure the settings above, we developed the following combination of a batch file and PowerShell script and disbursed them as a GPO startup script.

We created the PowerShell script below to inject the desired settings and placed it in the default startup script location on the master image (C:\Windows\System32\GroupPolicy\Machine\Scripts\Startup). The primary DNS suffix should be set to the desired value from Figure 1.

Set-ExecutionPolicy Unrestricted -Scope Process

Set-ExecutionPolicy Unrestricted -Scope CurrentUser

$adapters = get-wmiobject -class Win32_NetworkAdapterConfiguration -filter "IPEnabled=TRUE"

$adapters | foreach-object {

$_.SetDynamicDNSRegistration($TRUE, $TRUE)

$_.SetDNSDomain(‘primary DNS suffix’)

}

We experienced issues getting the PowerShell script above to deploy properly via GPO directly, so we ended up executing it via the following batch file command:

powershell.exe "path to .ps1 file above"

From here, we added the batch file as a startup script via GPO (which can also be applied via local policy or any other third-party personalization tools).

After following the steps above, voila! Each MCS machine within the specified subnet(s) now may function properly with corresponding DNS entries. DNS entry cleanup isn’t a significant concern because Azure MCS machines retain their NICs between reboots.

In summary, Azure-hosted Citrix resources can use on-premises Infoblox DNS by following the three primary configuration steps detailed above:

  1. Configure firewall ports for Dynamic DNS
  2. Configure Infoblox for Dynamic DNS
  3. Create Startup Script to modify NIC settings of MCS machines

For other third-party DNS solutions, consult your third-party DNS provider for details on enabling Dynamic DNS. Moving forward, those with on-premises non-Microsoft DNS may use Dynamic DNS as a workaround but should consider testing and moving towards cloud-hosted DNS solutions.

Add comment


Security code
Refresh

Download Freewww.bigtheme.net/joomla Joomla Templates Responsive