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.


2 Comments   [ + ] Show comments
  • If the amp.conf file is correct, does restarting the agent without replacing it fix the connection?

    Also, I recommend checking out PSTools, particularly PSExec to connect to the machine, it will save you a lot of time. - chucksteel 3 years ago
  • Sometimes. Not always. The current behavior we see is that the client is running agent 8.1.52. The system will be "live" and show up as "online" in KACE but will never check in thus never get updated. If we reinstall the agent manually we can get it working. But touching clients by hand is not a solution in an enterprise. Also, generally, if I replace the AMP.CONF with a known good copy it will generally begin working on it's own.

    We do deploy via GPO. We are deploying the current client (9.1.204). I have not verified if the client is getting reinstalled as part of the GPO. Will take a look at that.

    I do notice that if I do a upgrade to 9.1 using the installer, it hangs and eventually errors out saying it can't kill the offline amp scheduler. If I kill the process manually it then works and installs the new agent. Weird. - kenrinc 3 years ago

Answers (2)

Posted by: n1md4 3 years ago
Second Degree Blue Belt

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?

Posted by: Channeler 3 years ago
Red Belt

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.

This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