Tag Archives: XenApp

Windows 2016 Bandwidth Estimates for XenApp


For 10 months in the cold north, we are addicted to winter weather forecasts (ok, 10 months is a little extreme. Winter does not usually last that long in Minnesota). But during winter, we always want to know how much snow we are going to get. The answer always comes down to ranges

  • Less than 1 inch
  • 1-2 inches
  • 2-4 inches
  • 3-5 inches
  • 5-8 inches
  • 6-10 inches
  • 8-15 inches
  • Head south

As the totals get larger, the ranges get larger. There is so much room for error due to many variables.

The same thing can be said for estimating network bandwidth requirements for XenApp and XenDesktop. In another blog, I focused on Windows 10 bandwidth for XenDesktop. I want to now look at the same series of tests but for Windows 2016.

I broke the bandwidth estimate down into 3 categories

  • VDA Version: Certain releases of XenApp make improvements to the network utilization. Bandwidth tests must account for these changes by looking at different VDA versions.
  • Policy: XenApp policies can have a drastic impact on overall bandwidth utilization. With heavier compression (at the expense of CPU), overall bandwidth usage drops. Each test includes a look at WAN and User Experience policies (defined at the end).
  • Workload: A user watching videos and browsing Internet content will consume significantly more bandwidth that someone mostly using Office applications. The workloads are broken down across task worker, knowledge worker and power worker.

First, let’s look at the averages for a 60 minute simulation:


By looking at averages, I can make out a noticeable bandwidth reduction for the task worker on a WAN policy between 7.11 and 7.15/7.17 releases. To get a better idea on the network bursts, let’s look at the 95th percentile

Again, we see a drop in the task worker with the WAN Policy between 7.11 and 7.15 release.  I can also see a drop in the Task worker with the user experience policy between 7.15 and 7.17 releases.

And remember, these tests are simulations. Your results will be different because you are using real users with real workloads with real network congestion.

Note: The naming convention is follows: “Workload – XenApp Policy”
The XenApp policies are

Policy WAN UX
Audio Quality Low High
Desktop wallpaper Disabled Allowed
Dynamic windows preview Prohibited Enabled
Extra color compression Disabled Disabled
Limit video quality Max 480p/720kbps Not configured
Menu animation Prohibited Allowed
Preferred color depth for simple graphics 16 bits per pixel 24 bits per pixel
Target frame rate 16 fps 30 fps
Target minimum frame rate 8 fps 10 fps
Use video codec for compression Do not use video codec For the entire screen
View window contents while dragging Allowed Allowed
Visual quality Low High

 

Daniel (Follow on Twitter @djfeller)
XenApp/XenDesktop On-Prem Poster
XenApp/XenDesktop Cloud Service Poster
Citrix XenApp and XenDesktop 7.15 VDI Handbook

Advertisements

Latest XenApp XenDesktop bandwidth utilization tests


As many of you saw, XenApp and XenDesktop 7.17 was recently released.  And again, there are statements saying that due to optimizations in the codecs, bandwidth usage rates dropped again.

Is it just me, or does it seem like every few releases Citrix finds ways to further reduce bandwidth consumption. When 7.13 came out, there were statements saying bandwidth utilization dropped. And in 7.17, we are hearing similar remarks.

I wanted to see how true this was, so I ran my own simulations. I decided to run tests against the 7.11, 7.12, 7.13, 7.14, 7.15, 7.16 and 7.17 releases.

Bandwidth Utilization

I know, the lines do get a bit jumbled, but you can see each simulation ran similar workloads as the rises in usage all appear within similar time periods.

To make it easier to see the overall bandwidth reductions, lets switch to a bar graph.

Bandwidth Utilization

Now you can easily see 3 distinct groupings of data:

  1. Group 1: 7.11 and 7.12
  2. Group 2: 7.13-7.16
  3. Group 3: 7.17

So it is true, 7.17 further reduces bandwidth consumption.

Daniel (Follow on Twitter @djfeller)
XenApp/XenDesktop On-Prem Poster
XenApp/XenDesktop Cloud Service Poster
Citrix XenApp and XenDesktop 7.15 VDI Handbook

 

 

Local Host Cache for Citrix Cloud


One of the best practices I talk about often is “You will fail“.

