The only way the clients can dynamically switch to use the new public IP you switched to is if you use an FQDN and not an IP. So basically there is no way to do what you need through LANDesk. So someone has to manually touch all the machines because they will never be able to check in to the Core Server on their own because they don't have any way of determining the new Management Gateway IP.
The solution sounds simple. All you have to do is create a broker.conf.xml file that uses FQDN where it says IP addres and put it in the C:\program files\LANDesk\Shared Files\Cbaroot\broker folder on every client.
Only there is that problem that the machine cannot check into the Core to run a task. So some one (probably the user or you) is going to have to touch the box and make the change.
This would be my recommendation.
1. Get one machine.
2. Go to BrokerConfig.exe and in the second tab change the IP address to an FQDN.
3. Make sure the client can now go through the gateway to the Core Server.
4. Go to the C:\program files\LANDesk\Shared Files\Cbaroot\broker and get the broker.conf.xml file.
5. Write a small self-extracting executable or installer that will copy that broker.conf.xml to the C:\program files\LANDesk\Shared Files\Cbaroot\broker directory.
6. Email out the little self-extracing exe or installer to your gateway users.
7. Create a policy to push that xml out to all users (because you need to change those in the office too before they go out and for those that are out, if they stop into the office and get policies great).
8. Create a query for machines that have not scanned in for a few days.
9. Monitor the machines in the query until you have them all.
Sorry...I misread that you didn't use FQDN but you say you did.
I believe there are ways from the LANDesk side that our software could handle this better in the future as well as some things you could do.
Let me explain what we do and you may want to call support and submit a bug/CR on the fact that you used FQDN and it didn't switch IP addresses.
1. We check for a broker.conf.xml, and its settings overrides all else.
2. If not broker.conf.xml, we check the broker.crt file for the broker IP and if the IP is there we use it. We also store the FQDN but it appears that the IP Address takes prcedence and the FQDN's new IP is not used.
3. If no settings are found in the broker.crt file we check the .0 file's broker settings for the ip of the gateway, again, we store the FQDN in that file to, but it seems we always use the IP address.
I have noticed that if you have an FQDN and an IP address, it will always use the IP Address and won't dynamically change.
However, if you have a broker.conf.xml file with the IP Address set to FQDN, it works well and dynamically changes, however, this file is not created by our agent, only if you manually make changes using brokerconfig.exe or manually push the broker.conf.xml.
I think there is a bug here that is going to affect you. Can you get a case with support open?
Unfortunately a bug fix won't fix your situation, it will only prevent it from happening in the future, you situation may still require the fix I stated before.
I will get a ticket open with support right now ... this is what I was afraid would be the case. Not looking good for LANDesk, my boss is NOT going to be happy we might have to touch every machine again. I have 800 machines scattered across the country.
Remember, customers change IP addresses like once every 5 years, so this is not a key feature that is used daily and so our design has been flawed. And no, you are not the first customer to go through this.
Unfortunately you and each customer who experiences this issue all have to take some of this blame as well because we have a solution that works, but you didn't use it.
You did a major change without testing it before hand. Does your company have any change control rules to follow?
I would have to say that while our software does not by default dynamically switch IP addresses for you, we have a solution that does as I have described above and you didn't use it because no time was spent testing before hand. Had you done a single test you would have seen it fail and called us or posted on the forum and you have received the solution I gave you before you were in a state where you had to do it manually.
Had you tested and called us, we would have given you the broker.conf.xml solution while you agents were still checking in through the gateway on the old IP and you would have been fine.
Sorry we don't handle this well, but we could have handled it had you given us the opportunity.
I am curious where in your employee handbook it states blaming the customer is a good idea?
Our first LANDesk installation was setup without a FQDN by one of YOUR techs, so when we had to change IP's the first time a few years ago, we had to rebuild the clients and push them out by hand. Then the next tech that was sent by YOUR comapny told us that was silly, we should use a FQDN so that if we have to change public IP's again (which he knew we would be within a year or two) that this wouldn't be an issue.
If we are to blame here it's for trusting what YOUR techs told us. I am the one who has gone to bat at my office for LANDesk everytime we have an issue or we find out it really can't do something we were told it could do. With this conversation, I have lost any and all inclination to do so anymore.
I hope that makes your little rant to a customer worthwhile.
Horrible response, and if you do not get repremanded for this I will be amazed and disappointed.