1 of 1 people found this helpful
Probably the most important thing to remember about the Management Gateway is that it is basically a bridge. The core establishes multiple connections to the Gateway, the client establishes connections to the Gateway and the Gateway bridges the connections. No decryption of the traffic takes place and I believe the connections are bridged based on the core certificate that's posted to the Gateway. This is a public/private encryption transmission where the private certificates that are generated and stored on the client are managed by the core server. This is really all the Gateway device is doing. The real key on the client side is a file called Proxyhost.exe. This file acts as a proxy or web server for applications in LANDesk and essentially makes it all happen. We have a support generated training video that covers a lot of the details and has a very thorough walk through of the certificate request process both on and off the network. The link is below. I hope it helps:
Thank you very much for the helpful link. It was very informative. However, I am still a bit lost when it comes to how the client communicates with the core via that gateway. I am assuming that the client initiates a connection via the gateway depending on the scheduled inventory scan, security scan, or a policy which was made available to it. If you can elaborate on this, I would appreciate it greatly. Thanks.
I'm not sure if this is what you're asking, but from my understanding and experience with the MG, this might be one way to think about it:
The only thing that the console/core side (read the administrator) can initiate immediately is remote control. All other functions are reliant on the client calling into the gateway and requesting or reporting something; inventory scans are initiated client side on a schedule, policies are checked on a schedule--on the client side. By default, there is a built in random delay of an hour. So with the MG, you cannot trust anything to happen at an exact, specific time, much less now.
I like what Ken said. Basically the way most people put it is that there is no way to do a "Push" to a client. The client can check in but there is no way to find the device when it's out somewhere on the internet. I believe this is part of the security that's built into the Gateway.
To further elaborate Remote Control (issuser.exe) when it launches will check to see if it's in Direct or Gateway mode. If it's in Gateway mode it will start a connection with the Gateway and basically poll the connection to keep it open but will otherwise do nothing. If the connection is severed then the Remote Control Service will need to be restarted in order to get the connection again. On a side note there is an option that can be added to make the connection persistant so that if the connection is severed issuser.exe will re-attempt connection periodically and re-establish on it's own.
As Ken said the Gateway bridges incoming connections when they are needed. So if a policy check, inventory scan, or vulscan is launched either manually or by the local scheduler on the client then it will call "proxyhost.exe" establish a connection, get what it needs from the core, and the connection is dropped. The Gateway has a theoretical connection limit of about 5,000 but few if any have reached this limit due to connections only being maintained as needed. I believe some applications may disconnect and reconnect several times during their execution.
The core (brokerservice.exe) maintains at least 6 connections to the Gateway at any given time. The Gateway can bridge these incoming client connections with the core connections and form a temporary SSL Tunnel. This allows the encrypted transmission from the client to be responded to by the core. I believe brokerservice.exe on the core responds to the SSL Tunnel connection with the information requested but it never knows where the client is on the internet at any time.
Again I hope this helps.
And I rather like what you said, Truffles. However, I'd love to know more about the RC re-enable functionality. My Vista laptops seem to drop right off the RC until the user manually restarts the service.
Sorry to side-track the thread.
Here is an example of what I was referring to. To summarize the service would need to be removed and then reinstalled with the /resident switch. This makes the Gateway connection persistant and will re-establish on it's own. At this time I don't know what the retry rate is but it will establish. Also, I'm not sure how this will effect clients that traverse on/off the domain. I've primarily used this switch for devices (like home computers or LANDesk Labs) that I want to always be available on the Gateway for me to reference. I would test this on clients that traverse before imploying it globally. Some networks seem to have problems going out then right back into the network to post to the Gateway.
• From a run prompt run the following command:
o issuser.exe /resident /b /lBROKERADDRESS
o for example issuser.exe /resident /b /lldmg.landesk.com
o This will install the service to windows
o NOTE: no space after the /l (l= lower case L)
o You will need to type the full path to the ISSUSER.exe!!
• To uninstall run the following command
o Issuser.exe /remove
o You will need to type the full path to the ISSUSER.exe!!
o This will uninstall the service AND delete all of the files from the machine.
Note: If the issuser command line is run incorrectly or if changes are needed to an existing resident agent, run the remove command and then re run the resident command line as shown above.
LANDesk Product Support Engineer
Toll Free 1-800-581-4553
Monday - Friday 7:00am - 4:00pm
***Please visit and sign up at our new LANDesk Community today at http://community.landesk.com***
Thank you both for that valuable insight. It all makes sense. Your input is greatly appreciated.