Ознакомьтесь с нашей политикой обработки персональных данных
  • ↓
  • ↑
  • ⇑
 
Записи с темой: scripting (список заголовков)
00:05 

Localization is EVIL.

В Dash'e под Chronostasis'ом.
Меня иногда спрашивают, мол, почему я с пренебрежением отношусь к русской версии Windows XP. Все просто. Я - админ. Человек, который с консолью подчас работает гораздо больше, чем с графическим интерфейсом, который при многократном выполнении одной операции проигрывает консоли прежде всего по скорости. Еще один плюс консоли - она работает скрытно, пользователь, компьютер которого подвергается настройке, ничего не видит и даже не догадывается, что систему потрошат.
Однако, есть проблема. Такие замечательные программы, как psexec, netsh и подобные, очень, ОЧЕНЬ плохо работают с русским языком. Вместо нормальных диагностических сообщений выводится сплошная абракадабра, кодировка страдает (ниже будет пример). А эта диагностика ох, как важна. Ради примера - текущая задача: необходимо на некоторой выборке компьютеров перенастроить DNS серверы в свойствах сетевого соединения. В связи со сменой IP адресов этих самых серверов. Кто-то может возразить, мол, а как же DHCP? Возразит, и будет прав, но лишь отчасти. Потому что есть ситуации, где DHCP просто отсутствует.
Продолжаем перечислять исходные данные. Сетевое соединение на всех тех компьютерах называется вот так: "Подключение по локальной сети". Ну и номер в конце, где-то он есть, где-то его нет.
Собственно, на этом все.
Сценарий работы, по идее, весьма прост. При помощи psexec подключиться к удаленной системе, открыть там сеанс cmd и в нем вбить следующее:

netsh interface ip set dns name="Подключение по локальной сети" source=static addr=a.a.a.a
netsh interface ip add dns name="Подключение по локальной сети" b.b.b.b index=2

Первая команда сносит текущие настройки и ставит первый DNS, вторая добавляет еще одну запись.
Но не тут-то было. psexec просто не примет русскоязычное название сетевого интерфейса. Что делать? Пытаться воспользоваться ключом -r в самом netsh, но и тут засада - при работе в удаленном сеансе netsh не поддерживаются команды настройки DNS, только просмотр. По вполне понятным причинам. Опять таки, что делать?
Решением стало следующее. Поскольку на предприятии используется пакет DNTU, открываем его, открываем тамошний RCmd в режиме Open View, цепляемся к удаленной машине и смотрим на то, как будет обозвано сетевое соединение в этой консоли (помним, что оно называется "Подключение по локальной сети")
Консоль выдаст следующее:
"Џ®¤Є«о祭ЁҐ Ї® «®Є «м­®© бҐвЁ"

Да, да и еще раз ДА! Именно так это соединение и будет называться. Кучей иероглифов. Если бы оно называлось английскими символами, 90% тех неприятностей, которые мы имеем сейчас, просто бы не возникли. Что ж, главный фокус. В командной строке открываем контекст netsh:

netsh interface ip, жмем Enter.

А дальше поочередно вбиваем вот такие конструкции:

set dns name="Џ®¤Є«о祭ЁҐ Ї® «®Є «м­®© бҐвЁ" source=static addr=a.a.a.a
add dns name="Џ®¤Є«о祭ЁҐ Ї® «®Є «м­®© бҐвЁ" b.b.b.b index=2

И это сработает.
А теперь сравните, чем можно было бы обойтись, будь соединение с англоязычным именем:

C:\psexec \\x.x.x.x cmd
netsh interface ip set dns name="LAN" source=static addr=a.a.a.a
netsh interface ip add dns name="LAN" b.b.b.b index=2
Никаких иероглифов, никаких лишних в данном случае DNTU, только то, что нужно.

Вас еще интересует вопрос, почему же я отдаю предпочтение английским версиям ОС?

На вкусное, как переименовать русскоязычное соединение в удобоваримый вариант:
netsh interface set interface name="Џ®¤Є«о祭ЁҐ Ї® «®Є «м­®© бҐвЁ" newname="NewLan"

@музыка: Tomoko Tane - Let Me hear

@темы: Scripting

23:50 

Chain of Earth -> Stone Shock.

В Dash'e под Chronostasis'ом.

Да, да, именно шок.
Преамбула - поставлена задача: найти, кто сидел за конкретным компьютером в определенный промежуток при условии, что сотрудники могут пересаживаться. Казалось бы, что сложного, открываем журнал Security и смотрим логи. Проблема в том, что требуемый промежуток - это уже довольно дальнее прошлое, в текущих логах уже давным давно стертое. Ладно, есть бекапы. Открываем их, лезем в заветную папку %windir%\system32\config, ищем там secevents.evt... и понимаем, что в полном бекапе контроллера домена этого лога нет. Как нет и любого другого из системного журнала событий. Вдумчивое ковыряние гугла подтверждает мысль - ntbackup даже при полном резервном копировании не сохраняет логи. Это касается Windows 2003 Server, платформу 2008 на это еще не тестировали (есть повод создать новую виртуальную машину и поиздеваться над ней).
Что ж, задачу удалось решить, но несколько иным и довольно кривым методом, но осадок остался. Одновременно с этим встал вопрос - что делать с бекапом логов. В итоге был найден и доработан напильником вот такой скрипт:
Backup Security Events.vbs

