• ↓
  • ↑
  • ⇑
 
Записи с темой: powershell (список заголовков)
20:37 

У семи нянек...

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

... или как мы Server Core 2012 крутили-вертели.
Именно так, причем ось этого кручения-вращения называть не будем.
Все прекрасно, практически все аспекты настройки выполняются довольно просто и быстро. Имя сервера, домен/рабочая группа, роли, дополнения - в Powershell настраиваются просто на ура. Феерия. Ровно до того момента, когда требуется подкрутить настройки сети. Потому что далее начинается ад.
Вспомним, практически все настройки сети у нас были в одном окне. Да, одном. Открыл нужный интерфейс, поменял, что надо, закрыл. Теперь давайте подсчитаем, что у нас имеется для настройки сети в командной строке:
- старый добрый ipconfig в случае настройки через DHCP (да, да, те самые /release и /renew);
- чуть менее старый и менее добрый netsh, там синтаксис команд вырвиглазный;
- новый и довольно злобный powershell, многообразие команд которого заставляет окунуться в technet, а вынырнуть может и не удастся вовсе. Судите сами:
get-netadapter (если надо свериться с сочетанием интерфейс-сетевой адаптер), set-netipaddress или new-netipaddress (в зависимости от ситуации - задать адрес так или сяк), set-dnsclientserveraddress (тут мы прописываем настройки DNS). А уж если облажались с настройкой шлюза по-умолчанию, то нам сюда, где мы познакомимся еще и с командами Remove-NetRoute и New-NetRoute для удаления неверного и прописи нужного шлюза.
А в итоге - в подавляющем большинстве намного быстрее и понятнее будет сделать следующее:

Где в разделе номер 8 можно настроить сеть как нам угодно.
Что ж, MSы сдержали обещание. В Windows Server 2012 они полностью пришли к Unix-way - все, абсолютно все можно сделать из командной строки. Но некоторые операции, подчас, в тех же никсах, сделаны куда изящнее и проще. Хотя тоже через командную строку.

@музыка: Nicolas Jeandot - Fiery Horse

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

21:36 

User account properties

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

Следующая подзадача в нашей эпопее - в образе есть дефолтная пользовательская учетка. После того, как образ развернется, этой учетке нужно поставить свойство User must change password at next logon. Естественно, по возможности опять же в powershell сделать.
Методов несколько. Чтобы не томить, привожу тот, что сработал в моем случае:

$username=%INSERT_ACCOUNT_NAME%
$user = [ADSI]"WinNT://$env:computername/$username,User"
$user.passwordexpired=1
$user.setinfo()

Код прост как две копейки. Получить от провайдера ADSI объект нашей учетки, поменять его свойство под названием "Пароль просрочен", подтвердить изменения. Все. Задача выполнена.
А вот в процессе написания выплыл интересный факт. Галка User must change password at next logon в интерфейсе свойств учетной записи связана с вот таким свойством: User Flags. Значение этого параметра вычисляемое и зависит от нескольких факторов. МСы в документации приводят полный список значений, которое это свойство может принять - Клац!
Ок, небольшой эксперимент. В свойствах учетной записи в графическом интерфейсе меняем все галки, кроме самой первой. Это как раз User must change password at next logon. А потом даем простые три строчки:

$username=%INSERT_ACCOUNT_NAME%
$user = [ADSI]"WinNT://$env:computername/$usenamer,User"
$user | fl *

И наблюдаем, что параметр UserFlags принял значение 8389121. Закономерный вопрос - как так?! Ответить на него еще только предстоит. А пока - добиваем в скрипт окончательной настройки системы после развертывания полученный ранее блок команд, и наслаждаемся результатом.

@музыка: Laliya - Just like river

@темы: PowerShell, Scripting

19:25 

Download KVRT in Powershell

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

Когда-то давно довелось мне написать скрипт автоматической загрузки Kaspersky Virus Removal Tool. Как показало время - запись та была достаточно популярной. Как и сам KVRT. Поскольку же прогресс не стоит на месте, и многие все же переходят на ОС Windows 7 и выше, специально для них (и для себя любимого в их числе) переработал тот сценарий, переписав его в Powershell. Вон он:

Download KVRT.ps1

Обработка напильником стандартная: в строке $folder = "d:\KVRT" прописать имя того каталога, куда будет складываться загружаемый файл.
ВНИМАНИЕ! Содержимое каталога, указанного в переменной $folder, будет удалено в процессе выполнения этого сценария. Это сделано специально, исходя из собственных нужд. Если очистка каталога нежелательна, нужно закомментировать строку remove-item $folder\*.* при помощи символа # (или вообще удалить ее).
Ну а о том, как можно Powershell-скрипт запускать по расписанию, в сети материала вагоны )

