The amp.conf dilemma....
You've all seen it. Even at 9.1.204 we still see it. Right now I'm going through a list of hosts all of which are physically "online" and pingable but show as "offline" in KACE. When I investigate further by doing an RDP to the machine and checking by doing a kstatus, I see "no" for both "running" and "connected". When I check the amp.conf, it's not blank, it has the correct "host=kbox" at the top, but nothing else. As I said, the "host=" entry is there and I can resolve the kbox DNS name from the client. I can ping the Kbox directly from the client. NOW, If I replace the amp.conf with a known good one from a working system and do a "amptools restart" the system comes online and checks in. Unreal.
For the life of me I cannot figure out what causes this. I've seen all the posts on this with no real solution. I understand Quest says it's not their problem and it's my environment. All of the KACE directories are white-listed in our security endpoint/virus solution so they don't get touched. That isn't the problem, since I have thousands of other machines that have never had this issue. So for now, I've resigned to create a script that I can target to affected machines that replaces their amp.conf with a know good copy and restarts the amp agent. The problem is that on some systems, I have to do this once a week! I have a few replication servers that drop off once a week. I'd love to talk to anyone else that sees this. We were told that this problem would go away with v9 but it's exactly the same as it was with v7 and v8.
the "blank" amp.conf with just host=kbox in it comes with the client installation
you can try rename your installation file to ampagent-version-x86_your.kbox.host.com.msi
this will use the hostname from filename to contact your kbox
how is your agent deployment working? can you verify the agent is not installed over and over again from GPO or any other deployment method?
Do you deploy an earlier version of the agent via GPO and use the agent provisioning from the kace settings to update the agent? or vice versa having a lower version in kace and use latest version in GPO deployment? refering to my first line this could reset your amp.conf.
do you use https to contact your kbox? are the clients in same subnet like your kbox? can a blocked or missing https in your firewall rule be the root of the cause. nowadays the client just uses http/https for communication with the kbox.
do you have some kind of proxy in your environment? web filtering proxy? transparent proxy on your firewall? maybe create an exception for your destination host kbox.host.com / IP.
you could check the konea.log for connection problems
you can try powershell: test-netconnection kbox.host.com -port 443 if your broken client can access the kbox via HTTPS (or -port 80 for HTTP)
Do you redirect http80 to https?
I would say this is one of the top 2 issues I have seen here in ITNinja in terms of complexity...
Being honest, it is very hard to reproduce, and like other users said, this might happen to each PC from 0 to 2 times per year (at least on my environment).....
It has been improved with latest versions , but like the author of the post says, the issue have been around since 6.0 versions.
Support confirmed there are no routines or modules on the code to clear amp.conf . That means something bad happens and cleans that file out...
Maybe is something simple, but it doesn't happen very often and it will not leave any clues or logs pointing to the reason why.
Please post here your results from support if you have any new Data\Findings.
(in my case I have a GPO policy that will replace the file every three months, with one that is fully populated, maybe that is why I don't see that often).
(we also have a folder in Documents inside the golden Image with a bunch of BAT files for users, one of them will generate an AMP.conf file, users just have to double click the BAT file, and it will generate a brand new populated amp.conf file).
Again it doesn't happen very often, the last time one user our of many, had use the BAT file was on June 4th according to our helpdesk.