We rise up for the things we believe in over and over again

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

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

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

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

@темы: PowerShell, Scripting

We rise up for the things we believe in over and over again

Возможно, кому-то этот небольшой скрипт будет полезен при чистке рабочего 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

@темы: PowerShell, Scripting

We rise up for the things we believe in over and over again

Продолжая опупею с уборкой всякого мусора...
Все домашние папки уволенных сотрудников перемещаются на резервную файлопомойку, где и живут. Обращений к этим файлам нет, но хранить мы их обязаны. Возникла мысль утрамбовать все это на кассету ленточки. Сказано, сделано, тем более, что ленточка имеется - 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

We rise up for the things we believe in over and over again
В течение вот уже пары лет нам удавалось избегать этой процедуры. Потому что ставить 300 мегабайтный пакет через политики AD (Software Installation node), да еще и не слишком к тому приспособленный - это убийство. Ладно еще центральный офис, все таки локальная сеть. А что делать с отделениями, на которых каждый компьютер будет тащить все это барахло, забивая канал напрочь? Об этом, как всегда, в Редмонде не слишком сильно думали. На МС кричали многие, мол, вы, ребята, сделали инструмент, разворачивать который в доменной среде почти невозможно, разве что в административной установке, то есть руками на каждом конкретном компьютере. И то верно, просто так в Soft Installation этот пакет не подставить (потому что выполнен в виде обычного exe-файла), через WSUS, в отличие от 4 версии он просто не распространяется. SCCM? А денег дадите? А самое главное, для нашей задачи нужен именно .NET 3.5, потому что совместимости между этими версиями нет. С одной стороны это разумно, сразу же отсекается множество багов предыдущей версии, но с другой... держать зоопарк этих самых .NET, чтобы работали все необходимые приложения - жуть да и только. Хорошо, что обновления для них всех через WSUS можно доставлять.
Впрочем, довольно лирики. Задача есть, нужно решать. А для этого пришлось очень хорошо прошерстить MSDN. И вот что нашлось:
.NET Framework 3.5 Deployment Guide for Administrators - msdn.microsoft.com/en-us/library/cc160717%28v=v...

Собственно, после прочтения сего документа стало понятно, почему же .NET 3.5 весит порядка 300 Мб, в то время как четвертая версия - всего 50. В пакете 3.5 зашиты все необходимые компоненты, которые должны быть установлены на машине до непосредственно установки 3.5, отсюда и объемы.
А самым ценным на этой странице является скрипт, который из этого многомегабайтного пакета делает набор папок с MSI пакетами внутри. Exactly what I need! Потому что уже эти MSI файлы можно спокойно подставить в Software Installation node в GPO и натравить политику на тестовую машину.
В ремарках к скрипту указано, что с компонентом Software Rasterizer for the Microsoft DirectX 9.0 Software Development Kit (SDK) будут проблемы, он просто не установится. Подтверждаю, выдается целая серия ошибок установки через групповые политики:
Error List
Но самое любопытное в том, что несмотря на эту ошибку наше приложение смогло запуститься и предложить весь спектр необходимых функций. Похоже, что ни для одной из них Software Rasterizer не используется, но это будет предметом еще более глубокого тестирования. Времени у нас - до нового года, должны успеть.
Итого имеем готовую политику для расстановки .NET 3.5, что уже неплохо. Но это только первая часть глобальной задачи. Дальше будет еще интереснее...

P.S. Результат попытки ручной установки сбоящего компонента - все чудесатее и чудесатее (с):
Тип события: Уведомление
Источник события: MsiInstaller
Категория события: Отсутствует
Код события: 11707
Дата: 18.12.2011
Время: 11:44:26
Пользователь: xxxxxxxxxxx
Компьютер: SPB-TESTXP
Описание:
Product: RGB9RAST -- Installation completed successfully.

Дополнительные сведения можно найти в центре справки и поддержки, в "go.microsoft.com/fwlink/events.asp".

Ни добавить, ни убавить. Мистика :)

@музыка: Sonata Arctica - Last Drop Falls

We rise up for the things we believe in over and over again

