• ↓
  • ↑
  • ⇑
 
Записи с темой: 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

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

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

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

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

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

22:28 

Localization is EVIL (part 2)

В Dash'e под Chronostasis'ом.
Продолжение истории, рассказанной вот тут.
Да, да, снова возня с сетевыми адресами, снова очень хочется обеспечить абсолютную прозрачность для пользователей. В предыдущей истории пришли к выводу, что psexec можно заставить понимать русский текст в названии сетевого соединения, но каждый раз набирать команды в окне DNTU - все же удручает. Вот если бы написать скрипт.
Размышляя над этой задачкой, вспомнил, что нечто подобное мне уже делать доводилось, нужно было написать сценарий для работы исключительно в DOS-окне, в котором русский текст воспринимался так же отвратно, как и в psexec. Вспомнил и метод решения этой задачи - скрипт был написан в редакторе AkelPad. Эта штука полезна тем, что кодировок знает неисчислимое множество, в том числе и пресловутый OEM 866 Russian, в которой и писался тот скрипт.
Стащить AkelPad из сети - дело нехитрое, набросать в нем заветные строки в нужной кодировке - тоже. Получаем вот такое:

netsh interface IP set dns "Подключение по локальной сети" static %PRIMARY-DNS% primary
netsh interface IP add dns "Подключение по локальной сети" %SECONDARY-DNS% index=2
netsh interface ip set address "Подключение по локальной сети" static %ADDRESS% %MASK% %GATEWAY% 1

А вот как это выглядит, если просматривать в том же Lister из Total Commander'a:

netsh interface IP set dns "Џ®¤Є«о祭ЁҐ Ї® «®Є «м­®© бҐвЁ" static %PRIMARY-DNS% primary
netsh interface IP add dns "Џ®¤Є«о祭ЁҐ Ї® «®Є «м­®© бҐвЁ" %SECONDARY-DNS% index=2
netsh interface ip set address "Џ®¤Є«о祭ЁҐ Ї® «®Є «м­®© бҐвЁ" static %ADDRESS% %MASK% %GATEWAY% 1

Да, мы видим все те же самые "кракозябы", которые уже совершенно спокойно будут восприняты программой psexec. Дело за малым - прописать в файле нужные параметры, сохранить, скопировать на удаленную систему, после чего:
psexec \\%TARGET-SYSTEM% -s c:\changeIP.cmd
(подразумеваем, что скрипт называется changeIP.cmd и скопирован в корень диска С:)

Кто-то может задать резонный вопрос - а почему не резервирование по DHCP, оно же куда проще? Абсолютно корректное замечание, и сетевому отделу было об этом сказано. Но... гремлинов среди гоблинов всегда хватает ;) (с)

@музыка: Within Temptation - Faster

@настроение: А сайт и софт от MSI - все равно зло.

@темы: Scripting

22:25 

Script run time

В Dash'e под Chronostasis'ом.
Время выполнения скрипта. Весьма важный показатель производительности системы. Ни с того ни с сего некоторые сотрудники начали жаловаться, что при загрузке компьютера уж очень много времени уходит на стадию "Выполнение сценариев запуска". Сценариев этих вообще-то к компьютерам привязано довольно много, и тот факт, что нужное на их выполнение время исчисляется далеко не секундами, а их парой-тройкой десятков - это норма. Но не 10 минут же! К тому же 10 минут - это deadline для системы, по достижении которого она (система) просто прекратит обработку сценариев и продолжит загружаться. Нужно узнать, какой из скриптов тормозит процесс.
Есть два варианта. Первый применим в том случае, если в домене не включена параллельная обработка сценариев - каждый следующий скрипт будет запускаться только по окончании выполнения предыдущего (это настройка по-умолчанию). В этом случае можно просто открыть консоль GPMC, взять интересующую нас систему и собрать с нее результирующий набор политик. Дальше на вкладке с перечисленными параметрами, которые применяются к системе из политик, можно раскрыть раздел сценраиев запуска и просто посмотреть, когда в последний раз был запущен тот или иной скрипт. Учитывая, что запускаются они последовательно - можно сразу увидеть, где узкое место.
Второй метод может пригодиться там, где параллельная обработка сценариев уже включена (это ускоряет процесс загрузки, по понятным причинам). Но для этого придется каждый выполняемый сценарий немного изменить - повесить на него "рамку":
sсript run time
Эта рамка выведет время выполнения сценария в текстовый файл. Его расположение задается в блоке set output file name - в профиле пользователя (если измеряем производительность скрипта входа пользователя), либо в папке %SystemRoot% - если интересует скрипт загрузки самого компьютера. Естественно, эти пути можно и поменять под свой вкус.
Блок sсript body понятен и без объяснений.
Можно, конечно, обойтись и простым выводом на экран, а не в файл. Однако, учитывая, что лично мне придется эти изменения вносить в боевые версии сценариев, лучше лишний раз пользователям не докучать и выполнять все действия в фоне.

