Miscellaneous Question

amp.conf Getting wiped?

07/11/2017 5110 views
Hi everyone,

We've been using kace for the last couple of years and it seems that every so often without warning some machines (not all) will have their C:\ProgramData\Dell\KACE\amp.conf file will lose all its relevant information and then be unable to talk to the kace agent as it doesnt have the kace hostname anymore.

It happened since being on version 6.1 and is now still happening on version 7.1. There hasnt been a common theme among any of the users that I've found.

Anyone had this happen?
Answer Summary:
12 Comments   [ + ] Show comments


  • I have never had this happen. How are you pushing / updating your agents?
    • I just do it through the kace console when an agent update is available, and push it out there.
  • We are currently investigating this issue. Not all customers are facing it (which would've be easier, so we can find the root cause) It seems to happen in some environments.
    No settings or programming within the Kace Agent, are established to reset or reconfigure the amp.conf file. So I was wondering, could anyone help to check AV logs, Firewall, or incase those agents are remote, review load balancer or Proxy?
    • When we rolled out KACE we were using Trend Officescan on our workstations, but in the last couple of months we've swapped to Dell Threat Protection (made by Cylance) and while Trend has caused many issues and headaches for me, its not been a common factor in the KACE agents that have had their amp files wiped. And this is across many different configurations for Trend.

      And so far Dell Threat Defense also hasnt had a negative impact on KACE.

      From what I can tell it seems to happen every 4-6 months it just decides to wipe some peoples config files, but I cant see anything in the kace user logs that show the agent getting wiped. Not to mention its not something you realize until a few weeks of it not checking in.
  • I see this on Replication servers. We are at 7.0. We also have PC's with an incomplete amp.conf. I found these after upgrading from 6.4 to 7. I would really like to know how this happens. It would be easier to target and remediate.
  • I have experienced this issue since 6.2 – 6.4 while working at NASA. KACE has never fully identified the cause. It has to do with a networking glitch. At some point, the agent communicates to the server and confirms the host name of the server. When it doesn’t get a response, its wipes out the name. In 6.3, KACE added the "last known good host" entry at my request and that helped with the issue. I am now at a different employer (DoD) and on version 7.2. I have found multiple occurrences of the host name being wiped out since my arrival. This issue is still an issue because KACE has never found root cause, and their fix has always been the work around of running the amptools command with host switch.
  • Anyone in 8.0 with 8.0 agents have seen this issue?
    • We are running 8.1.52 and have been able to remove machines cleanly with out Issue.
    • We saw it with 8.0 and still see it with 8.1.52. not sure if it is left overs from having the issues with 8.0 or new occurrences.
  • We had same issue for past year and a half. Seems like whenever Quest brought k1000 from dell. And first of all it's been really frustrating trying to have support realize that this is an issue with their agent/appliance. Second even if they see this issue and numerous logs, etc. but still can't provide a fix for it even after the tether sessions etc. So much wasted time when they could just be like "Oh we have this issue/bug and we don't have a fix for it" rather than requesting all these logs and remote session just to keep gathering the same data over and over again. The sadness part about this is that.. this appliance fails to do one thing thats it's designed to do... connect to agents.
    • To be fair, the issue exists since 6.1, that was like 2013, DELL was in charge... but it appears it's appearing more and more according to this post...

      I haven't seen it in 8.0, yet.... ? (I asked two months ago if anyone with 8.0 and 8.0 agents is experiencing the same thing).

      Now I always see it affecting 1,2 or 3 machines the most, out of 1000, so I guess is not an easy one....

      If you are getting a good number of devices affected by this then better troubleshoot with support.

      But yeah it's random, and it should not happen.
      • upgrading our appliance to 8.0 next Friday. running 7.6 atm I believe. Also, I posted my current work around included with window task instructions etc. hopefully that helps someone out.
  • just seen this post, yes i have 8.0 and im still seeing this issue on a very few machines.
  • i'm still seeing this issue on few machines too in my company. We deploying the agents with GPO
  • i'm still seeing this issue on few machines too in my company. We deploying the agents with GPO
  • Yep, seeing the issue as well. We're going to sunset Kace for a product that actually does what it's supposed to do very soon.
    • FYI, we're on version 8.0.318, not even going to bother with upgrading to the new version.
  • We are on 8.2 and use trend AV. we recently upgraded trend and change ip's on the network. Found trend now blocking cleanup.vbs post task when imaging, as well as agent task now failing with unknown error. funny as it was just the amptools.conf being deleted now it is the whole post task for the agent and the device is not even on the domain yet.
  • This issue has been around since 6.2 and before. It still occurs in our environment on 8.1. I use other system admin systems to fix broken agents, since all are remote. This issue has never been resolved. The closest I was able to reproduce this, was by changing between wireless and non wireless networks during an inventory. I now have a 9.0.167 test server, and I am very UNHAPPY to report, that the issue is not resolved. I deleted the contents from the amp.conf file on a 9.0 agent, while it was connected. It never fixed itself. Very disappointing .

Answer Chosen by the Author

What I noticed was after my amp.conf got corrupted, I saw it trying to connect to "kbox:443" in the log. 
Well, I just added a DNS record on my domain(cname) for "kbox" to the correct host and as soon as the machine's dns cache was cleared and service restarted the machine connected correctly to the correct host and it "fixed" it's amp.conf. A reboot probably could have also worked.
Hope that might help. 

------ Second update --------

I have seen a bunch of references that are concerned with remote endpoints losing their amp config which my initial solution did not cover. 

Why not just add an entry to your hosts file for "kbox" with the ip of your host? External users will then get the right info when it reaches out to the server. 

I just tested this by nuking my amp config, reboot. No connection/dead and then added the hosts entry. upon it's next connection attempt it fixed itself all up. 

In theory this would work for osx/windows as well. 
Answered 10/09/2017 by: b.adams
Senior White Belt

  • I too noticed that agents were attempting to connect to kbox even though the agent was originally pushed with the correct host name. I used your CNAME fix yesterday and >100 machines started communicating with my K1000 again. Thanks for the tip. Hopefully this gets fixed in a future release.
    • Best tip for K1000 so far!
  • Finally was able to get the dns record in, and its starting to rectify PCs. Thanks very much for the tip.

    What log did you see this in though?
    • It's been awhile tbh, but I believe I found it in the konea.log in windows generally located C:\ProgramData\Dell\KACE

Community Chosen Answer

Also, it doesn't help having remote users who don't connect to your vpn etc. so you can't psexec or anything. You have to remote into their machine and run amptools.exe resetconf host=hostname since those users don't have admin credentials. Really disappointing and waste of time.
Workaround create a windows task by using k1000 scripting feature and have this run on all of the machine. Of course you'll have to bring the "dead agents" back online for this to work. But once you have this taken care of, you won't run into this issue in feature. Again this is a work around not fix. 

attached is the picture for the script. I will aslo add the xml script on the bottom as well. 

1)  "createtemp.bat"** to create a temp folder (you can verify/create on failure by running the .bat)
2)  "resetk1000host.bat"** file to reset amptools.exe 
3)  "exportedwindowstask.xml"** from task I created and than exported it. (Believe me, you want to create a task and then export it) 
                **made up name for explaining purposes**