Ситуация уже привычная. Поражение ноутбука. На сервере - за 15 минут - тысяча сообщений о пристреленной заразе. Активный зловред, ничего не скажешь. Пытается записать вирусное тело с расширением *.vir в текущей папке, если есть доступ. Эти-то тела корп. антивирус и пристреливал, зловред же в памяти ему по-прежнему не по зубам. Делать нечего, удаленное выключение ноута, звонок сотруднику, мол, тащи машину, будем лечить.
Ноут на столе. Метод лечения - мой излюбленный - оффлайн-проверка, хотя дальнейшее показало, что это было излишним. Заодно решил проверить, что может предложить LiveCD от Касперских: www.kaspersky.com/virusscanner. Образ стащен, болванка зажарена, загрузка ноута.
Гентушная сборка линуксов, выбираем рекомендуемый режим работы (графика). Не тут-то было. Графический адаптер, стоящий в ноуте (кто-то из ATI) мы не понимаем, грузиться не хотим. Вот вам текстовый режим, разбирайтесь. Хороший подход, ничего не скажешь. Документации не нашел, хотя и не сильно активно искал, скрывать не буду. Ладно, второй рестарт, выбираем альтернативный режим работы. Результат тот же, видео недоступно, только текст без документации. Сидящий рядом коллега-никсоид решился поковырять команды этой сборки, но через пять минут безрезультатного ковыряния забросил это дело.
Ладно, расчехляем старый добрый BartPE, этот не подводил никогда. В дополнение к нему с того же сайта Касперских стаскивается новая версия KVRT, пресловутая 11-ая, в надежде, что ее все же допилили до вменяемого состояния. Запуск ноута, BartPE приветствует нас своими темносиними обоями, запускаем инсталлятор KVRT. Сам по себе установочный файл этой утилиты - это SFX-архив, который все необходимые файлы распаковывает в директорию tmp. Поскольку диск BartPE - это "дела давно минувших дней" (с), в качестве временного хранилища данных он создает RAM-диск на 80 мб. В те времена этого хватало за глаза. И именно в этот RAM-диск пытается распаковаться инсталлятор KVRT, но места ему там не хватает. Утилита весело рапортует о том, что места нет, и... правильно, просто завершает работу, даже не предлагая выбрать альтернативное расположение временного каталога. Это вообще как?
Где наша не пропадала - открываем командную строку, и далее:

set temp=c:
set tmp=c:
c:\setup.exe

Bнсталлятор KVRT был заблаговременно скопирован в корень диска С: и переименован в setup.exe.
Чудо свершилось наполовину, инсталлятор все же распаковался туда, куда теперь ему сказано, то есть в тот же корень диска С:. Однако, установиться все равно не смог. Access Violation и закрытие приложения. Итог: 11-ая версия KVRT была послана в далекие места. При помощи скрипта, выложенного ранее, стаскиваем старую добрую девятую, без каких-либо эксцессов ставим в окружение BartPE и излечиваем ноут от заразы.

@музыка: Twisted Sister - I wanna Rock

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

We rise up for the things we believe in over and over again

Время от времени попадаются заявки о том, что письмо, отправленное через Outlook, не может достичь адресата. Но самое любопытное в подобных проблемах - адрес указан верно, и более того, перед глазами исходное письмо от того человека, которому письмо и пишем. В чем же проблема?
Ключом к пониманию ситуации является вот такая ошибка на сервере Exchange:

Event Type: Information
Event Source: MSExchangeTransport
Event Category: Categorizer
Event ID: 6015
Date: 13.12.2011
Time: 13:03:50
User: N/A
Computer: Server-Name
Description:
Categorizer is NDRing a recipient with address SMTP:mailto:[email protected] with reason code 0xc004054d ().

For more information, see Help and Support Center at go.microsoft.com/fwlink/events.asp.
Data:
0000: 4d 05 04 c0 M..À

