When I was a Citrix consultant one thing I tried to keep in mind when architecting a solution was to always keep it simple for the customer. Meaning that one should only put a solution in place based on the in house expertise that is there to support the infrastructure. In other words just because you purchase a XenDesktop  or XenApp platinum license that you shouldn’t try and install every technology that comes with the license or at least initially. All too often we had seen implementations sold to the customer (by other vendors of course) that was too much too soon and the end result was a delayed project that could not get to production due to time a costs. Just because you can do it does not mean you should do it.

One of the items that I always waited to put into play with an initial implementation phase of any project was EdgeSight. Especially for I.T. shops that were “newbie” Citrix administrators. I remember being called into a customer’s site after the original vendor had exhausted it’s time trying to get a XenApp project into production. The customer was not too happy with the complexity of all that was surrounding the XenApp implementation which included items such as AppSense and EdgeSight. The customer wanted to scrap EdgeSight altogether but  in the end I convinced them to keep EdgeSight but put it in play once XenApp was fully in working and in production. Over time after they learned how XenApp worked EdgeSight was able to further give them insight into the environment.

Ok, Enough of the Chatter, Give me the example!

Fast forward to my current gig where I recently was tasked to trouble shoot a remote location as they have been reporting  “response time” issues that had been going on for some time, years actually. Naturally I love a challenge. The users are still using full desktops (keep in mind Citrix is still relatively new in our company), local file servers, and remote domain controllers. The complaints were the usual issues of browsing files were slow, remote connections to servers were slow, logging on is slow at times, and many more. What had been established is local servers are not resource taxed and  the network people swear there is hardly any bandwidth being utilized. The first thing I decided to do is install EdgeSight Endpoint agents on the computers in the remote locations. This exposed a few items right away

One of the glaring items I found is identify a network delay but it was happening for a specific process. With the tools that were in place there was nothing that could dig down to the application layer this effetely prior to installing the ES agent. The one process happened to be lsass.exe which had issues at times talking to the domain controller. As you can see in the screen cap below the lsass.exe process was experiencing a large delay in communicating with the domain controller where other processes on the same endpoint were not having any issues:

We can also pinpoint which domain controller is involved:

The EdgeSight data exposed that the domain controller was not responding to lsass.exe requests in a timely fashion. The domain controller happens to be in the data center across the WAN. However since other processes were able to communicate to other servers that were also in the same remote data center without issue revealed that either the remote domain controller is under powered or a local domain controller is needed.

I will published more “real life” EdgeSight examples that will show how powerful EdgeSight is when using it as a tool to monitor and troubleshoot. Remember, EdgeSight does not just have to be for Citrix related products.

>trevor