Citrix provides a nice PowerShell command to query the RAM cache used via the MCLI PowerShell snap-in.  This snap-in (McliPSSnapIn.dll) comes standard with Provisioning Server Console install and is located in C:\Program Files\Citrix\Provisioning Services Console.  Before it can be added to PowerShell, the dll must be registered on any system wish to run the query from.

To register the dll on a 64-bit machine, run the following PowerShell command:

• C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\InstallUtil.exe ‘C:\Program Files\Citrix\Provisioning Services Console\McliPSSnapIn.dll’

To add the snap-in to a PowerShell command prompt, run the following command:

• Add-PSSnapin -Name McliPSSnapIn

Run the following command against a XenApp server to see how much RAM cache is used:

• mcli-get deviceinfo -p devicename={servername} -f status

The second number returned in the status section is the percentage of the RAM Cache used.

First, let’s take a quick look at the MAKtivation process.  Before any target devices are activated, the following option is available in the Provisioning Server console:

Selecting that option brings up the following dialogue:

Assuming you’ve installed Microsoft VAMT 2.0 on all Provisioning Servers, simply enter your MAK key, click OK, and you’re off to the (somewhat slow but effective) races.  When all target devices are activated you’ll receive the following confirmation, and your target devices should be free of any Windows activation warnings.

You’ll also notice that the option to “Manage MAK Activations” no longer appears in the Provisioning Server console:

This process worked well until I upgraded the VDA in my vDisk to support XenDesktop 5.5.  After rebooting, Windows reported that hardware had changed and that I needed to reactivate.  Unfortunately no one told Provisioning Server because the MAKtivation option was still gone, temporarily leaving me in unactivated and unable to reactivate purgatory.

Per Citrix’s guidance, an automated vDisk update process must be followed in order to preserve MAKtivation.  Yeah… so we’re gonna have to go ahead and break that on purpose by manually disassociating the vDisk from the affected target devices:

Ensure your target devices are powered off and confirm that the vDisk associations are removed in the console:

Once that’s done, manually reassociate the vDisk, boot your target devices, and *POOF* the MAKtivation option is back:

As expected, the new receiver requires some updates to your existing XenApp or XenDesktop environment to work (you’ll need a MyCitrix login to download them).  Additionally, the receiver currently only supports XenDesktop 5.0 and XenApp 6.0 environments running on Windows Server 2008 R2.  Whether that list will be expanded as the receiver matures – given that this is still listed as a tech preview – remains to be seen.

The release of this new receiver, though currently limited to a very small market, could be the start of a much broader shift in how remote users access Citrix environments, and we’re quite excited to finally get our hands on it.  We’ll work on getting our environment set up in the next day or two to give the new receiver – as well as that Chromebook that’s been sitting on my desk – a run for its money.

The Samsung Chromebook Series 5

Chrome OS, which officially launches on June 15th,  is  Google’s much-anticipated entry into the operating system space.  At first glance, it looks like little more than a Chrome browser window.  At second glance, you realize that it really is just a browser on steroids.  This makes perfect sense, because the OS is centered around Google’s (lofty) assertion that the applications we use day to day on our current machines are “legacy” apps, and that the future of computing lies in web-based applications.  While I fully agree with the second part of that statement and am continually impressed by what web apps are able to do these days, many Enterprise applications are far from being web app ready.  That’s where the Citrix Receiver comes into play.  Citrix’s XenApp platform has long been utilized to access published applications on non-Windows operating system,  and Citrix’s announced support for Chrome OS opens up a whole world of possibilities for the new operating system.  Unfortunately, as of this afternoon, the Receiver continues to be missing-in-action from the Chrome Web Store.

Plenty of angry birds, but no Citrix Receiver.