how this script works 
1) check to see if "temp" folder exist. if it does copy resetk1000host.bat file to rest the ampfile. if it doesn't, use the createtemp.bat to create temp folder and then copy the resetk1000host.bat file to that location. 
2) verify resetk1000host.bat file exists. if it doesn't create a task using 
"schtasks.exe /create /xml exportedwindowstask.xml /tn "name of the task" /f" (f overwrites any tasks that are already there with that name" 

Here's the xml for the script. Of course change the name of the dependencies on this xml for the creating temp folder, k1 reset batch file, and exported windows task xml file. I highlight the names in this xml that you need to rename or maybe name those files to these names so you don't have to modify this script. 

<?xml version="1.0" encoding="utf-8" ?>
<kbots xmlns="http://kace.com/Kbots.xsd">

<config name="Windows task - K1Reset" type="policy" id="132" version="1518633317" description="">

    <dependency name="/packages/kbots/132/CreateTemp.bat" checksum="9318d7e6f2af4819fce251866b14d955"  />
    <dependency name="/packages/kbots/132/K1KReset.bat" checksum="aa83fc2f6c92fb8931d8b528b093c112"  />
    <dependency name="/packages/kbots/132/K1Reset.xml" checksum="77e2fc5e30b2382c0aeb51e752ebf0d0"  />

  <execute disconnected="false" logged_off="true">
    <event name="NOW" />



  <verify on_failure="break" attempts="1">

    <directory_exists path="c:\temp" />

      <launch_program path="$(KACE_SYS_DIR)" program="cmd.exe" wait="false" parms="/c xcopy $(KACE_DEPENDENCY_DIR)\K1KReset.bat c:\Temp /q /y" />

      <launch_program path="$(KACE_DEPENDENCY_DIR)" program="CreateTemp.bat" wait="false" parms="" />

        <launch_program path="$(KACE_SYS_DIR)" program="cmd.exe" wait="false" parms="/c xcopy $(KACE_DEPENDENCY_DIR)\K1KReset.bat c:\Temp /q /y" />




  <verify on_failure="break" attempts="1">

    <file_exists path="c:\temp" file="K1KReset.bat" />

      <launch_program path="$(KACE_SYS_DIR)" program="schtasks.exe " wait="true" parms="/create /xml $(KACE_DEPENDENCY_DIR)\K1Reset.xml /tn K1Reset /f" />

      <always_fail />







** hopefully this helps someone. If you need further assistance, please feel free to contact me since I been through all the scenerios related to this issue/work around and would love to help other people.***
Answered 02/14/2018 by: TechFreak
Senior White Belt

All Answers

Hi @TechFreak and thanks for your script.
Can you upload or explain the three dependency files, please?

Thank you :)
Answered 02/28/2018 by: c.castellari
Orange Senior Belt

