How to deploy EdgeSight 5.4 XenApp agents using install scripts to all your Citrix Farms

EdgeSight Agents for XenApp can be deployed and configured to all of your XenApp servers easily via command line scripts/batch files. Here are the 3 .bat scripts I have written for the 3 different agent flavors, 5.3 for 32 bit and 64 bit 2003 OSes and 5.4 for 2008 XenApp 6.0, 6.5, etc. OSes. It also writes a very verbose log file to the C: drive so you can troubleshoot if the agent fails to install. Keep in mind I have the “XENAPP_AGENT” folder shared out on the EdgeSight server in these examples but you can stick it on a network share and modify the path accordingly:

2003 32 bit agent install:

2003 64 bit agent install:

2008 64 bit XA6+ agent install:

Now let me go over what each of these switches does. Keep in mind some of these values are ideal for my current environment, but you may need to edit these scripts for yours:

–SERVER_NAME = the EdgeSight server name

–COMPANY = the company you created in EdgeSight. You can also use “DEPARTMENT” to further breakdown but that is for Endpoint agents. XenApp agents will use the Citrix farm name to break down so you don’t need to worry about this value.

–ALLOWSERVEROS = I set it to 1 which means go ahead and install on Server OSes but this is really an EdgeSight for Endpoints setting and not for EdgeSight for Xenapp. I just leave it to maintain consistency with my VDI install script. Doesn’t hurt anything.

–INSTALLROOT = is where the Edgesight agent will be installed. I am installing on the D: drive instead of the default C: drive as you can see. The directory will vary depending on your OS so please pay close attention to this. Inside this directory are the various agent related files like rscorsvc.exe, Firebird files (including Fbserver.exe), etc. are located.

–DATA_DIR = is the EdgeSight working directory and will contain important logs like SYS_EVENT_TXT.txt and all the Worker logs. Again, I tell it to install on D: drive because I don’t want my C: drive to ever fill up with logs. Slim chance with EdgeSight but I try to follow best practice whenever I can. Also note the Firebird database (RSDATR.FDB) is also located in this directory. If anything, that is the file that will be growing the fastest.

–REMOTE_SECURITY = So if you ever use the Monitor or Troubleshoot tabs in the EdgeSight web console and click on a server, your desktop is actually connecting to the EdgeSight agent on that server over port 9035 using the credentials you are logged into your desktop with, not the EdgeSight web console.

So let’s say you are using your domain user account to login to your desktop, but use a server administrator account to login to the EdgeSight web console. When you click on a server under Monitor, your desktop immediately opens a connection on 9035 to that server. If your domain user account is not a local administrator on that server, EdgeSight will display a message like this:

Real time information is unavailable.
There was an error connecting to the remote Citrix System Monitoring Agent database. The Citrix System Monitoring Agent may not be running on the specified machine. Please try again.

OR

Real time information is unavailable.
Access denied: You do not have permission to access this resource.

Naturally if you are using a regular domain user account and another administrative account for server administration, you are probably not going to have the domain user account as a local admin on the server. So the EdgeSight agent allows you a couple of options to work around this. Namely, allowing anyone to connect over the EdgeSight web console or limiting it to a certain AD security group. Unfortunately, both these options have to be set in the registry, it’s not something you can set in the EdgeSight agent GUI. The location of these keys are:

32 bit OS:
HKEY_LOCAL_MACHINE\Software\Citrix\System Monitoring\Agent\Core\4.00\RemoteSecurity

64 bit OS:
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Citrix\System Monitoring\Agent\Core\4.00\RemoteSecurity

By default, RemoteSecurity is set to “1” meaning you have to be a local admin on the server. Setting it to “0” allows you to specify the AD security group that should have access to the EdgeSight agent. This security group should contain all the domain user accounts that will be using the EdgeSight web console. To actually specify the group, you need to drop the security group name into one of the following keys:

32 bit OS:
HKEY_LOCAL_MACHINE\Software\Citrix\System Monitoring\Agent\Core\4.00\RemoteSecurityGroup

64 bit OS:
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Citrix\System Monitoring\Agent\Core\4.00\RemoteSecurityGroup