I know, not a very positive message, but it is the truth… You will fail. It is only a matter of time. Those of us who are in IT know how painful it is when there is a failure. We understand all that can go wrong. And when dealing with cloud-based solutions, the concern for an outage is even more terrifying.

Why?

Probably because it is out of our control. When there is a problem, we are at the mercy of those who operate the service. But if the cloud solution is designed properly, a disruption doesn’t necessarily mean all hope is lost.

Let’s take a look at section of the XenApp and XenDesktop Service of Citrix Cloud poster where we have StoreFront and NetScaler Gateway on-prem.


What, in the diagram, catches your eye?

For me it is the many items going between the on-prem Cloud Connector and the cloud-hosted XenApp and XenDesktop service. If the connector cannot talk to the XenApp and XenDesktop service, what happens?

Well, until recently, you were out of luck.

But now, cloud connectors have local host cache functionality that can overcome cloud or WAN outages.

When the cloud connectors have access to the XenApp and XenDesktop Service, the remote broker provider handles the interactions between Citrix Cloud and the VDA/StoreFront/NetScaler instances. In addition, the Cloud Connector’s config sync service maintains a local cached database of the cloud-hosted XenApp and XenDesktop config.


When the Cloud Connector is unable to reach Citrix Cloud, the remote broker provider, which is responsible for handling interactions between Citrix cloud and the VDA/StoreFront/NetScaler, transfers brokering control to the high available service, which uses the locally cached database.

Even if the link between our resource location and Citrix Cloud is broken, users can still access their apps and desktops.

Daniel (Follow on Twitter @djfeller)
XenApp/XenDesktop On-Prem Poster
XenApp/XenDesktop Cloud Service Poster
Citrix XenApp and XenDesktop 7.15 VDI Handbook

Use Citrix Director Historical Trends


It is amazing how much data gets captured as we interact with people and things throughout the day. Do you ever look at it?

I DO! I love data. I find it fascinating to see what trends you can observe.

The other day, I was reviewing how much water we use at home. Our city tracks usage, which I can view. For the past 12 years, my water usage was 48, 59, 46, 59, 56, 55, 62, 71, 62, 69, 73, 83.

Not super helpful until we turn that data into a graph.

Two things immediately pop out:

  1. Over the past 12 years, our water usage has steadily gone up, which makes sense as my kids get older and take longer showers (I can’t even imagine what happens to this graph when they become teenagers).
  2. Three points in time, my yearly water usage dropped. Why? After a little research, I concluded that each one of those years corresponds to the year where I replaced one of our 3 toilets, which were 20+ years old. You’ve probably heard that new toilets use less water than older ones, so much so that I can see the impact on my yearly water usage. Fascinating

For XenApp and XenDesktop admins, many of you know that Director includes real-time tracking and historical usage trends. Ever wondered how you can use this capability effectively?

Let’s say you have to install a cumulative update, a security patch or an app update on a XenApp host. Are you concerned about the potential impact on the scalability of the server? You should be. Who knows what it will do to the overall user density.

Because we are unsure about the potential impact of an update, we should follow a cloud-thinking strategy with updates by using a canary model where we patch a small subset of systems first to identify any issues before rolling out to all of production servers.

Let those servers run and bake for 7 days, if possible, to gather enough real-user data to generate useful historical trends in Director.

Here I did 2 hour historical trend, and although I can see increases in RAM and CPU, the insights can get lost with all of the minor fluctuations within real user behavior.

 

By using a longer time period for the trend, those minor fluctuations smooth out and better insights can be gathered.

Those insights are critical to the ongoing stability of your environment. Did CPU increase/decrease? Did RAM? Did user load? If there is an increase, you need to determine if the percent increase is greater than your available extra capacity within your environment. If so, you have to allocate more resources BEFORE you roll out the update to all production servers, or else you will end up with a lack of server resources to service all of your user requests.

In the end, if you don’t plan properly, your usability gets flushed down the drain.

Daniel (Follow on Twitter @djfeller)
XenApp/XenDesktop On-Prem Poster
XenApp/XenDesktop Cloud Service Poster
Citrix XenApp and XenDesktop 7.15 VDI Handbook

Show window contents while dragging


Let’s test your XenApp/XenDesktop design skills.