1) createtemp.bat

mkdir C:\Temp
/c xcopy $(KACE_DEPENDENCY_DIR)\K1KReset.bat c:\Temp /q /y 

2) K1kReset.bat

cd "c:\program files (x86)\dell\kace"
amptools.exe resetconf HOST=k1000.gmac.com
runkbot.exe 4 0 

3) k1kreset.xml is created by exported a windows task scheduler and setting up per your preference i.e. when to run, etc. and than exporting it to .xml
Answered 02/28/2018 by: TechFreak
Senior White Belt

1) createtemp.bat

mkdir C:\Temp
/c xcopy $(KACE_DEPENDENCY_DIR)\K1KReset.bat c:\Temp /q /y 

2) K1kReset.bat

cd "c:\program files (x86)\dell\kace"
amptools.exe resetconf HOST=k1000.gmac.com
runkbot.exe 4 0 

3) k1kreset.xml is created by exported a windows task scheduler and setting up per your preference i.e. when to run, etc. and than exporting it to .xml
Answered 02/28/2018 by: TechFreak
Senior White Belt

I've contacted support last Friday with the same problem. 

This was their response: 

There is an entry in our defect / feature requestdatabase regarding this behavior.

HOWEVER no one has ever been able to reliably reproducethe issue and engineering is convinced that the behavior is not caused by theappliance but rather by AV solutions / firewall / proxy or simliar in certainenvironments.


A workaround, which is supposed to avoid this behavior,is planned to be implemented in the 9.0 Version of the appliance (current ETAis August 2018).

In the meantime, what you could try is something likecreate an offline script which re-sets the hostname in certain intervalls (for exampleonce per week).

For devices that are already disconnected / have an emptyamp.conf we need to replace the affected amp.conf with a working one andrestart the agent or run "amptools.exe -resetconf host=your_fqdn" inthe agent binary folder on the affected devices.

