Can clients switch between Kace servers (one in a DMZ), using the same database?
We have one K1000 onsite - Version: 6.4.120822
I've been asked to create another K1000 in our DMZ to manage clients that are offsite and not connected to the VPN. It would run from the same DB. The problem is our offsite machines may be offsite for anything from 1 day to multiple months and then brought back onsite for a lengthy period of time. Most do use the VPN, but there's concern that some folks aren't connecting to the VPN (that's another discussion...yes). We would need clients to dynamically switch between our DMZ server when offsite and our onsite server when onsite. Even if I created local scripts to find what network a machine is on and then based on that update the K1000 name in every file it needs to when the machine gets moved, it seems like a potential nightmare. What if an offsite machine gets half way patched, gets shutdown by the user, then brought onsite? Does it continue patching without issue?
The way I understand it is, offsite clients that would be patched from a DMZ Kbox, would always be patched by that method and couldn't be patched by the onsite Kbox. Likewise, onsite clients or clients on the VPN would patch from the onsite Kbox.
Is there a way to have a K1000 onsite in our network to handle clients when they're onsite and also have a DMZ K1000 to handle many of the same clients when offsite?
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
Ericenri
8 years ago
I do not see that feasible at the moment, at least not from the appliance/agent side because that would involve some sort of automatically changing the host name in the amp.conf file and there is only one host name there that allows the agents to check in with one K1000 server.
Posted by:
nshah
8 years ago
What we typically recommend is to give your internal KBOX a public facing FQDN address and then NAT the traffic from the firewall to the internal KBOX so you can manage it and not have anything in the DMZ. In the firewall do a loopback to the KBOX so it doesn't go out and back in again for those internal clients.
Since the KBOX is all inclusive, you can't have two boxes talking to one DB. AS Ericenri mentioned you'd have to find a way for the user to change their amp.conf file each time they left and came back in again.
Just an idea but you could..
1. Create a script that would run on all machines to execute the amptool.exe with the variable host=
amptools.exe host=kbox.companya.com
you will need elevated rights to run this via cmd
2. this would then change the name in the amp.conf file to the new public facing. Ex. kbox.local to say kbox.companya.com
3. Once all the machines stop checking in then you rename the KBOX server to the public facing FQDN and reboot.
4. Once rebooted those machines that ran the script should check (internal only until you create the firewall rules)
5. External users will then hit your firewall with the FDQN and then that traffic is sent to the KBOX so you can manage your system.
