Here’s the slide deck from my Geek 115 Summit presentation this evening. Enjoy!
Here’s the slide deck from my Geek 115 Summit presentation this evening. Enjoy!
For several years now, one of the defining differences between XenApp 6.5 and XenDesktop 7.x has been the absence of the Local Host Cache. As a refresher, LHC was used to keep a local copy of the database on each XenApp server to insure that in the event of a database outage your farm would continue to function. That’s all well and good when every XenApp server in a farm essentially had the brains to run itself off that local copy! Unfortunately in this case times have changed, and an individual VDI or VSI now merely has the limited guts it needs to broker sessions. All the true heavy lifting is now handled by the Delivery Controllers. And those, as you probalby know, are COMPLETELY reliant on SQL being available. Yes, Citrix provided a partial solution with Connection Leasing. That has serious limitations however, and I didn’t see it get a ton of use.
So after thinking long and hard about the problem, the Citrix team has come up with an interesting (albeit somewhat limited) solution. The new LHC methodology allows connection brokering to continue to occur when there is a disruption in the connection between the DDCs and the SQL databse OR between the local network and the Cloud Control Plane if you are using the Citrix Cloud. Please note though this important caveat… LHC is NOT a replacement for a highly available SQL infrastructure. That should always be your first line of defense in keeping your Site highly available. As you will see later in the post, there are some limitations and concerns that LHC cannot address.
So what is the actual solution? Essentially, one of your brokers in a Site (or potentially in a Zone) will fill the role of a Secondary Broker. That Delivery Controller will run a local SQL Local Database that maintains a limited copy of the Site Data to allow users to continue to broker. Let’s take a look at how it works under the covers.
I had a common scenario come up the other day that I decided to finally expand my horizons a bit for and write a simple script. Many thanks to Shane for walking me through it!
Scenario: Users have multiple static VDI published to them, all in the same Delivery Group. By default the Display Name is always what the Delivery Group says it should be… ie “Win10” or whatever you have defined. You do not have the ability in the GUI to change this setting to make the desktops unique. This is very common for administrators, test users, etc;
Need: Change the Display Name to be the same as the Machine Name so that the user knows what machine they are launching.
$ListofVMS=get-BrokerDesktop -DesktopGroupName “YourDeliveryGroupName”
ForEach($VM in $ListofVMS)
Set-BrokerPrivateDesktop -MachineName $VM.MachineName -PublishedName $NametoSet
This simple script grabs all the machines within a specific Delivery Group and writes the list of Machine Names to an array. It then processes each one as a variable, splitting the Machine Name at the \ to remove the Domain from the name in the array. It uses that new split Machine Name as a variable NametoSet and then uses the Set-BrokerPrivateDesktop command to change the “Published Name” to display the MachineName as per the NametoSet 🙂 Nice and easy.
With the more recent releases of XenApp/XenDesktop, Citrix reintroduced the concept of Zones. Unlike Zones in XenApp 6.5, the 7.x version is more of a parent/child relationship. You have a Primary zone which handles all of the communication to the database(s), and then secondary Zones which communicate to the Primary. Zones are less flexible in this configuration but still very useful for scenarios like DR. Think of it like this… you have your Primary DC which is where all your production infra lives. You build your Citrix infra there. You have a warm DR site as well. In the past, you would have had to build an entirely new Site there with all the overhead required for it. Now, using Zones, you simply build a couple Delivery Controllers and connect them to the hosting infra local to DR. Use NetScaler as your GSLB to detect when the Primary zone is down and redirect your users to DR and voila, they can still connect!
But there’s a problem with that scenario. When the Primary zone is down, you lose the ability to manage the Site through the Delivery Controller GUI. Remember, database connectivity all runs through the Primary Zone. Now one school of thought says “Well, your Primary Zone is down so you’ve likely lost your database anyway and the important point is your users can connect!” In my experience that’s seldom true. Most customers are doing some form of HA for SQL, whether it’s mirroring or AlwaysOn or even just restoring it in an outage. So your SQL remains up but your Primary Zone Delivery Controllers are down… you still can’t manage the Site. Thankfully there is a way to fix it! And that answer is PoSh:
Set-ConfigSite -PrimaryZone <Zone>
That command, run from your Secondary Zone DDC, will switch the defined Primary Zone over and allow database communication to resume. Huzzah! It’s important to keep this one in your back pocket if you intend to use Zones AND you have HA SQL involved. Otherwise you may have to scramble to restore your Primary Zone faster than intended.
Many thanks to the Citrix folks who pointed this out to me 🙂
When I first coded the XenDesktop farm migration tool, I only included support for XenDesktop 7.x, believing that most people would have upgraded to it by this stage. I guess I was wrong. Having received a good number of requests from people to add support for XenDesktop 5.6, I dutifully complied. The tool now has a checkbox option beside both the source and target DDC text boxes that allow you to indicate that the farm is XenDesktop 5.6. When this is selected, the tool will then use the correct version of the XenDesktop PowerShell SDK for commands to that farm. Continue reading »
Late last night Citrix dropped the bits for XenDesktop 7.11. There are a ton of great features in this release and I will discuss them over the next few weeks but there’s a gotcha you need to be aware of buried in the new 7.11 license server. Let’s talk about the Citrix License Manager Service. First, check out this article: http://docs.citrix.com/en-us/licensing/11-14/technical-overview.html
Here’s what Citrix says about this service:
“Citrix License Management Service
The License Management Service enables better capacity planning and license management. This service also helps you avoid prohibited practices:
This service further alerts the administrator in Citrix Insight Services about duplicate licenses in a Disaster Recovery (DR) environment. For more information about Citrix Insight Services, see Citrix Insight Services.
The License Management Service uses product telemetry, built into the License Server, to send data to Citrix Insight Services. The first upload occurs one week after the License Server first starts and subsequent uploads occur every week thereafter. The schedule resets if you reinstall the License Server. If an upload fails, another attempt is made in 24 hours. This continues indefinitely until either the upload succeeds or you disable the License Management Service. Citrix may use uploads to help you understand and support your license environment. See Use the command line to disable or enable the License Management Service.”
So here’s the gotcha… many Citrix administrators with a large environment have a DR. Citrix has never provided a decent DR for the license server, choosing instead to give you a grace period to reestablish one in the case of failure. So what many of us tend to do is run a second license server at the DR site with the same license files. Please note, this IS an allowed strategy as long as you aren’t using the same licenses for different users. With this new service (on by default) you now phone home your license server data to Citrix Insight Service and it WILL start to warn you that you are running the same licenses on multiple license servers. Does a warning matter? Not yet. And in many cases the license servers can’t reach the Internet anyway. But I’m a paranoid old admin, and I see where that road could lead. So with that said, Citrix does provide you a way to disable this service:
From a command line –
-enable enables license management. The first upload to Citrix occurs seven days after you install the License Server.
-disable disables license management. We recommend you use the License Management Service to manage your licensing environment.
-query Displays the current configuration.
I haven’t had a way to try this, but I suspect license server upgrades may re-enable this service. So make sure when you go to say 7.12 you check for this. And if you don’t care about this at all, then feel free to ignore this paranoid post 🙂
This morning Citrix publicly announced the acquisition of Norskale. If you have ever been to a Synergy you probably remember Norskale for the cute little foam ghosts they give out on the floor (my dogs love them!). Helmed by fellow (now former!) CTP Pierre Marmignon Norskale has been enhacing the VDI space for years with top notch EUM solutions. They also provide a very easy thin client transformation technology that gives Citrix an interesting play in the Physical Desktop space. Once the transition is complete Norskale technologies will be available to all Enterprise and Platinum customers with a current Software Maintenance (NOT Subscription Advantage… it’s a combination of SA and Support basically).
This is big news for Citrix. One of the perceived stack weaknesses against VMware was their EUM component. Citrix Profile Management was an ok stop gap for many customers but Norskale brings a whole new level to their EUM space and one that customers should happily embrace. What makes this an interesting play is going to be the reaction of their partners… RES, AppSense, Liquidware, etc; There is still absolutely room for all of those products in the ecosystem. They bring a more complete, wholistic solution. But for many mid-small size implementations this announcement will take some of those partners off the table.
Congrats to Pierre and the Norskale team!
The XenDesktop Farm Migration Utility allows you to seamlessly migration VM’s between different XenDesktop farms. This can be done on a per VM basis or in batches of up to 500. As well as providing migration functionality, it can also be used for Disaster Recovery, allowing you to back up and restore your VM’s on your farm.