Далее - Планировщик задач и задача по созданию резервной копии журнала на регулярной основе.

@музыка: Alice in Videoland - Ladykiller

@темы: Security, Scripting

17:00 

Cached Files

В Dash'e под Chronostasis'ом.
Кэш. Не тот, что наличный, а тот, что временное хранилище файлов. Хорошая вещь, помогающая сэкономить на трафике, но только в том случае, если за ним следить. А пользователи, как правило, вообще не в курсе, что это такое, зачем оно нужно. Более того, они не в курсе, что он вообще существует. Но обязанности следить за ним это не отменяет.
Если не ограничивать в размерах временные папки - они склонны раздуваться, раздуваться и раздуваться. Плодитесь и размножайтесь, так вроде было? Значит, нужно как-то эти папки чистить, потому что пользователя не допросишься это делать.
Основные два рассадника "времянки" - браузер и почтовый клиент - IE и Outlook. И если в первом еще можно размер обозначить, то второй чрезвычайно любит покушать. Суть идеи проста - удалять содержимое этих хранилищ когда пользователь выходит из системы. Расположения кэшей известны:
C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\Content.IE5\ - браузер
C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\Content.Outlook\ - Outlook 2007
C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\OLK*\ - Outlook 2003

Имея все эти данные, можно набросать небольшой сценарий выхода из системы, после чего подцепить его к групповой политике. Сам cmd-файл будет выглядеть следующим образом:
Clean Cache.cmd

Одним из плюсов постоянной очистки, по крайней мере, кэша браузера видится тот факт, что это позволит стирать с жестких дисков пользователей всякую вредоносную дрянь, которая сидит в Temporary Internet Files, и запускается c User-level правами на старте системы. Антивирус все же не панацея.

@музыка: Moya Brennan - Tara

@темы: Scripting

21:05 

IE 6,7,8

В Dash'e под Chronostasis'ом.
Гром таки грянул. Сколько пришлось попариться для того, чтобы обновить IE на компьютерах домена до версии выше, чем 6 - почти все напрасно. Выяснилось, что один из компонентов используемого бизнес-приложения стабильно работать может только в версии 6. Во всех других он может завесить браузер намертво, что приводит к лишнему расстройству, потери набранных в форму данных (браузер нужно будет перезапустить без сохранения состояния). В общем, обещается много-много неприятного. В связи с чем встал вопрос - как бы версии 7+ снести с порядочного количества компьютеров максимально быстро и по возможности без лишних телодвижений и звонков. Немного ковыряния в предметной области показало, что у приложения Windows Internet Explorer 7/8 есть так называемая строка деинсталляции (в общем и целом, эта строка есть почти у всех продуктов, которые прописываются в апплете "Установка и удаление программ"). Оно и понятно, системе ведь нужно что-то запускать для процесса удаления ненужного приложения.
Что ж, это радикально меняет дело. Строка известна, стало быть нам нужен еще один скрипт, который будет запускаться на нужных компьютерах. В итоге получается следующий vbs-файл:

'Internet Exploer 7,8 Uninstallation
on error resume next
Set WshShell = CreateObject("WScript.Shell")
'Uninstall IE 8
WshShell.Run "C:\WINDOWS\ie8\spuninst\spuninst.exe /quiet /norestart",1,true

'Uninstall IE 7
WshShell.Run "C:\WINDOWS\ie7\spuninst\spuninst.exe /quiet /norestart",1,true

Вот такой небольшой сценарий.
Последний момент - после удаления всех старших версий компьютер нужно перезапустить. Проблема в том, что пользователи на это чаще всего забивают. Что делать? Выход прост - этот скрипт нужно выполнить в момент завершения работы компьютера.
Таким образом получаем довольно простой сценарий: групповая политика, область действия - выбранные компьютеры (а они известны), параметры политики - Shutdown sсript, именно туда нужно будет подставить указанный выше сценарий. Дело за малым, перезагрузить машины - и задача выполнена.

@музыка: Clannad - From Your Heart

@настроение: Scripts are my best friends

@темы: Scripting

10:15 

Oneliners

В Dash'e под Chronostasis'ом.

Oneliner - сценарий, состоящий из одной строки (one line). Их удобство в том, что для решения какой-то задачи достаточно открыть консоль, набрать нужную команду, запустить ее на выполнение и получить результат. Нет необходимости писать текст скрипта, сохранять его, затем писать команду на вызов этого сохраненного файла. Все просто.

