Finally cleared to post this again 😉
So if you haven’t seen the latest, Citrix has finally publicly released their XenDesktop Essentials product! It’s exciting stuff – CITRIX BLOG COMING BACK SOON!
That said there are some serious caveats that you need to be aware of before you rush out to enjoy! The biggest problem, in my opinion, is the target audience. If you are thinking XD Essentials sounds awesome for a small shop you are right, its does. Unfortunately you can’t get it as a small shop. XD Essentials can only be used by customers with an EA license from Microsoft with Win10 entitlements. And you only qualify for an EA license if you are (I believe) 250 seats or higher.
So, that small business of 40-50 seats that seems like it would be an ideal candidate for this service can’t qualify. And that, to me, is the major weakness of this product. Let’s be clear, this is a Microsoft limitation and not Citrix. But larger customers who have EA are the ones who would look at Azure and Citrix Cloud primarily from an IaaS perspective. They aren’t going to use the Azure Store to provision new VMs, they are going to handle it themselves (or have partners handle it for them). I am not sure why Microsoft made this decision other than they would rather focus on the bigger $$$ right now. To me, it’s a real shame. This could have been a great way to go for the SMB space but they are immediately eliminated.
There are other design weaknesses… for example there is no NetScaler included with the XDE license which means another cost and more manual configuration that you have to do. And the wizard also doesn’t create the Cloud Connectors, Network, AD, etc; All things required for this service to actually work. So even as an EA customer be ready for a lot of manual setup!
Just a reminder that the 7.13 license server upgrade might turn your phone home back on, or if you are new to 7.11 or higher then it is on by default! If you want to be paranoid like me and disable it then you have to do it from the command line still. Follow the steps here to disable (confirmed still on 7.13):
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.
Continue reading »
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.
I’ve found myself really digging the Universal Gateway feature of NetScaler. I admit I don’t do a TON of NS work but it’s become almost a necessity for a good Citrix admin to have some good knowledge there. With that said, I was presented with a very interesting scenario that took me a few hours of digging. A customer has a 3rd party help desk system with no SSO. They wanted a link for that to be on the Universal Gateway page, but by default any link you add NetScaler treats as an INTERNAL link so it rewrites it. They wanted this to go straight to the external link without the need for internal proxy, etc; The answer turned out to be pretty simple but not one easily found by Google 🙂 Here’s how I did it (please note there are likely other ways to do this too, this is just what I found!)
- First we add a bookmark through the normal process. In this example I’m using docs.citrix.com. Netscaler Gateway -> Resources -> Bookmarks
2. Next we define the actual bookmark. Please note we are NOT using the NetScaler as a Reverse Proxy.
3. This gives us a simple bookmark. But if you click on that today it’s going to try and proxy it for you and you aren’t getting where you want to go (or if you do, not how you want it to get you there).
4. So we need to tell NetScaler to NOT try and proxy that domain. And the way we do that is in NetScaler Gateway -> Global Settings -> Configure Domains for Clientless Access. Under Allow Domains we are going to add the FQDN that we created the shortcut. for.
5. Now log in to your Universal Gateway VIP and you are presented with the shortcut.
6. And finally when you click that link, your browser goes directly to the site. No NetScaler proxy involved.
Yes it’s a very specialized use case but it’s interesting enough to note. Who knows maybe someone else will find this helpful 🙂
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 »