Создание сценария для диагностики компьютеров
Думаю, все согласятся, что было бы неплохо предложить специалистам службы технической поддержки общее решение для получения информации о конфигурации компьютера, включая членство в группах, наличие установленных программ и обновлений, данные о дисковом пространстве, время пребывания системы во включенном состоянии и информацию о случаях появления «голубого экрана». Если предоставить эти сведения специалисту службы поддержки, прежде чем формулировать для него задачу, то он получит полное представление о технических характеристиках системы, что в свою очередь поможет ему быстрее выявить скрытые проблемы. Во многих случаях поиск и устранение неполадок невозможны без присутствия технического специалиста на рабочем месте пользователя. При этом хорошо бы иметь возможность выявлять потенциальные проблемы и решать их до того, как они блокируют всю работу. Однако, насколько мне известно, не существует готового решения в виде универсального программного средства, которое может предоставлять подробный отчет и о конфигурации персонального компьютера, и о правах пользователей. Тем не менее с помощью различных утилит в сценариях командной строки можно создать собственное средство генерации отчетов, содержащих эту информацию. Для тех, кто ранее не занимался созданием подобных программных средств, разработанный мной сценарий DesktopDiag.bat послужит неплохой стартовой площадкой. Отмечу, что данный сценарий обладает двойной функциональностью, поскольку может использоваться и для серверов. Для обеспечения проверки конфигурации серверов, а также при планировании восстановления после аварий и при переносе серверов в виртуальную среду может возникнуть необходимость в подробной информации об установленных на серверах программах, службах и различных параметрах их настройки.
Многие подразделения ИТ ориентируются на использование готовых коммерческих (Commercial Off-the-Shelf (COTS)) продуктов и избегают разработки собственных решений. Однако если говорить о рассматриваемом здесь специализированном решении на базе сценария DesktopDiag.bat, то данный инструмент является достаточно простым для разработки и поддержки и запускается в режиме только сбора данных без внесения каких-либо изменений в конфигурацию. Тем самым исключаются характерные недостатки решений собственной разработки, к которым относятся высокая стоимость разработки и поддержки, а также риск вывести систему из строя в результате применения подобных средств. К преимуществам таких специализированных программных инструментов следует отнести также то, что они отлично адаптируются к конкретной среде, ведь различные организации могут использовать разные информационные инфраструктуры, соответственно их требования к собираемой информации также могут различаться. Располагая подобным инструментом собственной разработки, можно менять формируемые им отчеты, добавляя и удаляя те или иные разделы. Кроме того, при появлении новых версий пакета Resource Kit или каких-либо утилит от независимых компаний, с помощью которых можно получать полезную информацию, можно будет легко интегрировать их в разработанное решение. Еще одним преимуществом такого решения является низкая стоимость. Поскольку большинство утилит, используемых в сценариях, распространяется свободно, соответственно стоимость их объединения в интегрированное решение тоже будет минимальной. И наконец, если планируется в дальнейшем переходить на какой-либо коммерческий программный продукт, опыт эксплуатации решения на базе сценария поможет более точно выработать требования к приобретаемой системе.
Процесс разработки сценария DesktopDiag.bat начался с того, что был сформирован перечень параметров, представляющих интерес. Данный перечень естественным образом можно разделить на две категории: параметры пользователя и параметры компьютера.
Пользовательские параметры (для пользователя, зарегистрировавшегося в системе, или для заданной учетной записи пользователя):
- имя (имена) пользователя (пользователей), регистрирующегося (регистрирующихся) в системе;
- параметры учетной записи пользователя, такие как домен, дружественное имя пользователя, идентификатор;
- пользовательские установки по умолчанию (диск, путь, сценарий регистрации, срок окончания действия учетной записи, время нахождения в системе, срок действия пароля, момент последнего сброса пароля);
- уровень полномочий вошедшего в систему пользователя;
- локальные группы, членом которых является данный пользователь;
- пользовательские профили на компьютере;
- членство пользователя в локальных и глобальных группах.
Параметры компьютера:
- версия операционной системы и пакета обновлений;
- перечень установленных исправлений;
- параметры настройки сети (IP-адрес, MAC-адрес);
- список автоматически загружаемых программ;
- тип и скорость процессора, установленная память;
- результирующий набор политик (Resultant Set of Policies - RSoP);
- размещение в организационном подразделении (OU);
- перечень установленных программ
- перечень служб и их статус;
- перечень каталогов с открытым совместным доступом;
- расширенная информация по логическим дискам (буква, обозначающая диск, объем свободного и занятого пространства);
- сведения о физических дисковых накопителях;
- сведения о видеоадаптере;
- установленные в системе принтеры;
- состав локальных групп компьютера;
- информация о сбоях и времени функционирования системы;
- перечень членов локальной группы администраторов;
- перечень локальных групп, членом которых является данный компьютер.
Какими средствами?
Выбор и последующий поиск утилит, которые будут собирать нужные данные, производится аналогично формированию списка необходимых информационных параметров. Во многих случаях утилита может предоставить больше информации, чем требуется для решаемой задачи. В такой ситуации можно либо сразу организовать фильтрацию выводимых данных, либо сначала собрать всю предоставляемую информацию, а затем выполнить ее сортировку с помощью соответствующих утилит. Недостаток подхода, связанного с применением большого количества фильтров, заключается в том, что при этом увеличиваются накладные расходы, сложность и время, необходимое для выполнения сценария. К тому же в ряде случаев требуется объединять несколько команд в цепочку. Например, сначала собирается исходная информация (скажем, имя зарегистрировавшегося в системе пользователя), а затем она используется для получения сведений о членстве в группах. Сценарий DesktopDiag.bat задействует фильтрацию в минимальном объеме. Время выполнения данного сценария на локальной машине составляет примерно одну минуту, а при удаленном запуске он выполняется от 1 до 1,5 минуты. Если для сбора аналогичной информации запускать все эти утилиты по отдельности или воспользоваться графическим интерфейсом Windows, то времени потребуется гораздо больше.
Для заполнения отчета данными в сценарии DesktopDiag.bat задействовано 14 внешних утилит и большое количество встроенных команд. Перечень этих утилит приведен в табл. 1. Я также разработал матрицу утилит, которая содержит более подробные сведения об используемых в DesktopDiag.bat командах и утилитах. Данную матрицу и файл DesktopDiag.bat можно загрузить с сайта журнала в разделе загрузки Download. Поскольку на компьютерах, с которых предполагается снимать информацию, далеко не всегда установлен пакет Resource Kit или какие-либо утилиты независимых фирм, я рекомендую разместить все используемые программные средства в общедоступном сетевом каталоге на сервере, после чего указать запускаемому сценарию путь к этому каталогу. При этом следует учитывать, что утилитам свойственны некоторые ограничения. В частности, одна из наиболее информативных программ, Ipconfig, не может быть запущена на удаленной системе. Поэтому для запуска подобных программ в этом режиме необходимо воспользоваться специальной утилитой для удаленного запуска команд, например PsExec от Sysinternals или BeyondExec компании Beyond Logic.
Возможности, реализуемые каким-либо разработанным решением, будут определяться выбранной методикой сбора данных и ограничениями, свойственными используемым программным средствам. Приведу пример. Допустим, создается отчет о конфигурации персонального компьютера и планируется включить в него информацию о пользователе. Что получится, если во время удаленного обращения к компьютеру выяснится, что пользователь вообще не регистрировался в системе? Для работы DesktopDiag.bat я выделил четыре возможных варианта сбора данных, в которых постарался учесть большинство типичных проблемных ситуаций.
- Cбор данных на локальной машине, когда пользователь или администратор осуществил локальную регистрацию в системе.
- Cбор данных на удаленной машине, когда пользователь осуществил локальную регистрацию в системе.
- Cбор данных на удаленной машине от имени принудительно заданной пользовательской учетной записи.
- Cбор данных на удаленной машине, при наличии нескольких зарегистрировавшихся на ней пользователей, как локально, так и через терминальную службу Terminal Services Windows 2000 Server.
Компоновка элементов сценария
После того как был определен набор используемых утилит, следует заняться компоновкой последовательности из соответствующих команд, в результате выполнения которых будет сформирован отчет с необходимыми выходными данными. Обычно сначала я выбираю простейший вариант сценария (который соответствует варианту 1 в приведенном выше списке) и занимаюсь его отладкой. После того как заработает локальная версия сценария, данный код берется за основу для разработки других вариантов сбора данных. Формат базового синтаксиса сценария DesktopDiag.bat приводится ниже. Он включает начальную строку, идущую следом за ней пустую строку, затем следует строка вызова команды или утилиты, за которой вновь идет пустая строка. Двойной символ знака «больше чем» (>>) служит для перенаправления выходных данных в файл в режиме добавления. Если этого файла нет, то он будет создан, если же он существует, то информация будет дописываться в конец файла. Если используется одиночный символ перенаправления (>), то в этом случае вместо существующего файла создается новый с тем же именем; содержимое предыдущего файла при этом теряется.
Для запуска 14 используемых в сценарии утилит и встроенных команд применяется следующий базовый синтаксис:
ECHO ********** Строка заголовка ********** >>"%file%" ECHO.>>"%file%" C:UtilLocToolName.exe >>"%file%" ECHO.>>"%file%"
В листинге 1 показан пример синтаксиса вызова в сценарии программы Gpresult.exe из пакета Windows 2000 Resource Kit.
Если сбор данных выполняется в соответствии со вторым вариантом, то в этом случае сценарий DesktopDiag.bat осуществляет сбор данных с удаленной машины. К счастью, прошло то время, когда большинство команд и программ можно было запускать только в локальном режиме. Наличие встроенной возможности удаленного запуска в таких утилитах, как Srvinfo.exe из пакета Microsoft Windows Server 2003 Resource Kit или PsInfo от Sysinternals, а также появление специальных утилит для запуска программ на удаленных системах (PsExec и BeyondExec) позволили выполнять запросы к удаленным системам, что еще несколько лет назад было невозможно. Исходный код для сбора данных с удаленных систем очень напоминает код локальной версии сценария, за исключением того, что в данном варианте добавлены комментарии N/A для тех команд, которые не могут корректно работать в режиме удаленного запуска. Обратите внимание на точку перехода для удаленного выполнения кода на листинге 2. Если администратор при запуске сценария не задал для него никаких аргументов, то сценарий будет выполняться в локальном режиме. Если был задан единственный аргумент, сценарий осуществит переход по соответствующей метке в раздел удаленного выполнения.
В тех случаях когда сбор данных осуществляется по третьему варианту, обращение к удаленной системе производится от имени некоторой заданной учетной записи вместо той, под которой пользователь локально зарегистрировался на этой системе. При таком варианте запуска сценария после аргумента «имя компьютера» должен быть указан второй аргумент «имя пользователя» в формате <доменидентификатор пользователя>.
Раз уж мы коснулись темы задания аргументов, нужно отметить, что одним из наиболее сложных, но необходимых аспектов технологии написания сценариев является определение корректности вводимых пользователем данных. Это особенно важно в тех случаях, когда разработанное программное средство должно быть передано для дальнейшего использования человеку, который может не иметь ни малейшего представления о сценариях. Если бы я не включил в код DesktopDiag.bat процедуру обработки ошибок, а пользователь запустил бы данный сценарий с некорректными именами компьютера или пользователя (либо указанный компьютер в этот момент был недоступен), то сценарий продолжил бы выполнение с возвратом кода ошибки, а затем сформировал сбивающий с толку пустой отчет.
Итак, возвращаясь к третьему варианту сценария, первым делом следует убедиться, что указанный компьютер существует и доступен. Проверка выполняется при помощи конструкции «If Exist», обозначенной в Листинге 3 меткой A. Если на удаленном компьютере с указанным именем не удается обнаружить общий системный ресурс C$, то сценарий завершает выполнение с сообщением о том, что необходимо проверить правильность ввода имени компьютера или наличие доступа к нему по сети. Фрагмент кода, обозначенный меткой C, проверяет, существует ли учетная запись пользователя. Для этого введенный аргумент сопоставляется с результатами, возвращаемыми утилитой GetUserInfo от Joeware. Если в выходных данных GetUserInfo присутствует «membership» (членство в группах), это говорит о том, что такой пользователь существует и, соответственно, выводится информация о группах, членом которых он является. Если в выходных данных GetUserInfo «membership» отсутствует, сценарий завершает работу и посылает оператору соответствующее сообщение об ошибке. Данная процедура позволяет избежать непроизводительных затрат времени при запуске утилиты с неверно заданными параметрами, при этом нужно еще иметь в виду, что в таких случаях некоторые утилиты выдают неверные результаты.
Вернемся к учетной записи пользователя, заданной в листинге 3 в качестве второго аргумента. Обратите внимание на то место, где сценарий обнаруживает второй аргумент, что обозначено в коде сценария меткой B. Сначала переменная DUres имеет пустое значение, затем ей присваивается значение %2, что соответствует второму аргументу сценария. Конструкция If defined проверяет, имеет ли переменная DUres непустое значение, затем с помощью команды For формируется строка данных, состоящая из названия домена и имени пользователя, которая затем сопоставляется с данными, полученными утилитой GetUserInfo.
Четвертый вариант сбора информации представляет собой тот случай, когда на компьютере локально зарегистрировалось более одного пользователя. Многие, наверное, сразу же подумали: «Как такое вообще может быть?» Между тем это вполне возможно благодаря терминальной службе Terminal Services, с помощью которой на одной машине может локально зарегистрироваться несколько пользователей. А так как сценарий DesktopDiag.bat «не знает», какого именно пользователя администратор имел в виду в «пользовательской» части кода, то это может стать причиной ряда проблем и, соответственно, потребует некоторой доработки со стороны администратора. В частности, можно собрать информацию о членстве в группах по нескольким пользователям с помощью утилиты Findgrp из пакета Windows 2000 Resource Kit в сочетании с командой For. Однако если мы запустим утилиту Gpresult для того, чтобы получить данные о наборе политик RSoP пользователя, зарегистрировавшегося в системе, то результаты, возвращаемые этой программой, будут некорректны, поскольку при каждом запуске она будет формировать запрос для учетной записи того пользователя, который зарегистрировался через данную консоль. Следовательно, сценарий должен уметь определять наличие нескольких локально зарегистрировавшихся пользователей и в этом случае отключать сбор данных о политиках через Gpresult. В листинге 4 приведен вариант команды For, в которой для подсчета количества локально зарегистрированных в системе пользователей применяется переменная usercntr. В листинге 5 показана реализация конструкции If, которая отключает запуск утилиты Gpresult, если было обнаружено, что в системе локально зарегистрировано более одного пользователя (т. е. if %usercntr% GTR 1).
Тестирование и внедрение
Прежде чем учить сотрудников пользоваться сценарием DesktopDiag.bat и внедрять его, логично было бы предварительно провести всестороннее тестирование этого программного средства в рамках информационной инфраструктуры компании. После того как сценарий был сконфигурирован и размещен на разделяемом сетевом ресурсе, можно выполнить пробный запуск в тестовой среде. Не забудьте проверить работу сценария для всех четырех описанных выше вариантов сбора данных. По окончании тестирования можно начинать выборочно использовать данный сценарий таким образом, чтобы было легко наблюдать за результатами и при необходимости вносить изменения. Если созданный сценарий работает безупречно и руководство оказывает соответствующую поддержку, можно приступать к его полномасштабному внедрению в службе поддержки пользователей и среди других технических служб.
Я проверял функционирование сценария DesktopDiag.bat на следующих системах: Windows Server 2003, Windows 2000 Server Service Pack (SP) 3, Windows 2000 Professional SP3 и Windows XP Professional SP1. На примере отчета, показанном в файле WORK1-diag.txt, который в свою очередь входит в состав загружаемого с сайта архива, можно посмотреть, как выглядят данные, получаемые в результате работы DesktopDiag.bat. Ниже приведены пошаговые инструкции для развертывания данного сценария.
1. Загрузите сценарий DesktopDiag.bat.
2. Загрузите или каким-то другим способом получите те 14 утилит, которые сценарий использует в процессе работы. Перечень необходимых утилит и ссылки на адреса, где их можно получить, приведены в табл.1.
3. Разместите утилиты в разделяемом каталоге таким образом, чтобы в названии пути не было пробелов. Задайте пути аналогично приведенному ниже примеру:
Set UtilLoc=SalesDiagUtilities
4. Для запуска сценария на локальной машине используйте следующий синтаксис:
DesktopDiag.bat
без указания аргументов.
5. Если сценарий запускается на удаленной машине, то синтаксис должен выглядеть так:
DesktopDiag.bat <имя компьютера>
например:
C:ScriptsDesktopDiag.bat pc5559000
6. Команда запуска сценария на удаленной системе с принудительным использованием заданных параметров учетной записи должна выглядеть следующим образом:
DesktopDiag.bat <имя компьютера> <доменID пользователя>
Например:
C:ScriptsDesktopDiag.bat pc5559000 sales lewis
7. В результате выполнения сценария его выходные данные будут отображаться в окне Internet Explorer (IE), при условии что IE был установлен в стандартный каталог. В том случае если каталог размещения IE отличается от стандартного или в системе используется другой браузер, нужно будет либо модифицировать код сценария, задав в нем другой браузер, либо просматривать выходные данные с помощью Notepad или Wordpad.
8. Если не изменить соответствующим образом исходный код сценария, то текстовый файл с выходными данными будет сохранен в пользовательском каталоге для временных файлов. Если нужно удалить, переместить или скопировать этот текстовый файл, следует снять комментарии или изменить соответствующие команды удаления, перемещения и копирования. Далее я покажу, как это сделать проще всего.
При запуске DesktopDiag.bat на локальном компьютере большинство параметров конфигурации будет отображаться корректно даже в том случае, если локально зарегистрировавшийся пользователь не обладает административными правами на данной системе. При обращении к удаленному компьютеру наличие прав администратора на этой системе является обязательным условием.
Для отображения результатов диагностики, полученных от DesktopDiag.bat, в распоряжении администратора имеется несколько вариантов. По умолчанию после завершения работы сценария открывается окно IE с полученными выходными данными. Тем не менее, если для просмотра файла отчета обычно используется другой браузер или еще какая-либо программа, то можно модифицировать сценарий таким образом, чтобы файл отчета открывался другим браузером, или, например, программами Notepad или Wordpad. После того как сценарий создаст и отобразит выходной файл, он будет находиться в пользовательском каталоге для временных файлов. Данный файл можно переместить или скопировать в нужное место для дальнейшего хранения и последующего анализа либо удалить его. Чтобы удалить файл сразу же после того, как закроется окно IE, нужно снять комментарий со следующей строки:
rem del «%file%»
Если после закрытия окна IE требуется переместить выходной файл, необходимо снять комментарий со следующей строки:
rem Move «%file%» «servernameshare- name\%computername%-diag.txt»
После того как будет закрыто окно IE, можно скопировать выходной файл в нужный каталог. Это реализуется путем снятия комментария со следующей строки:
rem Copy «%file%» «servernameshare- name\%computername%-diag.txt»
Для того чтобы тиражировать сценарий DesktopDiag.bat, можно воспользоваться любым съемным носителем, будь то USB-накопитель или обычная дискета. Альтернативное решение состоит в том, чтобы разместить файл сценария на каком-либо разделяемом централизованном ресурсе, например в том же сетевом каталоге, где хранятся необходимые утилиты.
Модификация сценария
Одно из основных преимуществ использования решения на базе сценариев состоит в том, что можно в любой момент быстро добавить или удалить из него ту или иную функцию. При этом если сам сценарий будет храниться в общедоступном сетевом каталоге, то его редактирование только в данном месте приведет к тому, что все потенциальные пользователи сценария сразу же получат доступ к его обновленной версии. В том случае если какому-то свежему вирусу или программе-шпиону удастся незаметно проникнуть через защитный барьер, можно использовать сценарий DesktopDiag.bat для поиска сигнатурных файлов или соответствующих установок в реестре. Если потребуется собрать какую-либо дополнительную информацию, просто добавьте в сценарий строки запуска соответствующих команд, придерживаясь базового синтаксиса, который мы рассмотрели выше.
Я полагаю, что сценарий Desktop Diag.bat может стать одной из самых гибких и полезных утилит в арсенале средств диагностики. С его помощью можно за одну-две минуты получить данные о неисправном компьютере, что позволит избежать необходимости присутствия на рабочем месте пользователя технического специалиста или, по крайней мере, поможет сэкономить его время.
Дик Льюис - Старший системный инженер компании Lewis Technology (Риверсайд, шт. Калифорния). Имеет сертификаты MCSE и MCT, специализируется на управлении серверами и рабочими станциями Windows Server 2003, Windows 2000 и Windows NT. dlewis@windowsitpro.com
Листинг 1. Базовый синтакс использования Gpresult.exe
ECHO ********** Resultant Computer Group Policy Summary **********>>»%file%» ECHO.>>»%file%» %UtilLoc%GPRESULT.EXE /C >>»%file%» ECHO.>>»%file%»
Листинг 2. Направления захвата данных с удаленной системы
:StartHere if «%1»==»» GOTO :Local GOTO :Remote
Листинг 3. Проверка существования удаленной системы
:: BEGIN CALLOUT A If Not Exist \%1C$ ECHO PC %1 is either offline or incorrect pc name entered.>>»%file%»&GOTO :jumpover :: END CALLOUT A Set domres= Set userres= :: BEGIN CALLOUT B Set DUres= Set DUres=%2 Set UserOK= For /F «tokens=1,2 delims=» %%i in («%DUres%») do (SET domres=%%i) & (SET userres=%%j) If defined DUres ECHO Note: Script is running using the %DUres% user «Forced» as the logged in user.>>»%file%» :: END CALLOUT B :: BEGIN CALLOUT C If defined DUres For /F «tokens=*» %%i in (?%UtilLoc%GetUserInfo %DUres% ^| Find /I «memberships»?) do Set UserOK=%%i If defined DUres If Not Defined UserOK ECHO There is a problem with the %DUres% user account. Verify domain and used ID and retry.>>»%file%»&GOTO :jumpover :: END CALLOUT C ECHO.>>»%file%»
Листинг 4. Подсчет числа пользователей, зарегистрированных локально
Set usercntr=0 If not defined domres For /F «tokens=1,2,3,4,5 delims= « %%i in (?%UtilLoc%psloggedon.exe -l \%1 ^| find «/»?) do SET /A usercntr+=1 If not defined domres For /F «tokens=1,2,3,4,5 delims= « %%i in (?%UtilLoc%psloggedon.exe -l \%1 ^| find «/»?) do (SET domres=%%l) & (SET userres=%%m) & (Call :GetLOUInfo)
Листинг 5. Отмена запуска Gpresult, если локально зарегистрировано более одного пользователя
If %usercntr% EQU 1 %UtilLoc%GPRESULT.EXE /U >>»%file%» If %usercntr% GTR 1 ECHO Multiple locally logged in users detected — User Group Policy enumeration disabled. >>»%file%»