поиска на warning.dp.ua
  

 

10 программ дистанционного управления из Microsoft Windows Resource Kit

Даррен Мар-Элиа

 

Я нисколько не сомневаюсь, что все системные администраторы – и особенно те, чьему попечению доверены сотни и тысячи удаленных систем, в своей повседневной работе постоянно обращаются к служебным программам из Microsoft Windows 2000 Server Resource Kit или Microsoft Windows NT Server 4.0 Resource Kit. Обо всем многообразии представленных в этих пакетах полезных средств администрирования в одной статье рассказать невозможно, поэтому я отобрала 10 инструментов, которыми пользуюсь чаще всего, – пять для среды Windows 2000 и пять для Windows NT 4.0.

К помощи этих утилит я прибегаю постоянно в процессе управления своей сетью, включающей как Windows 2000, так и NT-системы. Я покажу, как применяется каждая из программ, имея при этом в виду использование Microsoft Windows 2000 Server Resource Kit Supplement One и Microsoft Windows NT Server 4.0 Resource Kit Supplement 4; впрочем, почти все описываемые программы входят в состав базовых версий данных пакетов.

И еще одно замечание перед тем, как мы перейдем к образу инструментальных средств: отдельные компоненты комплекта Windows 2000 Server были существенно переработаны. Часть из этих новых средств функционирует только в среде Windows 2000, а часть с таким же успехом выполняется под NT 4.0. Кстати, ни одно из описанных в данной статье средств Windows 2000 не работает под NT, хотя, повторяю, другие утилиты Windows 2000 могут функционировать и там. Иначе говоря, если кому-то приглянется еще какое-либо средство из комплекта ресурсов Windows 2000 и захочется использовать его в системе NT, обязательно нужно проверить это средство на обратную совместимость. Возможно, оно окажется универсальным.

Пять утилит для Windows 2000

Некоторые из представленных ниже программ обеспечивают управление такими новыми средствами Windows 2000, как Windows Installer и Group Policy. Не во всех инструментах комплекта ресурсов Windows 2000 возможность выполнения той или иной функции на удаленных машинах реализована в явном виде. Однако существует целый ряд приемов, которые позволяют задействовать локальные утилиты в качестве дистанционных. Например, с помощью таких средств, как Rcmd и Rconsole, можно устанавливать на системах Windows 2000 оболочку для удаленного управления системой. Установив такую оболочку, администратор получает возможность передать копию утилиты на удаленную машину и запускать ее дистанционно.

1. Addiag. Утилита Addiag.exe представляет собой многофункциональное средство диагностики, предоставляющее информацию о приложениях рабочей станции или сервера, установленных с применением технологии Windows Installer. Кроме того, с помощью Addiag.exe администратор определяет, является ли текущий сеанс работы сеансом Server Terminal Services. В зависимости от заданных параметров Addiag может предоставлять информацию, группируя ее по пользователям или по машинам. Кроме того, программа сообщает администратору о записях журнала регистрации событий, относящихся к работе службы установки ПО для данной групповой политики. Поскольку работать с групповыми политиками сложно, утилита Addiag представляет собой бесценное средство мониторинга состояния рабочей станции, к которой применяются заданные администратором политики установки программного обеспечения.

Команда

addiag /verbose:true /user:false
/test:«Info,ServerApps,ADHistory,
MSILinks, EventDump,Check»

создает журнальный файл для рабочей станции из домена Windows 2000 и выполняет настройку программ в соответствии с заданной групповой политикой. Ключ /verbose:true означает, что требуется подробный отчет. Ключ /user:false предписывает системе применять политику к машине, а не к пользователю. Применение ключа /test требует наличия строки, состоящей из разделенных запятыми ключевых слов, которые обозначают набор тестов. Тест Info собирает информацию общего характера, такую, как имя рабочей станции, на которой выполняется команда, а также имя и идентификатор SID зарегистрированного пользователя. В результате выполнения теста ServerApps администратор получает список прикладных программ, установленных с использованием групповой политики. В ходе ADHistory система выполняет опрос реестра для выявления номера версии последнего из примененных к данной машине объектов Group Policy Object (GPO). Тест MSILinks производит опрос оболочки Windows Explorer и выясняет, сопровождалась ли установка ПО размещением ярлыков на рабочем столе, а если да, то каких именно. Тест EventDump отбирает все относящиеся к программным средствам регистрационные записи журнала приложений, а тест Check определяет, содержит ли установленное на локальной рабочей станции ПО все указанные GPO компоненты.

