I have 4 machines that just don't want to check in. I can occasionally force a check-in with PSEXEC, but they always stop responding again soon. There's nothing stuck in the to-install list, and the AMP connection is still present. We have several machines of this model with no issues, but there are 4 that I can't explain. Thoughts?

Model: HP Compaq dc7800 Convertible Minitower
Agent Version: 5.0.25648
OS Name: Microsoft Windows XP Professional
Service Pack: Service Pack 3
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

1
You may want to create a support ticket. I've had the same issue and so far I have not been able to resolve it. Luckily, only a handful of machines have been affected. If you contact support, they'll have you run a client debugger and give them the agent logs so they can attempt to determine the cause of your particular issue.
Answered 11/24/2009 by: airwolf
Tenth Degree Black Belt

Please log in to comment
1
take a look into the config.xml and smmp.conf files. make sure the server name is correct. I have had issues with this... I used psexec to stop the service, fix the config file, and start the service.
Answered 11/24/2009 by: dtuttle
Purple Belt

Please log in to comment
1
In my case, it isn't a configuration issue. However, checking the config files is a great idea.
Answered 11/24/2009 by: airwolf
Tenth Degree Black Belt

Please log in to comment
1
Its not a config issue, more of a code issue. I found it happens on laptops more then desktops so maybe its them just disconnected for so long.


In my case, I would notice that the clients stopped checking in, once I looked deeper and checked the config files to find that in one config file (I cant remember what one) chanced back to kbox, rather then the correct hostname.
Answered 11/24/2009 by: dtuttle
Purple Belt

Please log in to comment
1
Makes it a lot simpler for me since the hostname of our kbox is "KBOX". [;)]
Answered 11/24/2009 by: airwolf
Tenth Degree Black Belt

Please log in to comment
1
ORIGINAL: airwolf

Makes it a lot simpler for me since the hostname of our kbox is "KBOX". [;)]



that would really simplify some things here
Answered 11/24/2009 by: dtuttle
Purple Belt

Please log in to comment
1
ORIGINAL: dtuttle

Its not a config issue, more of a code issue. I found it happens on laptops more then desktops so maybe its them just disconnected for so long.


In my case, I would notice that the clients stopped checking in, once I looked deeper and checked the config files to find that in one config file (I cant remember what one) chanced back to kbox, rather then the correct hostname.


I'm told this can't happen, but I've seen the same behavior. In my case it's changing from a FQDN with SSL enabled back to an unsecure "kbox" address.
Answered 01/26/2010 by: cblake
Red Belt

Please log in to comment
1
I have seen the config file revert back to kbox as well. That is the default name so if it were my network I would have at least DNS entry for kbox as well if not also naming it explicitly kbox in the settings->network settings. A DNS entry alone doesn't help you for SSL though since the name needs to match the certificate.

Your network settings should look like this:
http://www.kace.com/support/customer/faq/index.php?action=artikel&cat=1&id=628&artlang=en

The 5.1 agent (next major release) will be a lot smarter at trying previously known good settings as well as other possibilities when the cached config information fails.

If you are having issues checking in then please see this document:
http://www.kace.com/support/customer/faq/index.php?action=artikel&cat=3&id=713&artlang=en

This faq solves most cases and when it does not it provides support with the background information and symptoms to troubleshoot.

What is not listed in the faq is the debugger that airwolf mentions. We want you to contact tech support to obtain that (get the latest version and interpret the results). The debugger does a better job at comparing apples to apples then some of the tests that the faq suggests. The debugger will check things in the same way that the client does. For example, I saw a case recently where I was able to resolve the host name and connect via ping and telnet respectively but the debugger gave an error. This was because the .Net 1.1 call to that name was failing.

Other things that could be causing the problems:
- firewall (on PC, on intermediaries like gatewas, etc)
- invisible and / or explicit proxy servers

When in doubt make the problem as simple as possible and build up from there. I have solved many cases by asking the customer to physically put a PC on the same switch as kbox and re-test.
Answered 01/26/2010 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
1
Have you checked the presence of Virus on these systems ? We have experienced the same issue , later it is discovered that the installed Antivirus was not able to detect these Trojans. Use KasperSky to detect viruses. Further you may reinstall the Dot NET framework.

Afzal Yousufi
Foresight Technologies
Answered 02/08/2010 by: afzal
Fourth Degree Green Belt

Please log in to comment
1
ORIGINAL: airwolf

Makes it a lot simpler for me since the hostname of our kbox is "KBOX". [;)]


We also use KBOX as the hostname and have helpdesk as another DNS entry for the end users to remember better.
Answered 02/09/2010 by: ustacp
Second Degree Blue Belt

Please log in to comment
Answer this question or Comment on this question for clarity