By default clients that connect to the Management Gateway from the internet will use the IP address of the Gateway instead of the domain name. This connection method has both pluses and minuses but if the IP address of the Management Gateway ever changes the clients themselves will be lost and won't be able to connect. Therefore when changing an IP address of an established Management Gateway careful planning must take place.
When a client starts a connection with the Management Gateway it will retrieve connection information in the following order
- C:\Program Files\LANDesk\Shared Files\cbaroot\broker\broker.conf.xml (NOTE: This file is not created by default and is usually skipped)
- Any broker certificates already on the client.
- The hash.0 file located in C:\Program Files\LANDesk\Shared Files\cbaroot\certs
There are many different possibilities to correcting this problem. One of the best resolutions is to create a broker.conf.xml file on a test client, modify the file to use the domain name of the Management Gateway and then distribute the file along with an updated hash.0 file to clients. This process will minimize client loss as the client will then use the domain name located in the broker.conf.xml file instead of the IP address.
The broker.conf.xml file is created when the "Update" button on the "Gateway Information" tab is clicked. The button becomes available when a change is made to the configuration. After creating the file edit the xml and replace the ipaddress in the public domain name for the Management Gateway. Testing this file is recommended. (Note: The broker.conf.xml file is only read when brokerconfig.exe is loaded into memory so reloading brokerconfig.exe is necessary before changes take affect and testing will produce good results)
For computers residing within the DMZ which have neither connection to the Internet or Intranet, it is still possible to manage these devices via the LANDesk Cloud Appliance, using the same 'Broker.conf.xml' work-around.
1. Creating a specific "Broker.conf.xml" file for the devices in the DMZ. What you'd do is create the "Broker.conf.xml" on one client in the DMZ by running the "BrokerConfig.exe" manually. This is in the \ldclient directory.
The broker.conf.xml file is created when the "Update" button on the "Gateway Information" tab is clicked. The button becomes available when a change is made to the configuration. You'd want to pick "Connect using the Management Gateway"
The ‘Broker.conf.xml’ that is generated is in the \\Program Files (x86)\LANDesk\Shared Files\cbaroot\broker
2. The 'broker.conf.xml' should be edited so that the <ipaddress>xxx.xxx.xxx.xxx</ipaddress> reflects the internal network's IP address. Having this file in the \\Program Files (x86)\LANDesk\Shared Files\cbaroot\broker directory will cause the agent to use that IP address as opposed to using the public facing address.
Remember, the 'broker.conf.xml is only read when BrokerConfig.exe is loaded into memory, so it is necessary to reload BrokerConfig.exe before the devices will use the new address.
Note: Please make sure to test a few devices to make sure the results are what you expect.
Producing a new hash.0 file:
Open the Configure - Management Gateway option on the core server. Temporarily enter the new public address and click "Ok". You may receive an error concerning communication with the broker. This error is fine and normal. Save the changes anyway. You'll find the new hash.0 file located in C:\Program Files\LANDesk\ManagementSuite\LDLogon folder. (Note: Some cores may have multiple hash.0 files. Open each file and make sure you get the correct one) After the modified hash.0 file is created change the Configure - Management Gateway settings back to what they were before.
Distribute the modified files:
After collecting a broker.conf.xml file and a modified hash.0 file they will need to be distributed to the clients. Configure a policy task through the Management Gateway to replace them.
Summary: It will take some time for all clients to check-in. However once the domain name is being used the clients should be able to connect to the Gateway regardless of it's IP Address. It is recommended to plan and start this task well ahead of the actual IP change to the Gateway so that most (if not all) clients are updated.