Как видим, была попытка отправить письмо по несуразному адресу SMTP:mailto:[email protected]. Хорошо, создаем новый бланк письма, руками вбиваем [email protected], отправляем. А через пару-тройку минут получаем отлуп от сервера, что не удалось письмо доставить и ту же самую ошибку в логе приложений на сервере. В чем же проблема?
А заключается она в кэше ранее набранных адресов. Лежит этот файл по следующему пути:
%USERPROFILE%\Application Data\Microsoft\Outlook\< OutlookConfigurationName >.NK2
Outlook - довольно умная программа, вместо набранного руками верного адреса подставила тот, что уже давно попал в кэш. И в итоге письмо летит в никуда. Выходом является очистка сбойной записи из кэша. Чем чистить? Идем на www.nirsoft.net/, стаскиваем оттуда мелкую утилитку под названием NK2Edit и с ее помощью смотрим все внутренности кэша. Интересующая нас запись будет обладать не типом SMTP, как все нормальные, а типом MAILTO. Удалять или править запись - вопрос личных предпочтений.

@темы: MS Exchange

15:50

Home folders

We rise up for the things we believe in over and over again

Продолжаем наводить порядок.
На этот раз объектом преследования выступают домашние папки пользователей. Есть куча учеток уволенных сотрудников. У кого-то из них их домашние каталоги перенесены с боевого файлового сервера в архив, у кого-то нет, и зря занимают место. Надо от этого избавиться. Как быть? Для начала нужно получить список всех уволенных, это достаточно просто.
Далее учитываем тот факт, что домашняя папка названа по логину сотрудника, следовательно, нужно каждый из выбранных логинов проверить на наличие в пути следующего вида:
\\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

We rise up for the things we believe in over and over again

В продолжение записи, опубликованной ранее.
Как известно, при блокировании учетной записи сотрудника, в почтовый ящик этого человека почта продолжать поступать будет. Это не 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

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

We rise up for the things we believe in over and over again
Вздумалось мне посмотреть, что же из себя представляет тестовая лаборатория от Microsoft с развернутым в ней Forefron Endpoint Protection. Давно хотел оценить, что предлагает МС на рынке защиты конечных компьютеров. Результаты, надо сказать, просто удивительные:

Для тех, кто не в курсе - копия операционной системы, установленная в развернутой виртуальной машине, не прошла проверку подлинности. Причины остаются за кадром, важен сам факт. Напоминаю, это скриншот официальной виртуальной лаборатории.

Ну а второе - лишнее подтверждение тому, что Windows 2008 Server Computer Manager, написанный на .NET - все же очень сильно проигрывает по отзывчивости старому доброму ММС образца 2003 версии.


@музыка: Lifescapes - Awakening (да, Хокть, оно все еще крутится на автоповторе)

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

We rise up for the things we believe in over and over again
Если кратко, то первый - это анахронизм уже во времена Windows XP. Абсолютно неинформативен и даже вреден. В 2008, Windows 7 уже появился вменяемый Resource Monitor.
А полностью история выглядит так. Есть корпоративный антивирус, имя которому Trend Micro Office Scan 10.5. Да, да, кто "в теме" - тому уже все ясно. Есть система наблюдения за состоянием серверов, которая исправно докладывает в контрольной панели о том, что на каком-либо хосте нештатная ситуация. Как и сегодня - на одном из серверов зарегистрировано расходование огромного количества памяти. Свободной осталось пара процентов, а это RODC, который таким никогда не страдал. Открываем Task Manager - тишь и благодать. Но ведь свободной памяти нет... Открываем любимый Process Explorer и видим прекрасное:

Особое внимание на процесс TmListen.exe. Это мелкая служба, задача которой принимать команды от сервера Trend Micro. Второй столбец - это объем памяти, который данная служба сейчас действительно занимает в RAM. Первый же - сколько эта служба подгребла под себя за все время своей работы. Тут и RAM, и Page File. Полтора гигабайта. Служба, которая просто принимает собщение от центра контроля, и больше ничего. У меня просто нет слов.
А самое противное, эта утечка памяти проявляется не только на одном сервере, а практически на всех компьютерах, где стоит клиент TM, а стоит он, по понятным причинам, везде. Рабочие станции спасает тот факт, что они все же перезагружаются. Постоянно работающие же серверы - под ударом. Лечение простое - Unload Client, Run Client. И до следующего раза, который будет где-то месяца через два.

@музыка: Lifescapes - Awakening

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

