Building a Citrix XenApp 7.18 POC with Netscaler! Part 4

In part 3, we went over how we easily got our Netscaler VPX to work in conjunction with providing external access to our XenApp 7.18 POC farm. At this point, you should have a working and functional environment to play around in. Anything else you do from here on out can be considered tweaking and customizing XenApp to your liking. In this last blog post of the series, I’ll go over some of the things that I’ve personally adjusted after having installed XenApp. Majority of these are clearly optional but should provide you with some insight as to how powerful this product can be. I’m probably just skimming the top of the surface but hopefully it will get you motivated into venturing out on your own afterwards into customizing your XenApp environment to suit your needs.

Part 1: Building a Citrix XenApp 7.18 POC with Netscaler!

Part 2: Building a Citrix XenApp 7.18 POC with Netscaler!

Part 3: Building a Citrix XenApp 7.18 POC with Netscaler!

HTML5 Instead of Citrix Receiver

One of the first things I messed around with was getting HTML5 to work instead of requiring the clients to have the native Citrix Receiver installed on their machines. HTML5 is the future and many modern browsers have been supporting it for quite some time now. By allowing your users to connect to your XenApp environment without requiring any previous software pre-installed can be a huge benefit. For example, users who frequently travel may use machines other than their own. Kiosk machines comes into mind. These machines are usually locked down and it wouldn’t be possible to install third-party software. Even if it was possible, the user may wish to skip that procedure and log directly onto XenApp to minimize time wasted. With the HTML5 feature enabled, clientless access is now a possibility. Fortunately, enabling is extremely simple!

1. Head over to Citrix Studio –> Policies.
2. By default, you’ll have one policy called ‘Unfiltered’ which should be blank with no settings enabled/disabled. Select the ‘Create Policy’ link at the upper right panel.
3. In the policy creation window, head over to the Search field and type in ‘websoc’. You should then see three settings in the window.
4. We need to enable all three of these settings. First is Websockets Connection. By default this is disabled. Select the Allowed button to enable this feature.
5. Next is Websockets port number policy. Select  the policy. The default value should be 8008. Leave this as is and hit the OK button. Do not hit Cancel. You must hit OK.
6. Last of the policy is the Websockets trusted origin list. Again, select the policy and leave the default value of *. Hit the OK button, not Cancel.
7. Once all three policies have been enabled, hit Next to proceed. In Users and Machines, select the radio button of ‘All objects in the site’.
8. Finally, on the Summary screen, give your policy a name. It’s very important here that you checkmark the ‘Enable policy’ option otherwise this will not work.
9. With the policy enabled, we now enable the clientless option for our Receiver for Website store. Head over to Citrix Storefront –> Stores –> Manage Receiver for Websites –> Configure. In the ‘Deploy Citrix Receiver’ section, change the default from ‘Install locally’ to ‘Use Receiver for HTML5 if local Receiver is unavailable’ and hit OK.
10. Time for testing! Preferably, you’ll want to try this on a client machine with no Citrix Receiver installed. If you don’t have a spare machine, simply uninstall the Citrix Receiver program for this test. Log back into your site. You should now see the option ‘Use light version’. If you don’t see this, clear your browser cache and try again. Click on this option to let XenApp know that you will be connecting over HTML5 instead of the native Citrix Receiver. Launch your virtual desktop and a new browser tab should open connecting you to your resource!
11. If you want to change back to using the native Receiver app, click on your user account in the top right corner in Storefront and select the option to ‘Change Citrix Receiver’. You’ll then be prompted to detect your Receiver again.
    

    Enabling Unified Experience

By turning on this feature, you’re essentially doing your users a favor by making both the Citrix Receiver for website and native Citrix receiver to look and behave the same. This causes less confusion for your users because both experiences are “unified” and the same.

