В последних двух статьях мы изучили некоторые концепции и проблемы, связанные с написанием удаленных сценариев (remote scripting) на платформе Windows. В этой статье я расскажу о двух уловках, связанных с написанием удаленных сценариев с помощью сценариев WMI, написанных на языке VBScript.
Во-первых, как насчет подсказки из Windows Vista Resource Kit? Этот Resource Kit (набор ресурсов) – книга для специалистов по информационным технологиям (IT pros), которые планируют установку операционной системы Windows Vista в корпоративных сетевых средах среднего и большого размера, и мне выпала честь привести автора этой книги в этот проект, поэтому у меня есть разрешение от издательского дома Microsoft Press выложить некоторые выжимки из этой потрясающей книги.
В этом разделе рассказывается о первой подсказке, она достаточно проста, но очень хитра, и нам необходимо кое о чем узнать, прежде чем рассмотреть ее. Я уверен, что теперь вы знаете, что есть несколько способов, которыми вы можете запустить сценарий на выполнение на компьютерах с операционной системой Windows. Например, если у вас на компьютере есть сценарий ChangeIPAddress.vbs, то вы можете запустить его следующим образом:
А что произойдет после того, как вы выполните эти действия, зависит от настроек по умолчанию для Windows Script Host (WSH) на вашем компьютере. WSH – это независимый от языка узел, где располагаются механизмы выполнения сценариев (scripting engines), т.е. WSH использует механизм выполнения сценариев VBScript scripting engine для запуска сценариев, написанных на языке VBScript, которые вы пытаетесь запустить, поэтому WSH работает, как среда, внутри которой вы запускаете ваши сценарии. Но в действительности WSH имеет два узла для сценариев по умолчанию (default script hosts):
Давайте посмотрим на различия между ними в том случае, если вы не совсем все поняли или просто забыли что-то. Я буду использовать для демонстрации сценарий ChangeIPAddress.vbs из второй статьи из этого цикла. Давайте откроем командную строку на компьютере с операционной системой Windows Vista и используем этот сценарий для изменения IP адреса компьютера на 172.16.11.173. Теперь, первое, на что необходимо обратить внимание, это то, что изменение настроек сетевой конфигурации требует прав локального администратора (local admin) на компьютере, поэтому, чтобы сделать это мне нужно щелкнут правой кнопкой мыши на ярлыки командной строки (command prompt) под Accessories и выбрать пункт Run As Administrator (запустить от имени администратора). После это появится окно User Account Control (UAC), поэтому я должен либо нажать на кнопку Continue (если учетная запись моего пользователя состоит в группе локальных администраторов Local Administrator на этом компьютере) или вести логин и пароль для учетной записи локального администратора (если учетная запись моего пользователя явлется лишь членом группы локальных пользователей local Users на компьютере).
В любом случае я получаю командную строку с правами локального администратора, в которой я набираю команду для изменения адреса компьютера (Рисунок 1):
Рисунок 1 Попытка изменения IP адреса с помощью сценария
Теперь, что случиться, когда я нажму на кнопку ENTER. Через несколько секунд появится следующее диалоговое окно (Рисунок 2):
Рисунок 2 Результат выполнения сценария отобразиться в виде диалогового окна
Откуда появилось это сообщение? Насколько все мы помним, наш сценарий ChangeIPAddress.vbs содержал следующие строчки в конце сценария:
'Display result or error code
If errEnableStatic=0 Then
Wscript.Echo "Adapter's IP address has been successfully changed to " & strAddress
Else
Wscript.Echo "Changing the adapter's address was not successful. Error code " & errEnableStatic
End If
Итак, произошло следующее. Предложение Wscript.Echo позволяет отображать вывод в окне (т.е. всплывающие диалоговые окна), вместо отображения результата выполнения сценария в самой командной строке. Причина этого заключается в том, что Wscript.exe по умолчанию является узлом для выполнения сценариев (script host), и все, что из этого вытекает, т.е. отображение результатов выполнения сценариев с помощью всплывающих диалоговых окон вроде этого.
Как мы можем остановить такое поведение и заставить наш сценарий отображать результаты выполнения в командной строке (command prompt)? Единственный способ для этого, это явно вызвать узел для работы с командной строкой command-line script host Cscript.exe, когда вы запускаете сценарий. Вы можете сделать это следующим способом (Рисунок 3):
Рисунок 3 Использование cscript.exe, чтобы результат выполнения сценария отображался в командной строке
Но это очень надоедает, всегда перед названием сценария печать cscript, поэтому вместо этого мы можем сделать Cscript.exe в качестве узла для сценариев по умолчанию (default script host) для всех вызовов WSH с помощью следующих действий (Рисунок 4):
Рисунок 4 Делаем cscript.exe узлом для сценариев по умолчанию (default script host)
Теперь мы можем запустить сценарий и увидеть результаты его выполнения из окна командной строки (command prompt), при этом нам не нужно набирать перед названием сценария cscript (Рисунок 5):
Рисунок 5 Т.к. Cscript.exe является узлом для сценариев по умолчанию (default script host), то результат выполнения сценария отображается в окне командной строки (command prompt)
Вы, вероятней всего, знали все это, но это не беда. Предположим, что у вас есть несколько сценариев ChangeIPAddress.vbs, которые мы хотим удаленно запустить путем установки их на исходные компьютеры в качестве сценариев, запускающихся при входе (login script), или в качестве сценариев, запускающихся при загрузке (startup script), с помощью политики группы Group Policy. И предположим, что некоторые из этих сценариев используют предложения Wscript.Echo для отображения результатов выполнения сценария. Что произойдет, когда один из этих сценариев будет установлен на удаленном компьютере, а затем запуститься на ней? На рабочем столе пользователя появиться несколько всплывающих окон, и пользователю необходимо будет постоянно нажимать на кнопку OK, OK, OK и так далее до тех пор, пока не исчезнут все всплывающие окна и сценарий не закончит свою работу. Вот ведь весело! Существуют ли какой-нибудь способ избежать этого?
Да конечно, можно обойти это двумя способами. Первый заключается в том, что вы можете изменить все ваши сценарии и удалить или закомментировать все предложения Wscript.Echo, чтобы сценарий больше не отображал результаты своего выполнения. Это не очень удобно, особенно если у вас очень много таких сценариев, которые нужно изменить.
А какой же второй способ? Здесь описана вторая подсказка, который я хочу с вами поделиться, с разрешения Windows Vista Resource Kit:
В среде Active Directory, в которой политики группы Group Policy используются для управления компьютерами, вы можете изменить узел сценариев по умолчанию (default script host) с Wscript.exe на Cscript.exe на всех компьютерах в организационной единице OU следующим образом:
Примечание: ChangeToCscript.bat должен быть запущен в качестве сценария, запускающегося при загрузке (Startup script), а не как сценарий, запускающийся при входе (Logon script). Если вы запустите его, как сценарий, запускающийся при входе (Logon script), то сработает лишь в том случае, если пользователи являются локальными администраторами на своих компьютерахs.
Здорово, когда вы можете все это с помощью командного файла (batch file), состоящего из двух строк, не так ли? Теперь вы можете устанавливать любые сценарии на свои компьютеры и не беспокоиться о том, что у пользователей на экране будет появляться огромное множество всплывающих окон.
Вторую подсказку я узнал от одного из моих читателей после того, как он прочитал одну из моих предыдущих статей из этой серии. Мне она показалась очень классной, поэтому спросил у него разрешение поделиться ей с читателями WindowsNetworking.com, на что он ответил согласием. Поэтому я просто процитирую его электронное письмо, в котором он рассказал о своем трюке:
Мой трюк, с помощью которого я запускаю ‘runAs’ (выполнить от имени), не вводя логин и пароль администратора, заключается в том, что я использую учетную запись администратора (local administrator account) для вызовов WMI, а затем сохраняю пароль локального администратора (local admin password) в текстовом файле на сетевом ресурсе (network share), который защищен NTFS. Например, если ‘tech1’,‘tech4’ и ‘tech5’ – это обычные учетные записи в домене (domain accounts, а не администраторы домена или domain admins), но у этих пользователей есть права на запуск WMI сценариев, то я открываю для этих учетных записей разрешения NTFS на доступ к текстовому файлу, в котором содержится пароль для учетной записи локального администратора (local administrator password). Затем я импортирую в сценарий этот пароль и подключаюсь с помощью Set objWMIService = GetObject(«winmgmts:\\» & strComputer & «\root\cimv2», strComputer & «\Administrator», strImportedPassword)
На самом деле все вышесказанное верно не на 100%. Я использую:
Set objSWbemLocator = CreateObject("WbemScripting.SWbemLocator")
objSWbemLocator.Security_.Privileges.AddAsString("SeSecurityPrivilege")
Set objWMIService = objSWbemLocator.ConnectServer(strComputer, "root\cimv2", strComputer & "\administrator", strPWD, "", "", &H80)
Set objReg = objSWbemLocator.ConnectServer(strComputer, "root\default", strComputer & "\administrator", strPWD, "", "", &H80)
Set oReg = objReg.Get("StdRegProv")
…что делает абсолютно то же самое.
Подключение от имени учетной записи локального администратора (local administrator account) имеет еще один интересный побочный эффект; в результате этого не остается копии профиля вашей учетной записи администратора домена в папке Documents and Settings вашего компьютера. При использовании моей учетной записи в домене, некоторые пользователи спрашивали меня: «Зачем вы подключались к моему компьютеру?», и думают, что имело место шпионство. С помощью учетной записи локального администратора, они даже не узнают, что кто-либо подключался к их компьютеру (они не могут увидеть журнал безопасности или security log).
На практике мы всегда используем несколько различных паролей для учетной записи локального администратора, поэтому сценарий может импортировать список этих паролей и поочередно вводить их до тех пор, пока не будет произведен успешный ввод.
www.windowsnetworking.com
Tags: domain, redirect, Windows Vista