With XenApp/XenDesktop 7.15, do you want to show window contents while dragging?

NO CHEATING! Answer before continuing

Continue reading Show window contents while dragging

Windows 10 End of Support Cycle


Let’s go through a typical conversation I end up having

 

Me: What version of Windows are
you using on your desktop? 

You: Windows 10

Me: What VERSION of Windows 10?

You: Do you mean Pro or Enterprise?

Me: No. What Windows 10 version
number, like a build number?

You: Build number? Who cares?
I’m no  developer. It’s just
Windows 10

Me: Au contraire mon capitan!
There are 4 different Windows 10
versions, 5 as of October 17, 2017.

You: WHAT?

Me: And the first version no longer
receives updates, with the second
version stops in October of 2017

You: Are you #$@% kidding me?

Even though Windows 10 has been available for over 2 years, many people are unaware of the servicing cycle of Windows 10, and it isn’t surprising. We’ve all been used to the Microsoft desktop OS cycle being measured in years. We would roll out Windows XP and thought nothing more about it for 5-10 years until it was time to move to Windows 7, wait 5-10 more years and move to Windows 10.

But with Microsoft turning Windows into a service, we must start measuring the Windows 10 cycle in terms of months and NOT years.  Look at the history of Windows 10.

Windows 10 Version Name Release Date Branch End of Servicing/Support Update Count
1507 Windows 10 July 29, 2015 CBB

LTSB

May 9, 2017

October 13, 2020

30

32 and counting

1511 November Update November 12, 2015 CBB October 10, 2017 37 and counting
1607 Anniversary Update August 2, 2016 CBB


LTSB

TBD (March 2018)

October 12, 2021

20 and counting

20 and counting

1703 Creator’s Update April, 11, 2017 CBB TBD (September 2018) 3 and counting
1709 Fall Creator’s Update October 17, 2017 Semi-Annual TBD (March 2019)
(TBD) 1803 March 2018 Semi-Annual TBD (September 2019)
(TBD) 1809 September 2018 Semi-Annual TBD (March 2020)
(TBD) 1903 March 2019 Semi-Annual TBD (September 2020)

For anyone using the CBB (Current Branch for Business), which is being renamed to Semi-Annual, we are able to skip 2 updates (that’s good) before reaching the end of servicing timeframe where we will no longer receive security fixes (that’s bad). And with each CBB/Semi-Annual release running on a roughly 6 month cadence (that’s good), this requires us to perform a major update every 18 months (that’s bad).

Each release provided significant improvements in the overall user experience.  We received new functionality, plugins for Edge. We had better performing apps, like Edge. We could integrate newer technologies, like IoT.  But each release changed the operating system by including new default apps, services and scheduled tasks; impacting user logon time and overall system resource consumption.

In order to follow best practices, we need to optimize appropriately to achieve the best combination of user experience and resource consumption.  Each time we have a major feature upgrade for Windows 10, we need to repeat our optimization

  1. Optimize default apps
  2. Optimize Windows services
  3. Optimize scheduled tasks
  4. Optimize user interface/runtime

Daniel (Follow on Twitter @djfeller)
Citrix XenApp and XenDesktop 7.15 VDI Handbook
XenApp Best Practices
XenApp Video

XenApp and XenDesktop Component Architecture Poster


Note: For a deployment utilizing Citrix Cloud, use the XenApp and XenDesktop Service Architecture Poster

Focusing on XenApp and XenDesktop for many years, I hear certain questions over and over again:

  • Do you have an conceptual architecture drawing for a XenApp and XenDesktop on-premises deployment?
  • How about a hybrid-cloud deployment?
  • What about the XenApp and XenDesktop Service in Citrix Cloud?
  • What does the logon/app enumeration flow look like?
  • What network ports do I need?

I’ve seen separate diagrams answering these questions, but they are usually buried in an appendix of a very long paper. I thought it would be nice to have a single source for this technical information, which is why I created the XenApp and XenDesktop Component Architecture Poster (PDF File)

Do you like?

And I’m already anticipating your next question: Can we have the source Visio file?

Of course! I just added them to the Citrix Workspace Visio Stencil.

Daniel (Follow on Twitter @djfeller)
Citrix XenApp and XenDesktop 7.15 VDI Handbook
XenApp Best Practices
XenApp Video