В тех случаях, когда запрашивается большое количество данных (и особенно если выполняется тест Event-Dump, а в журнале регистрации содержится множество записей, относящихся к установке программных компонентов), утилита Addiag.exe выполняется медленно. Полученные данные я рекомендую сохранять в отдельных файлах, иначе можно упустить из виду какую-нибудь запись.

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

addiag /trace: MSIIOn

предписывает системе выполнять подробные регистрационные записи в файлы msinnnn.log. Прикладная программа Windows Installer генерирует эти регистрационные файлы в папке \%temp% в тех случаях, когда с ее помощью в системе устанавливается новое приложение. А для того, чтобы в регистрационном журнале приложений генерировались подробные записи об установке ПО, нужно ввести команду

addiag /trace:AppMgmtOn

Правда, для выполнения этой команды требуется проделать некоторую подготовительную работу. На машине, где она будет выполняться, следует создать раздел реестра HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\ Windows NT\CurrentVersion\Diagnostics.

2. Gpresult. Утилита Gpresult.exe тоже связана с Group Policy. Эту служебную программу можно назвать версией Resultant Set of Policies (RSoP) «для бедных»: как и RSoP, она показывает, какие групповые политики применяются для пользователя, зарегистрировавшегося на машине, на которой выполняется команда. Кроме того, Gpresult извещает администратора о том, какие узлы функциональности объекта GPO (скажем, защита данных, установка ПО, административные шаблоны) выполняются на данном компьютере. В режиме отображения подробных сообщений утилита представляет дополнительные данные: например, сведения о том, какие записи реестра модифицирует та или иная политика использования административных шаблонов, а также о том, развертывание каких приложений предусматривает та или иная политика установки ПО.

Для запуска команды достаточно ввести в командной строке ее имя

gpresult

Если добавить к имени ключ /v, команда будет выполняться в режиме verbose с отображением подробных сообщений; с ключом /s она переходит в режим superverbose, т. е. предоставляет пользователю максимально возможный объем данных. По умолчанию при отображении сведений, касающихся GPO, утилита Gpresult.exe группирует их либо по пользователям, либо по компьютерам. Если использовать команду с ключом /u, будет выводиться информация, связанная с пользователем, с ключом /c – с компьютером. На Экране 1 показано, как выглядят данные, отображаемые утилитой Gpresult.exe. Кстати, следует иметь в виду, что при перечислении групп, к которым принадлежит выполняющий команду пользователь, утилита Gpresult указывает группы только того домена, в котором выполняется команда. Членство пользователя в группах за пределами локального домена программа не отражает – даже в тех случаях, когда это может повлиять на обработку данных GPO.

Экран 1. Информация о примененных к пользователю GPO в Windows 2000.

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

Inuse.exe вызывается следующим образом:
Inuse   /y

Ключ /y подавляет вывод программой Inuse.exe каких-либо запросов на подтверждение. Обратите внимание на такую особенность: хотя фактически замена файлов осуществляется только в ходе последующей загрузки системы, утилита Inuse регистрирует операцию замены сразу, изменяя значение в параметре реестра HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\ Control\SessionManager\Pending-File RenameOperations. При этом нужно отметить, что Inuse не вступает в конфликт со средством защиты файлов Windows File Protection (WFP) и не осуществляет замены созданных Microsoft системных файлов Windows 2000, защищенных механизмом WFP.

4. Moveuser. При перемещении учетных записей пользователей в новый домен могут возникнуть трудности, связанные с параллельным перемещением профилей пользователей; особенно это касается тех случаев, когда речь идет о перемещении учетных записей в филиалах для нескольких компьютеров, на которых профиль пользователя кэшируется. Профиль пользователя Windows 2000 связан с идентификатором SID пользователя или группы. Когда администратор создает для пользователя новую учетную запись в другом домене, идентификатор SID последнего изменяется, и этот пользователь теряет доступ к своему профилю. Но с помощью входящей в комплект ресурсов утилиты Moveuser.exe проблема решается просто. Данная утилита изменяет зафиксированные права доступа на файл профиля ntuser.dat и тем самым обеспечивает возможность работы с ним под новой учетной записью.