What excites me about Google’s new operating system is how vastly different it is than the competition.  They set out to redefine how we think about personal computing in a web-centric world, and that in turn requires users to change some of their behavior.  I don’t expect Chromebooks to be springing up in large numbers in the legal sector any time soon (despite Google’s compelling Enterprise offers), but they are perfectly suited for mobile users and it won’t be long before people start asking about them for remote access.  I’ll be keeping an eye out of the Citrix Receiver and plan on reporting back on how it handles the XenApp environment once I have it up and running.

Test Configuration

The tests below use XenDesktop 5 SP1 and Provisioning Server 5.6 SP1.  The target VM is Windows 7 64-bit SP1 running on vSphere 4.1 and is configured with 4Gb RAM.

The vDisk is configured with 2Gb RAM cache.

This results in 4Gb total, 2Gb usable in Windows.

The Clown Car

We’ll begin with a fresh VDI session.  The PvS system tray applet shows 1% of the system cache is used.

We’ll then saturate the RAM cache by generating a 2Gb test file.

The test file is created successfully and the RAM cache is maxed at 100%.

Since we started with 30Mb and wrote another 2048Mb that should be it for our session, right?  Not quite.  Let’s copy a 1Gb Exchange ISO from the network…

…and download a 900Mb Windows service pack from the Internet.

“Shut the front door!” you say?  “Does Windows still work?”  Well, this video of the Swedish Chef plays perfectly.

I’m also able to create and save content in Paint, WordPad, etc.  Weird, right?  Let’s take a look at why this occurs.

The Explanation (per Citrix engineering)

When Citrix network stack interface driver (bnistack) MIoProcessWcRamWriteTransaction detects insufficient memory it returns successful to the caller (Windows) without actually saving the data to the RAM cache, so if Windows never reads the same data back, practically unlimited data can be added (though it may be limited by other factors like available disk space – Windows will prevent you from creating a 10Gb file when you have 8Gb free on your vDisk, for example).  Once the RAM cache becomes saturated errors are logged as follows:

Unfortunately by the time you attempt to access the Event Log your system is likely frozen, and if it’s a Standard image without redirected log files you’re out of luck when the frozen session is reset.

Digging Deeper

What does the explanation above really mean?  Does it hold up in practice?  Where does excess data go if it isn’t actually written?  What happens when you attempt to access excess data?  The examples below explore these questions.

Example 1

Upon logging on to a fresh VDI session and opening my test file creator, I have over 6 Gb free on the C drive…

…and memory usage is as follows:

I then create five separate 450Gb test files.

As the files are created RAM cache utilization increases, memory in use remains roughly constant, standby memory (Windows system cache) increases, and free memory decreases.

I can continue creating test files up to the limit of available hard drive space, at which point the following error is generated:

In other words, similar to “The Clown Car” above, I was able to generate test files that far exceeded the RAM cache before encountering an issue, and if I’d had a larger hard drive I would have been able to generate more.

So where did the data go?  We see in the table above that as test files are created the RAM cache increases in direct proportion to test file size until no more RAM cache remains.  Standby memory increases and free memory decreases in a similar manner, presumably showing that Windows is caching the most recently created data for quick access later, though this can’t really be considered “storage” for purposes of this analysis.

So what about the excess?  Let’s look at another example…

Example 2

Five 450 Gb test files are created, thus saturating RAM cache.  Attempting to open any of them results in an immediate system freeze and eventual reset.  In addition, deleting one or more of them then attempting to open one that remains results in an immediate freeze and eventual reset.  Finally, deleting all five files, creating a sixth, and attempting to open it results in an immediate freeze and eventual reset.  This suggests that once the RAM cache is saturated, attempting to access any content within it freezes the system.

Example 3

Four 450 Gb test files are created and RAM cache is at 89%.  Any one of them are opened.  A fifth is then created, thus saturating RAM cache.  We would appear to be in the same position as the previous example, but this time any of the first four files can be opened again and opening the fifth freezes the system.  This suggests that opening a file before the RAM cache is saturated somehow “protects” cache contents.

Example 4

