/build/static/layout/Breadcrumb_cap_w.png
05/07/2019 178 views

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.

Ken-

2 Comments   [ + ] Show comments

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.
  • 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.

All Answers

0

the "blank" amp.conf with just host=kbox in it comes with the client installation

1st

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


2nd

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.


3rd 

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. 


4th

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?

Answered 05/08/2019 by: n1md4
Blue Belt

0

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.

Answered 05/07/2019 by: Channeler
Red Belt

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