| Новые программы oszone.net |  |
Введение
Создание задания, используя XML-файлКак в случаях почти со всеми административными приложениями, создавать задания при помощи конфигурационных XML-файлов вы можете при помощи оснастки «Планировщик заданий» и средствами утилиты SchTasks командной строки. Для того чтобы создать задание при помощи оснастки, вам нужно открыть ее, выбрать узел, в котором задача будет расположена, а затем выбрать любое из следующих действий:
Рис. 1. Импорт задания из XML-файла В отобразившемся окне «Открыть» выберите папку, в которой находится созданный заранее 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. Указав этот элемент в конфигурационном файле, вы определяете задания, тип запуска которого назначен при старте операционной системы. Непосредственно для данного элемента вы не можете указать никаких значений, так как все значения указываются во вложенных дочерних элементах:
<EndBoundary>2011-05-14T19:06:03.4579219Z</EndBoundary>; <ExecutionTimeLimit>P3D</ExecutionTimeLimit>; <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> <DaysInterval>1</DaysInterval> </ScheduleByDay>
<February />; Пример использования: <ScheduleByMonth>
<DaysOfMonth>
<Day>5</Day>
<Day>8</Day>
<Day>15</Day>
<Day>22</Day>
<Day>Last</Day>
</DaysOfMonth>
<Months>
<February />
<April />
<September />
</Months>
</ScheduleByMonth>
<Week>2</Week>; <Monday />. Пример использования будет таким: <ScheduleByMonthDayOfWeek>
<Weeks>
<Week>2</Week>
<Week>4</Week>
</Weeks>
<DaysOfWeek>
<Monday />
<Wednesday />
<Friday />
</DaysOfWeek>
<Months>
<February />
<April />
<September />
</Months>
</ScheduleByMonthDayOfWeek>
<Sunday />; <WeeksInterval>2</WeeksInterval>. <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 доступен еще следующий элемент:
Пример использования данного типа триггера: </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>Продолжение следует.
Теги:
Windows 7, Дмитрий Буланов, Schtasks, Планировщик заданий.
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.
|
|
В предшествующих статьях данного цикла вы познакомились с утилитой SchTasks командной строки Windows, предназначенной для создания и управления простыми и усложненными заданиями. Вы уже знаете о том, что задания могут быть назначены для запуска однократно, поминутно, через указанный вами интервал времени, при загрузке системы, при входе пользователя в систему, а также при ее простое. Из предыдущих статей вы могли узнать о способах просмотра назначенных заданий при помощи командной строки – контексте /Query утилиты SchTasks командной строки, а также о различных методах создания разнообразных заданий, используя триггеры и всевозможные параметры. В предыдущей статье были расписаны все способы создания событийно-управляемых заданий (задания, которые запускаются при возникновении указанного вами события в заданном журнале). Все эти знания помогут вам избавиться от рутинной работы, автоматизировав задачи, которые вам приходится регулярно выполнять. Но для того чтобы полностью понять структуру заданий, которые вы периодически создаете, необходимо разобраться со структурой конфигурационных XML-файлов, в которых указываются абсолютно все настройки для создаваемого или существующего задания. О структуре таких файлов и пойдет далее речь в этой статье.
