Попробую перефразировать еще так.
Вы решаете задачу выполнить действие X в ситуации Y, если питание от батареи. Решение успешно.
Мне хочется видеть, обеспечить срабатывание задания TaskExample в ситуации Y, совершающего действие X. Когда ни X, ни Y, мы не знаем и знать не хотим. Они приватно инкапсурированы внутрь задачи. А известно нам только ее имя TaskExample.

И что в моей постановке задачи может этот мониторинг?
У нас есть задания успешно работающие при питании от розетки. Некоторые из них, перестали срабатывать при переключении на батарею. Именно так, во множественном числе! Допустим 5, от TaskExample1 до TaskExample5.

Допустим перехватили мы переход в сбережение и знаем, что с этого момента с задачами проблема. Что дальше? Как без их модификации и не изобретая новый способ форсирования под триггеры конкретного TaskExample, вернуть как было́?

P.S. на соседний пост про абстрагирование отвечать не буду. Темы плотно пересекаются. Поймать переход не проблема. Главный вопрос, что дальше?

Lecron: В целом, если говорить языком разработчиков: слишком сильная связность задания и метода форсирования. Они нужны абстрагированными. Задание отдельно.

Смотрите, для решения задачи сделана альтернатива запуску задания планировщика по событию в журнале, штатной функции. Но у подхода много применений.

Фоновое задание powershell — это нечто вроде простенькой службы. Через планировщик же запускаем его при старте системы. Потому что так проще всего запустить от системы. Но можно иначе это реализовать.

А дальше подписка на события в журнале это тоже лишь пример. В статье упоминается регистрация событий WMI (запущен процесс, например).

Я понимаю что это может всё не так очевидно, потому что много всего сразу. Надо просто сесть и попробовать сделать, и окажется что это достаточно легко. Один скрипт, пара команд.

Lecron: Не понимаю как. Статья сильно завязана на триггер «выход из сна»,

Это первый скрипт, есть ещё второй в разделе

Мониторинг журналов приложений и служб

Допустим, мы хотим выполнять задачу при переходе системы в режим энергосбережения.

Vadim Sterkin: Прописывайте какие угодно задачи в том же блоке и выполняйте их. Конечно, это могут быть те же самые запланированные задания. Вызываем их из скрипта.

Не понимаю как. Статья сильно завязана на триггер «выход из сна», для конкретной задачи Дениса. И как-то плохо сочетаются рядом стоящие фразы «Прописывайте какие угодно задачи» и «главное не запутаться в костылях». :))

В целом, если говорить языком разработчиков: слишком сильная связность задания и метода форсирования. Они нужны абстрагированными. Задание отдельно. Самостоятельное, НИЧЕГО не знающее про его форсирование. Создаваемое как из GUI планировщика, так и программно. Форсирование отдельно. НИЧЕГО не знающее про задания, их триггеры и другие параметры. И простейший биндинг между ними.

Может при таком архитектурном подходе, если он конечно возможен, и конкретная задача Дениса будет выглядеть проще.

Lecron: Нет связи, между перехватили событие и форсировали заданиЯ (любое из заданий, с любым штатным триггером).

В скрипте действия при перехвате события — это запись события в текстовый файл и вывод в консоль. Но это же просто примеры.

Прописывайте какие угодно задачи в том же блоке и выполняйте их. Конечно, это могут быть те же самые запланированные задания. Вызываем их из скрипта.

Тут главное не забывать, что задания планировщика сами по себе умеют запускаться по событию в журнале. Поэтому смысл городить с ними огород имеет только в описанном особом случае, когда задания не отрабатывают в режиме энергосбережения.

Lecron: устранив одно из условий возникновения проблемы — «Задание настроено выполняться для всех пользователей, нежели для конкретного пользователя»?

С одной стороны, здесь исходная задача диктовала работу для всех пользователей. Фоновая задача не видна (не мешает), а без прав админа её и не остановить.

С другой стороны, даже если отбросить джобы Powershell и методы .NET, а просто периодически опрашивать журналы с помощью Get-winevent, не во все журналы есть доступ без прав администратора.

Емнип, как раз в Operational нет (в такой пишется запись о переходе в режим энергосбережения). Тут можно пристегнуть ещё один набор костылей https://www.outsidethebox.ms/20970/ Тут главное не запутаться в костылях:)

Не совсем. Поймать не проблема. Но, ключевое «…которая обслуживает этот список». Нет связи, между перехватили событие и форсировали заданиЯ (любое из заданий, с любым штатным триггером). Либо я ее не увидел.

Еще раз повторю, как я вижу удобную работу. Создаем обычную задачу, ни на секунду не задумываясь в каком режиме энергосбережение. Узнаем что она не срабатывает или вспоминаем о таком поведении ОС. Помещаем имя задачи в список «Эти должны срабатывать». Всё!

Можно ли такое сделать программно? Например создавая копию задачи, устранив одно из условий возникновения проблемы — «Задание настроено выполняться для всех пользователей, нежели для конкретного пользователя»?

Lecron: Создается задача с триггером «Перешли в режим сохранения энергии», которая обслуживает этот список

Так второй скрипт именно это и делает. Так-то наверное есть API, но скриптом событие ловится нормально.

Но раз такой опции нет, ее надо эмулировать. А вот дальше, знаний администрирования и PS не хватает. Но подумайте в такую сторону. Имена нужных задач вносятся в определенный реестр — файл, ресурсы скрипта, системный реестр. Создается задача с триггером «Перешли в режим сохранения энергии», которая обслуживает этот список и каким-то обходным образом (каким?) форсирует их сработку. Возможно это будет создании копии задачи с правами запуска залогиненного пользователя. Не забыть откатить… Возможно как-то еще. Но работа именно со списком абсолютно стандартных задач.

В приложенном решении, как понял, модифицируется сама задача.

Я уже три года как уехал из РФ, не собираюсь возвращаться, а потому постепенно (по мере надобности, а что не надобно — само отвалится) перевожу аккаунты с почты мейл.ру на гугл. Говорю то же самое делать жене. Но у нее вечно нет на это времени, в отличие от инстаграма, а если что, муж все порешает…