Four 450 Gb test files are created and RAM cache is at 89%.  Any one of them are deleted.  RAM cache remains at 89%.  A fifth file is created.  RAM cache remains at 89%.  This suggests that deleted info isn’t reclaimed (or at least isn’t reported as reclaimed by the Virtual Disk Status applet) but is available for reuse when deleted.

Example 5

Four 450 Gb test files are created and RAM cache is at 89%.  Attempting to open all 4 maxes out memory in use, the system begins paging, the page file consumes additional RAM cache, and when RAM cache becomes saturated the system freezes.

Conclusions

The examples above suggest the following:

• RAM cache can be reused, but not reclaimed, up to the point of saturation.
• RAM cache saturation will likely not be apparent to end users.
• Once the saturation point is reached, data is at risk.
• If no files in the cache were accessed prior to saturation, any attempt to access cache contents will result in a freeze.
• If any file in the cache is accessed prior to saturation, contents in the cache prior to reaching saturation appear to be “protected.”
• Page file size and use is another important consideration.

Future

Citrix engineering has acknowledged that this is a bug, and has indicated that the fix should be to crash (BSOD) when RAM cache becomes saturated. “The fix should be to crash?  Really?” Yes, following the philosophy that existing user data should be protected and further corruption should be prevented.

Final Thoughts

As a best practice, a proof of concept with write cache on the server is recommended as it allows analysis of write cache size over time.  Once confidence is established with regard to write cache size, cost/benefit analysis can be performed relative to write cache location.

Thanks to my colleagues Matt Liebowitz and Niraj Patel for their help with this post.

(One last thing to note, to be fair, there are some Citrix KB articles that document some of the steps below that I used to help me compile some of this information, but it is not as organized and is disparate.)

Adding a corporate logo to the splash screen

Even if organizations are not doing many advanced customizations, this is a basic task that I see most firms do. It can be done right from the Citrix Web Interface Management console if the Web Interface was running on a Windows Server/IIS box. Completing on the NetScaler is a bit more tedious. Without getting into too many details about where the authentication point is configured (that might only require only one of these logos to be customized) , the two logos in question are as follows:

Citrix Access Gateway logo:

Citrix Web Interface logo:

First thing you’ll want to do is get an SFTP client to login to the NetScaler appliance. I use WinSCP, but any client should do.  The other thing I would recommend procuring before starting is the correct size and file format of your corporate logos . (It is important these logos are the appropriate size or they will get squashed or cut up on the page.) For the ‘Citrix Access Gateway’ splash logo, that would be going with a 265×62 pixel GIF file. Name this file “ctxHeader01.gif“.  For the ‘Web Interface’ logo, that would be a 59×25 pixel PNG file. Name this file “CitrixLogoHeader.png”.  Once you have procured these custom corporate logos, they need to be replaced on the NetScaler appliance itself with the default images.  Once connected to the appliance with an SFTP client, replace the default logos with the newly created ones in the following locations:

1. Citrix Access Gateway logo: <root>/netscaler/ns_gui/vpn/images
2. Web Interface logo: <root>/var/wi/tomcat/webapps/Citrix/XenApp/media*

*Note: This location would be the name of whatever the Web Interface site was named on the NetScaler.  In my example, it was “XenApp”.

Once the files have been replaced, the NetScaler splash page and the Web Interface should be reflected immediately with the updated logos.  The one caveat here is that these logos will be replaced back to default every time the appliance is rebooted.  Not to worry though, there are some basic steps to follow to make sure they are copied back the appropriate location each time, so that they are updated after an appliance reboot.

Follow the basic steps below to complete this:

1. Create “customizations” folder in the following location:  <root>/var/customizations.
2. Copy the custom “ctxHeader01.gif” and “CitrixLogoHeader.png” files to this newly created folder.
3. Browse to <root>\flash\nsconfig and insert the following lines to the bottom of the rc.netscaler file and hit save.

