/build/static/layout/Breadcrumb_cap_w.png

KACE Product Support Question


K1000 v7 agent devices

01/10/2017 4205 views
Hello,

Ever since we updated to Kace K1000 v7.0.121306 al lot devices that are running the kace agent v7.0.763 constantly pop up the KACE screen when users log on.

I'm unable to find the cause of this, and we have no offline scripts running, the agents check in every 2 hours but shouldn't do this while interrupting users.

Any idea on what's causing this?

Thanks in advance,

Duncan
Answer Summary:
0 Comments   [ + ] Show comments

Comments


Answer Chosen by the Author

1
I did beta testing of 7.0 and that was a problem with the early version of the 7 client.  They changed components of client with version 7.0 vs all earlier clients. It should only do this once or twice.  it is running some system scripts, you can find what it is running by looking at the kbots_cache and see what extra scripts you have over the ones you deploy.

also check your settings to suppress:

Answered 01/10/2017 by: SMal.tmcc
Red Belt

  • SMal,

    I haven't seen a clear answer on this but I do know that there is some type of issue involving certificates and orphaned agents.

    Would you be able to shed some light on that?

    We're running 7.0.121306 on a VM but using agent 6.4.522.

    We just switched from a physical server to the VM, and changed hostnames at the same time. From my physical appliance, I started a script to updated the hostname on all my agents, and that was working.

    I'm concerned however that if I manually update my kbox to the v7 agent, I'll lose connections.

    Thoughts?
    • I ran into that when I updated the client on a few isolated machines and was able to fix that by running an amptools restrust on those couple of machines
      • So for clarification:

        You updated the agent on your server and broadcast the update.

        Things went well in most cases, but a couple didn't?
      • Further clarification:

        The word from Dell/Quest:
        "Important: While securing the Agent's connection, Konea is designed to be "sticky" to the first certificate it downloads from the appliance during the initial connection. If the appliance is restored or replaced, or if any other operation causes a new Konea certificate to be generated, all existing Agent instances will be orphaned, as they will not trust the appliance with the new certificate."

        Since I updated my clients on the 6.x agent to look to the new server already, should I assume they have already accepted the cert and that at this point, pushing out Agent 7 should be little to no issue?
      • SMal,
        Does the retrust switch only exist on the 7.0 agents?
      • if the 6.4 agents are talking to the server you should be able to turn on agent update and let it push it out from the new server and the retrust was added in 7
      • That's interesting. I've had similar issues in the past on a handful of servers. When running anything 6.0 and higher the server would not check-in. When I downgraded to 5.5 it worked immediately. I then upgraded back to 6.0+, and broke again. They never did get me a resolution on the issue, but instead said it was my server config. At least now I guess they are acknowledging the issue.

        I still haven't upgraded though, and not sure if/when I ever will. We have too many machines to be orphaned.
      • here are the v7 amptools options

        Usage:
        AMPTools [help | -h | -? | /?]
        This help text

        AMPTools get <config>
        Read configuration option from amp.conf. Configuration options are:
        host: Server hostname.
        debug: (true|false) Debug logging.

        AMPTools [set] [-n] <config>=<value> ...
        Set values in amp.conf. 'set' is optional. See 'get' for options.
        By default, restarts AMPAgent. -n prevents this.
        Known keys are host and debug.
        Changing host clears host-dependent config.
        AMPTools clearcache
        Clear AMP caches

        AMPTools killtasks [-f] [-w]
        Kill any running AMP subprocesses. With -f, force-kill them.
        With -w kill everything except watchdog.

        AMPTools shutdown [-f] [-r]
        Shutdown system. With -f, immediately without prompting user.
        With -r, reboot.

        AMPTools resetconf [-n] [<config>=<value> ...]
        Set amp.conf to defaults, optionally setting values (see 'get').
        By default, restarts AMPAgent. -n prevents this.

        AMPTools restart [-w]
        Stop and start agent. With -w everything except watchdog

        AMPTools retrust
        Remove certificate for current server.
        On next connection, server will be implicitly trusted.

        AMPTools delayed-restart
        Stop and start the agent, but delay for 20 seconds, this is used by RESETAGENT to allow time to send message back to K1

        AMPTools start [-w]
        Start agent if stopped. With -w everything except watchdog

        AMPTools stop [-w]
        Stop agent if started. -w everything except watchdog

        AMPTools uninstall [all|all-kuid]
        Uninstall agent. Leaves configuration and KUID.
        all: Also delete configuration, but not KUID.
        all-kuid: Delete everything, including KUID.
      • I'm betting that retrust would fix my current issue, but I'm not willing to upgrade to 7.0 to find out. We have three Kboxs, and I'm sure that's what it is. With 6.4 I don't guess there is currently a way to clear that cert.
      • you can try deleting the C:\ProgramData\Dell\KACE\cacert.pem then install the new client
      • I've tried everything.... trust me. I've completely removed everything including the KUIDs and it doesn't work. Our setup isn't typical with multiple Kboxs, and I do not think support knew really what to do.
      • Yea I remember your posting on this

All Answers

0
Thank you, after putting a check at these options the KACE screen dissapeared when logging in.
Answered 01/12/2017 by: anonymous_135268
White Belt

 
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