@музыка: El DeBarge - Who's Johnny

@темы: Scripting

20:29 

UMRA - User Manager Resource Administrator

В Dash'e под Chronostasis'ом.
Программирование без goto - Клац!
Я не случайно начал эту запись со ссылки на один из холиваров мира программирования - стоит ли использовать оператор goto при построении кода? Сам стараюсь его не употреблять ни в каком виде, благо, средств проверки условий и переходов по результату проверки достаточно. Но не в этот раз.
Довелось сегодня править код формы в этом самом UMRA. Форма работала, но после перегруппировки каталогов Active Directory работоспособность резко упала до нуля ;) Ожидаемый результат, который надо исправлять. Чем и занялся.
Итак, что представляет из себя редактор кода в этой консоли? Это достаточно прямолинейный список из заранее подготовленных команд, которые можно передать службе UmraSvc, и она уже будет их выполнять. Команд не так уж много, но и немало. Даже конструкция if... then... else поддерживается, которую я очень активно собирался использовать. Не тут-то было! Да, этот заранее заготовленный блок может проверять довольно много параметров (хотя и там нашлось, к чему придраться), но в качестве действий после проверки условия можно назначить только одно единственное! Угадайте, какое именно. Правильно - пресловутый goto!
Представить все это "великолепие" в виде псевдокода можно следующим образом:

variable1 = 5
if variable1 < 10 then goto label1 else goto label2
label1: action1
goto end
label2: action2
goto end
end:

И вот таким макаром проверять кучу условий. Повторюсь, в блоке then кроме тупого перехода к метке поставить ничего нельзя, вообще. Все дело в том, что код формы редактируется не в виде исходного кода как такового, где где угодно можно записать что угодно, а через самый что ни на есть GUI - отдельная формочка для ввода всех параметров блока if... then... else. Одним словом - такого кошмара я давно не встречал, если встречал где-то вообще.
Код этой несчастной формы в итоге был выправлен, но времени на отладку в итоге ушло куда больше, чем планировалось.
И на вкусное. Механизм проверки условий UMRA, как выяснилось, совершенно не может проверить какое-либо поле формы на непустое значение. На пустое - пожалуйста, можно выбрать тип проверки null or not present, но вот not null там не поставишь. Пришлось изгаляться с вариантом if var is null then end else blah-blah-blah. Тоже не добавило радости, если честно.

@музыка: Ryan Farish - Perfect Clarity

@темы: Scripting, Этот безумный мир

14:20 

Kaspersky Virus Removal Tool automatic download

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

UPDATE 19-07-2011:Тестирование скриптов на рабочей машине с установленной Windows XP показало, что сценарий очень плохо воспринимает пробелы, которые появляются в именах файлов при развертывании переменной %userprofile%. Выходом является заключение конструкции %userprofile%\filename.txt в кавычки. В тексте записи сценарии исправлены.

UPDATE 16-07-2011 #2: Учитывая, что на некоторых машинах наблюдались проблемы с запуском новой версии утилиты (см. здесь) - ниже выложен модифицированный скрипт для закачки старой, девятой версии KVRT (на сервере его инсталляторы лежат в отдельной папке) - Download KVRT version 9.cmd

