Support Forum

First, just wanted to hilight this post to make sure this was addressed, and didn't get lost in the other issue that thread was for originally, as it is still present from what I see: http://support.plugins4labtech.com/view ... 8414#p8414

Second, based on feedback from a client where we tried making use of the "Allow user to cancel" functionality:
- Can we set a custom amount of time for the prompt to allow the user to cancel?
- Instead of or in addition to the above, can we have the option of an "ask then deny" equivalent, where it asks the user if we can proceed and if they don't answer it just does not kick off?
- The "we are now upgrading you" popup locks the user completely out of doing anything during the upgrade. Would it be possible to allow this to be minimized so they can continue to work? If the "user cancel" option is not selected in the policy, it apparently runs in the background with no notification from what I've gathered so there doesn't seem to be a "safety" reason to keep this.

Third, would it be possible to add either some sort of "deployment window" per policy or a check so that if a machine is scheduled, goes offline in the interim, then comes online the next morning after missing the start time, the upgrade script will not go ahead and kick off anyways? While it does help make sure the upgrade gets done, it is resulting in users having their computer rebooted with no real warning that it could be coming(if the "allow user to cancel" option isn't selected).

Fourth, would it be possible to add the ability for recurrence in the schedule? I've got some machines that have been persistently offline, and I'd prefer to schedule them once to try on a daily or weekly basis while the appropriate people try to reach the users or client, rather than have to constantly re-schedule them over and over in case we are able to reach the people using those computers to make sure they get turned on and/or stay on.

As an alternative or way to handle the above (or potentially solve points 3 and 4 in one go), what about a "automatic deployment" option? Instead of manually scheduling everything we can maybe configure a group per policy and it will automatically push that policy to the computers in that group on a set recurring schedule. Since the script would be running against the group and not individual computers, it can skip the offline machines at the time of running and solve the issue in 3 at the same time. This would also help for onboarding new clients who might not be fully up to date with a minimum of work.

Lastly, on a very minor note: while the script does try to pull fresh system info in line 298, I don't see anywhere that re-sets the @WIndows10Version@ variable to match the new data, (and based on what I've seen it doesn't refresh itself) so the log in 305 and 301 will always show what version the computer was on previously.

I want to say I've also had mixed success with just "Resend System Information" updating the Windows version, and I usually do a "Resend Everything" when I'm manually checking - this also has the benefit of updating patch data so Automate's patch manager is updated on what patches the machine is missing post-upgrade.

On your first note, I will revisit this to make sure we are in the green with the missing (_). I maybe that we fixed but not released it yet which would make the most since.

As to point #2 we are limited to the options for "If User Response" script function.




We are offered a "Yes/No" response where yes will pass you to the next step and no will exit script. A non response is considered a no, which exits the script before we can retake control. We could play some word magic to reverse the question but then we would introduce a new problem with MSPs whom expected a different outcome.


On your third request

The automation service schedules the agent right after midnight (seconds) for what ever time of day that day you set to start install. This accounts for how it currently schedules agents for updates.

In a scenario where you set an agent to install at 8AM on 01/10/2021 the automation at 12:01AM on 01/10/2021 would schedule the script for 8 am that day. What we could do is test for agent to online at 12:01 AM and if not skip the scheduling. I would would want to add override flag in some manor as inevitably a MSP will want the opposite control.

I will look into this.

Your forth request is a bit more involved. We would need safeguards in place to stop the loop when certain criteria is met or and including a set of limits met. This would need to evolve some, MSPs that deploy and use functions as a 300 agent MSP would have different needs from a 5000 agent MSP.

The group idea has been tossed around some and we can see some real benefits with group usage. This maybe an option for several issues within Habitat where groups could be used to allow more flexibility.


On you last note we will look at this and make sure logic is staying updated. The resend everything seems a good start.

Thanks for your input and we will start looking into some of these issues.

Cubert wrote: Tue Mar 02, 2021 2:34 pm On your first note, I will revisit this to make sure we are in the green with the missing (_). I maybe that we fixed but not released it yet which would make the most since.

I was actually referring to the process check, where the powershell needs to check for "Setup" rather than "Setup.exe" when it looks to see if it's still running to get the correct response, and same when killing it. The typo issue itself is fixed from what I've seen. Sorry if I didn't make that clear.

We are offered a "Yes/No" response where yes will pass you to the next step and no will exit script. A non response is considered a no, which exits the script before we can retake control. We could play some word magic to reverse the question but then we would introduce a new problem with MSPs whom expected a different outcome.

Perfectly understandable - and actually I was just running some tests and it already is Ask Then Deny! I'm not sure where the complaints were coming from now from these users about missing the prompt and it going on anyways. Either way, looks like this is already set up as we'd want, despite what I was hearing.

As for the rest, I look forward to seeing what comes of it all!

*edit*

Also found a bug, though mostly just related to log feedback. If the download legitimately fails(and there is no network cache in play), the process still tries to go on and fails out at not finding the setup file, reporting that as the final message instead of a failed download. As such a suggestion: In the :Windows10Cachefailed section, have it check to see if network cache is enabled(or if @ISOPATH@ is blank), and if not exit out there with a message. That way if it is a network cache issue it'll still try to go on to use the local ISO, but if there is only the local ISO and that fails, it will give relevant feedback when checking the results the next day.

Thanks for the clarification, That has not been corrected /released yet but is on our fix sheet. so I would suspect it will be updated in next set of releases.