cp /var/customizations/ctxHeader01.gif /netscaler/ns_gui/vpn/images/ctxHeader01.gif
cp /netscaler/ns_gui/vpn/images/ctxHeader01.gif /var/customizations/
cp /var/customizations/CitrixLogoHeader.png /var/wi/webapps/Citrix/XenApp/media/CitrixLogoHeader.png*
cp /var/wi/webapps/Citrix/XenApp/media/CitrixLogoHeader.png /var/customizations/*

*Note: This location would be the name of whatever the Web Interface site was called on the Netscaler

Adding a disclaimer to the NetScaler splash page

Similar to adding a corporate logo, most organizations opt to add some type of disclaimer to the Citrix Web Interface site for legal reasons.  The process to complete this is significantly more tedious when doing this on a NetScaler than doing this on a Citrix Web Interface/Citrix Secure Gateway setup that leverages Windows IIS.   Follow the steps below to add a disclaimer to the NetScaler:

1. Edit the index.html in the location: <root>/netscaler/ns_gui/vpn/index.html.
2. Underneath line 116 in index.html, input the following text with the organizations custom disclaimer and save the file.

<td></td><td></td><td align=”right”><span style=”display:none”><img src=”/vpn/images/LoginButtonRolloverGlow.gif”/></span><input type=”submit” id=”Log_On” value=”" class=”CTX_CaxtonButton” onclick=”ns_check();” onmouseover=”this.className=’CTX_CaxtonButton_Hover’;” onmouseout=”this.className=’CTX_CaxtonButton’;”/></td>
</tr>
</table>
</div>
</td>
</tr>
</table>
<!– Disclaimer customization –>
This is a private computer system. It is for authorized use only. Users, whether authorized or unauthorized, acknowledge that there is no right or expectation of privacy with respect to any communication, information, or file sent, received or stored through this computer, e-mail, voicemail or other electronic systems.
<!– End of Disclaimer customization–>
</FORM>
<script language=”javascript” type=”text/javascript”>

3. The disclaimer should apply immediately once the index.html is saved.
4. Again, like the corporate logos in the previous step, this setting will reset if the NetScaler appliance is rebooted.  In the “customizations” (created in the previous step) folder copy the newly edited index.html
5. Browse to <root>\flash\nsconfig and insert the following lines to the bottom of the rc.netscaler file and hit save.

cp /var/customizations/index.html /netscaler/ns_gui/vpn/index.html
cp /netscaler/ns_gui/vpn/index.html /var/customizations/

Deploying the Citrix Online Plugin

One of the most basic customizations that I recommend organizations do is deploy the Citrix Online Plugin from the organizations web interface site instead of the default redirection to the Citrix download page if a client is not detected.  Deploying the client from the Web Interface simplifies the experience for users who are connecting with non firm workstations and ensures the same version that was tested and deployed on firm workstations is deployed to non workstations that require the client.  Again, completing this task from the Windows IIS Web Interface is a fairly straightforward, however the task is not as a straight forward on the Web Interface running on the Netscaler.  Actually, I found the task to be particularly challenging because I could not find good documentation, but below are the steps that worked for me:

1. Create ‘Clients’ folder structure in the following location and copy the Citrix Online Plugin executable in the following path: <root>/var/wi/tomcat/webapps/Citrix/XenApp/Clients/Windows/On-line Plugin/CitrixOnlinePluginWeb.exe*
2. Update the WebInterface.conf file (see below for more details) and uncomment “UpgradeClientsAtLogin=On”
3. Save configuration and reboot NetScaler.

*Note: The folders here are case sensitive.

General Management of the Web Interface running on NetScaler

Most administrators who managed the Citrix Web Interface are accustomed to leveraging the management console that is bundled with the install.  Not only does it allow for basic management of the Web Interface site, over the years Citrix has added more and more functionality within the GUI console to handle most customizations and advanced options that previously required folks to manually update the Webinterface.conf file.  Unfortunately, Citrix takes a few steps back with the integrated Web Interface on the NetScaler.  There is absolutely no management console for it and administrators are forced to make update the Webinterface.conf file to configure any custom settings they might need to make.  This link to Citrix’s eDocs library details out all the parameters that can be configured in the Webinterface.conf file for all the different settings the Web Interface accepts for any additional customization/management that needs to be done.

(As an aside, this post is only talking to VDI and in particular as a desktop replacement and not other use cases that may include, but are not limited to training rooms, war rooms, remote access, etc.)

Licensing is confusing and expensive

The finger is first pointed at Microsoft and their ever changing (confusing) licensing scheme for VDI.   A quick browse of the VDI licensing guide details seven scenarios and the licensing implications for using VDI with respect to each.  Does it really need to be this confusing?  Can’t Microsoft license VDI in the same way they license Terminal Servers to simplify this?  The other hindrance here is the essential requirement that an organization purchase Software Assurance for desktops or purchase a VDA for each user/device connecting to a VDI desktop.  This is a cost of about $100 per user/desktop that some firms have not been used to shelling out.  Most of the firms that I have worked with (specifically the SMBs) don’t purchase Software Assurance for Windows desktops as they purchase Windows OEM licenses from Dell, HP, etc.

Let’s now point the finger at Citrix.  I have a law firm client at the moment that currently leverages XenApp as a desktop replacement and owns a XenApp license for every user in the firm.  “Upgrading” these licenses to XenDesktop using Citrix’s trade up calculator results in the firm paying $20,000 (retail) to convert their existing (140) concurrent use XenApp licenses to named user/device XenDesktop licenses.  Should they want to continue to leverage CCU licenses for XenDesktop, they would have to shell out almost $50,000….  ‘Yes’, they are technically now getting XenDesktop and XenApp as part of the upgrade, but I would contend that if Citrix allowed a 1:1 conversion from XenApp CCU licenses to XenDesktop  CCU licenses (and did not give XenApp for “free” as part of it), it would be more palpable for customers (but clearly less profitable for Citrix) to make the conversion.

Citrix and VMware’s Offline VDI solutions are not there yet

Let me start by acknowledging there are less and less scenarios in which a user is “offline” the days.  However there are still scenarios in which users are offline or have a degraded connection that require a functional offline VDI solution.  Specifically, airplanes, spotty WiFi in hotels (my personal pet peeve) and public spots along with low bandwidth/high latency air cards among other scenarios.  VMware’s botched approach with its Type II hypervisor with checking in/out VMs would not meet expectations of law firm users.  Citrix’s approach with its Type I hypervisor, XenClient, is promising but is still a 1.0 product one year later.  The HCL for XenClient is also limited to a subset of machines and the server piece (Synchronizer) of XenClient is also only available for Citrix XenServer, which also makes it a non starter.  The bottom line is that the current offerings by Citrix and VMware are just not good enough from a usability/manageability perspective for law firms to accept it.

Organization politics and delegation of responsibilities

This section is very specific to the legal space as most firms are structured such that there are “Infrastructure” folks and “Applications” folks that work in individual silos.  The Infrastructure folks are primarily responsible for networking, security, messaging, virtualization, shared storage, sometimes Citrix XenApp, etc. while the “Applications” folks are responsible for Windows desktops, user profile management, software distribution, application integration and the overall user experience.  My experience has been that most Applications folks don’t want to touch the Infrastructure, and Infrastructure folks definitely don’t want to deal with anything user facing.  If a firm were to embark on a VDI initiative, it would require tight collaboration between the two different silos as a successful VDI implementation requires careful infrastructure planning as well as application integration for good user experience.  Of course, fighting organizational politics and contention of responsibilities is left up to a CIO, but I see this is another reason why VDI goes nowhere in law firms.

User Experience is not as good as local desktops

Isn’t this what a desktop is all about?  If a firm invests hundreds of thousands of dollars in a new VDI desktop, and the user perception is that it doesn’t perform as well as the traditional desktop it was replacing, is the project a success?  PCoIP and ICA protocols have improved significantly along with some of the HDX and user experience improvement with the latest versions of XenDesktop and View, however designing a VDI desktop to perform as well as a typical local desktop (4 cores/4 GB RAM) with Windows 7 is still difficult to impossible.  Specifically when it comes to media (audio and video) and resource intensive applications.

The local desktop is still required

Ideally, a VDI environment would leverage a BYOPC or Thin Terminal model in which the local corporate desktop is obsolete and not required.  Users would have their own PC and Thin Terminals to access their “managed” corporate VDI desktop in which all their applications were available to them.  Unfortunately, its not that black and white at law firms.  To start, law firms have hundreds of applications and making them all available through a VDI desktop is very challenging even with application virtualization solutions.  Additionally, the local desktop in some way provides an “insurance policy” for firms to allow for local applications (outside the VDI desktop) in some facet.  This could be business applications such as a browser toolbar required for collaboration, or  Adobe PDF reader to view large PDF files a user brings in on a DVD.  These local applications could also be non-business applications such as DVD video software and iTunes.  The point is that law firms have knowledge workers who have an array of IT demands with respect to their applications and user experience and the local desktop would not get replaced
even with VDI.  I am not saying it is impossible, it would just be very hard.

The fact that the local desktop is still required creates multiple management points for IT as they have to not only manage a VDI desktop, they have to continue to maintain, service, patch, etc. a local Windows desktop.  Citrix and VMware would contend that the capital costs of VDI is not where the savings are, but the operational costs are where all the savings come from.  I am sure there are some fancy marketing charts or Gartner charts that attempt to prove this, but let’s take them at their word.  The challenge here is that most law firm’s would not be replacing their local desktops (with Thin Terminals) should they move forward with a VDI solution.

Honorable Mention

Capital costs for shared storage and virtualization infrastructure, Thin environments with XenApp/Terminal Servers can be built for a fraction of the cost of VDI.

Conclusions

I am going to end this post by saying the success to any VDI environment (or any technology project for that matter) is knowing your use case and business requirements.  This has been drilled into me by my colleague Matt Liebowitz who probably starts every VDI conversation with the phrase “know your use case”.  Too many times technologists lose sight of the business requirements and use cases for a particular technology before attempting to fit a square peg in a round hole.  VDI offers obvious benefits in some areas over a traditional desktop, but it isn’t a one size fits all model.   The use case I focus on in this post (VDI as a desktop replacements) relay my thoughts on why most firms see VDI as an non starter because the challenges associated with implementing VDI outweighs the firm’s business requirements for doing it.  Is VDI a non starter for all law firms?  Absolutely not. There are some scenarios in which a firm’s business requirements and existing desktop circumstances make VDI an attractive and potentially more cost effective approach than a traditional desktop.

To achieve optimal results when you use Outlook with Remote Desktop Services, pay attention to how you customize your Outlook configuration. For example, in Outlook 2010 you can configure Cached Exchange Mode with Remote Desktop Services.

The article is careful to mention that you’d need to have enough disk space on the server to handle each user’s OST file. Maybe this makes sense for small environments with only one Terminal Server and tidy mailboxes. I can count on less than one hand how many firms fall into that category.

Based on our experience, we recommend disabling Cached Mode on any XenApp server we put in place. At the same time, we want to allow our users to run in Cached Mode on their Windows 7 desktops. How do we achieve this?  Through the use of Loopback Policy, we can ensure that when users log in to a XenApp server, Cached Mode will be disabled.  This policy will override the settings within a MAPI profile that is roamed or flexed to the XenApp server. When the user logs back into their Windows 7 desktop, they are happily working in Cached Mode again.

This is just another example of how technology can change without much fanfare.  For many years, we never hard to worry about this situation. The mere fact that the user was logging in to a Terminal Server with Outlook 2003 meant that Cached Mode would be disabled no matter what. But with Outlook 2010 and Server 2008 R2/XenApp, a successful implementation relies on a successful configuration of the environment. You can download the Microsoft White Paper on the planning considerations of Outlook 2010 on Server 2008 R2 here.

I contacted Citrix support and learned that the Receiver does not currently support Subject Alternative Name (SAN) certificates (a.k.a. Unified Communications or UC certificates) unless the principal name (the “Issued to” name) is the first entry in the subject alternative name list.  Since the first entry in the subject alternative name list IS the principal name, this is another way of saying that subject alternative names are not currently supported.

In the example below, example.domain.com is the principal name.

It’s also the first entry in the subject alternative name list, so if I want to use it when connecting with the Receiver I’ll be in good shape.

However, if I connect to another entry that’s lower in the subject alternative name list, mobile.domain.com for example, it will fail.

Hopefully Citrix will resolve this issue in a future release. In the meantime I hope you find this information helpful.

Upgrading to Netscaler 9.3

It was a no brainer upgrading my 9.2 VPX 1000 Netscalers (running the “classic” code) to 9.3 by downloading the update from Citrix and following the GUI wizard.  The process took less than 20 minutes and went without error or any downtime since my Netscalers are setup in an HA pair.  It was pretty straightforward to perform a failover, upgrade, and repeat.

What is important to note is that after version 9.3 there will be no new releases of the Netscaler “classic” code in favor of the “nCore” code.  To provide some background, with the release of Netscaler 9.2 last year, Citrix made their nCore code available to the VPX appliances as it was previously only available for the physical MPX boxes.  At the same time, the existing code set was dubbed “classic” and each new revision of 9.2x was released in both classic and nCore flavors.  The change also bumped up the minimum requirements of the Netscaler VPX from 1 vCPU and 1 GB of RAM (running on classic) to a heftier 2 vCPU and 4 GB of RAM if you are running nCore.  For environments leveraging some of the advanced content caching and acceleration features, nCore might make sense, however for ones using the Netscaler for ICA/SSL proxy and application level load balancing, there is limited value in the nCore code.  (I don’t care to go into the specific improvements to the code, architecture that nCore brings over classic, but feel free to read this Citrix Whitepaper if you are interested.)  The notable here is that after version 9.3, Citrix will no longer be releasing updates to the “classic” version of the code, thus forcing you to run nCore going forward.

Integrated Citrix Web Interface on Netscaler nCore

While technically, this has been available since 9.2 version of the Netscaler running nCore, I figured I would mention this feature in this post.  The Citrix Web Interface which is required for any XenApp or XenDesktop solution can be integrated within the Netscaler.  (This Citrix Technote shows you how.)  The ability to spin up Citrix Web Interface sites on the Netscaler appliance is an attractive solution for a number of reasons.  The first is a reduction in at least two Windows 2008 R2 servers that are typically dedicated for the Citrix Web Interface.  While this might not mean much from a licensing perspective when running Windows 2008 R2 Datacenter in a virtualized environment, an argument can be made that the all-inclusive (within the Netscaler) is simpler to manage than Windows 2008 R2 boxes that require patches and anti-virus among other things.  I usually allocate 2 GB of RAM and 1 vCPU for a Windows 2008 R2 server running Citrix Web Interface, so reducing a couple of these servers also provides a nominal reduction of resources to the virtualization solution.

One thing to note about integrating the Web Interface on the Netscaler are the implications about customizing it.  Most organizations brand their Citrix Web Interface to some degree.  This might mean something simple as adding a banner, logo, disclaimer, or something more complex that includes custom fields, embedded links, etc.  Completing these customizations on a Windows/IIS server is significantly easier for Systems Administrators than completing them on the embedded web server of the Netscaler.  While Citrix does provide a GUI driven interface to customize the logo and banner, advanced customizations of the integrated Web Interface can be challenging.

Over the next week, I’ll be upgrading my environment with integrated Web Interface on my 9.3 Netscalers to replace my existing Windows 2008 R2 based Web Interface servers.  I plan to follow up this post with my thoughts, findings and successes/failures in customizing it, so stay tuned.