UPDATE 16-07-2011: В связи с обновлением KVRT, введением формы загрузки и сменой структуры папок на сервере Kaspersky Lab пришлось немного модифицировать скрипт, чтобы вновь привести его в работоспособное состояние. Изменения выделены жирным шрифтом.

Оригинальная запись:
KVRT - весьма полезный инструмент, с которым довелось вылечить уже немало систем. И Винлоков, и простых файловых вирусов, и трояснов. Но есть у него один недостаток - он не умеет обновляться автоматом. Этот функционал в него специально не закладывался. Он не видит сети, не видит никаких других источников обновленных антивирусных баз, даже намека на кнопочку "обновить" нет. Это сугубо сканер-по-требованию.
Но тем не менее, обновлять его базы все же надо. Делается это выкачкой новой версии утилитки. Каждый раз открывать браузер, щелкать на закладку на ресурс devbuilds.kaspersky-labs.com/devbuilds/AVPTool/, затем подтверждать сохранение файла. Долгое время так и делал. Наконец, мне это надоело. Антивирус (пусть даже такой специфичный) все же должен обновляться регулярно, а не как бог на душу положит. Поэтому командную строку в зубы, гугль в помощь, и вперед.

Вводные данные: папка для сохранения новой версии утилиты - j:\software\kvrt (на флешке), утилита сохраняется под тем же именем, под каким лежит на сайте.
А теперь сам скрипт: Download KVRT.cmd

Как всегда, скрипт требует маленькой доработки напильником. В нем нужно заменить тот самый каталог j:\software\kvrt на то, куда требуется загружать новую версию программы. И еще одно замечание - блок REM check if target KVRT folder exist. Его назначение - проверить, а существует ли тот самый целевой каталог. Если его нет (читать - нет флешки) - не выполнять ничего, так как бессмысленно. Существование каталога я проверяю на уровне самой флешки. Если она есть, значит есть и каталог.
Что можно сделать с этим скриптом? Варианты использования ограничены лишь фантазией. Лично у меня он прицеплен в Планировщик задач, запускается в момент захода моего пользователя в систему или каждый день в 8:30 утра (на случай, если компьютер проработал всю ночь).
запись создана: 04.12.2010 в 18:50

@музыка: Nobuo Uematsu - Beyond the Wasteland

@темы: Scripting, Kaspersky Lab, Viruses and Spam

23:38 

Инвентаризация серверов.

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

Перепись всего серверного хозяйства. Эта процедура не давала мне покоя все то время, что я работаю. До текущего момента это был стандартный Excel-файл с кучкой листов. И конечно же, обновлялся он из рук вон плохо. В конце концов, это порядком поднадоело.
Составные части автоматической инвентаризации:
- MS Access в качестве базы данных. База будет довольно мелкой, а потому поднимать что-то большое для этих целей кажется пошлым.
- Powershell как исполняемый процесс.
- WMI как средство сбора данных.
- Группа серверов в AD.

Требования к системе:
1. Наличие провайдеров доступа к базе MS Access 2007. Проще всего выполняется путем установки самого MS Access 2007 на 32-разрядную машину. На 64-разрядной системе получим ошибку "Провайдер незарегистрирован, пожалуйста, переустановите его".
2. Наличие Powershell v.2 и набора Quest AD Management. Если используется Windows 2008 Server R2 - можно обойтись и без него, но в скрипте придется изменить одну строку.

Особо. В работе сценария сбора информации используются функции для работы с базой MS Access 2007, написанные Richard Siddaway - ссылка на его блог - Клац!.

О самом сценарии. Практически целиком он основан на командлете Get-WMIObject. Указав нужный класс и обратившись к определенному объекту внутри этого класса мы можем получить практически всю интересующую нас информацию о системе. В качестве примера можно привести вот такую часть самого скрипта:
get-wmiobject Win32_computerSystem -computername $srv.name | %{
$sysName=$_.Name
$sysManufacturer=$_.manufacturer
$sysModel=$_.model
}

Если попытаться перевести это на русский язык, получим следующее: извлечь данные из класса win32_computersystem (тут хранятся общие параметры компьютера), обратившись к компьютеру с именем, хранящемся в переменной $srv.name, в переменной $sysName сохранить его имя, в $sysManufacturer - фирму-производителя, в $sysModel - модель компьютера.
В дальнейшем эти параметры в числе других будут записаны в специально подготовленную для этого базу данных.
Похожим образом извлекаются и остальные параметры системы, коих довольно много.