@музыка: Adrian von Ziegler - The Stormbringer

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

12:56 

Parse and sort

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

После развертывания MDT, которым сейчас вовсю пользуются ребята из службы поддержки, возникла одна проблема. Большая она или нет - это с какой стороны взглянуть. Суть в следующем - когда рабочая станция получает образ ОС и вводится в домен при помощи MDT, она попадает в базовую OU Computers. В то же время у нас AD разбита по отделениями и филиалам, на каждый филиал своя OU. И теперь нужно вручную все эти компьютеры раскидать по различным OU. Лениво. Впрочем, так скажет любой администратор. Что же делать?
У каждого отделения свой диапазон IP адресов. Все IP адреса есть в DNS. Стало быть, можно определить, какой компьютер из базовой OU куда должен улететь. Остается лишь получить IP адрес компьютера и сказать скрипту, чтобы он принял решение о переносе компьютера в нужную OU именно на основании полученного адреса. Но как это сделать? Стандартная команда nslookup выдаст нам море лишней информации - имя контроллера домена, его адрес, имя интересующего нас хоста... Более того, все это будет в нескольких строках. Значит, придется парсить эти строки, ничего не поделать. Снова и снова берем в руки Powershell и начинаем размышлять.
Утрамбовать вывод стандартного nslookup в какую-либо переменную труда не составляет:
$var = nslookup hostname
Дальше пропишем небольшую модель нашей сети. Итак, пусть диапазоны адресов, которые будут использоваться, выглядят так:
Главный офис - 10.10.1.1 - 10.10.6.255
Филиал 1 - 10.20.1.0/24
Филиал 2 - 10.20.2.0/24
Филиал 3 - 10.20.3.0/24
...

В главном офисе стоят все серверы, их подсеть - 10.10.1.1-10.10.1.254. Среди них и сидит наш DNS сервер, который будет отдавать информацию по nslookup. Диапазон адресов рабочих станций в центральном офисе - 10.10.3.1 - 10.10.6.255.
Стало быть, когда будем парсить вывод nslookup, нам нужно будет игнорировать в выводе адрес вида 10.10.1.x - адрес нашего DNS - он бесполезен.
Стандартный вывод nslookup будет выглядеть следующим образом:
c:\> nslookup hostname

server: DNS-fqdn
Address: DNS-ip

name: hostname
Address: hostname-ip
Последняя строка может приять вид Addresses: hostname-ip1, hostname-ip2 если адресов больше одного.
Итак, нас будет интересовать последняя строка. Для построчного анализа можно использовать следующую конструкицю
foreach ($line in $var) { sсript-block }
В переменную $line будут поочередно заноситься все строки, хранящиеся в многострочной переменной $var, и уже переменная $line будет подвергаться анализу, что нам и нужно. Основной вопрос - как проверять? Тут на помощь придет трава (иначе и не скажешь) под названием регулярные выражения. Выглядеть в реализации Powershell это будет следующим образом:

Под CO тут понимается центральный офис (он же главный офис).
На этом самая заковыристая часть скрипта написана. Остается только сделать выборку компьютеров из базовой OU Computers, прописать механизм переноса записи компьютера между OU, да перечислить все возможные блоки в цикле foreach ($line in $var) { }. Все это уже тривиально.
Ну и попутно придется курить руководства по MDT в плане возможности выбора OU, куда компьютер будет сразу прописываться.

@музыка: RA - Creation of Tefnet

@темы: Scripting, PowerShell

16:10 

Windows Distribution Point #2

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

В предыдущей записи было рассказано, как можно подготовить пачку обновлений для интеграции их в дистрибутив ОС. Следующий шаг - непосредственно внедрение. Делается просто - вызываем интересующий нас файл с параметром /integrate, в котором прописываем путь к дистрибутиву. Само собой, что дистрибутив нужно скопировать с компакт-диска, ведь на сам компакт просто так ничего не запишешь. Ну и само собой - язык ОС должен совпадать с языком обновлений, иначе интеграция не пройдет.
Хорошо, ну один файл, ну два, ну три... А когда их нужно под сотню обработать? Не руками же все это каждый раз прописывать. Верно, не руками. Снова запускаем ISE и пишем там следующее:

Где E:\WinXP-Update-Pack - имя каталога с файлами обновлений, d:\winxp - каталог с файлами дистрибутива Windows XP SP3.
Скрипт сначала прочитает список файлов обновлений, а потом будет обрабатывать их по одному, попутно выводя на экран сообщение о том, что именно в данный момент встраивается в дистрибутив. Процесс довольно долгий, можно выпить не одну чашку чая/кофе. В моем случае пришлось на это положить час, завалившись на диван с прелестной книгой.
По окончании процесса нужно будет лишь из каталога d:\winxp (с моем случае) собрать ISO файл, который уже можно использовать для установки ОС.
На первый взгляд - все просто. Но - как бы не так. При попытке установки Windows XP из полученного дистрибутива получаем странное:
lsass.exe - недостаточно квот на виртуальную память или файл подкачки для завершения требуемой операции.
Как подсказывает всемирный разум - такое поведение наблюдается при интеграции в дистрибутив, помимо всего прочего, еще и Internet Explorer/Windows Media Player старших версий. Убрал файлы этих обновлений из каталога перед интеграцией - проблема решилась. Ладно, эти продукты можно и через WSUS ставить.

@музыка: Poets of the Fall - May be tomorrow is a better day

@темы: PowerShell, Scripting

15:55 

Windows Distribution Point.

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

Идея единой точки распространения дистрибутива Windows на работе занимает мой мозг уже давно. В принципе, этот сервис уже поднят, настроен и работает. Связка WDS + MDT 2010 отработала просто прекрасно, стоило потратить пару дней на "вкуривание" процесса настройки MDT. Но остался нерешенным один вопрос - что делать с обновлениями ОС после установки? Да, поднят и работает WSUS, но сам процесс установки, когда машина тащит и натягивает на себя больше сотни обновок, просто очень долог. Остается только один вариант - интеграция обновлений непосредственно в дистрибутив. После установки ОС уже будет пропатчена по самое не могу. Идея хорошая, но где взять эти обновления? Не руками же с сайта Windows Update вытаскивать, хотя и была такая идея.
Сначала попробовал вынуть из из WSUS при помощи новоразвернутой машины. Да, вынуть их удалось, но уже в распакованном виде. Не пойдет, потому что заветный ключ /integrate применяется только к упакованным обновлениям, а как их паковать таким образом, MS, конечно же, не объясняет, ибо зачем?
Гугл, запрос, курение результатов. Результатом стала следующая ссылка:
support.microsoft.com/kb/913086 - Security updates are available on ISO-9660 DVD5 image files from the Microsoft Download Center
Да, вы не ошиблись. Все апдейты доступны в виде ISO образов. Для всех систем. Трафика, конечно, ушло безумно много - 90 Гб, зато теперь есть все необходимое.
Только вот одна проблема. 56 образов, если считать от месяца выпуска SP3 для Windows XP (меня интересует этот дистрибутив). Каждый из них нужно распотрошить, выбрать оттуда каталог с нужной версией, архитектурой, языком, вытащить оттуда файлы и сложить в отдельный каталог. Ужас. Что же делать? Окидываем взглядом систему, понимаем, что в ней есть следующие компоненты: Daemon Tools, Powershell, ISE. Большего и желать нельзя. Ну и справка от Daemon Tools, конечно же.
Итак, идея в том, чтобы заставить Powershell-скрипт извлекать из образов нужные файлы. Структура каталогов внутри каждого образа известна - номер Knowledge Base, версия ОС, архитектура, язык, например, DriveLetter:\2723135\WindowsXP\x86\*.exe
Заставить извлекать файлы по таким путям - дело нехитрое. А вот что делать с процессом монтирования образов? Тут-то на помощь и придет Daemon Tools. Эта широко известная программка способна работать не только в обычном графическом режиме, но и через командную строку. Ее ключи подробнейшим образом расписаны во встроенной справке, хотя и там не обошлось без накладки, ее я выделю позже.
Теперь перечислим, что у нас имеется (применительно к моей системе):
Файлы всех ISO образов лежат в папке D:\Temp\Архивы
Складывать все обновления мы будем на диск E: в соотвествующие папки.
Daemon Tools установлен в стандартный каталог C:\Program Files (x86)\DAEMON Tools Lite.
Виртуальный диск, в который монтируются файлы-образы, имеет букву G:
Поехали:

В принципе, код не сложен. Отдельно хотелось бы остановиться на паре моментов.
Первый - строка $args = "-mount 0,$iso. Именно здесь задаются ключи запуска Daemon Tools. И именно здесть есть небольшая накладка в справке самой DT. В ней указано, что среди параметров необходимо указывать тип драйва, в который мы стараемся монтировать файл-образ. На практике попытка указать тип приводит к ошибке, поэтому тип драйва просто опущен. А должно было быть вот так: $args = "-mount scsi,0,$iso".
Ну а второй момент - искуственная задержка start-sleep 5 - самой Daemon Tools требуется некоторое время на монтирование образа.
Ради интереса в код ввел вывод времени начала и окончания выполнения. Выяснил, что весь скрипт отрабатывает 5 минут или около того. Представляю, сколько времени я бы все эти действия выполнял руками...
Может возникнуть вопрос - а что за блоки, связанные с обновлениями Win7 и язык такой Neu. Ответ на первую часть вопроса прост - в рамках этого же скрипта еще и для семерки файлы обновлений вытащим. А вот что за локаль такая - я и сам не знаю. Все обновления Win7 идут только в ней. В папках Rus для семерки не оказалось ни одного файла, только в Neu.
... И почему нативная поддержка ISO в Windows появилась только в Win 8...

@музыка: Poets of the Fall - May be tomorrow is a better day

@темы: 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

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

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

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

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

15:50 

Home folders

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

Продолжаем наводить порядок.
На этот раз объектом преследования выступают домашние папки пользователей. Есть куча учеток уволенных сотрудников. У кого-то из них их домашние каталоги перенесены с боевого файлового сервера в архив, у кого-то нет, и зря занимают место. Надо от этого избавиться. Как быть? Для начала нужно получить список всех уволенных, это достаточно просто.
Далее учитываем тот факт, что домашняя папка названа по логину сотрудника, следовательно, нужно каждый из выбранных логинов проверить на наличие в пути следующего вида:
\\server-name\share\userlogin
Если такой путь имеется - значит домашний каталог не перенесен, и нужно этим озаботиться.
Объединяя все это в простой цикл получаем примерно следующее:

$colUsers = Get-QADUser -SizeLimit 0 -Disabled
write-host "Start of home folders checking..."
foreach ($user in $colUsers) {
$name = $user.SamAccountName
if (Test-Path \\server-name\share\$name) {
"Moving $name home folder to archive..."
$userhomedest = "\\archive-server-name\share\" + $name
copy-item -path \\server-name\share\$name -destination $userhomedest -container -recurse
remove-item -path \\server-name\share\$name -recurse -force
"$name home folder was moved successfully"
}
}

Соответственно, server-name - имя боевого файловика, archive-server-name - имя архива.

@музыка: А за окном забивают сваи... уже второй месяц.

@темы: 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

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

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

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

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

15:27 

Oneliners #3 - Перенаправление писем

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

Захотелось посмотреть, а у кого и куда стоит перенаправление почтовых писем в AD. И заодно подсчитать количество таких записей. Компоненты этого скрипта известны - get-qaduser, конвейеры, оператор вывода write-host. Основная сложность в том, что ключевой параметр altrecipient, в котором и хранится информация о цели перенаправления почты, в конвейер просто так не выводится, на выходе получаем пустые значения. Немного поковырявшись в справке по командлету get-qaduser находим ключ -IncludeAllProperties. Данный параметр заставляет команду get-qaduser выбрать из AD всю информацию о пользователе, по-умолчанию этого не происходит. Вторая сложность - по конвейеру нельзя передать конструкцию вида $_.altrecipient оператору write-host. Следовательно, приходится сначала упаковывать требуемые нам значения в переменные, а потом через write-host выводить на экран значения этих переменных. Одновременно в цикле можем подсчитать, сколько таких пользователей нашлось.
Суммируя всю эту информацию, скрипт принимает следующий вид:
get-qaduser -includeallproperties -oa @{altrecipient='*'} | %{$name = $_.name;$alt=$_.altrecipient;$i=$i+1;write-host $name" -> "$alt};write-host $i;$i=0

@музыка: Faun - Iduna

@темы: PowerShell, MS Exchange

18:26 

Oneliners #2

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

Возникла сегодня интересная задачка: узнать, у кого из пользователей нашего домена стоит перенаправление почты на древнючий ящик. Лет тому ящику уже много, пора бы это дело и снять. Решение оказалось простым:
$user = (get-qaduser 'USERNAME').directoryEntry.DistinguishedName; get-qaduser -oa @{altrecipient = "$user"}
Входной параметр - имя того пользователя, на которого поставлено перенаправление. Выход - список пользователей, которые заваливают несчастный ящик своими сообщениями.
Конечно, можно было бы огульно сменить у всех в домене параметр altrecipient на NULL, но это порушило бы нужные перенаправления (а их немало).
Самым любопытным здесь является параметр {altrecipient = "$user"}. Переменную $user нужно обязательно заключать в парные кавычки. Именно в парные. Без них команда будет ошибочной, потому что переменная не распознается. Если же заключить переменную в одинарные кавычки - в скрипт вместо значения переменной будет передано ее имя.

@темы: PowerShell, MS Exchange

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

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

главная