1. By default, logging into the native Citrix Receiver will present the old Storefront green bubble theme. Not really the prettiest of themes to be honest but besides that, it also behaves differently than if you were to use the Storefront via the web site. In this demo, I’m logging into the Citrix Receiver right from my delivery VM, which holds all the roles of my Citrix lab. For the URL, I’m typing in the address for public login via Netscaler which is https://citrix.anotherwindowsblog.com. It will then prompt me for username and password. If you are doing this from another computer, you will need to first import the certificate of your Storefront VM into the Root Certification store of the computer you are connecting from.
2. Once the Receiver app opens, I’ll have to unfortunately logon again with my domain credentials. If the prompt does not appear, hit the Logon button at the top. Once you’re signed on, if your user has a virtual desktop assigned, it should automatically launch in the background. At first, your home screen will be completely blank. Hit the + icon to the left and you should then see a list of all your assigned applications and desktops. Clicking on them won’t actually launch them but rather put them on the front page. Think of this as marking/subscribing these applications as your favorites.
3. The awesome part about using the native Citrix Receiver rather than having users go through the web page is that their favorite apps actually appear on their Start Menu. This makes it look as if those apps have been natively installed on the users local computer. In my example, I choose to add Server Manager and Paint as my favorites in the Receiver so these appeared in my Start Menu as newly installed applications.
4. Enabling the Unified Experience feature is very simple. In Citrix Storefront –> Stores, Configure Unified Experience link on the right panel. In the dialog box, enable the checkbox and select the default website.
5. To have the new setting take effect immediately, I had to unfortunately reset my Citrix Receiver. Exiting and relaunching it did not work nor was a logoff/logon. Once I logged back on, I saw the familiar Storefront for Web interface instead of the green bubble theme.
   

   Creating IIS Self-Signed Certificates Longer Than 1 year

By default, creating a self-signed certificate in IIS defaults with an expiration of 1 year from date of creation. This is obviously fine for lab scenarios and testing environments but if for whatever reasons you want to create one that lasts much longer, there is a way to accomplish that using PowerShell. Credit goes out to Glennopedia website for teaching of this awesome trick.

Because the trick only works on Windows Server 2016 or Windows 10, I’ll need to generate this on a separate computer and then import both the private and public key pair back onto my delivery controller machine. Below you can see the output after having ran the command. I deleted the -DnsName option. After the certificate has been generated on your machine, you can then export it along with the private key using the Certificates MMC snapin. Once you have it imported, you should then see it in IIS manager and from there you just bind the newly created certificate to the default website. Although using self-signed certificates is considered bad practice in production environments, it can still be done should you understand the consequences for doing so. Do remember that if you’ll have users connecting to your Citrix environment using the native Citrix Receiver, they will each need to have the self-signed certificate installed onto their local machines in order to be able to connect. This can usually be done with Group Policy to push the certificate out.

Workspace Control and Client Settings

When you launch an application or desktop from the Receiver for Web page, by default it will automatically disconnect you of your app if you either sign off from the website or your session times out. When the user reconnects to their app later, Citrix will reconnect them to the same session used previously. This setting can be controversial in my opinion but most users I’ve dealt with do not prefer this option. Many would usually prefer to disconnect/logoff of their session on their own. Luckily, this setting is easily controlled.

If you find that a virtual desktop is automatically launching after a user logs in, you can disable this behavior via the Client Interface Settings page. From my testing, this behavior only happened during the very first time I configured my Citrix Receiver after having logged on. This behavior did not repeat itself afterwards. If you do however find this constantly happening, you can easily disable it as well.

Assigning Apps and Desktops to Specific Machines

This feature is huge where older XenApp 6.5 customers are concerned. In this older infrastructure, admins were able to easily bind specific apps and desktops to only launch on certain servers. This obviously defeated the purpose of load balancing but there can be many different types of scenarios where this is warranted. For example, the most common is for troubleshooting purposes where an administrator would have each desktop in a farm published just for them. So, if a farm had four desktops, the administrator would have four individual desktops published to be able to launch any one of them for troubleshooting issues rather than waiting for load balancing to hopefully drop them in the right server. The latest version of Citrix 7.x now gives us this capability via tag restrictions.

Limiting Desktops

1. To apply tags to our servers, simply double-click on your machine catalog within Citrix Studio. This should automatically perform a search and present you with all the servers in that machine catalog. I only have one machine catalog with two machines in it.
2. Right-click on a server and select Manage Tags. Simply create a new tag. You’ll obviously want to create a naming convention that is easy to remember and easily identifiable. After applying, you should then see the tag applied to the server in the Tags section of the server in the bottom pane.
3. Now we need to edit our Delivery Group to publish a new desktop but only apply to server(s) with this tag. In our Delivery Group, we’ll select the Desktops tab and then Add. You can see in my screenshot that I’ve added a new desktop but the most important part is that I’ve restricted which servers can be used by selecting the tag that I’ve just created. Because there is only one server with this tag applied, launching this desktop will always launch my worker00.lab.local server. It will never launch worker01.lab.local. I’ve also only published it to my Domain Admins group. It should then show up when I log in as a user within the Domain Admins group.
4. When I now launch the desktop, it should only launch on the machine that has the tag applied. To really test this, apply a different tag to your second server, edit your Delivery Group and the desktop you’ve just created but this time, filter via this new second tag and relaunch. It should now only launch on your second server instead of the first.

