(imported topic written by rkc91)
Is there a way to have just one session BESClientUI.exe on terminal server
rkc
(imported comment written by BenKus)
Hey rkc,
The BESClientUI.exe is launched in the userspace for each user as a secure way of showing them message boxes, restart boxes, and other agent based UI. The user interface can’t run as the SYSTEM like the BES Client does because of security reasons related to the “shatter attack”.
Is this causing you an issue? I believe it uses less than 1 MB of memory and basically no CPU so hopefully it is not affecting anyone adversely.
Ben
(imported comment written by rkc91)
Thanks Ben we had issue in which a session was being held.
(imported comment written by BenKus)
Yes. Everyone that uses BigFix Agents on Terminal Services might want to consider excluding the BESClientUI.exe from holding the session. I will see if we can get a KB article for this question.
Does anyone who has terminal services experience have any basic instructions on how to exclude this process?
Thanks,
Ben
(imported comment written by rharmer91)
Yeah, we excluded it - but I hope you change the behavior of the agent to not do this.
(imported comment written by BenKus)
Hey Rich / anyone else,
Can you help me understand what you think the ideal behavior in this situation would be?
Here are some options I can think of:
-
Launch BESClientUI.exe for each user to potentially show them message boxes/restart dialogs (current behavior).
-
Same as #1, but allow a client settings option to disable BESClientUI.exe from launching (and no message boxes/restart boxes would show to anyone).
-
Same as #1, but allow a client settings option to disable BESClientUI.exe from launching for remote users (and only the logged in console user on the computer would see messages).
Anything else that might help?
Ben
(imported comment written by SystemAdmin)
This is very timely. I was going to start a new thread on this. I ran into this yesterday.
We send Citrix user “disconnect” SNMP traps to our monitoring system - and for the last month we were getting tons of “disconnect” traps (which we found started with the install of the new v7 agents). And we noticed numerous double and triple sessions happening.
As you know (which I stumbled on yesterday) the reason was that unless you tell Citrix to terminate the BESClientUI.exe during a session log-off - the session would stay open until it was finally disconnected by Citrix. If you put that .exe in the “LogoffCheckSysModules” reg key on the Citrix server - then the sessions close properly. Since the process is very small when running - I don’t particulary have an issue with it running inside every user session. I would like to request from Big Fix - that they keep Citrix systems in mind with respect to version updates and upgrades - as there is potential to unknowingly influence user sessions.
Here is the key to modify to kill those processes that Citrix won’t natively do.
a. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Citrix\wfshell\TWI then open the LogoffCheckSysModules key.
b. Add any new services to auto shut down (add a comma between services - no spaces).
http://support.citrix.com/article/CTX891671
-Mike
(imported comment written by SystemAdmin)
By any chance do you run AppSense on your Citrix boxes? You could put the .exe in the “not allowed” policy - and then it will only run for the system and the administrators - but not the users.
Mike
(imported comment written by BenKus)
Hey guys,
I think I can get a change into another 7.0.x version if you guys can help me out with desired behavior…
I am thinking that this would work best:
Allow option to configure the BES Client to only launch BESClientUI.exe for the “console user” (which would not show the remote users the message boxes/restart dialogs).
Any feedback would be greatly appreciated…
Ben
(imported comment written by SystemAdmin)
Ben,
For me - that is a good option. For our Citrix environment - I don’t have any need to send the users any messages or restart dialogs (sending restarts boxes could be dangerous). I never thought about using Big Fix to send messages to users with sessions - so having the ability to keep the option - might be useful to some. We never send messages to users - so for us, turning off the option is better.
Were you thinking of adding the change as a client config - or a fixlet? If it was a fixlet - then I could setup a baseline with it and have it so that any new Citrix boxes would get the action automatically.
Speaking of the next v7 update. Any approx ETA on release? Thanks.
Mike
(imported comment written by mynameisbear91)
Forgive the intrusion into the discussion, I used to admin some Citrix systems back when I was a senior admin at Bridgestone/Firestone, but I suspect a lot has changed since then. In that context, these are simply questions I had after reading the thread, with basic knowledge of Citrix and terminal servers in general.
If there’s a setting in the terminal server specifically for programs like BESClientUI.exe to prevent them from holding a session open, why isn’t the solution to the problem “use the exclusion list”?
Adding a client option to hide the client interface seems like it will add yet another step to the troubleshooting process (problem: the bigfix icon is not showing up? answers: are you sure there is a relevent offer? are you sure the icon isn’t hidden?) as well.
As for the problem of dialogs showing to remote users, why is the message even showing for those people? There are options in the action creation dialog to specify specific users that will see the interface, why not use it?
Hope someone can help me out with understanding the needs here. 
(imported comment written by rkc91)
mgoodnow
We do not run appsense on the citrix farm.
Ben
When is the new version of client scheduled to release
rkc
(imported comment written by SystemAdmin)
I am not aware of a setting in Citrix to not allow the BESClientUI to load for each session (maybe a group policy). So, the only thing I know of to do is to have Citrix close the service upon session close (in the registry). That works - however, if there are 20+ sessions on a single Citrix server - then I have 20+ BESClientUI’s running for each session. Although not huge - they do take up CPU and memory for each one.
We do run Appsense - so I could include in the policy to not allow non admins to launch the BESClientUI.exe - but I’m not sure of the ramifications yet for blocking it.
Also, we currently don’t have our farm running in an AD environment - so Big Fix is our main solution for making global changes on the farm. I can only utilize local group policies - so making changes there on each box is time consuming (to do by hand). Anything I can deploy through Big Fix is a huge time saver. Having the ability to make the change for a BF agent from the console would make things quick and centralized).
I could see use of the BESClientUI for sessions - if I wanted to perhaps send all the attached users a message of some sorts. Typically though - we never send any alerts to users.
Anytime I can manage and control changes through Big Fix over locally on a box - I go the Big Fix way!
Mike
(imported comment written by BenKus)
Thanks for the feedback…
I put in this change request… it is too late for BigFix version 7.0.7, which should be released soon, but hopefully it can make it into the next version.
Ben
(imported comment written by Bjowah91)
Thanks Ben for putting this on the change list…
We also ran into this after upgrading to version 7.07, however I rather see that the besclientui.exe was disabled for all but the console users. The way we look at terminal services (with Citrix) is that it should not be possible for the end user to install own code on the server. If they have that need they can stay with a ordinary computer.
I think that amount of RAM can be more wisly used.
/Björn Wahll
(imported comment written by Efairrell91)
Ben
We’re running 7.0.9, and we’re seeing this problem on the Citrix servers we’ve loaded it on. Do you have an ETA on the feature request you put in? We’re not running AppSense, so is there anything on the Citrix side that we can do? We’d like to have a way other than the reg key, so that we can prevent the ClientUI from popping up for every user instance.
Eric
(imported comment written by BenKus)
Hey folks,
So we have implemented an ability for the BigFixClientUI to avoid launching for remote user sessions, which I think goes to the heart of the issue discussed here. This change will be implemented in our next major release, which will probably be called version 7.1.
In the meantime, here are some notes on how to handle the besclientui.exe on Citrix/terminal servers:
-
If you are worried about the issue that the BESClientUI.exe will keep a Citrix session open – Use mgoodnow’s suggestion above to tell Citrix to ignore this app: http://support.citrix.com/article/CTX891671
-
If you are worried about the BESClientUI.exe running in every session:
a. The besclientui.exe usually is <1MB in memory and uses almost no CPU and it is responsible for showing logged in users message boxes. If this small amount of memory isn’t going to be an issue, you can just let it run normally.
b. You can modify the permissions on the besclientui.exe to only allow execution by SYSTEM or Administrators. In this model, the besclientui.exe will not launch for users because it won’t have permissions (note that if you do this, the permissions probably will be reverted during an upgrade).
Important notes!!! If the BESClientUI.exe is not for all logged on users and you send a restart to the computer, the system will not restart (because the client will be waiting for the clientui to respond), so if you implement 2b above, you will want to make sure that you either have an Administrator logged-in or you won’t be able to forcefully restart the computer through BigFix. Also… if you have the BESClientUI disabled, the client will not be able to determine AD User Group contraints specified in the “Users” tab in the console (so if you have an action targeted for a specific user group, the client won’t know that user is logged in).
Hope that helps,
Ben
(imported comment written by average-joe91)
I am running 7.0.9.164 is this option in that release? If so how do I make that change?
(imported comment written by gjahn23)
We have the same issue and are running 7.0.9 - is this feature released in this version … or is 7.1 available yet?
I ended up using a GPO and performing a registry hack to exclude the BigFixUI.exe. The session still hangs on for 60 seconds before closing - but that’s better than never closing!
Gordy