We rise up for the things we believe in over and over again
В мире линуксов эта вещь не нуждается в описании - о ней в курсе все. В мире Windows то же самое известно под именем Event Collector. Было настроено ранее, но результат откровенно разочаровал. Вот пример сообщения, которое можно увидеть:

Log Name: Application
Source: Windows Server Update Services
Date: 16.11.2011 14:13:17
Event ID: 13001
Task Category: (6)
Level: Warning
Keywords: Classic
User: N/A
Computer: XXXXXXXXXXXXXXXXXXXXXX
Description:
The description for Event ID 13001 from source Windows Server Update Services cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
Client computers are installing updates with a higher than 10 percent failure rate. This should be monitored.

И это - самое безобидное, последняя строка хоть какую-то информацию дает о том, что происходит со службой на удаленном сервере. В большинстве же случаев будем довольстоваться именно вот этим: The description for Event ID XXX from source XXXXXXXXXXXX cannot be found.

А централизованное хранилище логов все же хочется. И решили с коллегой-никсоидом попробовать связку syslog-ng + Snare Agent for Windows.
Скажу сразу - именно то, что нужно. Полный текст сообщения преобразовывается именно в текст, после чего уже в таком виде пересылается в базу данных на syslog-ng. Настройка агента весьма подробно описана в официальной инструкции, так что проблем быть не должно. За одним исключением. В последней на данный момент версии агента на странице настройки сетевых параметров через web-интерфейс присутствует занятный баг: при попытке выставить приоритет отсылаемых событий в DYMANIC, после сохранения настроек приоритет выставляется в Emergency, что доставит немало головной боли тем, кто уже наблюдает за событиями на syslog-ng. Как побороть - очень просто, нужно зайти в редактор реестра и в следующем ключе - HKEY_LOCAL_MACHINE\SOFTWARE\InterSect Alliance\AuditService\Network сменить значение параметра SyslogDynamicCritic на единицу. После чего перезапустить службу Snare. В результате приоритет в окне настроек выставится в DYNAMIC, что нам и нужно.
Если кого-то это заинтересовало - официальная страница Snare Agent for Windows: InterSect Alliance.

We rise up for the things we believe in over and over again
Запись скорее для себя, чтобы помнить: как найти все динамические группы рассылки в домене. Обычный однострочник с использованием Quest AD, единственный затык - это незнание того, что динамические группы это объект AD, принадлежащий классу msExchDynamicDistributionList. Ну а с этим знанием все становится до безобразия просто:
get-qadobject -ldapfilter '(objectClass=msExchDynamicDistributionList)'

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

@темы: PowerShell, Scripting

12:58

Time Zones

We rise up for the things we believe in over and over again

Как всем известно, благодаря инициативе нашего президента 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 (Кавказское время (Зима) для русской версии ОС). Перезагрузка компьютера не потребуется.
После этого, уже имея запас времени, можно разбираться с причинами неудачи установки апдейтов.

@темы: PowerShell, Scripting

We rise up for the things we believe in over and over again

Когда-то доводилось мне писать о весьма удручающем баге в Android-телефонах - отсылка СМС не тому получателю. Ради интереса залез в этот тред посмотреть, чего нового написано. В самом конце оставлена пара записей от куратора этого сайта (судя по всему). Вот они, что называется, без купюр:
Comment 1820 by [email protected], Jun 23, 2011
I'm going to block further comments on this issue because it is suspected of placing excessive load on one part of our server-side software for Google Project Hosting.


И вторая (видать с правами что-то не то было):
Comment 1821 by [email protected], Jun 28, 2011
Corrected permissions to just block additional comments because of server load.


Мир должен знать своих героев!
Читаем статус этого треда:
Status: Released
Owner: [email protected]
Closed: Jan 2011
Type-Defect
Priority-Critical
Version-2.2
ReportedBy-User
Restrict-AddIssueComment-Commit

Google, огромное спасибо за такую дезу, но факт остается фактом, в прошивке 2.3.3 этот баг сохранен и так же хорошо воспроизводится, как и раньше.
Печально. Очень печально, что такая крупная, и вроде как уважаемая компания не удосуживается дать хоть какую-то обратную связь.

@музыка: Galaxion - Sleeping Beauty

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

We rise up for the things we believe in over and over again