Синтаксис команды Moveuser таков:

moveuser  
 /c 

Программа Moveuser.exe предписывает системе установить соответствие между первоначальным профилем пользователя, который кэширован на рабочей станции workstationA, и его новой учетной записью, созданной администратором в новом домене. Понятно, что сначала нужно создать новую учетную запись и лишь затем выполнять команду Moveuser. При желании администратор может отступить от традиционной схемы domain\user и воспользоваться именем в формате user principal name (UPN), т. е. сформировать запись типа user@mydomain.tld.

В фоновом режиме Moveuser модифицирует раздел реестра HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Windows NT\ CurrentVersion\ProfileList. В результате изменяется идентификатор SID, ассоциированный со старым профилем пользователя, и открывается возможность доступа к новому профилю пользователя из новой учетной записи. Ключ /c позволяет применить команду к удаленной машине. Кроме того, утилита модифицирует права доступа на ntuser.dat для обеспечения доступа нового пользователя к текущему профилю пользователя. Иными словами, когда этот пользователь регистрируется на рабочей станции work-stationA с новой учетной записью, он получает профиль, идентичный тому, который был у него в старом домене.

Наряду с этим программа Moveuser.exe может перемещать профиль локальной учетной записи пользователя (т. е. записи, сделанной не в домене, а на одной из рабочих станций или в базе SAM одиночного сервера). При выполнении этой операции необходимо использовать ключ /k, который блокирует удаление локальной учетной записи после перемещения соответствующего профиля. Утилита Moveuser сопоставима с другой служебной программой – User State Migration Tool (USMT), однако нужно иметь в виду, что эти утилиты предназначены для разных задач. Программа USMT позволяет сохранять относящиеся к пользователю и компьютеру разделы реестра и восстанавливать их в ситуациях, когда пользователь переходит на новую машину и получает новый профиль.

5. Rpcdump. Чтобы определить, подключен ли к сети тот или иной сервер либо рабочая станция, многие администраторы применяют тестирование с использованием команды ping. Такой метод тестирования прекрасно подходит для выполнения базовых диагностических процедур (скажем, для поиска соединений и для замеров задержек при обмене информацией по сети), но его применение сопряжено с рядом ограничений. Механизм работы ping основан на использовании протокола Internet Control Message Protocol (ICMP). Он позволяет выяснить, готово ли к работе то или иное сетевое устройство, но не дает возможности судить о том, установлена ли на этом устройстве определенная служба и работает ли она в данный момент. Наконец, при тестировании с помощью ping возможна еще одна проблема – в том случае, когда тестируемое устройство находится под прикрытием средств сетевой защиты, ибо многие средства защиты блокируют передачу пакетов ICMP. Допустим, ответ на запрос не поступил. Почему? Из-за блокады трафика со стороны брандмауэра? Или из-за неполадок в удаленном устройстве? К сожалению, эти вопросы остаются без ответа.

Утилита Rpcdump позволяет администратору опрашивать интересующие его устройства и определять, готовы ли они к «общению» средствами указанного протокола, причем опрос выполняется с помощью этого же протокола. Данная программа неоценима в ситуациях, когда приходится выяснять причины неисправности удаленных систем, которые перестали реагировать на запросы. Утилита предусматривает использование как низкоуровневых сетевых протоколов, таких, как TCP, UDP, IPX и SPX, так и протоколов более высокого сеансового и прикладного уровней – NetBIOS over TCP/IP (NetBT), Net-BEUI, Microsoft Message Queue Services (MSMQ), а также именованных каналов (named pipes). С помощью программы Rpcdump можно определить, через какие порты удаленный сервер готов принимать сигналы и какие порты обеспечивают прохождение трафика сквозь средства сетевой защиты.

В команде