Недавно понял, что нужно привести в порядок в нашем домене ограничения на максимальный размер передаваемого через почту сообщения. У кого-то стоит одно, у кого-то другое, у некоторых вообще десятое. Это неправильно. Два параметра (размер входящего письма и размер исходящего письма) хранятся непосредственно в записях Active Directory, следовательно, вытащить их достаточно просто. Вариантов довольно много, но в итоге я остановился на Powershell и его сторонней оснастке Quest Management Shell. Quest - это отдельный набор команд, облегчающих работу с Active Directory и делающих ее более прозрачной, чем обычные команды Powershell. Сами параметры зовутся так:
SubmissionContLength - размер исходящего сообщения;
DelivContLength - размер входящего сообщения.

После непродолжительного чтения справки удалось набросать сценарий, шаблон которого выглядит так:

foreach ($name in get-qaduser -searchroot 'INSERT_ROOT_OF_SEARCH') {set-qaduser $name -objectattributes @{SubmissionContLength='INSERT_VALUE';DelivContLength='INSERT_VALUE'}}

Пара слов о том, что он делает.
foreach - это команда, которая выполняет определенный набор действий с каждым объектом какой-либо выборки. в общем случае она записывается так:
foreach (selection) {sсriрt}
где selection - это выборка, а sсript - то самое действие (или несколько действий), которые нужно произвести с объектами выборки.
$name - переменная, хранящая в себе имя пользователя.
get-qaduser - одна из ключевых команд сценария. она вытаскивает из Active Directory полную информацию о пользователе, чье имя хранится в переменной $name
-searchroot - модификатор, задающий область поиска. Сюда нужно подставить путь к ветке в Active Directory, в которой сценарий будет искать нужного нам пользователя. Формат записи: 'OU=TestOU,DC=Domain,DC=com'

Таким образом, первая часть сценария создает выборку объектов Active Directory, у которой нужно будет сменить пару свойств. Непосредственно сменой свойств занимается вторая часть скрипта, заключенная в фигурные скобки.
set-qaduser $name - изменить параметры учетной записи, имя которой указано в переменной $name,
-objectattributes @{SubmissionContLength='INSERT_VALUE';DelivContLength='INSERT_VALUE'} - здесь задается, что именно меняеть, как раз те самые два параметра. Следует обратить внимание, что набор параметров заключается в фигурные скобки.

@темы: MS Exchange, PowerShell, Scripting

15:34 

Ключи...

В Dash'e под Chronostasis'ом.

... от квартиры, где деньги лежат.
Нет, на самом деле речь пойдет о ключах другого рода, лицензионных. Первое, что приходится учитывать компаниям, это ключи на ОС и офисный пакет, если используется MS Office. И может сложиться такая ситуация, когда нужно быстро собрать информацию о ключах на довольно большом количестве машин. Как это сделать?
На помощь может прийти утилита под названием Produkey. Свободно распространяемое мелкое приложение, которое позволяет узнать ключи Windows, MS Office и некоторых других пакетов. Сама эта утилита содержит в себе возможность сканирования удаленных машин с целью сбора информации о лизензиях. Но есть один момент - компьютер для этого должен быть включен. Другой же вариант решения проблемы - запустить Produkey в момент запуска компьютера. Это можно сделать сценарием запуска машины.
Групповые политики, Параметры компьютера, Сценарии запуска. Сюда нужно будет положить сценарий, шаблон которого представлен ниже: GetKeys.vbs

Что делает этот сценарий? При загрузке компьютера из папки \\NETWORK-SHARE\ вызывается программа produkey.exe с определенным набором параметров. Результатом ее выполнения будет созданный в корне диска С: файл с информацией об установленном на компьютере ПО (в той части, которую "распознает" produkey). Далее этот файл копируется в сетевую папку "\\REPORTS-FOLDER-SHARE\", после чего из корня диска С: файл будет удален. Таким образом в папке "\\REPORTS-FOLDER-SHARE\" создается набор файлов, каждый из которых соответствует одному компьютеру. Этот набор файлов уже можно анализировать в спокойной обстановке.
Отдельно об анализе этого набора файлов. Например, требуется узнать, что творится с ключами ОС (типичная в России ситуация для нового системного администратора на предприятии). Известно, что в отчетах produkey информация об ОС идет первой строкой. Значит, задача сводится к тому, чтобы пробежать по всему набору отчетов, вытащить из каждого отчета первую строку и внести ее в файл итоговой таблицы. Эту задачу можно легко решить при помощи Powershell, например:

$ReportPath = "\\REPORTS-FOLDER-SHARE\"
foreach ($name in ls $ReportPath) {get-content $ReportPath\$name -totalcount 1 | Out-file winkeys.txt -append}

Этот нехитрый сценарий пройдет по всем файлам в папке \\REPORTS-FOLDER-SHARE\, прочитает по одной строке из каждого файла в ней, после чего результат скинет в файл winkeys.txt, находящийся в домашней папке пользователя. Работать с единой таблицей же куда проще, чем с набором файлов.

@музыка: Stone Age - Maribrengall

@темы: Security, Scripting, PowerShell

Записная книжка

главная