А началось все с того, что стукнуло мне в голову посмотреть, не вышло ли новых прошивок для моего Ведроида. Сказано - сделано, LG Mobile Support Tool на старт, внимание, марш. Да, он запустился, попросил соединение с телефоном и... не нашел оного. Как так? Устройство на столе, USB хвост подключен и к нему, и к системнику. Порт заведомо рабочий, пару часов назад в нем жила флешка. Нет, нету у тебя устройства, дорогуша, вынь да положь.
Чем черт не шутит, переключаем хвост в другой порт. Та же история. Так, если устройство в ОС не видно, стало быть дело может быть в драйверах, ибо устройство как USB хард-диск видно и работает, но оно же "Composite USB device". Не беда, драйверы все в наличии. Сносим текущие, ставим посвежее. Как уже можно догадаться - результат тот же. Ну черт с тобой, VMWare на старт, внимание, марш. Свежая VM, подключаем устройство туда. Неа, нету у тебя устройства, дорогуша, вынь да положь. Ну что за напасть...
К слову сказать, LG PC Suite отличился ровно тем же, устройства просто нет. Ладно, перезагрузка трубки, попытка подключения... тот же эффект.
Начинаем прикидывать. Вся информация дублирована в облаке (контакты, фото). Все программы, которые там стоят, можно и переставить, и довольно быстро. Устройству делается Factory Reset.
После этой весьма и весьма жесткой процедуры робот весело мигает сообщением о том, что он у нас базируется на Android 2.3.3. Это уже хорошо, потому что изначально LGP500 работает на версии 2.2, прошивку 2.3 ждали очень долго и мучительно. Подключаем к USB хвосту, и о, чудо! Девайс прекрасно обнаруживается! Ладно, отставляем это дело, проводим первоначальную настройку телефона. Добавить Google-аккаунт, вычистить все от ненавистных ярлычков на контакт, одноклассники, янедкс- и гуглопоиск и тому подобного барахла. Поставить все необходимые мне ярлыки, настройки... После всей этой косметической оттделки можно и софт докидывать. Вход в Маркет, выбор первого из нужных приложений, установка. Все отлично. Докидываем половину из оставшихся и вспоминаем, что через веб-сайт на ПК это делать несколько удобнее. Заход в Android Market на компьютере, выбор нужного приложения... а дальше челюсть пробивает пол до фундамента: "У вас нет подходящего Android-устройства для установки данного приложения". Это уже за гранью понимания. Проверяем список устройств и понимаем, что там пусто. Простите, а где все? Где все ранее (в марте месяце) установленное? Ну хорошо, даже если был сделан хард-ресет, и после оного информация с аккаунта Google удаляется, уже сейчас как минимум три программы должно светиться, и сам телефон - тоже. Нет, нифига, говорит нам гугл, нет у вас телефонов. Идите в магазин, купите, активируйте, тогда я может быть чего-нибудь и покажу. Ах ты ж зараза.
Лезем в справку, читаем - для того, чтобы телефон появился в списке устройств на сайте, необходимо зайти в Маркет с этого телефона, авторизоваться в нем, а затем уже зайти на сайт на ПК, введя тот же логин и пароль, под которым авторизовался в Маркете на телефоне. Проклятие и еще раз проклятие, все это было сделано!
Ладно, нам не привыкать! Второй Hard-reset. Только на этот раз учетку Google подключаем уже после того, как об этом попросит Маркет. Ввели, авторизовались. Даже поставили одно из нужных приложений. Лезем на сайт, в списке устройств ноль. Да твою ж... материнскую плату! Обновить страницу и с удивлением обнаружить, что телефон наконец-то опознан сайтом, но без этого самого приложения. Да и фиг с тобой. Уже через сайт добавить все необходимые программки, удостовериться, что они появились в списке установленных и со спокойной душой закрыть Маркет.
Можно приступать к обновлению самого ПО телефона (да, я знаю, что вообще-то делается наоборот). В этот раз LG Mobile Support Tool отрабатывает на ура, прошивка меняет свою букву в идентификаторе на актуальную. Для успокоения души прогоняется поиск обновлений еще раз, после чего эта самая душа офигевает, ибо найдено еще одно обновление. Ну что ж, как работает, например, WSUS, известно, некоторые обновки ставятся сугубо последовательно, так что ставь. LG Mobile Support Tool проверяет соединение с телефоном, после чего говорит, что данное обновление этим телефоном НЕ ПОДДЕРЖИВАЕТСЯ! Да твою ж... материнскую плату дважды!!! А хотя бы написать, что это за обновление, бывает? Нее, не бывает, вот вам ссылка на сайт LG - разбирайтесь сами. Сволочь. На это у меня уже сил не хватило.
В течение всех этих разборок рядом сидел товарищ, любитель яблочных огрызков, подкалывали друг друга, чтоб не так уж паршиво было. "А вот у нас в Секте...", "Да ну вас, у нас, робототехников, веселее". И все в таком духе.