rpcdump /s servera /v /i

ключ /s используется для указания имени удаленного сервера (в данном случае это имя «servera»), который мы собираемся тестировать. Ключ /v предписывает системе выдавать полные ответы, а ключ /i будет воспринят программой Rpcdump как требование опросить все конечные точки (т. е. службы), имеющиеся на устройстве servera. Иначе говоря, применение ключа /i приведет к тому, что утилита проверит все порты устройства servera и сообщит администратору обо всех портах, прослушиваемых сервером.

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

rpcdump /s servera /v /p ncacn_np

запрашивает сервер о наличии конечных точек, готовых к приему сообщений по именованным каналам. В данном примере вместо ключа /i используется ключ /p, который воспринимается утилитой как требование проверить только указанную конечную точку. За ключом /p следует выражение nccacn_np – это имя протокола именованных каналов.

Ключ /p означает, что запрос будет касаться только одного протокола. Если этот протокол не установлен на целевом устройстве, утилита Rpcdump выведет сообщение об ошибке «ERROR: RrpcNetworrkIsProtseqValid: (Tthe RPC protocol sequence is not supported)». Если же протокол установлен, но не инициализирован на данном стандартном порте, команда выполняется успешно, но не возвращает какой-либо информации о конечной точке. Рассматриваемая программа может опрашивать как системы NT 4.0, так и компьютеры с Windows 2000.

Пять утилит для Windows NT 4.0

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

1. Getsid. Getsid.exe – довольно простая утилита. Она возвращает идентификаторы безопасности SID двух указанных администратором учетных записей пользователей и сообщает, идентичны ли они. Getsid выполняется как на локальных, так и на удаленных машинах и очень помогает в тех случаях, когда требуется сопоставить идентификаторы SID на локальной и удаленной машинах.

При выполнении программы Getsid нужно указать имена двух учетных записей. Если нужно установить идентификатор SID только для одной учетной записи, проще всего – дважды указать одно и то же имя. Синтаксис для запуска команды Getsid таков:

getsid \\  
\\ 

Я обычно использую утилиту Getsid для того, чтобы определить, обладает ли уникальным идентификатором SID рабочая станция NT 4.0, к которой применяется пакет клонирования дисков (скажем, Ghost фирмы Symantec или Drive Image компании PowerQuest). Здесь уместно напомнить, как в системе NT 4.0 создаются идентификаторы SID для учетных записей пользователей. Система попросту конкатенирует SID машины и относительный идентификатор Relative Identifier (RID). К примеру, в SID-идентификаторе S-1-5-21-971243749-1317886497-1329147602-500 все знаки, за исключением последней группы цифр (500), – это SID машины. А последняя группа цифр – это RID, и надо сказать, что «500» – это широко известный RID-идентификатор; ОС всегда присваивает его учетной записи администратора того или иного устройства. Когда SID-идентификаторы исходной и целевой машин совпадают, все встроенные учетные записи и многие учетные записи, созданные пользователями в клонированной машине, имеют тот же SID, что и соответствующая учетная запись на исходной машине. А поскольку для определения прав доступа к таким ресурсам, как файлы и принтеры, в NT применяются не имена пользователей, а идентификаторы SID, наличие на различных машинах одинаковых идентификаторов SID учетных записей может вызвать серьезные проблемы, связанные с управлением доступом.

Чтобы этого не произошло, поставщики программных средств клонирования разработали специальные утилиты модификации идентификаторов SID, которые, как правило, запускаются после выполнения программы клонирования. Утилита модификации генерирует на машине-клоне уникальный SID-идентификатор. Любопытно, что к числу поставщиков присоединилась и Microsoft: специалисты компании разработали утилиту Sysprep, генерирующую уникальные идентификаторы.

Getsid позволяет администратору убедиться в том, что модификация SID на клонированной рабочей станции выполнена успешно, и полученный идентификатор отличается от того, который был присвоен исходной рабочей станции. Команда

getsid \\workstationa administrator
\\workstationbb administrator

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

Экран 2. Результаты работы утилиты Getsid.

