Are you talking about using the On Demand remote control feature? If so, the answer is yes.
Of course you will need to make sure that the DNS or hostname they connect to is set up to point to the internal IP Address and that all the other regular network requirements (port 443 accessible, etc.) are taken care of. Usually that's not as much of a problem internally, but I thought I'd throw it out there just in case.
Let me know if you have any problems setting it up!
I tried using the On Demand client, however found it not to show any display (This was on a machine that already had the full agent on there). I was hoping that I could just change the mode to Gateway and it would see the intenal addresses.
With the on demand, would it work with the existing agent on the machine? If so is there a specific reason the display would not show?
Alright, using the built in agent through the Gateway internally depends on your network configuration, but can be set up. Basically the tricky part would be that our agent only uses the public IP Address that is set up for the Gateway, and if the Gateway is using port forwarding (ie, in reality has in internal IP Address) then a lot of routers don't like the packet going outside (looking for a public IP address) then flip right around and try and come back inside (because the public IP is really forwarded). If you're situation is that you have the Gateway in a DMZ where the same public IP Address can be used for both internal and external clients then that whole problem goes away. Let me know which situation you are in there. If we need to we can work around the other problem.
As for using the Gateway on internal devices you would only need to get a client broker certificate, just like the external devices. Luckily internally it's a lot easier to do. There is a managed script already made called Create Client Gateway Certificate (or something like that). Drop your devices in it, run it, and you should be good to go. They won't be able to switch into Gateway mode until the remote control service is restarted. If they already have a Gateway cert then you're already past this point. [-8
The On Demand client won't work if there is already a resident client agent, and the user is not a local administrator. The problem is that the regular remote control service is running, and without admin rights the On Demand guy can't turn off the resident one, so it won't be able to lock on to all the resources it needs. In that scenario the solution we provide is to make your client Gateway enabled and switch back and forth that way (which is exactly what you are trying to do).
I hope I'm not being too long in my responses, I like to give a little background into what's happening so that what we are going to do makes sense, and because I've noticed that people on here are generally pretty intelligent and with a little information can make the product work for them quite a bit better.
Let me know about your network setup and if you're able to simply switch back and forth from Gateway mode.
The way we have our gateway setup is the external is posted straight onto a public address (81.171.x.x), and the internal on an internal IP (10.254.x.x). Running a trace route it looks like it hits our breakout point then hits the gateway straight away.
I have installed the broker cert onto the device (when it was internal), and the user can flip between direct and gateway mode (after a quick reboot)
I like the long responses, as you said it gives an insight into why these things behave like they do, and hopefully, limiting future issues
Hope this helps!
When they're in Gateway mode it's working as expected, right?
If so, I'm glad to hear it's working! [-8
No, they go into gateway mode, however they do not appear in the Management Gateway remote control tool.
However I have changed the IP address of the broker config and they do appear. Seeing as the majority of machines we need to use this on will be desktops and will never need to use the external IP this may be a work around.
That's exactly the workaround you should be using. Have it go directly to the internal address.
A little secret is that if you put the FQDN of the gateway in the IP Address then it WILL actually use the FQDN. If you have your internal DNS set up to route that to the internal address, and obviously you would need the DNS set up externally to go to the external, then it can be set up to use both.
The easiest thing to do would be to go into brokerconfig.exe manually on one device and change the IP Address field to be the FQDN. That will create a file called broker.conf.xml under the LANDesk\Shared Files\cbaroot\broker folder. Create a task to copy that file into the same location on your clients when they get the certificate and you should be done.
The following batch file should work (if the broker.conf.xml is stored in the same folder as the batch file and added as an additional file):
REM Copy the broker.conf.xml file to the broker folder
copy broker.conf.xml "%programfiles%\LANDesk\Shared Files\cbaroot\broker\broker.conf.xml"
REM Request the certificate
Try deploying that to a few test machines. If you need to reset everything to default, just delete everything from the broker folder (the broker.key, broker.cer, and broker.crt, as well as the broker.conf.xml). At that point you should be able to test using the same device as you already were testing with.
This should work for you if your DNS (internal and external) is set up correctly. Also, if you ever need to change the IP Address of the Gateway, you'll just need to update the DNS for all your agents to continue working.
Let me know the results of your testing.
I will give this a goon Friday, when I am back in the office.
Thank you very much for your help!