The last option and the one I have used in my scripts above is setting RemoteSecurity to “0”. This lets anyone using the EdgeSight web console to connect to a server to view realtime info. The reason is if you have several network segments with Citrix farms and they are all on different domains with no trust, you can’t specify all those different AD security groups in the registry unless you create a custom EdgeSight install script for each domain specifying the RemoteSecurityGroup value. This gets a little cumbersome to manage if you have a lot of domains. Even then, getting it to pass these credentials from your desktop to the XenApp server in question gets a little hairy. So just keep in mind, “0” is a workaround but really the best practice is to use “1” and specify a RemoteSecurityGroup if you can. My reasoning is “0” is okay since I already control who has access to the EdgeSight web console and I want all my console users (which are all server admins) to have access to realtime reports.

BTW, just add “REMOTE_SECURITY_GROUP=yourADsecuritygroupname” to the install scripts above if you want to specify this value for your EdgeSight agents.

–FUNCTIONALITY_MODE = I set this to “1” to set the agent to Advanced mode. If you set it to “2” it will install in Basic mode. So if your environment consists of a bunch of Enterprise Citrix servers and you don’t have any Platinum servers or an actual EdgeSight for XenApp monitoring license, then you may want to use the value of “2” to just pull basic EdgeSight data. Otherwise you will begin getting errors on your EdgeSight server like:

EdgeSight – Grace Period license violations detected on YourServerName
The device YourServerName at xxx.xxx.xxx.xxx has reported Grace Period violations
EdgeSight has detected license violations in the payload for the device YourServerName at xxx.xxx.xxx.xxx. This device is still within the 14-day licensing grace period.
Please take corrective action to prevent future violations.

I don’t really recommend the Basic mode. It will likely defeat the purpose of you deploying EdgeSight in your environment in the first place. Here is a good comparison of the EdgeSight Advanced vs. Basic agents:

http://support.citrix.com/proddocs/topic/edgesight54/es-feature-by-agent-type.html

As you can see, you lose some key monitoring metrics like:

-Network Performance
-XenApp User Summary
-Launch Summary for a Farm
-Summary for a Farm
-Users Summary for a Farm
-Application Errors
-Session Performance
-Active Application Monitoring (if you use application monitoring scripts)

In my opinion, you aren’t really getting key performance metrics on your Citrix farms unless you are running in Advanced mode. I heavily depend on the above reports to monitor farm health.

–SHOW_SERVICES_TAB = This is actualling meant for the EdgeSight for Endpoint agents but I do it for XenApp agents too to maintain consistency with my VDI install scripts. Setting the value to 0 will prevent users from being to to disable Citrix System Monitoring Services because it hides the Services tab under Control Panel > Citrix System Monitoring Agent. Setting it to 1 allows the tab to be displayed. It doesn’t really apply to server OSes since they display but default but it doesn’t hurt leaving the value as 1.

Here’s how XenApp agent vs. XenDesktop/Endpoint agent will look if you specify the value as 1:

A few other points. DO NOT run one of these install scripts against your License servers. License servers do not use EdgeSight agents, they are polled directly. You specify that in the EdgeSight web console under Configure > License Monitor Configuration > License Servers. They are polled every 15 min by default.

If you are trying to monitor a published application that launches using a script, like a .cmd extension for example, it may not register in EdgeSight as a launch. You need to install Citrix hotfix EUEM100W001 on your XenApp server to fix this:

http://support.citrix.com/article/CTX126997

By default, EdgeSight agents for XenApp upload performance data twice a day to the EdgeSight server. This means app launches, users, errors, etc. This can be configured to upload more frequently if you like. The default times are 5 AM and 7 PM. You can adjust it under Configure > Agents > XenApp Default > then expand the Performance Upload section.

I guess the only other thing I really want to stress is to make sure to double check your antivirus settings and also to verify ports 80, 443, and 9035 are open to every XenApp server you want to monitor. AV settings can be tricky with the various OSes in your environment, I may type up a quick guide on what to white list/set exceptions on if anyone needs it.

Jason Samuel

Jason Samuel is a visionary product leader and trusted advisor with a proven track record of shaping strategy and driving technology innovation. With extensive expertise in enterprise end-user computing, security, cloud, automation, and virtualization technologies, Jason has become a globally recognized authority in the IT industry. His career spans consulting for hundreds of Fortune 500 enterprises across diverse business sectors worldwide, delivering cutting-edge digital solutions from Citrix, Microsoft, VMware, Amazon, Google, and NVIDIA that seamlessly balance security with exceptional user experiences.

Jason’s leadership is amplified by his dedication to knowledge-sharing as an author, speaker, podcaster, and mentor within the global IT and technology community. Recognized with numerous prestigious awards, Jason’s contributions underscore his commitment to advancing technology and empowering organizations to achieve transformative results.  Follow him on LinkedIn.