В Windows 2000 реализована концепция администратора доступа (security principal), которому присваивается несколько идентификаторов SID. Однако версия утилиты Getsid, включенная в набор ресурсов Windows 2000, как и версия для NT, возвращает для каждого пользователя только первичный идентификатор SID.

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

Утилита Nltest обращается за информацией к службе Netlogon, которая устанавливается на рабочих станциях и серверах NT. Служба Netlogon отвечает за работу безопасных каналов связи между компьютерами и серверами внутри домена и между контроллерами доменов (domain controllers, DCs) внутри группы доменов, связанных доверительными отношениями. При использовании программы Nltest.exe допускается применение более чем 20 ключей, но я хочу остановиться лишь на нескольких основных.

С помощью Nltest.exe администратор определяет, какой контроллер домена локальная или удаленная рабочая станция (либо сервер) использует для организации безопасного канала связи с доменом. Дело в том, что именно этот контроллер домена применяется для регистрации пользователей, которые входят в систему через данную рабочую станцию. Поэтому информация о нем важна для решения проблем, связанных с регистрацией. А если администратор знает, какой контроллер домена обрабатывает запросы машины на регистрацию, он может ограничить поиски неполадок каналом связи между ней и этим контроллером домена.

Команда, позволяющая определить контроллер домена, ответственный за работу безопасного канала связи «компьютер–домен» формулируется так:

nltest /server: 
/sc_query:

Ключ /server указывает на имя рабочей станции или сервера, который нужно опросить, а параметр /sc_query определяет домен данной рабочей станции или сервера. Таким образом, для выявления контроллера домена, который проверяет аутентичность рабочей станции workstationA в рамках домена NewYork, нужно ввести следующую команду:

nltest /server:workstationA
 /sc_query:NewYork
Экран 3. Результаты работы утилиты Nltest.

На Экране 3 показано, как может выглядеть итоговое сообщение, выводимое системой после выполнения данной команды. Поле Trusted DC Name содержит имя контроллера домена, которое мы хотели получить, и в данном случае это имя NYDCC_5.

Если указать ключ /dcname, программа Nltest возвращает имя основного контроллера домена PDC. Этот ключ бывает полезен в тех случаях, когда администратор работает в незнакомом домене и ему нужно быстро определить, какая система выполняет функции основного контроллера. Конечно, для решения этой задачи можно воспользоваться и другим средством административного управления, а именно инструментом Server Manager, однако в домене, состоящем из множества серверов, главный контроллер домена проще отыскивать именно с помощью программы Nltest. В этом случае команда имеет следующий вид:

nltest /dcname:

где – это имя домена, контроллер PDC которого нужно определить.

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

nltest /server:NYDC_5 /trusted_domains

На Экране 4 показаны образцы команды с использованием ключа /trusted_domains, а также итогового сообщения.

Экран 4. Пример команды и результаты работы Nltest с ключом/trusted_domains.

Служебная программа Nltest включена и в комплект ресурсов Windows 2000. Версия утилиты для нее оснащена дополнительными ключами для работы с доменами Windows 2000, обеспечивающими, помимо прочего, возможность опроса узла Active Directory (AD), к которому принадлежит данная рабочая станция или сервер.

3. Netdom. Утилита Netdom позволяет создавать сценарии, формирующие в домене новые учетные записи рабочих станций или серверов. Разработчики Netdom предусмотрели возможность использования множества ключевых слов, каждое из которых может применяться с несколькими ключами и позволяет выполнять ряд операций. Так, с помощью ключевого слова member администратор может добавлять в базу SAM учетные записи машин и восстанавливать безопасные каналы связи между учетными записями машин домена и базой данных SAM. Используя ключевое слово master, можно устанавливать доверительные отношения между доменами. Без команды Netdom (или какой-либо аналогичной команды) использование сценариев для включения в домен рабочей станции было бы затруднено.

Ниже приводится текст команды, создающей для рабочей станции WS_1 новую учетную запись машины в домене New York:netdom /domain:New-York member \\WS_1 /add

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

Ключ /joindomain после слова member обеспечивает включение машины в домен после того, как создана ее учетная запись. Команда выполняется с любого компьютера домена, но требуется зарегистрироваться в качестве администратора на рабочей станции, которая будет включаться в состав домена. Команда

