By "maintenance window in the repair Task" are you referring to the Start Time (Start later)?
If so, that only tells the core when to "send" the task, are you using the CSA? (I'm)
and that only means that at that time the core is going to send the task, but that is not going to be detected until the next 5 hrs cycle. At which time the task will run. Unless you have specified a Maintenance Window in Distribution and Patch Settings that the Agent is using. Then it will install only during that time frame (I actually answer of couple of questions I myself had )
The first thing that needs to be done is ensuring that the maintenance is set in the agent settings (Distribution and Patch settings) and is actually *applied* to the clients. What you can do is the following:
1- Create a new Distribution and Patch settings (Or copy your existing one).
2- Modify the new settings to have the maintenance window you want (Based on your question this should be in the evening)
3- Push the new settings into the clients that you need to update.
4- Once you ensure that your machines got the new settings applied to them, create a task that will run during the maintenance window.
Once the patching is completed, you can push the old settings back to the clients if it is no longer required.
I didn't really work with CSA *YET* but I believe that the machines that are connected to LDMS do sync with the core server on daily basis. So you might need to create settings and then schedule them to be delivered as a policy.
I was afraid that would be my only option. As we are always doing a lot of deployments and the Windows upgrade will be spread out over a long period of time, changing the agent settings to use a maintenance window and then changing them back will be difficult to manage.
It would be nice if MW settings that are applied to a task could temporarily override the agent settings.
Unfortunatelly you can't override a default agent setting that have no MW configured to use one, It's only going the other way, if your agent has MW configured, you can bypass this by the task setting task as Motaz already wrote.
But what you can do is to configure the repair task as an accelerated push task and set the start time to the evening. When you client is online, it will grab the task and should start the repair immediatelly. You can set the accelerated push time out through the little gear Icon in the scheduled task Icon bar. Maximum is 240 minutes, which means if a device is off and comes online in this time, it will start the task too. If time runs out and a device comes up, it will fail to start the task. I think thats exactly what you need...:-)
Interesting idea. However, after the 2 hours it will convert to a policy. If I don't kill the task then could run outside of the desired time.
Nope, if you choose accelerated push, the task will stop after the configured timeout and isn't converted to a policy! Thats the difference between push and accelerated push.
To clarify what Christian stated.
Policy-supported Push: Does a one try push of the software then converts to a policy.
Push: Does a one try push of the software.
So don't assume a task with acceleration enabled will stop after the timeout, it will not it will still create a policy if its set as a policy supported push - you need to choose "Push".
I was told exactly the opposite way and we used it many times because our customer has exactly the same need, only deploy at night times and if a device is offline or not reachable, do nothing, just fail. With push only the behaviour was exactly the same as policy supported push. As the devices came up in the morning, they rerun the push task. We had very long discussion with the deveopers to get around this and the result was the accelerated push which acts like a push we knew from 9.5 and older releases. To have a bit more control on how long this accelerated push stays "active", you can configure the timeout. Maybe something has changed now but that was my state of knowledge...but maybe I'm wrong...
I had a similar conversation in another threat Patching Hangs with Paul Hoffmann, feel free to check this one too...;-)
... you know, we do have configurable Maintenance Windows as an additional safety layer here.
That way, vulscan won't start anything unless it's a pre-defined / acceptable date-time frame .