|
ВведениеВ предшествующих статьях данного цикла вы познакомились с утилитой SchTasks командной строки Windows, предназначенной для создания и управления простыми и усложненными заданиями. Вы уже знаете о том, что задания могут быть назначены для запуска однократно, поминутно, через указанный вами интервал времени, при загрузке системы, при входе пользователя в систему, а также при ее простое. Из предыдущих статей вы могли узнать о способах просмотра назначенных заданий при помощи командной строки – контексте /Query утилиты SchTasks командной строки, а также о различных методах создания разнообразных заданий, используя триггеры и всевозможные параметры. В предыдущей статье были расписаны все способы создания событийно-управляемых заданий (задания, которые запускаются при возникновении указанного вами события в заданном журнале). Все эти знания помогут вам избавиться от рутинной работы, автоматизировав задачи, которые вам приходится регулярно выполнять. Но для того чтобы полностью понять структуру заданий, которые вы периодически создаете, необходимо разобраться со структурой конфигурационных XML-файлов, в которых указываются абсолютно все настройки для создаваемого или существующего задания. О структуре таких файлов и пойдет далее речь в этой статье.
Создание задания, используя XML-файлКак в случаях почти со всеми административными приложениями, создавать задания при помощи конфигурационных XML-файлов вы можете при помощи оснастки «Планировщик заданий» и средствами утилиты SchTasks командной строки. Для того чтобы создать задание при помощи оснастки, вам нужно открыть ее, выбрать узел, в котором задача будет расположена, а затем выбрать любое из следующих действий:
В отобразившемся окне «Открыть» выберите папку, в которой находится созданный заранее xml-файл с задачей, и нажмите на кнопку «Открыть». Сразу после этих действий откроется диалоговое окно «Создание задачи», в котором вы можете проверить все настройки для импортированного задания и по окончанию нажать на кнопку «ОК». Для того чтобы импортировать задание из XML-файла при помощи командной строки, вам нужно воспользоваться командой /Create утилиты SchTasks с параметром /xml, который вкратце был рассмотрен во второй статье данного цикла. Как и во всех остальных методах создания задания при помощи данной команды вам необходимо использовать параметр /TN, отвечающий за название импортируемого задания. Значением параметра /XML должен быть полный путь к конфигурационному XML-файлу с параметрами вашего задания. Помимо этих двух параметров вы также можете использовать параметры /S для указания удаленного компьютера, /U, значением которого должна быть учетная запись, в контексте которой будет назначаться задание и /P – пароль для этой учетной записи. При необходимости вы также можете воспользоваться параметрами /RU и /RP, которые используются для назначения учетных данных пользователя, для которого будет применяться ваше задание. Структура конфигурационного XML-файлаНа первый взгляд, структура XML-файла задания может показаться весьма сложной и, при написании таких файлов с нуля, на первых порах, могут возникнуть серьезные трудности. Прежде всего, хотелось бы напомнить, что XML-файл – это документ, предназначенный для хранения структурированных данных, а также для обмена информацией между программами. Вначале, вы можете экспортировать существующие задания в XML-файлы, анализировать структуру полученных файлов и, немного видоизменив их, создавать свои конфигурационные XML. Экспортировать задание в XML-файл вы можете как при помощи графического интерфейса, так и средствами командной строки. Для экспорта при помощи GUI вам нужно открыть оснастку «Планировщик заданий», выделить экспортируемое задание, а затем из его контекстного меню или при помощи ссылки на панели действий выбрать команду «Экспортировать». Если вы хотите экспортировать задание средствами командной строки, воспользуйтесь командой /Query с параметром /XML, которая была подробно описана в первой части данного цикла.
Следующий листинг представляет собой конфигурационный XML-файл предустановленного задания обработчика очереди отчетов об ошибках, который расположен в узле «Библиотека планировщика заданий\Microsoft\Windows\Windows Error Reporting»:
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.3" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<Source>Отчеты об ошибках</Source>
<Author>Microsoft Corporation</Author>
<Version>1.0</Version>
<Description>Задача отчетов об ошибках обрабатывает очередь отчетов.</Description>
<URI>\Microsoft\Windows\Windows Error Reporting\QueueReporting</URI>
<SecurityDescriptor>D:(A;;FA;;;BA)(A;;FA;;;SY)(A;;FRFX;;;WD)</SecurityDescriptor>
</RegistrationInfo>
<Triggers>
<LogonTrigger>
<Enabled>true</Enabled>
<Delay>PT13M</Delay>
</LogonTrigger>
</Triggers>
<Principals>
<Principal id="AllUsers">
<GroupId>S-1-5-32-545</GroupId>
<RunLevel>LeastPrivilege</RunLevel>
</Principal>
</Principals>
<Settings>
<MultipleInstancesPolicy>Parallel</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
<AllowHardTerminate>true</AllowHardTerminate>
<StartWhenAvailable>true</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
<IdleSettings>
<StopOnIdleEnd>false</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
<UseUnifiedSchedulingEngine>true</UseUnifiedSchedulingEngine>
<WakeToRun>false</WakeToRun>
<ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
<Priority>5</Priority>
</Settings>
<Actions Context="AllUsers">
<Exec>
<Command>%windir%\system32\wermgr.exe</Command>
<Arguments>-queuereporting</Arguments>
</Exec>
</Actions>
</Task>
Для лучшего понимания структуры этих конфигурационных файлов, в следующих подразделах рассмотрим подробно каждый из его элементов. RegistrationInfoДанный элемент содержит административные сведения о времени создания задания, ее описание, информацию об авторе и прочее. Для этого элемента доступны следующие дочерние элементы: Author. При помощи этого элемента вы можете указать автора задания. Сведения об авторе необходимо указать следующим образом: <Author>%имя_автора%</Author>;
Date. Этот элемент предназначен для указания даты и времени создания задания. Для добавления элемента даты добавьте следующую строку: <Date>2010-05-15T13:58:27.1732266</Date>;
Description. Используя этот элемент, вы можете указать подробное описание создаваемого задания. Длина строки, указанной в данном элементе может быть произвольной. В этом примере этот элемент выглядит так: <Description>Задача отчетов об ошибках обрабатывает очередь отчетов.</Description>;
Documentation. Данный параметр определяет дополнительную информацию о назначенном задании. SecurityDescriptor. При помощи этого параметра вы можете указать дескриптор безопасности для создаваемого вами задания. Выглядит эта строка примерно так: <SecurityDescriptor>D:(A;;FA;;;BA)(A;;FA;;;SY)(A;;FRFX;;;WD)</SecurityDescriptor>;
Source. В этом элементе вы можете указать источник возникновения задания, такой как определенный системный компонент, службу, приложение или пользователя. При указании данного элемента, значением может быть текст, который будет получен из библиотеки DLL. Синтаксис строки: $ (@ [Dll], [ResourceID]), где [Dll] путь к библиотеке DLL файл, которая содержит определенные ресурсы, [ResourceID] – идентификатор ресурса. Пример: <Source>$ (@% SystemRoot% \ System32 \ ResourceName.dll, -101)</Source>;
URI. Этот элемент определяет унифицированный идентификатор ресурса, что представляет собой последовательность символов, идентифицирующую физический ресурс. То есть элемент используется для указания расположения, где зарегистрированная задача находится в иерархии узлов задач. В данном примере, этот элемент будет выглядеть следующим образом: <URI>\Microsoft\Windows\Windows Error Reporting\QueueReporting</URI>;
Version. Используя этот параметр, вы можете указать версию созданной задачи, например: <Version>1.0.1.5</Version>.
TriggersКак я уже писал в одной из статей этого цикла, триггер - это набор условий, при выполнении которых запускается задание. Триггеры могут быть основанные на времени и запускают задание однократно в определенное время суток либо ежедневно, еженедельно или ежемесячно, или основанные на событиях, которые запускают задание при возникновении определенных системных событий. Как вам известно, для указания расписания задания, вы можете выбрать один из десяти существующих триггеров. При создании конфигурационного XML-файла, вы можете указать один из семи элементов, который определяет тип триггера для вашего задания.
Рис. 2. Триггеры, которые определяют условие выполнения задания BootTrigger. Указав этот элемент в конфигурационном файле, вы определяете задания, тип запуска которого назначен при старте операционной системы. Непосредственно для данного элемента вы не можете указать никаких значений, так как все значения указываются во вложенных дочерних элементах: - Delay. Используя этот элемент, вы можете указать, через какое время после запуска операционной системы должно запуститься ваше задание. Синтаксис значения для данного элемента должен выглядеть следующим образом: PnYnMnDTnHnMnS, где nY – это количество лет, которые должны пройти после запуска операционной системы до запуска вашего задания, nM – количество месяцев, а значение nD, соответственно – это количество дней до запуска задания. Следующие значения после разделителя T позволяют вам указать время, через которое должно быть запущено ваше задание. Значение nH позволяет указать количество часов, которые должны пройти до запуска задания, nM – количество минут и nS, соответственно – это количество секунд, которые должны пройти после запуска ОС до старта вашего задания;
- Enabled. Этот элемент указывает на то, что триггер будет активирован. Значениями для данного элемента могут быть true или false, что, соответственно, указывает на то, что триггер будет активирован или отключен;
- EndBoundary. Данный элемент отвечает за срок действия вашего задания. По истечении указанного вами срока задание больше не будет запускаться. Значением этого элемента должна быть дата и разделитель T, который указывает на время окончания действия задания. Пример использования:
<EndBoundary>2011-05-14T19:06:03.4579219Z</EndBoundary>;
- ExecutionTimeLimit. Указав этот элемент, вы определяете дату и время, через которое ваше задание должно прекратить свою работу. Значение данного элемента ничем не отличается от значения элемента Delay. Пример:
<ExecutionTimeLimit>P3D</ExecutionTimeLimit>;
- Repetition. Это элемент, определяющий частоту повторения вашего задания, значениями которого являются дочерние элементы, такие как:
- Interval. Этот элемент отвечает за интервал, через который должно повторяться ваше задание. Синтаксис для интервала идентичен синтаксису элемента ExecutionTimeLimit, например:
<Interval>PT1H</Interval>;
- Duration. Указав данный элемент, вы определяете частоту повторения вашего задания. Значение абсолютно идентично со значением элемента Interval, то есть:
<Duration>P1D</Duration>;
- StopAtDurationEnd. Этот параметр отвечает за полную остановку вашей задачи по истечении повторов. Значениями данного элемента могут выступать true или false, что, соответственно, отвечает за активацию или деактивацию функции отключения задания. Например,
<StopAtDurationEnd>true</StopAtDurationEnd>;
- StartBoundary. Текущий элемент отвечает за дату и время активации вашего задания. Синтаксис этого элемента полностью совпадает с синтаксисом элемента EndBoundary. То есть, для запуска задания 14-го мая 2010 года в 22:35:54, вам нужно указать следующее значение:
<StartBoundary>2010-05-14T19:35:54.6356562Z</StartBoundary>.
Пример использования данного элемента: <Triggers>
<BootTrigger>
<Repetition>
<Interval>PT1H</Interval>
<Duration>P1D</Duration>
<StopAtDurationEnd>true</StopAtDurationEnd>
</Repetition>
<StartBoundary>2010-05-14T20:07:25.5165156Z</StartBoundary>
<EndBoundary>2011-05-14T20:07:25.5165156Z</EndBoundary>
<ExecutionTimeLimit>P3D</ExecutionTimeLimit>
<Enabled>true</Enabled>
<Delay>PT15M</Delay>
</BootTrigger>
</Triggers>
CalendarTrigger. Используя этот тип триггера, вы можете указать точное расписание для запуска вашего задания. Также как и при помощи графического интерфейса или командной строки, в конфигурационном XML-файле при помощи данного типа вы можете указать триггер для ежедневного, еженедельного, ежемесячного задания, а также для запуска задания в определенные дни недели. Для этого элемента помимо дочерних элементов Enabled, EndBoundary, ExecutionTimeLimit, Repetition и StartBoundary, вы можете еще воспользоваться на выбор одним из четырех следующих элементов: - ScheduleByDay. Указав данный элемент, вы можете определить частоту повторов задания в разрезе дней, то есть, назначить повтор заданий как ежедневно, так и до одного раза за 365 дней, причем за интервал повтора будет отвечать дочерний элемент DaysInterval. Пример использования:
<ScheduleByDay>
<DaysInterval>1</DaysInterval>
</ScheduleByDay>
ScheduleByMonth. Этот элемент позволяет вам запускать задание каждый месяц или каждые N месяцев в указанные дни. Дочерними элементами данного элемента являются:- Months. Значением этого элемента должны быть месяцы, в которые будет запускаться ваше задание. Каждый месяц должен быть указан с новой строки как отдельный элемент. Например,
<February />;
- DaysOfMonth. Этот параметр используется для того, чтобы указать точную дату, когда будет запущено задание в указанный вами месяц. Также как и с предыдущим элементом, каждый день должен быть указан как новый элемент с новой строки, например: <Day>5</Day>.
Пример использования: <ScheduleByMonth>
<DaysOfMonth>
<Day>5</Day>
<Day>8</Day>
<Day>15</Day>
<Day>22</Day>
<Day>Last</Day>
</DaysOfMonth>
<Months>
<February />
<April />
<September />
</Months>
</ScheduleByMonth>
ScheduleByMonthDayOfWeek. Этот элемент определяет частоту запуска задания в разрезе месяцев и недель. Помимо элемента Month, который был рассмотрен в предыдущем случае, вы можете использовать следующие элементы:- Weeks. Используя этот элемент, вы можете указать первую, вторую, третью, четвертую или последнюю неделю месяца. Синтаксис для данного элемента будет следующим:
<Week>2</Week>;
- DaysOfWeek. Данный элемент позволяет вам указать день недели, в который будет запущено ваше задание, например:
<Monday />.
Пример использования будет таким: <ScheduleByMonthDayOfWeek>
<Weeks>
<Week>2</Week>
<Week>4</Week>
</Weeks>
<DaysOfWeek>
<Monday />
<Wednesday />
<Friday />
</DaysOfWeek>
<Months>
<February />
<April />
<September />
</Months>
</ScheduleByMonthDayOfWeek>
ScheduleByWeek. Используя этот элемент, вы можете определить запуск задания каждую неделю или каждые N недель в указанные дни. С этим элементом вам нужно использовать следующие дочерние элементы:<ScheduleByWeek>
<DaysOfWeek>
<Sunday />
<Tuesday />
<Friday />
</DaysOfWeek>
<WeeksInterval>2</WeeksInterval>
</ScheduleByWeek>
Пример использования данного триггера: <Triggers>
<CalendarTrigger>
<Repetition>
<Interval>PT1H</Interval>
<Duration>P1D</Duration>
<StopAtDurationEnd>true</StopAtDurationEnd>
</Repetition>
<StartBoundary>2010-05-15T11:36:10.6686562</StartBoundary>
<EndBoundary>2011-05-15T08:36:12.7282265Z</EndBoundary>
<ExecutionTimeLimit>P3D</ExecutionTimeLimit>
<Enabled>true</Enabled>
<RandomDelay>PT1M</RandomDelay>
<ScheduleByMonthDayOfWeek>
<Weeks>
<Week>2</Week>
<Week>Last</Week>
</Weeks>
<DaysOfWeek>
<Sunday />
<Wednesday />
<Friday />
</DaysOfWeek>
<Months>
<February />
<April />
<September />
</Months>
</ScheduleByMonthDayOfWeek>
</CalendarTrigger>
</Triggers>
EventTrigger. Данный тип триггера указывается для создания событийно-управляемого задания, о котором было рассказано в предыдущей статье этого цикла. Наряду с этим элементом, вы можете указывать такие дочерние элементы, как Delay, Enabled, EndBoundary, ExecutionTimeLimit, Repetition и StartBoundary, которые были подробно рассмотрены выше. Самым основным элементом, для определения событий, при регистрации которых должно запускаться ваше задание является элемент Subscription. При помощи этого элемента, вы можете создать XPath-запрос для извлечения сведений о событиях из определенного журнала. Синтаксис этого запроса следующий:
<QueryList>
<Query Id='0' Path=”Application”>
<Select Path= Application >*[System[Provider[@Name='Application'] and EventID=1024]]</Select>
</Query>
</QueryList>
XPath-запрос должен быть указан внутри элемента QueryList. Во вложенном элементе Query вы можете указать журнал, а сама строка запроса должна быть расположена между тегами <Select> и </Select>. Если при экспорте ваш запрос будет выглядеть как одна строка – не стоит волноваться, запрос будет обработан правильно. Например:
<Subscription><QueryList><Query Id="0" Path="Application"><Select Path="Application">*[System[Provider[@Name='Power' or @Name='Microsoft-Windows-Program-Compatibility-Assistant' or @Name='Microsoft-Windows-ReadyBoost' or @Name='Microsoft-Windows-Search'] and (Level=1 or Level=2) and (EventID=1015) and TimeCreated[timediff(@SystemTime) <= 604800000]]]</Select><Select Path="System">*[System[Provider[@Name='Power' or @Name='Microsoft-Windows-Program-Compatibility-Assistant' or @Name='Microsoft-Windows-ReadyBoost' or @Name='Microsoft-Windows-Search'] and (Level=1 or Level=2) and (EventID=1015) and TimeCreated[timediff(@SystemTime) <= 604800000]]]</Select></Query></QueryList></Subscription>
IdleTrigger. Этот триггер используется для создания задания, которое запускается при простое вашей операционной системы в течение заданного периода. Для этого типа триггера не существует никаких дополнительных элементов, а воспользоваться вы сможете только следующими дочерними элементами: Enabled, EndBoundary, ExecutionTimeLimit, Repetition и StartBoundary. Пример использования: <Triggers>
<IdleTrigger>
<Repetition>
<Interval>PT1H</Interval>
<Duration>P1D</Duration>
<StopAtDurationEnd>true</StopAtDurationEnd>
</Repetition>
<StartBoundary>2010-05-15T07:19:11.1471718Z</StartBoundary>
<EndBoundary>2011-05-15T07:19:11.1471718Z</EndBoundary>
<ExecutionTimeLimit>P3D</ExecutionTimeLimit>
<Enabled>true</Enabled>
</IdleTrigger>
</Triggers>
LogonTrigger. Указав этот тип триггера, задание будет выполнено при входе всех или определенного пользователя в систему. Помимо основных элементов Delay, Enabled, EndBoundary, ExecutionTimeLimit, Repetition и StartBoundary, которые уже были рассмотрены, вам также необходимо будет указать идентификатор пользователя, под учетной записью которого должно выполняться ваше задание. Этот идентификатор указывается при помощи элемента UserId в следующем формате: <UserId>VirtDImaNs\VirtDImaN</UserId>. Если вам нужно выполнять задание при входе в систему любого пользователя, то данный элемент указывать не обязательно. Пример использования:
<Triggers>
<LogonTrigger>
<StartBoundary>2010-05-15T07:36:42.9362343Z</StartBoundary>
<EndBoundary>2011-05-15T07:36:42.9362343Z</EndBoundary>
<ExecutionTimeLimit>PT4H</ExecutionTimeLimit>
<Enabled>true</Enabled>
<UserId>VirtDImaNs\VirtDImaN</UserId>
<Delay>PT1M</Delay>
</LogonTrigger>
</Triggers>
RegistrationTrigger. Этот тип триггера вы можете указать для заданий, которые должны запускаться при создании и изменении других заданий. Для данного триггера нет элементов, которые еще не рассматривались, а оперировать вы можете шестью основными дочерними элементами. Пример использования: <Triggers>
<RegistrationTrigger>
<StartBoundary>2010-05-15T10:45:37.7067421</StartBoundary>
<ExecutionTimeLimit>PT1H</ExecutionTimeLimit>
<Enabled>true</Enabled>
<Delay>PT30S</Delay>
</RegistrationTrigger>
</Triggers>
SessionStateChangeTrigger. Вы можете применить этот тип триггера, если вам нужно создать задание, которое будет выполняться при подключении к пользовательскому сеансу, при отключении от пользовательского сеанса, при блокировании или разблокировании рабочей станции. Помимо уже известных вам дочерних элементов Delay, Enabled, EndBoundary, ExecutionTimeLimit, Repetition, StartBoundary и UserId доступен еще следующий элемент: - StateChange. При помощи этого элементы вы можете указать подключение с локального или с удаленного компьютера. Синтаксис для данного элемента будет следующим: <StateChange>RemoteConnect</StateChange>. Значениями для этого параметра могут быть ConsoleConnect или RevoteConnect для подключения к пользовательскому сеансу, а также ConsoleDisconnect или RemoteDisconnect для отключения от пользовательского сеанса. Также вы можете указать значение SessionLock для выполнения задания при блокировке рабочей станции или SessionUnlock, которое предназначено для выполнения задания при разблокировании рабочей станции;
Пример использования данного типа триггера: </RegistrationInfo>
<Triggers>
<SessionStateChangeTrigger>
<Repetition>
<Interval>PT30M</Interval>
<Duration>P1D</Duration>
<StopAtDurationEnd>true</StopAtDurationEnd>
</Repetition>
<StartBoundary>2010-05-15T11:19:08.1598671</StartBoundary>
<EndBoundary>2011-05-15T11:19:08.1598671</EndBoundary>
<ExecutionTimeLimit>P3D</ExecutionTimeLimit>
<Enabled>true</Enabled>
<StateChange>ConsoleDisconnect</StateChange>
<UserId>VirtDImaNs\VirtDImaN</UserId>
<Delay>PT1M</Delay>
</SessionStateChangeTrigger>
</Triggers>
TimeTrigger. Если вам нужно запустить какое-либо задание только один раз, то вы можете воспользоваться этим типом триггера. Как и для всех предыдущих типов триггеров, вы можете использовать такие дочерние элементы, как Enabled, EndBoundary, ExecutionTimeLimit, Repetition, StartBoundary, а также элемент RandomDelay, который по синтаксису абсолютно идентичен параметру Delay за исключение того, что этот элемент используется для произвольной задержки. Пример использования данного триггера: <Triggers>
<TimeTrigger>
<Repetition>
<Interval>PT1H</Interval>
<StopAtDurationEnd>false</StopAtDurationEnd>
</Repetition>
<StartBoundary>2010-05-15T10:51:00.9372109</StartBoundary>
<EndBoundary>2011-05-15T07:51:35.1413125Z</EndBoundary>
<ExecutionTimeLimit>P3D</ExecutionTimeLimit>
<Enabled>true</Enabled>
<RandomDelay>PT30M</RandomDelay>
</TimeTrigger>
</Triggers>
Продолжение следует.
Автор: Дмитрий Буланов • Иcточник: dimanb.spaces.live.com
|
|