Какие выводы можно сделать из всей этой истории? За всю свою жизнь у меня было два телефона, способные общаться с ПК. Это Benq-Siemens S68 (он лежит до сих пор, как резервный), и я считаю его идеальным для себя аппаратом; и Ведроид, который был взят из-за функционала. Я не жалею о том, что связался с Android, но вот такие казусы все же портят впечатлений от платформы. И тут уже даже не знаешь, это вина платформы или производителя самого устройства, в данном случае LG. Но по крайней мере я знал, что на Google-платформе такое возможно. А ведь есть еще огромное количество людей, которые берут андроидов только из-за того, что это массово, по принципу - у Васи есть, стало быть он крут, а я чем хуже. Люди, перед покупкой все же читайте материалы о том, что именно вы покупаете. Или все же порасспрашивайте знакомых знающих людей о плюсах и минусах такой покупки.
И еще одна претензия - это ПО для связи мобильника и ПК. Почти ни один из известных мне производителей (известных мне - читать как марки, прошедшие через мои руки) так и не смог написать вменяемое программное обеспечение для связи этих устройств в Windows. Почти. Единственный, кому это удалось (да, я знаю, что сейчас полетят помидоры) - это Microsoft. ActiveSync, конечно, тоже не без нареканий, но все они сводятся лишь к тому, что в случае возникновения ошибки по ее коду мало, что скажешь. Зато в процессе работы и настройки все просто супер. Лаконично, просто, понятно. Остальные же... куча мастеров, которые не нужны вовсе. Интерфейсы явно были написаны в состоянии измененного сознания (ну а как же без выпендрежа в наши-то дни, когда всем правит маркетинг). Да дьявол с ними, с интерфейсами, даже свою прямую обязанность: связь двух устройств, это самое ПО далеко не всегда выполняет так, как надо. Чего уж говорить обо всем остальном...

@музыка: Galaxion - Aftershock

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

We rise up for the things we believe in over and over again

Подкинули намедни интересную задачку. Есть папка. В папке кучка 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

@темы: PowerShell, Scripting

We rise up for the things we believe in over and over again
Вот задумайтесь, какой самый большой почтовый ящик (электронная почта) вам приходилось в вашей жизни видеть? Вот что довелось узреть мне:

При условии, что число в третьем столбце - это не байты, а килобайты, становится страшно. А потом сотрудники удивляются, почему это Outlook начинает периодически показывать сообщение о том, что программа "пытается получить данные с сервера", и зависать.
Ах, да, мы же клиенто-ориентированная компания (просто клиентами для IT-отдела являются сами же сотрудники). Все для них, все ради них, все для их удобства. Если меня сейчас читает кто-то из руководящего состава какой-либо компании - мой вам совет: когда ваш системный администратор положит на стол проект по введению квот на почтовые ящики (если их еще нет), прислушайтесь к его словам. Это только по неопытности кажется, что предельные размеры ящиков - зло, на самом деле пользы от них намного больше, чем неудобства. Это не прихоть IT отдела, это суровая необходимость.
К слову сказать, после очистки от всего шлака, объем того ящика резко уменьшился до 1.2 Гб. Только вот на размер почтовой базы данных это не повлияет, к сожалению. Для уменьшения базы ее нужно дефрагментировать в offline-mode, а это полноее ее отключение где-то на полдня.

@музыка: Frank Borell - Wake Up in Paradise (Dream Spirit Mix)

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

We rise up for the things we believe in over and over again