You could use psexec (as explained here: https://support.quest.com/kb/127898) or a gpo for this.

Answered 01/22/2018 by: cgMartijn
White Belt

Yes, we have had this happen. It is better since 6.4 but it still happens sometimes. I regularly look through the inventory to find machines that aren't reporting and we start figuring out why. It's easy enough to just add the host line and restart the service remotely.
Answered 07/13/2017 by: chucksteel
Red Belt

  • Have Dell, now Quest, said anything about this? Because while it is easy to copy over a working config and restart the services, it can get very hectic with laptops etc and multiple offices around the world. It gives off a lot of false positives.
    • Without being able to replicate the issue I never entered a ticket to have them look into it.
      • Hi Chuck, We've been experiencing the same issue. Kace K1000 appliance having issue with Kace agent not reporting to appliance. When looking into the issue, the amp.conf file either goes blank or is deleted and the device stops communicating with the Kace appliance. We've uninstalled and reinstalled the agent and have noticed the issue come back on some of the same devices. We're on version 7.1.62, upgrading from previous version did not resolve the issue. We have a Dell environment with the exception of some Surface Pros and Panasonic ToughPads. Issue happens on all of the various devices. We currently have a case open with Quest Support.
We have close to 20K agents in our K12 environment and this has plagued us for 2 years. We ruled out anti virus as well. Sometimes the file if full of null entries and sometimes it is empty. We had a support ticket in and the cause was never found. Our work around is a scheduled task that checks the amp.conf file for our server name. If it finds it, it quits and nothing harmed. If it does not find it, it replaces the file with a good one and runs an inventory. We have this task run three times a week. The batch file it points to is in a folder we create in the ProgramData\Dell\KACE folder which also holds the good version of the file.
Answered 12/07/2017 by: Bethski
Senior White Belt

  • Hi Beth, would you be willing to share the commands/syntax you used to check the amp.conf file for the host name? Is this something that can be done via command line or powershell? I'm not sure if you'll see this because your comment is 6 months old, but I would appreciate it a ton! Thanks!
    • I was able to figure this out.

      In case this helps anyone out, here is the batch file I came up with:

      CD C:\programdata\dell\kace
      findstr /c:"host=yourhostname" amp.conf
      "C:\Program Files\dell\kace\AMPTools.exe" -resetconf host=yourhostname
      "C:\Program Files (x86)\dell\kace\AMPTools.exe" -resetconf host=yourhostname
      "C:\Program Files\Dell\Kace\runkbot.exe" 4 0
      "C:\Program Files (x86)\dell\kace\runkbot.exe" 4 0

      This works on both 32 bit and 64 bit machines.
      *Don't forget to replace "yourhostname" with the host name of your kbox. i.e. k1000.companyname.com
      • This is close to mine, Sorry, I am at KACE UserKon 2018 and it WAS AMAZING! I actually talked about this with the Quest guys and shared what I had. Just a quick note, when you upgrade your SMA to the newer version the Dell folder will be recreated as Quest, so you will need to update this. I also learned when the updated agent checks in it will run an inventory automatically, so if you keep the runkbot 4 0 command it will run it twice. If you have a large number of agents, it may have a performance hit on your SMA so there is no need for it. You can safely remove it.

We are currently investigating this issue. Not all customers are facing it (which would've been easier, so we can find the root cause) It seems to happen in some environments.

No settings or programming within the Kace Agent, are established to reset or reconfigure the amp.conf file. So I was wondering, could anyone help to check AV logs, Firewall, or in case those agents are remote, review load balancer or Proxy?


FYI renaming host, is the fastest way to get around this situation in meantime the investigation completes

Use the “Amptools.exe resetconf host=x.x.x.x” in order to rename host on client machines.

The AMPTOOLS command can be found in one of the following Windows-based locations and must be performed in an elevated (Run as Administrator) command prompt:


On 32-bit systems: C:\Program Files\Dell\KACE\

On 64-bit systems: C:\Program Files (x86)\Dell\KACE\


I opened case today, as we have recently noticed this issue still occurring.  We are on 7.2 of the server and 7.2 of the agent. But some PCs still on 7.1 agent also have had this issue.

It can't be AV as Symantec would delete the file not empty the file.

And in the past the agent used to have 2 paths back to the server the URL name as well as the server's IP to ensure communication would not be so easily broken.  But I don''t see that any longer in the flle.

We see this on WIN 7 32 and 64 and WIN 10 64.

And while you could run the amptools fix what if you can't remote to a system in the field?

Answered 11/07/2017 by: mjohnson007
White Belt

  • I would say this is one of the top 3 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 (I would say from 0 to 1 time per year), 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 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 content is currently hidden from public view.
Reason: Removed by member request For more information, visit our FAQ's.
This content is currently hidden from public view.
Reason: Removed by member request For more information, visit our FAQ's.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login


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