Следующее. Поскольку сценарий достаточно велик, я не стал выкладывать его в открытом виде здесь, как поступаю обычно. Вместо этого все необходимые для инвентаризации файлы выложены на Google Docs - ссылка ниже:
Архив на Google Docs
Описание загружаемого файла: zip-архив GetServerInfo.zip, размер 50 910 байт.
Содержимое архива: скрипт db-functions.ps1 (библиотека функций для работы с MS Access 2007), скрипт GetInfo.ps1 (собственно, сам сценарий инвентаризации), база данных ServerDB.accdb - болванка базы данных. Именно в нее будут складываться полученные сведения.
Как использовать?
1. Распаковать содержимое архива в какой-нибудь каталог.
2. В файле GetInfo.ps1 исправить путь к файлу библиотеки (строка 5), и путь к базе данных (строка 8, изменить параметр -path)
3. Все Windows-серверы собрать в какую-нибудь группу в AD и прописать имя этой группы в строке 11, именно для нее нужен пакет Quest AD Management. При использовании родных средств управления Windows 2008 Server R2 нужно заменить командлет Get-QADComputer на Get-ADComputer с соответствующим изменением синтаксиса, а также закомментировать вызов оснастки Quest AD (строка 2).
На этом подготовка закончена.

Возможные проблемы. Да, куда же без них? Заключаются они в весьма странных наборах данных, которые отдаются скрипту через WMI. Например, на почти всех виртуальных серверах, крутящихся под esxi 3.5 (ОС самой виртуальной машины значения не имеет) вся оперативная память виртуальной машины размазывается по 4 банкам памяти, что приводит к следующим результатам:
банк 0 - 512 Мб
банк 1 - 256 Мб
банк 2 - 128 Мб
банк 3 - 112(!) Мб.
Почему так - я пока не разобрался. На железных машинах подобной проблемы не замечено.
Другая неясность - не все машины передают названия своих сетевых соединений, но это скорее проблемы конкретных машин.
Проблема базы данных. Абсолютно все поля базы имеют текстовый тип, что с точки зрения рационализации - не очень хорошо. Оставлять так или нет - решать вам. На просторах сети встречалось упоминание, что при работе через Powershell в MS Access можно записать данные только этого типа. Так это или нет, пока не проверял, но решил перестраховаться.

На этом все. Любые вопросы, дополнения, уточнения - приветствуются. Надеюсь, кому-то эта информация сможет сэкономить довольно много времени и сил.
P.S. Предвосхищая вопрос - а почему не использовать такие средства, как SCCM, MOM и другие? Ответ прост - бюджет компании. Он везде разный.

@музыка: Australis - Ephemerage

@темы: PowerShell, Scripting

21:54 

Сколько ж музыки у нас?

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

Подкинули намедни интересную задачку. Есть папка. В папке кучка wav файлов, требуется узнать их общую длину. Да не ту длину, под которой в powershell понимают размер файлов на диске, а количество секунд. Немного блужданий по TechNet, и сценарий готов:

Add-Type -AssemblyName presentationCore
$mediaPlayer = New-Object system.windows.media.mediaplayer
$files = Get-ChildItem "e:\media\music\*.mp3"
$size = 0
foreach($file in $files) {
$mediaPlayer.open($file.fullname)
start-sleep -m 500
$size = $size + $mediaplayer.naturalduration.timespan.totalseconds
}
$size

Можно задать вопрос - а зачем введена команда start-sleep -m 500, ведь попахивает индийским кодом. Ответ не менее забавен, чем задачка - без этой задержки объект $mediaplayer просто не успевает прочитать свойства файла, и в итоге общая длина будет равна нулю, что нам абсолютно не нужно.
Обработка напильником в этом скрипте стандартная - в строке $files = Get-ChildItem "e:\media\music\*.mp3" нужно указать свой путь и маску файлов.

@музыка: Deus Ex: Human Revolution OST - Final Boss Theme

