Kace SMA Agents Won't Connect After 8.0 upgrade
We updated our K1100 SMA to version 8 last week. Ever since then the agents are disconnected from the appliance, but only after the upgrade to the latest agent. If we manually reinstall the agent, and go to c:\programdata\quest\kace and edit amp.conf, the konea agent is set to communicate on port 80. If we then reinstall the agent manually, edit the amp.conf file and change it to port 443, the agent will communicate for a few hours, and then stop. I have provisioning turned off on the appliance, and I disabled agent update settings, but every night the SMA reinstalls the new agent to all workstations, and they all go offline again.
Also, I tried reinstalling the agent using provisioning on the appliance, and it fails every time. I can reinstall the agent one at a time, or using psexec, and it works. At least temporarily.
All of my agents show offline, and last inventoried 8 hours 10 minutes ago. It is 8:45 am, and I reinstalled all the agents approximately 5:00om last night, so they all died around midnight.
Interestingly enough, anything I have that is on an older agent (I have some servers still on 6.4 because they don't have enough free space to install the new agent), are showing online. All of my agentless devices (snmp) are showing online, and I have 10 workstations on the 8.0.152 agent that are online out of 130+.
Also, I tried reinstalling the agent using provisioning on the appliance, and it fails every time. I can reinstall the agent one at a time, or using psexec, and it works. At least temporarily.
All of my agents show offline, and last inventoried 8 hours 10 minutes ago. It is 8:45 am, and I reinstalled all the agents approximately 5:00om last night, so they all died around midnight.
Interestingly enough, anything I have that is on an older agent (I have some servers still on 6.4 because they don't have enough free space to install the new agent), are showing online. All of my agentless devices (snmp) are showing online, and I have 10 workstations on the 8.0.152 agent that are online out of 130+.
1 Comment
[ + ] Show comment
Answers (7)
Please log in to answer
Posted by:
GiSo
6 years ago
Good morning guys, I'm back.
With the support, we have established a possibile cause of the problem. Some old GPOs on our domains, could install an old version of the agent. Until "today", we never had this problem during the automatic upgrade process (what you order to run from the Kace console).
With the jump from 7.* to 8.* the problem happened. The support has suggested to make a GPO to uninstall the old Kace agent (using old MSI), and another GPO to install the new one. I have tried "without success". The uninstallation and new installation times were too long, then I have written a little PowerShell script to uninstall old agent, copy the new one on the local disk and then install this.
When the user make logon on the domain, a VBS script verify if %ProgramData%\Quest\Kace\kinventory.db is older then 10 days, then engage the PowerShell script to make the change and substitute an older agent version with the new one. In a couple of days the console has "recovered" his clients.
Posted by:
Giuliano.Maria
6 years ago
worse still, we could not provision the agent or insert new devices.........
[01/18/18 12:30:03 PM] Start provisioning ...
[01/18/18 12:30:03 PM] Running the Windows Platform Provisioning.
STEP 1: CONNECT TCP / SSH - FAIL
ERROR: A connection to the target device could not be established. See details in the provisioning log. - FAILURE
[01/18/18 12:30:03 PM] End of Provisioning Execution.
Posted by:
Brady Williams
6 years ago
Throwing in a "Me too"
What I'm finding is that the C:\programdata\dell\kace directory is either empty on my endpoints or the amp.config (conf?) file is missing.
All of my machines have dropped off as recently as 2am last night. I don't know when they started dropping, but the last connections are about 8 hours ago.
I've already put in an elevated support request, but if this is a big toes-up issue, I expect the techs are absolutely slammed.
Hope we hear back soon on this.
Comments:
-
Looks like the new location of the amp.conf file is in C:\ProgramData\Quest
I wonder if KACE is still looking to the old location for the conf file. - Brady Williams 6 years ago-
I don't think it is. when I reinstall the agent on some machines, they are still offline. But then I edit the amp.conf in the new location the Konea webport is still set to 80. If i update it to 443, the agent immediately begins to communicate.
However, if I only edit the amp.conf without reinstalling the agent first, it never communicates. - dweiskir 6 years ago-
If you try to navigate (with prompt) into %ProgramFiles%\Quest\Kace and put the command "amptools get", what is the port used to communicate with the console? Have you tried also to reset the configuration from prompt? "amptools resetconf host=kace.contoso.com" - GiSo 6 years ago
Posted by:
GiSo
6 years ago
We have a similar problem after the upgrade. Among the approximately 650 PC registered on Kace, we have a lot of this correctly updated to 8.0.152 from 7.1.62 (agent version), disconnected from console but online in our network (I can ping them).
Many other have been correctly updated and are instead connected to the console.
I can't understand where is the difference between the two situations.
If I connect to one of "disconnected" PC via PsExec, I can see two file in C:\ :
14/12/2017 11:26 0 KBOT.BOOTUP.LAUNCH
14/12/2017 11:26 0 KBOT.LOGON.LAUNCH
14/12/2017 11:26 0 KBOT.LOGON.LAUNCH
I don't have yet the folder %ProgramFiles(x86)%\Quest\Kace and I have a %ProgramFiles(x86)%\Dell\Kace with an older version of the agent compared to the one we had before!
C:\Program Files (x86)\Dell\KACE>amptools get
[2017-12-14.11:28:59][AMPTools:ConfigLogAll ] KACE Agent version 6.3.314 Apr 13 2015
[2017-12-14.11:28:59][AMPTools:ConfigLogAll ] KACE Agent version 6.3.314 Apr 13 2015
Nothing change if I reboot the PC. I have to reinstall manually (via PsExec) the agent, removing (before) the files in C:\ (KBOT.*), otherwise the agent can't be "put back on track"!
Can someone explain to me what the hell is going on? :-S
Comments:
-
If I navigate to %programfiles%\quest\kace on a machine that is not communicating, that folder is empty. When I reinstall the agent, the files magically reappear. It is then trying to communicate on port 80. Edit amp.conf in c:\programdata\quest\kace, change konea webport to 443, and agent starts communicating. - dweiskir 6 years ago
Posted by:
Brady Williams
6 years ago
I have opened a trouble ticket with Quest and it turns out that 70% of my services on the box (we have one of the original K1000 appliances) were not running. Quest technicians tethered in and took our box down for an hour yesterday and have determined that we have some DB corruptions (their words). In the process of repairs, they have restored connectivity to our endpoints, which is good, but have not confirmed that they are done with the tether, so I have not removed the key. While the tether key is in place, I cannot run the Services report in the support page of my box (I don't know if that's a weird anomaly or what... it just won't list the services.. other reports will load okay), so I don't know if we're back at 100% or not. I'm waiting to hear back from the techs.
This all started because I was building a script and it never actually ran... after checking the destination endpoint and seeing no KACE activity, I attempted to ping the endpoint from kace support tools, no reply, at which point I discovered that endpoint (as well as every other in our network) was failing to check in.
While it sucks that it seems that an update broke KACE (this is a first for us... early adoption has never failed us before... sigh), I'm glad to hear it's not my individual box that's failing.
Comments:
-
Bad story. I hope to have a reply on my "answer" (another question, actually), I would like to avoid opening a ticket and being told that this is a database problem! :-S - GiSo 6 years ago
-
(usually we are waiting for the stable release of new updates to avoid this kind of problems) - GiSo 6 years ago
-
I checked my services and everything is running perfect. We had a lot of "DB" issues in the past which turned out to be a bad motherboard and memory. Once Quest replaced both of those, we haven't had a problem with the appliance since. Until this update. - dweiskir 6 years ago
Posted by:
Brady Williams
6 years ago
Further update.... still no explanation on why the agents dropped off, but our 'corruption' was a bloated db table based on asset history settings. ours was still defaulted to 'forever' and it had grown to an unmanagable size. This is a feature that I've never looked at and I was unaware of a 'best practice' to set that to a lower threshold, so... whoops, lesson learned.
The technicians have got our services back up and running and the agents are connecting again.
I wonder if it was a crashed service that was 'rejecting' the connection to the endpoints.. if that's the case, I wonder if there's still a connection between all of our failures... @dweiskir @giso is there any possibility that you all are suffering similar issues?
Comments:
-
All possible. We don't use the asset feature. Where I can see / modify the configuration or check if the issue is the same here? I have opened a support case to Quest, I'm waiting for a response. - GiSo 6 years ago
-
adminui, Settings, History, then under the Subscriptions, you will have Assets, Objects, and Settings links. Click the Assets link and make sure it's not still set to "Forever". The tech said 12 months is an acceptable selection (it's the longest you can choose other than Forever). I don't even know why Forever is an option if it's capable of bricking the box. - Brady Williams 6 years ago
-
I have "3 months", then I think is not this our problem :-( (I'll waiting until monday to have a reply with a solution proposal, then I'll make a call to have faster support). - GiSo 6 years ago
-
also, for what it's worth, I've found that calling gets a much faster response than submitting a ticket. I don't know why a ticket entered via the phone seems to get a quicker reply, but that's been my experience.
I HAVE been very happy with Quest's support, however. They seem to be quite a bit more attentive than when KACE was under Dell. - Brady Williams 6 years ago
Posted by:
bodhi311
6 years ago
Same issue here. Agents all reporting the upgrade but it looks like they were never installed. If we manually run the agent it gets installed properly. What did support end up doing for you on the DB side of things because things seem all out of sorts.
We also tried running the provisioning from within case and that does not seem to work either.
Comments:
-
Perfect, We have the same problem. I have opened a support case and I have also sent KaceKapture logs. Now I'm waiting for a response and -I hope- a solution. - GiSo 6 years ago
-
We're back up and running 100% thanks to the Quest technician's hard work via tether.
He recommended that we move to virtualization if we're going to continue running on prem. Mostly, because we're using one of the early appliances and it's going to fall out of support (ver.8 will the the last supported version on our appliance).
Good luck with your connectivity issues. I hope you'll post up with your resolution so we can all learn a bit more of the diagnostics side as a community. - Brady Williams 6 years ago-
I'm already on a VA (ESXi 6.5) ;-( - GiSo 6 years ago
"but every night the SMA reinstalls the new agent to all workstations"
This part seems to be off... I mean provisioning from the K1 will not reinstall, since it cannot target machines that are already on the inventory with a KUID. (KACE unique ID).
Maybe a GPO policy is doing this?
Or maybe an scheduled Script was configured from the K1000?
Make sure the your AV or security solutions are white listing the new Agent Paths.
Try to telnet from a faulty workstation, using the Appliance FQDN through ports 80 and 443.
See if KACE Agent ProgramData folder, if there is any .PEM file and Inventory.XML file (they should not be in 0bytes) - Channeler 6 years ago