What do you mean by WAN mode? Because you can be on a WAN and still have access to the Core Server.
We check if there is access to the Core Server. So if it is not working when you are in WAN mode, then try to ping the Core Server and see if it works. It should not even resolve the IP to the Core Server if you on not on the Corporate network and if you ping by IP Address, it definitely should NOT work.
no what mean was when the computers are connected to the "wan" by when they are not on the corporate network and can't ping the core server. then it should automaticly connect to the gateway on the DMZ. but it still keeps the direct mode setting. not changing automatic to gateway.
Are you talking about the Remote Control Switch Mode? They do not automatically switch. They need to be switched manually or with an SWD job.
He has to be talking about remote control, cause there is not a switch mode anywhere else...I missed that and thought he was talking setting about brokerconfig.exe to use the Gateway.
Remote Control is different than other things like inventory, vulscan, policy.
Neither inventory, vulscan, or policy are services on the client. They are processes that are launched on the agent that contact a service on the Core Server to perform an action.
With remote control, the client / server relationship is reversed. Remote Control is the Service running on the agent workstation, and the process that initiates traffic is the Core or Console. So for remote control, the Core and Console are clients and the agent workstation is the server.
Inventory, vulscan, or policy process are outbound connections. These outbound connections are configured to go through proxyhost.exe when they initiate traffic to the Core Server.
Remote Control never initiates traffic. It receives inbound connections and normally makes no outbound connections so it cannot be configured to use Proxyhost.exe.
So you have the restart the Service to change how the service reacts and the switch mode button on the remote control icon does this. In this case, a connection is made directly to the gateway (I don't think it uses proxyhost.exe even now).
There are several possible ways that could make the Remote Control service try to restart and initiate a session with the gateway based on an event (such as not being able to contact the Core Server or Proxyhost.exe sending it a signal that other processes are now using the gateway) however, there are inherent flaws to those solutions that make them undesirable so we cannot implement them.
One of the ways is to periodically ping the Core Server and switch to gateway mode if the Core Server is not available, but sometimes you lose connectivity when on the corporate network. Also, this causes and extreme amount of network traffic, increasing a lot of network usage and adversely affects the Core Server.
Basically in our Gateway designs we really have found only two use cases that cover 99% of the time a machine will be in Gateway mode. The machine is either 1) permantly outside the Corporate network in which case if you want Remote Control, Remote Control should always be in gateway mode, or 2) The remote user is a traveler and he will be traveling with and hence be at at the machine and can click to switch modes.
If you have another use case where this is not the case that would be interesting to hear.
We found this problem with remote control too, and thought it was unrealistic to expect our customers to understand the different modes and to switch to the appropriate mode when they were on or off the corporate network.
To get around this I wrote a small executable that pings the core server and switches to gateway mode if the core can't be contacted (as discussed by Rhyous in the above post). To get around the issue of constantly pinging the core server, I've added as task to the local scheduler on all our clients, so this executable only runs on IP address change. The executable and local scheduler task are now part of our default agent configuration.
I thought it was an buildt in option on the client that it automaticly should check if there was an connection ping to the core server it was in direct mode and if not it would go to gateway mode.
over at http://www.droppedpackets.org/management-gateway-and-remote-control/folder.2007-10-25.8017126077/automate-laptop-remote-control-mode you can download a script that change to the right mode an when it runs in gateway mode it also check for vulability and policy.
This can get confusing since Inventory/Vulscan work automagically through the gateway. Remote control is manual. Personally I wish that logic to determine whether the core is accessible or not needs to be changed. Ping or a http success may not be tight enough. I think it should check to make sure the core is actually a core. Any server that responds with a ping or a successful http message broker thinks it is online.
and thought it was unrealistic to expect our customers to understand the different modes and to switch to the appropriate mode when they were on or off the corporate network
Can you explain this more.
Mayber there is some confusion.
Why would they need to switch modes and understand the modes. If a user is traveling, the only time in our use case that they would be remote controlled is if they are calling back to their help desk for support, in which case, it takes a few seconds to tell them to go into Gateway mode.
If we had everyone go to gateway mode automatically, then our customers that use the gateway heavily would use all their available connections establishing needless sessions with the Gateway. There should only be a session when it is needed.
We don't understand your use cases, I guess.
Possibly more a case of not understanding our customers. If a user could easily be talked through "Find the icon on your task bar that looks like a remote control and a little person, right click it, then click status. When the dialogue box appears click Switch Mode…etc..etc", we probably wouldn't need to be remote controlling them in the first place!
I wrote the executable because it was right for our organisation, i'm sure it's not a solution that would fit everbody's needs.
OK...so it is the frustration of walking the end user through the process of finding and clicking on the icon.
I understand that. When I worked Windows 2000 support for the Microsoft account 9 years ago, I spoke with a lot of users that did not understand simple commands such as "Right-click on My Computer". I can't say how many times some one asked me how to do that. Also, we are working on changing our Management Gateway interface to be easier for this very reason, as it used to be one click that worked with ActiveX but now that ActiveX is restricted by IE security, it is not longer one click, it is a frustrating pain. Even with IT administrators during support calls sometimes we encounter many times where it takes us 15 minutes just get remote controlled to help out. We have a sample working and hopefully we can get it into the Gateway as an update some time soon.
The correct solution exists, we just need to be careful that we don't implement a solution that is beneficial to small node count customers but detremental to large node count customers or visa versa. We need something that works for everyone.
So having a new executable that does this that can be called from a local scheduler task that runs on IP Address change is a pretty good idea. Still, that would be a lot of traffic and resource utilization in large organizations if every machine in the organization did that. So we would have to have it be an agent option that is not checked by default.
Usually, the gateway doesn't want everyone who is using it to maintain a session. Inventory, policy, vulscan sessions are temporary, so they don't really hurt the session count so much, but an RC session is permanent and remains open as long as the remote workstation is on line in that mode. So smaller customers with fewer nodes outside the gateway won't be affected. However are larger customers couldn't have this because so many sessions would take all their gateway connections.
I think after listening to all your input, adding a check box to the Remote Control section on the agent configuration would be a good solution. I should probably say this:
[ ] On IP Address change, check if the Remote Control Service needs to switch to Direct Mode or Gateway Mode.
I searched our CR database for enhancement requests and found these: (which are not what you are looking for but you may be interested in them none-the-less.)
- 17156 - ER - Add Remote Control Gateway mode option in the Agent Configuration.
This would allow the service to always start in gateway mode. So this would be for devices that are always outside the network and never on the corporate network.
- 13268 - ER: Ability to choose in the Agent Configuration an alternate security type for the Remote Control when it is switched in Gateway Mode
It looks like this is so that if you have NT Security and you are using Active Directory (which of course AD is not accessible for the remote device) then you may want it to go to Integrated Security when in Gateway Mode.
However, I did NOT find one on the exact enhancement you have requested, so I added one. Don't get too excited it is just an enhancement request, and making the request doesn't guarantee it gets into the product, but it is the starting point for getting it there usually. Here is the details:
- 21261 - Add an option to the Agent Configuration to add a local scheduler task with an IP Address change filter to check if the Remote Control Service should change modes to Gateway Mode or Direct Mode
- 17156 - ER - Add Remote Control Gateway mode option in the Agent Configuration.
do you know how much bandwich it use on the client pc when it stays is gateway mode for remote control ? and how much on the server side ? also the performence on the gatway server ? because you said something about the reson why you diddn't think it was a good idea to set all computers to gateway because of the session load on the gateway if its a big company.. we have about 400 laptops and I am thinking about distrubute a script that switch all our clients to gateway mode if they can't ping the core server. there will be about maby 100 pc's conntected to the gateway sometimes .. I think. is it to much for the gateway to handle `?