@темы: Scripting, PowerShell

12:58 

Time Zones

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

Как всем известно, благодаря инициативе нашего президента IT персонал обрел немного головной боли с отменой перехода на зимнее время. Обновление для операционной системы Windows, которое правит часовые пояса, вышло еще в августе этого года, и времени для его установки вроде бы достаточно. Но аврал в нашей стране - любимый метод работы. Кроме того, возможна ситуация с унаследованной системой, когда ничего не было сделано, а сделать надо.
Итак, самый простой вариант - развернуть WSUS, одобрить там все пакеты обновлений и спокойно сидеть и ждать, пока клиентские системы сами все съедят. Проблемы возникают тогда, когда по каким-то причинам компьютер не хочет ставить этот самый пакет: support.microsoft.com/kb/2570791/ru
В этом случае все просто - нужно смотреть на номер Service Pack, установленного в системе. Если он меньше третьего - придется ставить сначала его.
А что делать, если таких машин много, да еще и сам по себе SP3 ставиться в упор не желает, ссылаясь на ошибку Access Denied? Времени на решение этой проблемы может уйти порядочно, поэтому придется прибегнуть к костылю - нужно будет сменить часовой пояс на каждой такой проблемной машине, после чего через реестр заблокировать переход на зимнее или летнее время.
Инструментарий следующий:
1. Собственно, команда смены часового пояса (согласно выручившей меня странице - Клац!):
Control.exe TIMEDATE.CPL,,/Z XXXX,
где ХХХХ - имя зоны, которую нужно подставить. Посмотреть имя зоны можно в реестре по следующему пути:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
В нашем случае нужно будет подставлять Caucasus Standard Time
Блокирование перехода на зимнее/летнее время выглядит еще тривиальнее:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v DisableAutoDaylightTimeSet /t REG_DWORD /d "1" /f
Собираем все это в единый cmd-файл и выкладываем его в общую папку:

Control.exe TIMEDATE.CPL,,/Z Caucasus Standard Time
reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v DisableAutoDaylightTimeSet /t REG_DWORD /d "1" /f


2. Средство запуска команд на удаленных системах - старый добрый PsExec отрабатывает на ура.
3. Выборка компьютеров, где патч не применился. В моем случае такие системы собраны в группу Active Directory, назовем ее "DST"
4. Набор Quest AD Management. Все же остался пока на нем.
Суммируя все это получаем:
foreach ($comp in (get-qadcomputer -memberof "DST")) {$target=$comp.name;psexec \\$target -u LOGIN -p PASSWORD "path-to-cmd-file"}

Этот однострочник составит массив из имен компьютеров в группе DST, после чего к каждому через psexec будет выполнен cmd-файл, написанный на шаге 1. Результатом этого будет установка часового пояса в Caucasus Standard Time (Кавказское время (Зима) для русской версии ОС). Перезагрузка компьютера не потребуется.
После этого, уже имея запас времени, можно разбираться с причинами неудачи установки апдейтов.

@темы: Scripting, PowerShell

11:14 

Oneliners #4 - Query Based Distribution Lists

В Dash'e под Chronostasis'ом.
Запись скорее для себя, чтобы помнить: как найти все динамические группы рассылки в домене. Обычный однострочник с использованием Quest AD, единственный затык - это незнание того, что динамические группы это объект AD, принадлежащий классу msExchDynamicDistributionList. Ну а с этим знанием все становится до безобразия просто:
get-qadobject -ldapfilter '(objectClass=msExchDynamicDistributionList)'

@музыка: Heather Dale - Call the name

@темы: Scripting, PowerShell

02:17 

Oneliners #5 - Mailboxes of Fired Users

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

