We are about to deploy the application distribution phase of TEM in our environment. This means we need to install the console on a number of client services workstations for support of this.
My question.
What are other businesses doing with console users. We have one TEM application server, with a remote db. We have 33 relays around the globe.
My concern is that we may need to give the console to 30 - 40 console operators. We are concerned that this may seriously degrade the performance of the console as we add this many users.
I am curious as to what other companies have experienced with the same scenario.
Consoles do not run well across a WAN connection. What we do, and what I would recommend, is to have your users run the console from a Citrix/Terminal Server session. This Citrix/Terminal Server would be close to your BigFix Server/SQL Server (or atleast on the same corporat network). That way the console doesn’t have far to go to get it’s data, and you operators will have less problems running it.
@cstoneba - thank you for your idea, I am looking nto setting this up for test.
@Stacy - Thank you for your input as well. I feel we may be doubling this, and we have many global sites that may rely on the console. I have noticed it is very slow to initially lauch using VPN, and I imagine it iwll be worse at some of our links. I will monitor both solutions.
We have 250+ console operators with ~30 logged on concurrently. Terminal servers are the way to go. They eliminate potential issues with slow WAN connections between the console and the database.
With that said, you should plan to invest in a fairly beefy terminal server… lots of RAM, fast disks, and decent CPUs.
We have 250+ console operators with ~30 logged on concurrently. Terminal servers are the way to go. They eliminate potential issues with slow WAN connections between the console and the database.
With that said, you should plan to invest in a fairly beefy terminal server… lots of RAM, fast disks, and decent CPUs.
+1
A machine close to the main server is the way to go since the console is essentially making a DB connection to the main server. Upon first time logon of the console a bunch of data is cached locally and takes a while. A machine with fast disks will make a world of difference. I run the console from my desktop with SSDs and it is super quick to load up and close. I don’t regret having to close my console anymore for fear of it taking a while to open the console again.
We have 250+ console operators with ~30 logged on concurrently. Terminal servers are the way to go. They eliminate potential issues with slow WAN connections between the console and the database.
With that said, you should plan to invest in a fairly beefy terminal server… lots of RAM, fast disks, and decent CPUs.
We run a very similar setup with around the same amount of console operators. We typically have around 30 sessions spread across our load balanced terminal servers. We also have a GPO in place that will map a network drive for console operators. This drive is unique to each console operator and is used to store the BES Cache. This way console operators can clear their cache and expect it to be cleared on all terminal servers. It also helped reduce the console load time. Before we applied this GPO it’s possible you could get directed to a different terminal server the next day and have to build the cache from scratch again.
Apparently we are getting away from Terminal Servers at my company. We are trying a VM pool, using XP clones that will have the console running on it. The VM host server lives in the same Data Center as the TEM app and db servers.
Does anyone run a simular setup? Does anyone thing that this setup may cause issues with 50+ users (could near 100, not sure how many would be concurrent).