/build/static/layout/Breadcrumb_cap_w.png

Why dont scripts deploy to all machines on a smart label?

Hi guys,

I have been having some trouble trying to figure this out by myself so I have come here to see if someone can explain why what I am seeing is happening. 

We are running Version: 6.4.120756 of Kace with version 6.4.522 of the Agent.

So I have created a smart label that labels all Windows 10 Pro x64 machines on our network. The smart label has 200 computers on it. I can see that about 50 or so are offline currently. The rest are online.

I have an online script that is configured to run on Windows 10 Pro x64 machines only. When I run the online script against the 200 computers, the script only targeted then pushed to 9 computers. That's a tiny fraction of the number it should be deploying to. There is no conceivable way that many computers were on but not signed into by any users, at the time the script was run.

If a Windows 10 Pro x64 computer was online and had a used signed into it at the time the script was run and the online script was configured to run on Windows 10 Pro x64 computers, why would a script not get targeted then pushed to that machine?

I have tried changing the script so it's not so specific about the operating system it can run on, so its just 'Windows' as opposed to 'Windows 10 Pro x64' and it ran on 60 computers that time but still nowhere near as many as it should.

Usually, what I see when a run an online script on a machine that is online but not signed in, it will still be targeted and pushed to that machine but it will fail due to not having a user signed in. But I'm not even seeing that. 

If anyone could help me understand what on earth is happening here I would really appreciate it!

Cheers.

3 Comments   [ + ] Show comments
  • I am currently on the same K1000 and Agent you are.
    If I am reading correctly, Your label has 200 machines and when hitting Run Now (In the Scripting Page), only a few machines are targeted...

    The only time I see this happen is when the Target OS range is incorrect.
    Do you have the "Allow run without a logged-in user" checked as well? - Desktop Jockey 7 years ago
    • I've double checked the Target OS range setting, knowing this can be a cause but the target OS is/was correct.

      Sorry that is what I was trying to say when I said I configured the script to run on Windows 10 Pro x64.

      I have since changed that to just "Microsoft Windows" by unchecking the "select specific operating systems" option under the Deploy section. But the problem still exists, just to a lesser extent.

      I don't have "Allow run without a logged-in user" checked. I didn't want the script to run without a logged in user as I needed them to acknowldge some message windows etc. And sometimes with other scripts, they would still deploy to a machine without a logged in user anyway. They would just fail and show in the logs it was due to there being no logged in user.

      Unless I am mistaken, Kace does not do any checking for logged in users before deploying a script, so this shouldn't be a reason it doesn't get targeted or pushed. But maybe I am wrong about that? - designworks 7 years ago
  • I think I know what is happening now. The smart label isn't being applied to the machines that it should be applied to. Only a small subset of the qualifying machines are being labelled.

    Creating a manual label and then deploying using that label deploys to the expected amount of computers.

    It would appear that someone has changed the check-in interval for the agents on our K1000 to 6 hours. =/

    And from looking at the logs, compounding things is, under the "On Success" section of the Task, the "runkbot 4 0" that is executed in the script right after the "run program", doesn't appear to be getting executed if the "run program" completes with an error. >_<

    Can anyone confirm if that expected behaviour? A whole section of a Task in a script terminates if there is an error? - designworks 7 years ago
    • For each task sequence there should be a radio button for on failure, either break or continue. I believe the default is break. - chucksteel 7 years ago
      • Thanks Chuck. So to confirm, it's intended to break out of the *task* as soon as a step fails yeah? Potentially leaving steps in the task incomplete?

        Its not designed as I thought, to break out of the script when any step in a task sequence fails? - designworks 7 years ago
  • I am curious about this too. I can do the exact same script against one manual label and one smart label (same criteria) and it's always a crap shoot as to what the smart label pushes out to. In fact I've stopped using smart labels when intending to run scripts. Manual labels always works. Smart labels works fine in inventory, but on scripts it's very unreliable for us. Seems to randomly pick them. And if you do the script a second time, it's another random set, some repeats, some new. - five. 7 years ago
    • I'm glad I'm not the only one!

      I'm doing the same thing as you now too. Smart Labels are a largely a waste of time for script deployment. Manual labels are a more reliable alternative. - designworks 7 years ago

Answers (1)

Answer Summary:
Posted by: five. 7 years ago
Second Degree Green Belt
0

Top Answer

After talking to my jumpstart trainer about this issue. I think the problem is that at least on my end. I create the smart label and then go run the script against that new label. The problem with smart labels, is that they aren't applied when you make them. They are applied as clients check-in. So it would take x amount of time before your entire inventory has checked in and has that new smart label applied. And that is why it's sporadic, because as things check in the list will grow. I have not verified that was the issue, but it does make sense.
 
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