В продолжение записи, опубликованной ранее.
Как известно, при блокировании учетной записи сотрудника, в почтовый ящик этого человека почта продолжать поступать будет. Это не by design, такая логика работы в Exchange 2003 была включена в одном из обновлений, а в версиях 2007 и выше - уже по-умолчанию. И вроде как это даже разумно. Потому что далеко не всегда после увольнения сотрудника известно, кто будет его замещать, а переписку терять нельзя.
Но буквально недавно было поставлено условие - почтовые ящики уволенных сотрудников (которые не удаляются, равно как и учетные записи), не должны принимать никаких сообщений. Ведь на то эти учетные записи и заблокированы. Что ж, принимая во внимание тот факт, что такая мера хоть в некоторой степени остановит рост баз, всецело за. И в общем-то, оно и было сделано ранее - путем подставновки минимального и максимального разрешенного размера письма. Ага, равного нулю. И во время проверки выяснилась любопытная вещь: письма при такой настройке как проходили, так и проходят.
Неладно что-то в датском королевстве. Начинаем играть с параметрами и приходим к выводу, что если вместо нуля подставить любое целое число - ограничение работает. Ставим ноль - письма проходят как сквозь масло.
Что ж, можно, конечно, поставить в качестве ограничения 1 килобайт, но это как-то претит. Что можно еще сделать? А можно, например, сделать так, что почтовый ящик будет способен принимать письма только от себя самого. И поскольку учетная запись заблокирована, никто письмо послать не сможет. Точнее, сможет, но отправителю придет отбойник, что и требуется. Как реализовать?

$userDN = (get-qaduser $user).directoryEntry.DistinguishedName;set-qaduser -identity $user -oa @{authOrig = "$userDN"}
где в переменной $user хранится, например, логин увольняющегося человека (в моем случае он берется из заранее заготовленного расстрельного списка), а переменная $userDN получает значение атрибута DistinguishedName нужной нам учетной записи. Атрибут authOrig (разрешенный отправитель) в качестве значения хранит именно DN какой либо-либо учетной записи.
Ну а что же делать, если надо обработать пару сотен таких учетных записей? Как вариант - использование цикла foreach:

foreach ($user in (get-qaduser -disabled) {$userDN = (get-qaduser $user).directoryEntry.DistinguishedName;set-qaduser -identity $user -oa @{authOrig = "$userDN"}}
Буквально: для каждого элемента коллекции, полученной из выборки всех заблокированных учетных записей домена выполнить указанную выше команду.

@музыка: DA - Forest Runners

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

18:14 

Oneliners #6 - Archiving

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

Продолжая опупею с уборкой всякого мусора...
Все домашние папки уволенных сотрудников перемещаются на резервную файлопомойку, где и живут. Обращений к этим файлам нет, но хранить мы их обязаны. Возникла мысль утрамбовать все это на кассету ленточки. Сказано, сделано, тем более, что ленточка имеется - HP StorageWorks Ultrium 448.
300 Гб данных. В принципе, если все данные будут аппаратно сжаты с коэффициентом 2:1 при архивировании - на одну кассету влезут. А кассета как раз одна (Ultrium 2). Более старшие модели кассет эта ленточка не понимает.
Тестовый прогон показал, что не все не влезет. Значит, надо паковать, предварительно выкинув всякий плохо сжимаемый мусор. Mp3, Avi, Vob, Ost (да, там добра полно), но мусор уже был выкинут заранее. Остается только упаковать.
Инструментарий - Powershell + используемый на предприятии 7zip. Однострочник получается следующим:
$dirs=get-childitem < HOMES-PATH >;foreach ($dir in $dirs) {$cmd="C:\Progra~1\7-Zip\7z.exe a -r < PATH-TO-ARCHIVE-FOLDER >\$dir.7z < HOMES-PATH >\$dir\*.*";invoke-expression $cmd}

Разберем по складам.
Сначала в коллекцию $dirs выбираем все наши домашние папочки. Затем для каждой папки из этой коллекции, имя которой заносится в переменную $dir, формируем команду вызова внешней программы с таким набором параметров, которые обеспечивают архивацию всего, что в этой папке есть, в архив с именем, совпадающем с именем папки. Лежать этот архив должен по пути, задаваемом блоком < PATH-TO-ARCHIVE-FOLDER >.
Финальная часть, invoke-expression $cmd, просто вызывает заранее сформированную в переменной $cmd команду.
Что имеем? Имеем набор архивов, по одному на каждый домашний каталог. Каков будет выигрыш по занимаемому объему - покажет время, выполняться этот скрипт собирается долго, но спешить мне особо некуда.

@музыка: Galactic Warriors - Return to Atlantis

@темы: PowerShell, Scripting

16:20 

Удаление старых компьютеров

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

Возможно, кому-то этот небольшой скрипт будет полезен при чистке рабочего AD и DNS. Суть в следующем: при удалении объекта из каталога AD автоматического удаления записей об этом объекте из DNS не произойдет. Верно и обратное - сотрем запись из зон DNS, останется запись в AD, все нужно делать руками. А хочется автоматизации, хоть какой-то.
Прекрасно известно, что для очистки записей DNS существует механизм Aging/Scavenging, но не всегда им можно воспользоваться. Итак, сам скрипт ниже:

$DNSServerName = "servername"
$DNSDomainName = "example.com"
$hostname = (Read-Host -Prompt "Введите имя машины:")
$FQDN = $hostname + "." + $DNSDomainName
get-qadcomputer -identity $hostname | Remove-QADObject
Get-WmiObject -ComputerName $DNSServerName -Namespace 'root\MicrosoftDNS' -Class MicrosoftDNS_AType | where {$_.textRepresentation -like "$FQDN*"} | Remove-WmiObject
Get-WmiObject -ComputerName $DNSServerName -Namespace 'root\MicrosoftDNS' -Class MicrosoftDNS_PTRType | where {$_.textRepresentation -like "*$FQDN."} | Remove-WmiObject

Обработка напильником очевидна: нужно указать имя DNS-сервера, указать имя нашего домена, а в приглашении вводим имя той машины, информацию о которой требуется удалить из наших AD и DNS. Получив имя, скрипт сначала находит эту машину в базе AD и стирает ее командой Remove-QADObject.
Следующий этап - чистка записей DNS. Сначала скрипт пробегает по A-записям (прямая зона), вытаскивает нужную (критерием выступает FQDN нашей машины) и удаляет ее, затем та же операция выполняется применительно к PTR-записи (обратная зона).

@музыка: Joel Kanning - Sedona's Calling

@темы: Scripting, PowerShell

20:52 

Призраки в рассылках

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

Упало в ящик письмо от нашего любимого отдела травокуров (маркетинг, то есть). Мол, сделали рассылку, а назад почему-то вернулся список людей, которым она не дошла. И более того, все эти люди - уже давным давно числятся, как уволенные. В принципе, не дошла, и ладно, но хотелось бы, чтобы их в рассылке вообще не было.
И то верно, зачем нагружать почтовик лишний раз. Запрашиваю имя той рассылки, вспоминая, что при увольнении у нас учетка удаляется из всех групп. Как групп безопасности, так и групп распространения. Тем временем приходит ответ от травокуров с именем той рассылки. Читаю и понимаю, что это динамическая группа, и простым удалением из наших групп распространения тут дело не обойдется. И более того, группа создана в Москве.
Пишу московским админам, мол, так и так - на основании каких критериев формируется данная рассылка. Ответ пришел, из которого стало ясно, что одна из московских же систем определенным учеткам развешивает расширенные атрибуты (extensionAttributeN, где N - индекс от 1 до 15). На основании их-то и формируется список рассылки.
Прелестно. Хотите сказать, что теперь мне придется руками обнулить эти атрибуты у всех уволенных учеток? Нет, так дела не делаются. Консоль в зубы и вперед.

foreach ($user in (Get-QADUser -SearchRoot "INSERT_ROOT_OF_SEARCH" -SizeLimit 0)) {
foreach ($index in 1..15) {
set-QADUser $user -oa @{"extensionattribute$index"=""}
}
}

В принципе, несложный код, который понятен и без пояснений. Заодно основная его часть ушла в скрипт увольнения сотрудника. Интересно, какой еще функционал со временем данный скрипт приобретет...

@музыка: Joel Kanning - Sedona's Calling

@темы: PowerShell, Scripting

18:08 

DFSR Backlogged files

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

Что такое backlog? Это очередь файлов, которые еще не были реплицированы при помощи механизма DFSR. Само по себе наличие этой очереди еще не говорит о проблемах, но вот если при проверке выясняется, что эта очередь постоянно растет, стоит задуматься, а что идет неправильно. Но для того, чтобы иметь представление о динамике очереди, ее нужно наблюдать.
В Windows 2003 R2/2008/2008 R2 есть очень хорошая оснастка, через которую DFSR и управляется. Но есть у нее один недостаток: все операции с отчетами, которые там можно сделать, выполняются однократно. А хотелось бы автоматизации. Что ж, как всегда, консоль наш лучший друг.
Скрипт будет состоять из следующих логических блоков:
1. Сбор информации об интересующей нас группе репликации в специальный файл
2. Отсылка собранной информации (то есть выходного файла) на почтовый ящик администратора файлового сервера.
Основной инструмент, который нам поможет - консольная утилита dfsrdiag.
Сам сценарий выглядит следующим образом:

# get statistics
dfsrdiag backlog /receivingmember:%RECEIVING-SIDE-FQDN% /sendingMember:%SENDING-SIDE-FQDN% /RGName:%REPLICATION-GROUP-NAME% /RFName:%REPLICATED-FOLDER-NAME% /v > c:\DFSR-backlogged.txt

# send report to administrator
$filename = "c:\DFSR-backlogged.txt"
$smtpServer = %SMTP-SERVER-NAME%

$msg = new-object Net.Mail.MailMessage
$att = new-object Net.Mail.Attachment($filename)
$smtp = new-object Net.Mail.SmtpClient($smtpServer)

$msg.From = %SENDER-ADDRESS%
$msg.To.Add(%RECIPIENT-ADDRESS%)
$msg.Subject = "Backlog Report"
$msg.Body = "DFSR Backlogged files"
$msg.Attachments.Add($att)

$smtp.Send($msg)
exit

Масштабирование скрипта очень простое - добавляем столько блоков get statistics, сколько групп репликации нам нужно просмотреть, заканчивая их перенаправлением в файл с дозаписью в конец: >> c:\DFSR-backlogged.txt

Дальнейшее - тривиально: запуск этого powershell-скрипта через Task Scheduler на файловом сервере, и статистика будет приходить автоматом. Что и требовалось.

@музыка: Davol - Nautikos

@темы: PowerShell, Scripting

15:49 

Users in groups...

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

Недавно обнаружил странную особенность в поведении скрипта обработки учеток уволенных сотрудников. Предполагается, что учетная запись будет вышвырнута из всех групп, кроме базовой Domain Users, после чего заблокирована. Странность в том, что на одних учетках эта процедура отрабатывает на ура (в том числе и на моей тестовой), а на других - на первый взгляд не работает вообще. Вот как это реализовано:
(get-qaduser $user).memberof | Get-QADGroup | where {$_.name -ne "domain users"} | Remove-QADGroupMember -member $user
Начинаем разбор полетов. Берем учетную запись, уже отключенную ранее, видим, что в свойствах AD групп там перечислено довольно много. Понятно, скрипт не отработал. Загоняем данные этой учетки в переменную $user, запускаем строку на исполнение, и видим прекрасное:
Remove-QADGroupMember : Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
Уже интереснее. В голове тут же формируется мысль о том, что сотрудник этот сидит не только в группах нашего домена, но и соседнего, а в свойствах учетки через ADUC такие группы не видны. Что ж, даем следующее:
$col = (get-qaduser $user).memberof | Get-QADGroup | where {$_.name -ne "domain users"}
$col

Так и есть. Кучка групп из других доменов. Скрипт натыкался на такую группу, получал отлуп и прекращал обработку всех групп у этой учетки, переходя к остальным процедурам. Надо исправить:
$colGroups = (get-qaduser $user).memberof | Get-QADGroup | where {$_.name -ne "domain users"}
foreach ($group in $colGroups) { Remove-qadgroupmember -identity $group -member (get-qaduser $user) }

К чему приведет? Скрипт по прежнему будет нарываться на группы соседнего домена, но теперь будет пропускать лишь итерации цикла удаления групп, а не всю коллекцию разом. Что и требовалось.

@музыка: Medwyn Goodall - Snows of Kilimanjaro

@темы: PowerShell, Scripting

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

главная