Feature Suggestion: Job Queue Conditional Statement 2

[rokinron1]

Trying to re-post

Working with Job Queues and was wondering if we could have conditional statements added and a new action added that will “send logged on users a message”

If then statements for “Logged on Users”
1. In Job Queue, Under the “Special” section below ——–Conditional———– add two (or more) statements that will handle whether a user is logged on.

For instance,
“If 0 Logged On Users goto label:X”
“If Any Users Logged On goto label:X”

This would also allow for a step following to either terminate the queue or notify the user if a user is logged on, so as to reduce interruption to the end user.

2. A “Send Logged on Users a message” option in the Actions section of the Job Queue

So I could have a Job Queue like this:

—Job Queue Start—-
Label:CheckLoggedonUsers
Get Logged on Users
If Any Users Logged On goto label:Send User a Message
If 0 Logged on Users goto label:Check and install Updates

Label:Send Users a Message
Send Logged on Users a Message: “Updates are about to be deployed to your machine in X minutes”
Wait X Minutes

Label: Check and Install Updates
Check for Updates
Download and Install Updates Reboot if Required
—-Job Queue End —-

[doug]

Thanks. We’ll consider the conditional logged-on users option. In the meantime, there is already the ability to send a custom message to logged-on users from the Job Queue. See lower-left corner ‘Saved User-Defined Commands and Deployments’ grid in the Job Queue window. Any saved ‘Send message to logged-on users’ will appear there.

You can already get just about everything you need/want right now by simply skipping the conditional check for logged-on users. Instead just do the following, which satisfies the desire to warn users, and still gets updates installed on machines where no users are logged-on yet:

JOB QUEUE:
Send message – Updates will be deployed to your machine in X minutes
Wait X minutes
Download and Install Updates Reboot if Required

[rokinron1]

Awesome thanks Doug! I’ll use the suggestions that you have in the meantime! This Job Queue feature is an absolute game changer!

I think the only thing I’m not immediately able to do is terminate the job queue based on if a user is logged on. While that could be an option in itself within the job queue “If any users logged on then terminate the job queue” I found that I could do the same thing with a goto label, with a terminate action following.

[doug]

You’re welcome.

Can you clarify what you’re doing? I’m just curious to understand. Since you can’t currently have the job queue branch based on whether or not there are any logged-on users, why do you need a goto to terminate the queue at all? I mean what is the goto based on? The job queue example that I showed in my previous posting above will terminate after step 3 runs. No need for a goto or a terminate queue step. If you can show me exactly what you’re doing or attempting to do, it will just help me understand your exact needs so that we can make the best decision moving forward about exactly what to add or not add to the various actions/options.

Thanks.

[rokinron1]

Absolutely, here is what I’m working on. I’ve italicized the line that I hope the new feature would be, so that I can run the job queue and it will ignore machines that have users logged on and it will highlight the row in Orange so I can circle back.

I also have a rudimentary error remediation when the check for updates step fails. I’ve noticed in my environment if the check for updates fails it is because of Error 115 which is because the Opt in to MS hasn’t been run, so I have it loop through the MS Opt in, wait and then go back to check for updates again.

Label: Gather Info
Set row color: Default
Start pinging
If previous action failed/errored (returned non-0). goto label:Error
Get logged on users
If Any Logged on Users goto label: UsersLoggedOn (Which ultimately would terminate the queue and change row color to Orange for follow up)
Get C: disk space
Get MAC address
Get last boot time
Get pending reboot status

Label: CheckforUpdates
Check for available updates
If previous action failed/errored (returned non-0). goto label:Optin
If most recent Check for available updates’found 0 updates goto label:Finishing
Wait for host to have zero logged-on users
Set row color-16711681
Download and install updates + reboot if required
If this step is executed 4 times, terminate queue
If Get pending reboot status’ returns FALSE, goto label:CheckforUpdates
Wait 8 minutes
Wait for host to be detected online
Get pending reboot status
Goto label:CheckforUpdates

Label: Finishing
Stop pinging
Set row color-16711936
Terminate queue

Label: Opt In
Opt-in to Microsoft Update
If previous action failed/errored (returned non-0). goto label: Error
Wait 4 minutes
Goto label :CheckforUpdates

Label: Error
Set row color:-65536
Terminate queue

Label: UsersLoggedOn
Stop pinging
Set row color: Orange
Terminate queue

[doug]

This looks very good and is helpful to see. Thanks for sharing!

FYI this isn’t a big deal but using start and stop pinging in the job queue isn’t really necessary. Pinging will automatically start when BP initiates a reboot, and it will stop when the host comes back online after the reboot.

[rokinron1]

I’m wondering if it would be beneficial to have a condition based on row color, so I can do actions based off of colors of the rows that I set. I typically set row color to RED when there is an issue that requires a manual intervention.

If row color is Y goto Label:X

Where Y is a selectable color from the color palette, or simply the numeral that represents that color. -65536 for Red for instance.

[doug]

If you’re using the job queue to set the row color… then wouldn’t you just branch immediately after you set the row color? It would be weird and unnecessary for the queue to set the row color to red and then follow with “if row color is red…” because you already know the row color is red since you just set it that way in the previous step. Maybe I’m misunderstanding.

[rokinron1]

Yeah you make a great point, there would be no real benefit gained from a condition based on row color because I’d be the one setting the row color during the Job Queue steps. In which case, I’d just do a step after setting it to Red that would branch to other steps.
So something like this:

If Users Logged on then goto label: UsersLoggedOn

Label: UsersLoggedOn
Set Row Color: Red
Goto Label: Remediation

Label: Remediation
Wait for Users to be logged off
Apply whatever remediation needed, (Force user log off?)
Then Goto Label: Check for Updates

[doug]

Yeah that makes more sense 🙂

[Author]

Posts