- Deciding How Many Farms To Deployall About Citrix Technology
- Deciding How Many Farms To Deployall About Citrix Service
- Deciding How Many Farms To Deployall About Citrix Systems
- Deciding How Many Farms To Deployall About Citrix Using
Citrix Application Delivery is big business, and something many of us have made a career of for over a decade. While many of us have bet our careers on Citrix Application Delivery, and it has become second nature to us — I still get a lot of questions from people who are new to Citrix on this topic. They ask me why Citrix is so popular right now, and what is it about Citrix that makes application delivery so efficient in a virtualized environment? Let’s take a look at some use cases, and do our best to explain why Citrix is the leader of the application delivery market space.
1). Ease of Delivery
When I say that it’s easy, I don’t mean for the administrators, because it’s obviously a lot of work to deploy a virtualized Citrix environment! I say it’s easy for the end users, who have to do nothing except install a small Citrix receiver or ICA client on their PC. Some don’t even have to do that much, because there are many Citrix admins out there who are successfully deploying receiver and client to thin clients via software delivery packages like SCCM so that the users don’t have to lift a finger at all. The benefit to the users is great because they don’t have to do anything other than turn on their PC, and they see some application icons appear in their start menu.
Citrix Virtual Apps and Desktops are well suited for remote access when paired with Citrix ADC as the gateway. It is great for when there are limited resources and applications and desktops need to be shared with many users. Deciding How Many Farms to Deploy. Managing Farm Infrastructure Updating Citrix License Server Settings Configuring the Citrix XML Service Port and Trust.
Some primary use cases for Citrix are still electronic medical records (EMR) applications, which would normally be gigantic and complex to install on a user’s PC. By deploying EMR applications over Citrix, you give the users the ability to access the brain of a super computer on something as small as their IPad or tablet. This has come in very handy in the medical profession recently, because most medical charting has moved away from a clipboard, and has moved to an Ipad or tablet. Without Citrix, you would not have the ability to run such powerful applications on portable devices, and therefore this step could never have been achieved!
2). Ability to Run Applications in Segregated Environments
We all have complex custom apps in our companies that are many years old, and that have not been updated forever. These are your problem apps that can dominate your time, and really light up the help desk with tickets whenever something breaks within them. These types of applications do not play well with others, and can’t typically be deployed on servers that are hosting other applications. Citrix came out with a feature a few years ago that didn’t really catch on called “Application Isolation Environments”. This was created so that you could deploy virtualized apps on a server in a way that would keep them from touching other apps, and messing with common pieces of infrastructure like Windows Server! While this feature is no longer heavily used, most Citrix admins now use the streaming ability built into every version of Xenapp since 4.5, which allows you to push down virtualized applications to the client desktop in a package that exists within itself, and does not depend on the OS or risk breaking other apps. Streaming has become the new way Citrix admins achieve application isolation during delivery, and it is an amazing technology. Streamed applications can also be packaged in ways that allows them to run when the user is not even connected to the network, which has some great niche applications for the mobile workforce!
3). Ability to Maintain Redundancy, and Eliminate Downtime
One of the primary reasons big companies, hospitals, and manufacturers rely on Citrix for application delivery is because of its ability to create redundancy and virtually eliminate downtime. This is accomplished in a few ways, starting with application siloing. By maintaing multiple servers that host certain applications, a server can be taken offline at will without impacting the other servers in the farm. This comes in handy for maintenance windows and change management. Many hospitals are now using Citrix Provisioning Server in their application delivery model so that they can make changes to a virtualized server image in the background, then deploy it to the farm without having any downtime at all. PVS is a quickly growing technology that is allowing Citrix admins the freedom to scale their environments up and down depending on need, while retaining complete control over change management.
4). Reduces Support Costs
Obviously if you don’t have a custom application installed on individual user desktops across an enterprise environment, it’s going to reduce your support costs. Help desk calls will decrease, user productivity will increase, and your bottom line will be positively impacted. This has been one of the best kept secrets of Citrix Application Delivery for years now, and it appears to be getting better. Many companies are now finding that if they used virtualized desktop delivery via Citrix Xendesktop, they can actually save even more money on support costs because they eliminate the need to support user desktops all together. Images are scrubbed each time a user logs off, and you can control the user’s ability to install applications, printers, or any number of options that might reduce downtime and help desk calls.
In conclusion, Citrix has been the leading in the application delivery space for close to a decade now, and there is simply no viable competition. While Microsoft continues to fiddle around with tools like RDPApp, and remote desktop — it remains clear that they don’t want to intrude on Citrix, probably because they still own a sizable amount of Citrix stock. Overall, Citrix seems poised to continue leading in this space, and it is a great career niche to bet your chips on. Most of the largest companies in the world currently depend on Citrix for application virtualization and delivery, and that does not look to change anytime soon.
In this multipart blog series, I will go over step-by-step on how to build a fully redundant Microsoft Remote Desktop Services 2012/2016 farm in conjunction with a Netscaler VPX front end. This series isn’t really meant for the average home or casual users but more so for system administrators looking at a low cost solution in providing their workforce with the ability to connect back to their corporate network to consume remote apps and desktops. I am writing this series at the same time I am completing these very steps in my work lab so this blog also serves as a note for me when I do have to implement it in production at a future date. In this very first post we’ll go over what components are needed in your infrastructure to build such a farm redundantly. I have scoured and poured over a lot of different articles on how to put this lab together so I’m just piecing them all here in hopes that it will help other administrators out when trying to do something similar! This lab is also excellent if your company is looking for a Citrix XenApp alternative. Although Citrix XenApp is the leader in remote access technologies, there are many out there, including us, that cannot justify paying the extra cost. This is especially true if you aren’t taking advantage of all the extra bells and whistles Citrix has to offer either because it adds an additional layer of complexity or simply because they aren’t needed at all.
Part 1: RDS Components Explained and Requirements for Lab
Part 2:Installation of Gateway, Web Access and Connection Broker
Part 3:Installation of Netscaler HA pair and Connection Broker LB Server
Part 4:Installation of SQL Server 2016, Connection Broker Farm and External LB Server
Part 5:External Connection and Testing of High Availability and Load Balancing
Ideally for this lab, all Windows server should be Windows Server 2016 but my lab here will have a Windows Server 2012 R2 for both my domain controller and session host. This shouldn’t be a problem as a Server 2012 R2 session host will be able to join a 2016 RDS farm without problems. However, the reverse is not true. Also keep in mind that although a session collection must contain Windows Server of the same version, you can however create different collections for each of the different Windows Server session host OS. Microsoft also recommends that your RD Licensing server role also be on Server 2016 as it has the ability to dish out user CAL’s for all prior version of Windows. This is a non-factor in our lab because by default, Windows will allow you to remote into the session hosts without any user CALs for quite some time before you’ll be rejected. Once our lab has completed, we’ll be easily able to connect to our farm on any device that supports the RDP client such as PC’s, Mac’s as well as Android and IOS based devices like tablets and phones.
Let’s get started!
Below are the VMs and components needed with a brief description of their role along with the internal IP address being used in my lab.
Virtualization Platform = VMware vSphere
You most likely could utilize the free Microsoft Hyper-V to lab this out as well. I was actually at first using VMware Workstation on my home lab computer but decided to use work resources instead due to SSD space running out.
Active Directory Domain Name = lab.local
This is my internal domain name.
ADFS.lab.local / 10.40.77.201
This is my domain controller. In a production environment, you’ll obviously have at least two but a single DC is enough for this lab to showcase the redundant capabilities of RDS itself.
RDWS01.lab.local / 10.40.77.205
This server serves as my RD Gateway, RD Web Access and Connection Broker. In addition, this server will also be the management server where I will be managing all of the other roles on the other servers in the RDS farm. We do this by adding the other servers to be managed in Server Manager.
The gateway is an optional piece in the RDS farm setup but if you’ll want external users to connect to your farm, you’ll definitely want to use a gateway. By using one, clients will actually connect to the gateway via port 443 and not your usual RDP port of 3389. This makes it much more secure and easier to configure since wherever the users are located, chances are port 443 will be allowed on the external firewall. Do remember that all client traffic will actually pass through the gateway once their session has been established.
The web access portion allows users to get access to resources by signing into a secure website. Once authenticated, the users will see a list of resources that they are allowed to access. Administrators familiar with Citrix can think of the web access portion as the Storefront or Web Interface equivalent.
The connection broker is the central piece that keeps track of clients session states. When you have a session host farm consisting of dozens of Windows Server, a single user could be using any one of them. When they disconnect and reconnect, the connection broker consults its data and will redirect the user back to their original server so that they can continue working right where they left off. This piece is also responsible for determining which session host to direct a user to when they first try to access resources.
Deciding How Many Farms To Deployall About Citrix Technology
RDWS02.lab.local / 10.40.77.206
This server serves as my secondary RD Gateway, RD Web Access and Connection Broker.
CBSQL.lab.local / 10.40.77.207
This server serves as my SQL server for the database needed to create the highly available connection broker role. In addition I will be using SQL 2016 with SP1 Standard Edition as the database. This will also work on the SQL 2012 Standard edition. I have not tried this lab with any version of SQL Express nor will I recommend you doing so.
RDS01.lab.local / 10.40.77.211
This server serves as my first session host and is the server that will host the remote apps and session desktops for your users.
RDS02.lab.local / 10.40.77.212
This server serves as my second session host.
Netscaler VPX 12 Freemium Edition / 10.40.77.215
This will be my Netscaler’s IP (NSIP) used for the management of the Netscaler VPX appliance itself. Although the Netscaler technically is an optional component in an RDS Farm, it is highly recommended that you use some sort of front end device to perform the load balancing of the gateway servers and connection brokers rather than relying on Windows Network Load Balancing and DNS Round Robin, respectively. Since this is only a lab, feel free to explore other load balancers once you get your lab up and running smoothly. Once you use a dedicated front end load balancer, you’ll never want to go back. The only negative is that the learning curve can be quite steep depending on what you are trying to accomplish as well as adding to your overall project cost should you decide to move into production. The one awesome part concerning the Netscaler in our lab here should you take it into production is that no extra licenses are needed! You’ll only have to worry about purchasing the right edition based on maximum bandwidth needed to support your environment.
With the newest version of Netscaler 12 VPX, the Express/Free version is now called the Freemium edition (although the license mode is still Express). This version is completely free of charge to use in production but is limited obviously in features available but more importantly, is limited to only 20Mbps bandwidth. You are able to fully follow this tutorial using this Freemium edition without having to worry about licenses! You can even use this Freemium edition of Netscaler in production to host a small group of session servers for a small group of users all without paying a single penny. And yes, you can even use this edition to setup HA mode!
Netscaler VPX 12 Freemium Edition / 10.40.77.216 (optional)
This will be the Netscaler’s IP (NSIP) for the secondary HA node. If your primary node is offline for any reason, this secondary node will take over all the IP’s (except the NSIP) and configuration settings of the primary node. This secondary node will then serve as the new primary node while the other Netscaler will then be considered the new secondary. This secondary node is optional for this lab but once you see how simple it is to configure a Netscaler HA pair, it wouldn’t make sense for you to not put this in your lab. You’ll get to see firsthand how awesome it is when utilizing a Netscaler HA pair fronting your RDS farm!
This will be the IP used as the Netscaler’s Subnet IP address (SNIP) to connect back to our back-end RDS farm servers.
RDCB.lab.local / 10.40.77.208
This will be the IP used by the Netscaler as the virtual server hosting the connection broker load balancing front end. Rather than configuring for DNS Round Robin, our HA connection broker name will resolve to this single IP address and the Netscaler will take care of loading balancing the requests to our two servers. DNS Round Robin has no failure detection mechanism so if one of the servers fail, it will still route requests to that server. Netscaler and other load balancers have logic built into them so that when it detects a server is down, it will stop routing requests to that server immediately.
This will be the IP used by the Netscaler as the virtual server hosting the front endpoint for all external client connections. This is where the magic happens.
Public IP Address NAT’ed to Main Virtual Server
In my case, my main virtual server would be the 10.40.77.220 IP on the Netscaler.
Port Forwarding TCP 443 and UDP 3391 (optional)
You will need to forward these two protocols and ports to your main virtual server. Although UDP 3391 is optional, it is highly recommended that you do this to allow a much better and smoother remote user experience.Because UDP is a connectionless protocol, it has less overhead than TCP and therefore is able to provide a better remote session experience for users. This is especially true if the remote users are connecting to your farm over a slow WAN link.
Deciding How Many Farms To Deployall About Citrix Service
Publicly Trusted SSL Certificate (optional)
This certificate will secure the external namespace used for the connection point of RD Web Access as well as the RD Gateway server. Although optional, it is highly recommended that you purchase a publicly trusted certificate to save you the work and hassle of having to install the untrusted certificate on your test machines. Because we are building a HA connection broker which will utilize a separate namespace, you can choose to either purchase a SAN certificate to secure two names on a single SSL certificate or do what I did to save money by using the public certificate to secure just the external name, which is more important of the two, and utilizing a self-signed certificate to secure the connection broker name. You can purchase a cheap three year SSL certificate for just $15 over at https://cheapsslsecurity.com and choosing the Comodo Positive SSL option. You will be able to reuse this certificate for future labs so your money is not wasted after this experiment has ended!
Publicly Registered Domain Name
You will need your own personal domain name for testing purposes as we will need to create a DNS record pointing our public IP address used for this lab to the name used in our SSL certificate. For security purposes, I will not be showing the pubic IP address nor the external name I used for my lab.
Deciding How Many Farms To Deployall About Citrix Systems
As you can see, there’s quite a lot of pieces that goes into creating this redundant RDS farm! It definitely can be daunting at first but I honestly think it’s not too bad once you explore the individual pieces by itself. The most beastly component of this lot is definitely the Netscaler. It can be as complicated as you want it to be or as simple as well. Luckily, our lab falls into the “simple” category as it will only take us less than 10 minutes or so to configure.
Deciding How Many Farms To Deployall About Citrix Using
In the next article, we’ll begin building out RDS pieces such as the gateway, web access and the connection broker.