All other in Citrix published application and channel name

Active Sessions is a counter retrieved from the Windows performance counters and it represents number of Citrix sessions on the server. Please note that we retrieve this counter every 5 minutes and then it is an aggregate in this 5 minutes. Then aggregation id further applied on CAS reports. in 12.3.2 and above the aggregated reports will show MAX value of the 5-minutes samples, so the result will be as Fiederieke achieved with 1-day resolution. In earlier versions the number was an average of the 5-min samples.

The "All Other" traffic always represents difference between what has been seen on the client-server binode level and what has been measured specifically by the decode. In case of ICA, we may not decode all operations, for a number of reasons: 

• encryption: RC5-encrypted traffic will show up under specific application name, but channel name will be "All Other Channels"
• session not seen from the beginning: all such traffic will show up under "All Other" application and "All Other Operations" channel name
• some session packets not delivered to the AMD or dropped by AMD because of overload: effect will be the same as with session not seen form the beginning because AMD needs to seek whole unbroken ICA stream to follow it (ICA is compressed using stream compression, so loss of a single packet inevitably breaks the analysis)

Summarizing "All Other" stuff is there for purely accounting purposes. You can measure overall usage and performance on the server-user level and if specific channel insight is required - focus on what has been measured to examine how the channel performs in relation to other ones, e.g. to see whether print or audio is not affecting interactive screen updates.

Hi Sylvian

Interesting questions. First of all you need to work out what resolution they want this in. Are they going to charge by the seat or by the hour?

Do the Citrix Admins really understand the concept of "response time"? A response time for teh ICA protocol is not the same as the user perceived response time. That is why we have the decodes on teh "back" of the Citrix to actually understand the Application response time and correlate that with the delivery over the ICA protocol.

Then,  a XenApp and XenDesktop isn't the same thing and even if they use the same delivery protocol (ICA) it has again, nothing to do with the Application Response TIme. Quite often I see "double bubble" which means that first you have a XenApp server and then you have a XenDesktop server so in a sense, the user has to traverse 3 different platforms (the third being the application and which can then be broken up into a number of tiers). The good thing is that you can monitor all of this but it's a serious job to get everything in place.

Why do you think you get better data from version 6 versus 7?

Isn't it just so that you have different things running in them?

As always - I recommend spending time listen on the PM Chris talk about this and what to do with the data and how to read it so that you don't draw the wrong conclusions http://apmu.dynatrace.com/?category_id=607&course_id=973&mod_id=17690  there is 2 that are really good

Hello Sylvian,

did you check if there is RC5 decryption in place for the XenApp 7 environment?

We had some trouble with this decryption because Citrix Decode cannot encrypt this.

For the "Active sessions" metric: I think it had something to do with the resolution of the report. We had some discussion with customers about this as well because Citrix administrators always stated that our count was too low. But if we switch the resolution to 1 Day it was the appropriate value here.

Hi Ulf,

Thanks for asking. The Citrix admins here want to know how many Citrix users and how long they stay with the connection during a day, a month ..... for charge back purpose.

Another thread posted by me regarding detect the user experience (response time) within XenApp and XenDesktop is their ultimate goal. To be fair, it is not what DCRUM decode design for, at least not at this moment. As a result, only can show the Citrix decode value from "RTT", "Realized Server Vandwidth" and "Loss rate"....

Interestingly, decode result of Published Application (tasks in dcrum) & channel (operation) from XenApp 6.0 seems much meaningful than XenApp7.6

I still wonder what "Active session" actually count, having followup with helpdesk on this for weeks. 'sigh'.

Thanks Ulf.

You mean it is something related to packet quality, but not similar to the "All Other Operation" in HTTP scenario?

 In HTTP at least we can use monitoring rule to decode URL as many as we can.

You're correct the traffic is from several SPAN ports. However I've checked the AMD packet stat and don't see significant packet loss while traffic throughput is around 500Mbps at peak.

Looking at the Citrix Landing Page, Published Application and Channel together with Citrix administrator and he wonder it is not what he want, from a Citrix admin perspective.

A silly question just come up, what are the values of Citrix Decode and TCAM? Why Citrix administrator endorse DCRUM Citrix decode instead of using Citrix monitoring tool?

Hi Sylvian

This often boils down to network packet quality.

What is the source of the data to you AMD's?

As you know, the analytics are based on looking at the binode conversations between the client and the server. If a packet is truly lost, it will be resent and we will see this. These are the default mechanics of TCP. If the traffic is fed to the AMD via a SPAN port, you can potentially loose the packet on the way to the port or at the port due to collisions (if you have multiple sources) or due to oversubscription. It will not be resent because the "true" packet got to the destination. Should that happen, the decode engine will see that it's missing a packet and drop it's association to a published Application or Operation and instead associate it with "All Other" so that the general high level metrics still are somewhat accurate.

To be able to calculate the right "Server Realized Bandwidth" there also needs to be some statistical data so that we get a good dataset. Having just a few 3-4 packets during a 5 minute interval doesn't make a good statistical base to make any assumptions upon.