/build/static/layout/Breadcrumb_cap_w.png
10/18/2019 238 views

Hi,

We recently updated our KACE URL on agent 7.x which caused all of our clients to drop off because their amp conf file was still pointing to the old host. Fix was to just have a batch file at startup that checks for the correct host string in the amp conf and if it dosent exist its resets the conf file with the correct host and runs an inventory. Easy. Many devices have come back and are still continuing to come back.

Ive also since updated kace to 8.1 and set kace to automatically update the agents. So once they check back in on 7.x (after the amp conf gets fixed) they get updated to 8.1 by KACE. This has also been working well.

After a week of the batch file being implemented, i pushed out KACE via GP: https://support.quest.com/kb/111244/installing-the-agent-through-windows-group-policy - for new devices. I was stupid here and targeted all computers. This ran for a few days.

I assume devices that already had the new agent (and are connected to KACE) it would've just reinstalled and its fine, however i noticed a few devices that have installs in c:\Program Files (x86)\quest\kace and the amp conf file is correct in programdata however they dont appear in KACE. These devices are from around the time that the amp conf needed to be fixed on 7.x agent.

Im assuming that the batch file and the GP install has conflicted and GP has installed the new 8.1 msi over the broken 7.x existing install with the bad amp conf file before the batch could fix it. Ive since removed the GP and just left the batch file there. To test ive gone back to some of the old devices that still have the broken 7.x agent and did a restart on them and the batch runs and fixes up the amp conf to the correct host and they appear in KACE - so basically with the GP removed its back to how it was.

I think this means that theres a few devices out there that were restarted in those few days and their agent is broken. Ive found 3 and ive tried doing an uninstall-reinstall and they dont show up in KACE. Im trying to find a fix so i could potentially push out an additional fix for these. Any idea? I could provide/generate a log for you.

Any assistance would be appreciated.




0 Comments   [ + ] Show comments

Comments


All Answers

0

All agents from 8.0 are located under a different location.
The <8.0 agents are located under:
c:\programdata\dell\kace
c:\program files (x86)\dell\kace
c:\program files\dell\kace

the 8.0 agents are located under:
c:\programdata\quest\kace
c:\program files (x86)\quest\kace
c:\program files\quest\kace


So the best way would be:
1. uninstall all agents using a GPO from both locations and delete the remaining files. 
     I would use psexec to do so, a GPO is also fine but a GPO would need a longer tine to run
     something like (the * is used for all systems in the domain) psexec -accepteula \\* c:\program files (x86)\quest\kace\amptools -uninstall would be helpful

2. upgrade the SMA to the latest version (as of now it is 10.0) since even the 8.x box is end of life already. Follow this article: https://support.quest.com/kb/155574/

3. Setup a GPO using the GPO tool: https://support.quest.com/kb/217592/

4. Enable Auto Update of the agents ( Settings |Provisioning | Agent Update ) to keep the agents up to date

Answered 10/19/2019 by: Nico_K
Red Belt

  • Thanks for your response.

    So if the agent was on 7.x with an amp conf file pointed at the wrong host and the 8.1 msi was installed over the top would this cause issue? On the few devices with this scenario ive tried uninstalling KACE with 'AMPTools.exe uninstall all-kuid' and re-install 8.1 and they just wont check in.

    Seems like the only agents that work are the ones where the batch file fixes the amp conf file to the correct host, they check into kace on 7.x and get updated.
    • well, if it points to the wrong host, this is another issue (but I did not reads something about this here) which can be solved by amptools -resetconf host=RIGHTHOST (set your right host as RIGHTHOST) you can use a GPO for that or other psexec etc.

      If still some systems dont check in after they have been handled like that
      , please contact support for a deeper analysis

Don't be a Stranger!

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

Sign up! or login

Share