Limited Applications

With restricting applications, the process is nearly the same except for an extra step in creating an Application Group.

1. Start off with selecting the machines you want to run this specific application and create a tag. In my example, I will limit the Server Manager application to only run on my worker01.lab.local machine and not worker00.lab.local.
2. With the tag created and applied, I now create my Application Group. Click on Applications and then the “Create Application Group’ link on the right panel. Similarly when restricting desktops, you’ll want to apply the tag you’ve just created. You can see in my screenshot that only 1 out of 2 servers will serve this application when launched by users.
3. Within Applications options, I will choose to add an existing one and select Server Manager.
4. Test by refreshing your apps either in the native Citrix Receiver if you’re using that or via the web Storefront and then launching your restricted application. You can see in my screenshot that my Server Manager has been launched on my worker01.lab.local machine.
   

   Citrix Director

A very helpful piece to go along with your Citrix environment is Citrix Director. This web-based portal gives you the opportunity to troubleshoot your user sessions along with viewing historical stats and more importantly, monitoring the health of your farm. This can be a great tool to give to your support team as well.

1. Log in to Director by browsing to https://yourserver/Director. You’ll be presented with the main dashboard that will give you an overview of your environment such as currently logged on user sessions, average logon duration, failed machines, licensing status and more.
2. Head over to the Trends section and you’ll get to view a whole lot of information regarding how well or not, your environment is. This section is a great place to stay ahead of the game by viewing traffic trends and patterns. It will allow you to scale your environment when the time comes where you see slower performance over time. Rather than waiting for users to start complaining, you can be proactive and join more servers into the farm.
3. Shadowing user sessions plays a big part in a Citrix environment. This is where your help desk/support team comes into the picture by using Director. They can easily send remote messages to the user informing them that help is on the way. Also, offering Remote Assistance is just a couple of clicks away.
   

   Disabling Smart Access and Smart Control in Netscaler

   Two advanced feature when it comes to the Netscaler and Citrix is Smart Control and Smart Access. These features allow you to configure restrictions and conditions on how users connect to your environment. For example, you could create a policy that prevents your users from accessing some resources if their antivirus signature is too out of date. These features are obviously for advanced cases. The problem is that both of these features require an additional Netscaler Gateway Universal License for each concurrent user connection. If you have 1000 concurrent users who will utilize either one of these features, you will need to purchase 1000 of these Universal Licenses. The good news is that newer version of Netscaler, like version 12 as of this writing, automatically comes with 500 of these licenses for the Standard edition. If you purchase the Platinum edition of Netscaler, you can utilize an unlimited amount of Universal licenses. If however you won’t be using these two features, it’s better to disable them on the virtual server. I believe by default a virtual server you create for accessing XenApp in the backend will have Smart Access feature enabled

Fortunately, disabling this is extremely easy. Simply head into your virtual server on the Netscaler and enable the checkbox for ‘ICA Only’. Once you do this, your users will not be able to take advantage of any features of Smart Control or Smart Access. The Netscaler allows an unlimited amount of ICA Only connections.

I hope everyone had a easy time setting up their Citrix XenApp POC environment with Netscaler by following this blog series. It’s not advance in any way imaginable but my goal has always been to just get people interested in something and go out afterwards to learn more on their own. If you are planning on mobilizing your workforce then you’re obviously going to be looking at either Microsoft RDS or Citrix XenApp. I don’t think one is miles ahead of the other but instead, you’ll just have to pick one that will work to your needs. Citrix offers a ton of optimization but has a higher overhead cost due to licensing and the requirement of some type of load balancer like the Netscaler. Microsoft RDS is baked into Windows Server so if your shop is mainly focused on Microsoft products, it makes sense to not stray too far from home.

Either way, always test, test and do more tests! Get your users involved because they will usually be the deciding factor when it comes to product adoption (I highly want to emphasize the word ‘usually’ here). Both Citrix and Microsoft allow you plenty of time to do evaluation and trials.  

The post Building a Citrix XenApp 7.18 POC with Netscaler! Part 4 appeared first on AnotherWindowsBlog.