netdom /domain:NewYork 
/user:NewYork\Administrator /password:
 RE#122 member \\WS_1/joindomain

включает рабочую станцию WS_1 в домен New York. Кроме того, эта команда указывает учетную запись и пароль администратора домена. Эта «верительная грамота» необходима в том случае, если рабочая станция, на которой вводиться команда Netdom, не является частью домена и если на этой станции не выполнялась регистрация с использованием учетной записи администратора домена. При использовании ключа /joindomain на одном из компьютеров домена программа Netdom просто проверяет и восстанавливает его безопасный канал связи.Обычно для того, чтобы установить доверительные отношения между доменами NT 4.0, администраторы запускают инструментальное средство User Manager for Domains дважды: в первый раз для создания записи главного домена (master domain) в домене-ресурсе (resource domain), иначе именуемом доверяющим доменом (trusting domain), и во второй раз – для создания записи домена-ресурса в главном домене. Ключ master утилиты Netdom позволяет объединить эти этапы в рамках одной команды.

Ниже приводится текст команды, которая устанавливает полное одностороннее доверительное отношение, в котором домен NYResource является доверяющим доменом, или доменом-ресурсом, а домен New York – главным доменом:

netdom /domain:NYResource/user
:NYResource\administrator /password
:R44ryt52 master NewYorknewyork
 /trust

Ключ /domain указывает имя домена-ресурса. Ключи /user и /password указывают, соответственно, имя пользователя и пароль администратора в домене-ресурсе. Ключевое слово master предваряет имя основного домена, которому должен доверять домен-ресурс. Первоначальный пароль для создания доверительных отношений следует за именем основного домена. Если его не указать, система NT назначит пароль, применяемый по умолчанию. Наконец, ключ /trust требует создать новое доверительное отношение. Команда будет работать лишь при регистрации с правами администратора главного домена.

Утилита Netdom поставляется и на установочном компакт-диске Windows 2000 вместе с набором средств Support Tools. Правда, в предназначенной для работы под Windows 2000 версии этой программы применяются синтаксические конструкции, отличные от тех, что используются в версии для NT 4.0, но по своим функциональным возможностям эти версии близки.

Экран 5. Использование Sc для просмотра настроек драйвера и службы.

4. Sc. Утилита Sc.exe позволяет направлять запросы к службам NT на локальных и удаленных машинах, а также выполнять с этими службами различные манипуляции. Как правило, в NT настройки служб хранятся в разделе HKEY_ LOCAL_MACHINE\ SYSTEM\Current ControlSet\Services системного реестра. Поскольку NT рассматривает драйверы устройств как своего рода службы, с помощью программы Sc.exe можно также выполнять запросы и менять настройки драйверов устройств. Однако, поскольку драйверы устройств – это процессы, выполняемые в режиме ядра, в случае внесения в конфигурацию драйверов устройств каких-либо необдуманных изменений система может дать сбой. На Экране 5 представлен вариант команды Sc, выполняющей запрос к драйверу Atdisk и службе Browser, а также образец информации, предоставляемой утилитой Sc. Для деактивизации или инициализации служб можно применять следующие синтаксические конструкции:

sc \\workstationA stop browser
sc \\workstationA start browser

Для выполнения таких команд необходимо обладать достаточно широкими полномочиями на рабочей станции workstationA. По умолчанию система NT 4.0 исходит из того, что осуществлять остановку и запуск служб на рабочей станции или сервере может только пользователь с правами администратора.

Ключ config команды Sc открывает перед администратором дополнительные возможности. Допустим, некая служба инициализируется в автоматическом режиме и нужно изменить режим ее запуска на ручной. Для выполнения этой операции можно воспользоваться оснасткой Control Panel Services, но это едва ли удобно, если изменение должно затронуть многие компьютеры сети. В этом случае можно включить команду Sc в сценарий и с легкостью изменить режим запуска службы на любом количестве рабочих станций. Команда

sc \\%1 config browser start= demand