Перепись всего серверного хозяйства. Эта процедура не давала мне покоя все то время, что я работаю. До текущего момента это был стандартный 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

We rise up for the things we believe in over and over again

Окончание истории, начатой тут. Как я и предполагал, процесс удаления файлов растянулся надолго. Аж на двое суток неторопливого выпиливания орды мелких, очень мелких файлов. MFT от такого поворота дел просто в ужасе была, поскольку вся эта мелочь явно хранилась прямо в ней. Статистика это подтверждает: на диске рабочей станции на 70 с небольшим тысяч файлов MFT заняла около 70 мегабайт, а вот на многострадальном файловике на те же 69 тысяч она уже разрослась аж до 4 Гб! Ясно, сильнейшая фрагментация после удаления всего мусора, с этим еще придется повозиться, но главное, работа антивируса, все же починено.

@музыка: E.S.Posthumus - Anumati

@темы: Viruses and Spam, Security

We rise up for the things we believe in over and over again

По непонятной причине стоящий на файлопомойке клиент корпоративного антивируса отцепился от управляющей консоли. Offline режим, и все тут. Принял решение его переустановить, хотя и помню об замечательной утилитке IpXfer, которая и нужна для переподключения клиента к другому серверу. Или тому же самому, как раз вот в таком случае.
Сказано, сделано, команда на удаление отдана. В процессе видно, что удаление происходит с ооочень большим скрипом, удаление служб продолжалось минут 15, на стадии удаления файлов система воткнулась еще на 40 минут. Все симптомы зависания. Делать нечего, распечатывается специальный документ, и пошагово проходим процедуру ручной очистки системы. В конце этого списка значится - reboot. Ясное дело, что боевой файловый сервер перезагрузить в течение рабочего дня никто не даст, значит, откладываем это дело до вечера, команду на рестарт можно отдать и из дому.
Перезагрузили. С радостным лицом поставили клиент заново и... поняли, что что-то пошло не совсем так, как надо.
"Все вышло не так, как ты планировал, Итэн..." (с) M:I:2
Вместо трех нужных служб в системе зарегистрированы только две. Более того, служба сканирования в реальном времени запускаться отказывается в принципе, ссылаясь на то, что ей нечего делать(!). И вспоминаем, что до повторной установки нужно было все же вынести старые каталоги антивируса. Дурная голова ногам рукам покоя не дает. Ладно, снова сносим антивирус, и ожидаемо получаем затык на стадии удаления файлов. Что ж, взглянем на этот процесс под микроскопом, то есть Process Monitor'ом, по критерию:
Process Name is NTRMV.EXE
Результат следующий - данный процесс вовсю елозит по папке C:\Program Files\Trend Micro\Office Scan Client\Hlog, открывает файл, пишет в него, закрывает.
Что ж это за логи такие? Залезаем в папку проводником и получаем зависший проводник. Снять процесс, попробовать пролезть другим шеллом. Получаем то же самое. Ладно, расчитай мне размер этой папки. Explorer.exe уходит в подсчеты, отгребает на себя гигабайт оперативной памяти, но результат удручает - найдено 0 объектов. К слову сказать, ни TC, ни cmd в этом плане тоже не отличились. Что же делать? Это логи, они находятся в папке, которая полностью предполагается к сносу. Их надо снести. Прпробуем метод, который меня еще не подводил:
cmd
cd c:\program files\trend micro\officescan client
del /f/s/q hlog\*.*
После минутного раздумья шел все же начал удалять все то, что там было. Тогда я еще не знал, сколько там всего.
Через минут 20 этого терзания диска я остановил процесс и попробовал снова зайти туда проводником. Увиденное повергло меня в шок. Проводник все же смог показать часть этого каталога: 300000 объектов, каждый размером меньше килобайта. И это - еще не весь каталог. Ну что же, повторный запуск удаления всего и вся через командную строку и ждать результатов. Это надолго...
P.S. Поймал себя на мысли, что это уже не первые боевые действия с данным антивирусом. Связка Trend Micro и Symantec Backup Exec уже показала себя во всей красе.

@музыка: KOTO - Die Klapperschlange

@темы: Этот безумный мир, Viruses and Spam, Security