1 of 1 people found this helpful
Mike, when the clients get a gateway certificate the .0 file on the agent is modified and the IP address of the Management Gateway is added. If the IP address of the gateway changes, then the clients will be hard coded to a bad address and will not be able to create the SSL tunnel to establish a session with the gateway.
If you absolutely have to change the public IP address of the Gateway, then you need a way to update the client certificates. You can have them manually run brokerconfig, but that option kind of sucks if you have a lot of users.
I wrote an autoit script that will update the .0 file that can be pushed out through a policy or a push.
Hopefully this helps.
Thanks for the response Chad.
Yeah, it's unfortunate but we do have to change our Public IP. When I first installed the LDMG a few years ago, I actually used Security and Patch and a Custom Definition to run brokerconfig.exe -r. I created a definition that looked for the existence of the 3 files in the \cbaroot\broker folder. If they did not exist I ran brokerconfig.exe -r. Since I had no machines outside the Gateway at that point it worked great. I'd love to be able to use that again after making the changes, but I think it would just get messy.
Thanks for the AutoIT script. I tried to get it working and when I run the script on my test box the modified date of the .0 file is changed, telling me that the script did something, but when I run brokerconfig.exe the IP address is still the same. If I create the broker.conf.xml (I commented that section out earlier for troubleshooting), brokerconfig.exe shows the new FQDN in both the "Management Gateway" fields, one under each tab. I guess that would be OK for remote control but I do not see the IP address changing to reflect the new Public IP.
Any ideas where this may be going wrong? I like this approach as I can use a policy to automate the install to my clients, but so far I'm not having any luck getting the IP to change in brokerconfig.
The BrokerIP field within the .0 file did in fact change when I ran the AutoIt script. It's just not being reflected when I run brokerconfig.exe and look at the tabs. Is this normal behavior? I figured brokerconfig would read from this .0 file when it displays the gateway information. The .0 file was changed to reflect the new IP, but it seems the broker.conf.xml file supercedes whatever you put in there? Or is that only for remote control?
Mike, did you restart the remote control service after running the autoit script? Yes, the broker.conf.xml is used for gateway remote control. When you start a gateway remote control, the client reads the broker.conf.xml for where it should go. In the .0 file the IP address is used to build the secure tunnel with the gateway.
I just tried that. The .0 file is definitely being updated with the new BrokerIP but even after restarting the remote control service when I run brokerconfig.exe I don't see the new IP address anywhere. It still shows the old IP of the gateway. Now granted, I haven't actually made the change to the gateway service on the core yet, I'm still in planning mode.
Where is brokerconfig.exe reading that information from, and by information I mean from the 2 tabs that state "Management Gateway"? When I add the broker.conf.xml the information definitely changes when I look at brokerconfig.exe, but then both fields state the FQDN that I specify in the AutoIt script. Maybe this is working as intended? Based on what you're saying I guess I'm good as long as the .0 file has the correct BrokerIP but I'd feel a lot better if I actually saw that IP show up in brokerconfig.exe.
Another quick question. If I were to make the changes to the LDMG and the Gateway service on the Core, then push out a new agent configuration and run brokerconfig.exe -r, the new changes would already be reflected, correct? I know this would not work for units outside the LDMG, but at this point I'm not too concerned. Most of our units check in at least once every few weeks on the local LAN so they could be updated at that point.
I'm thinking of going this way since it would make it very easy to identify the devices which still needed the new LDMG info. Besides the overhead of deploying a new agent, is there any reason this would not work?
We've had a similar situation in that we are in the middle of a side by side upgrade of both our Landesk core and the Management Gateway which needed to be deployed to about 1000 machines across 60 sites outside our main network.
Getting it all working was quite a battle.
In the end, I modified the agent ini to delete the old certificates, include a broker.conf.xml file and used the brokerConfig.lng workaround to run brokerconfig.exe with the correct credentials to pull a new certificate.
The relevant part of the agent ini file is as follows:
FILE100001=BrokerConfig.lng, %PROGRAMFILES%\LANDESK\SHARED FILES\cbaroot\Broker\brokerConfig.lng
FILE100002=broker.conf.xml, %PROGRAMFILES%\LANDESK\SHARED FILES\cbaroot\Broker\broker.conf.xml
EXEC10001=Brokerconfig.exe, /r, INSTALLONLY