вводит на рабочей станции ручной режим инициализации службы browser. Обратите внимание на то, что в приведенном примере вместо имени рабочей станции используется параметр %1. Эту команду можно вводить в командном файле, который «пройдется» по списку рабочих станций и при каждой итерации будет заменять параметр %1 именем соответствующей рабочей станции. Данная команда указывает утилите Sc.exe, какую именно службу следует настраивать (в данном случае это служба browser) и устанавливает значение режима запуска как demand, т. е. ручной запуск. Кстати, если не ввести знак пробела после знака равенства (и перед режимом запуска), команда будет выполняться некорректно.

Как и другие описанные здесь инструменты для среды NT, утилита Sc.exe представлена в комплекте ресурсов для Windows 2000 обновленной версией, которая обеспечивает дополнительные возможности при выполнении запросов и работе со службами.

5. Rmtshare. К программе Rmtshare.exe я обращаюсь всякий раз, когда возникает необходимость создать на локальном или удаленном устройстве разделяемый ресурс. Кто-то, возможно, скажет, что столь немудреную операцию можно с легкостью выполнить средствами пользовательского интерфейса Windows. Но, к сожалению, разработчики системы NT не позаботились об удобном способе решения этой задачи. Возможно, все дело в том, что в ту пору, когда создавалась эта система, была популярна программа File Manager.

Утилита Rmtshare позволяет создавать разделяемые ресурсы на удаленных или локальных машинах. Так, команда

«rmtshare \\sauternes\reskit=g:ntreskit 
/remark:«NT 4.0 Resource Kit» /grant
 everyone:read /grant administrators:
«full control»

создает на машине sauternes разделяемый ресурс reskit. Новый ресурс ссылается на каталог G:\ntreskit данной машины. Ключ /remark указывает на примечание, которое пользователь может увидеть при просмотре списка общедоступных ресурсов сервера (скажем, когда выполняется команда Net View \\sauternes). Ключ /grant я использую для указания прав доступа к разделяемым ресурсам: члены группы Everyone имеют доступ уровня Read, а члены группы локальных администраторов – доступ уровня Full Control.

Другие ключи команды Rmtshare дают возможность устанавливать ограничения на доступ к ресурсу для того или иного пользователя, отменять права доступа и даже удалять разделяемый ресурс. К примеру, с помощью команды Rmtshare можно организовать совместное использование принтеров:

rmtshare \\sauternesBroLaser=
«Brother HL-1040»
/printer /remark:«Brother laser printer»

Эта команда обеспечивает возможность совместного использования лазерного принтера Brother как ресурса с именем BroLaser. Команда содержит имя принтера («Brother HL-1040»), которое следует заключать в кавычки, поскольку в нем есть пробел. Ключ /printer предписывает серверу рассматривать принтер в качестве разделяемого ресурса, а примечание помогает пользователю идентифицировать устройство. К сожалению, программа Rmtshare не входит в комплект ресурсов Windows 2000, однако я убедилась, что ее версия для NT 4.0 прекрасно выполняется и на машинах Windows 2000.

Если выдастся свободная минутка, советую устроиться поудобнее перед рабочей станцией Windows 2000 или NT 4.0 и запускать по очереди все инструментальные средства из соответствующего комплекта ресурсов. Посмотрите, на что способна каждая из этих утилит. Вполне возможно, что какая-нибудь программа наконец-то поможет решить давно надоевшую проблему.

Даррен Мар-Элиа – внештатный редактор журнала Windows NT Magazine. Специалист по архитектуре NT. С ней можно связаться по адресу: dmarelia@earthlink.net.

Постоянный URL статьи: http://www.osp.ru/win2000/2001/04/174787/



Читайте также:

SelectorNews
 

     быстрая навигация по порталу   <СПРАВОЧНИК ПО БЕЗОПАСНОСТИ>
способы выживания личная безопасность корпоративная безопасность безопасность средств связи
дорожная безопасность агентура и сбор информации компьютерная безопасность сексуальная безопасность
 


 



Реклама:

Реклама на портале WARNING.dp.ua

Исходя из безусловного права личности на собственную безопасность всем предоставляется право свободного копирования, распространения
и издания этих материалов, как в полном объеме, так и по частям в любых комбинациях!

KMindex Rambler's Top100