TMG 2010 vs Java. War continues...

Фаза 2. Тестовая группа расширена до сотни человек. И что, вы думаете, что все прошло гладко? Да как бы не так.
Есть у нас подразделение, работающее с веб-сайтом, попортившим уже немало крови. Знающие да поймут меня: audatex. Вот честно, дай мне волю, искоренял бы ересь под названием Java всеми доступными мне методами. Впрочем, я отвлекся от темы.
Суть в следующем. Конфигурация браузера: использовать скрипт автоматической настройки маршрутизации. Интернет работает, страницы открываются, все авторизуется как надо. А вот как только дело касается запуска Java-апплета, процесс втыкается намертво. Java просто не может пробиться через файрволл. Ради теста переключаем пользователя на предыдущую конфигурацию и на старый прокси. А там настройка такова: прямо в браузере поставлена галка "Использовать прокси-сервер" и прописаны необходимые параметры. Честно, этот метод я не люблю, и в TMG 2010 я от него уйду (отсюда и скрипт автоматической настройки). Через старую прокси все работает. Закономерный вопрос выражается в трех символах: WTF?
Ковыряем интернет, находим вот такую любопытную статью:
support.microsoft.com/kb/925881 - An ISA server or Forefront Threat Management Gateway server requests credentials when client computers in the same domain use Internet Explorer to access Web sites that contain Java programs.
В частности, заинтересовало описание второго метода решения проблемы. О сетевых настройках внутри самой JVM как-то не подумалось, а зря. Что ж, идем на проблемное рабочее место и начинаем играться с параметрами JVM. Результат неутешителен. Попытка использовать ее настройки по-умолчанию (Use browser settings) провалена, как и описано выше. Попытка прописать новый прокси прямо в JVM - снова неудача. Попытка подставить тот же адрес сценария автонастройки - дальше продолжать? Остается последний вариант - Direct connection. Я точно знаю, что он сработает, но в то же время использовать его я не могу. Потому что в этом случае запрос пойдет на старую прокси. Что ж делать?
Остается только одно, установить на машину TMG/ISA client, чтобы он заворачивал, причем гарантировано, все запросы на новую прокси. Сказано - сделано, клиент поставлен, настроен, JVM сказано - ломиться напрямую, мимо прокси. Настройки браузера приведены к виду указанному ранее - через сценарий автонастройки. Все заработало.
Ну а теперь, как говорилось в известной передаче - внимание, вопрос? Нафига козе баян? То есть зачем в JVM такое богатство настроек прокси, если реально работают только два варианта, а один из них еще и с серьезными ограничениями?
Нет, никогда мне не подружиться ни с Java в общем, ни с разработчиками на этой платформе.

@музыка: Davol - Lucky day

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

---

TMG 2010. It's a war.

Вот и добрались мои руки до этого "замечательного" продукта - Treat Management Gateway 2010. Все та же линейка ISA-образный файрволлов, которые я от всей души ненавижу, и с которыми волею судьбы приходится работать. Весьма своеобразные это файры, должен сказать. В копилке уже два случая, за которые очень хотелось бы пристально посмотреть в глаза разработчикам. Итак, начали.
1. Во всей документации сказано, что ISA/TMG - файры, обрабатывающие правила исключительно по их следованию в списке - от первого до последнего. Еще во времена ISA 2004 у меня появились большие сомнения в том, что это верно. TMG 2010 и его функция имитации трафика с логами этого процесса только подтвердили эти догадки:
условия теста - есть правило, разрешающее доступ всем на группу сайтов yammer.com. Ну и последним, естественно, идет правило, запрещающее все и всем, правило по-умолчанию.
Имитация трафика - пакет по протоколу http на сайт yammer.com. Имя пользователя несущественно, доступ в разрешающем правиле - для всех.

результат теста

4810 12.09.2012 9:40:41 fff8de32 Firewall service The Firewall service is performing rule evaluation.
4811 12.09.2012 9:40:41 fff8de32 Firewall service Protocol: BranchCache - Retrieval
4812 12.09.2012 9:40:41 fff8de32 Firewall service Packet properties: Source IP address: N/A Source array network: Internal Destination IP address: N/A Destination array network: External
4813 12.09.2012 9:40:41 fff8de32 Firewall service Forefront TMG will check only rules that are associated with the protocol BranchCache - Retrieval.
4814 12.09.2012 9:40:41 fff8de32 Firewall service Forefront TMG is evaluating the rule [System] Allow MS Firewall Control communication to selected computers.
4815 12.09.2012 9:40:41 fff8de32 Firewall service The source port does not match the rule.
4816 12.09.2012 9:40:41 fff8de32 Firewall service Forefront TMG is evaluating the rule Default rule.
4817 12.09.2012 9:40:41 fff8de32 Firewall service The rule Default rule matches the packet and may deny it. However, a rule that precedes this rule in the list of policy rules and matches the packet will take precedence and may allow the packet.
4818 12.09.2012 9:40:41 fff8de32 Firewall service The rule Default rule blocked the packet.
4819 12.09.2012 9:40:41 fff8de32 Firewall service The Firewall service is performing rule evaluation.
4820 12.09.2012 9:40:41 fff8de32 Firewall service Protocol: HTTP
4821 12.09.2012 9:40:41 fff8de32 Firewall service Packet properties: Source IP address: N/A Source array network: Internal Destination IP address: N/A Destination array network: External
4822 12.09.2012 9:40:41 fff8de32 Firewall service Forefront TMG will check only rules that are associated with the protocol HTTP.
4823 12.09.2012 9:40:41 fff8de32 Firewall service Forefront TMG is evaluating the rule [System] Allow all HTTP traffic from Forefront TMG to all networks (for CRL downloads).
4824 12.09.2012 9:40:41 fff8de32 Firewall service source does not match the packet.
4825 12.09.2012 9:40:41 fff8de32 Firewall service Forefront TMG is evaluating the rule [System] Allow HTTP/HTTPS from Forefront TMG to specified Microsoft error reporting sites.
4826 12.09.2012 9:40:41 fff8de32 Firewall service source does not match the packet.
4827 12.09.2012 9:40:41 fff8de32 Firewall service Forefront TMG is evaluating the rule [System] Allow HTTP/HTTPS requests from Forefront TMG to specified sites.
4828 12.09.2012 9:40:41 fff8de32 Firewall service source does not match the packet.
4829 12.09.2012 9:40:41 fff8de32 Firewall service Forefront TMG is evaluating the rule [System] Allow HTTP/HTTPS from Forefront TMG to specified Microsoft Update sites.
4830 12.09.2012 9:40:41 fff8de32 Firewall service source does not match the packet.
4831 12.09.2012 9:40:41 fff8de32 Firewall service Forefront TMG is evaluating the rule [System] Allow MS Firewall Control communication to selected computers.
4832 12.09.2012 9:40:41 fff8de32 Firewall service The source port does not match the rule.
4833 12.09.2012 9:40:41 fff8de32 Firewall service Forefront TMG is evaluating the rule Yammer.
4834 12.09.2012 9:40:41 fff8de32 Firewall service The rule Yammer matches the packet. The packet is allowed.
4835 12.09.2012 9:40:41 fff8de32 Firewall service The rule Yammer allowed the packet.
Покупайте наших слонов. Первым делом проверено правило тотального запрета, и ясен красен, что тестовый пакет ему удовлетворяет. Хорошо хоть, что тут же показывается ремарка, что, мол, есть тут у нас какой-то список правил, так уж и быть, проверим и его...

2. Обработка адресов в URL Sets. Если меня читают те, кто еще застал в своей жизни символы-маски со времен DOS - меня поймут. Как вы думаете, если в правиле задано следующее - разрешать всем доступ на сайты, удовлетворяющее маске *yammer*, пропустит ли TMG 2010 пользователя вот по такому пути: http : // yammer . com / sitename (без пробелов, естественно)? Как ни странно, ответом будет однозначное НЕТ. В то же время, если в правиле изменить маску на *yammer.com - файр станет пускать на все сайты группы yammer.com и все их подразделы, что и требовалось.
Эх, старпер я, как есть старпер. До сих пор мыслю категориями DOS, но ведь и работали они до сих пор...

@музыка: Diane Arkenstone - The sacred forest

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

---

Outlook 2010 Profile Issues

Вот честно, когда вышел Office 2007 и его ленточный интерфейс, я ругался как черт. Хоть в Outlook там оставили привычный интерфейс. Когда же вышел Office 2010 - я начал плеваться и на Outlook тоже. Ибо более... ээммм... оригинально работающей программы я в славном племени офисных представителей не видел. Впрочем, речь пойдет не об интерфейсах, а о другом. Начать с уже ставшего головной болью сообщения "Загрузка профиля" (впрочем, тут я все же склонен винить больше серверную часть, нежели клиентскую) и закончить проблемой, которую пришлось решать совсем недавно.
Проблема эта проявилась в двух вещах. Первое - при работе в кэшированном режиме Outlook напрочь отказывается загружать автономную адресную книгу. Если вспомнить, что в кэш-моде идет работа исключительно с автономной книгой - все очень печально. Вторая проблема - автонастройка конфигурации Outlook. В какой-то момент в 100% случаев при ее использовании ответом стало: Unknown Error 0x80070057.
Обе любопытны. Дело в том, что обе они оказались завязаны на автоматическое создание профилей. Потому что:
1. Профиль, созданный руками, не испытывает никаких проблем с загрузкой OAB.
2. Профили, создаваемые руками с указанием адреса сервера и имени клиента, не испытывают никаких проблем с процессом, собственно, создания.
Пришлось отказаться от полностью автоматического создания почтовых конфигураций и заменить полуавтоматическим созданием - клиенту нужно будет три раза нажать кнопку Далее. Вопрос - как это сделать, и как было реализовано полностью автоматическое создание. Ответ рядом - setup.exe /admin, а уже в ней редактировать файл настроек Office 2010, который применяется в процессе установки всего комплекта. Лежит он в папке Updates. Открываем его, смотрим, видим, что помимо всего прочего именно там и задано поведение Outlook - "Определить изменения существующего профиля по умолчанию. Если профиль по умолчанию не существует, в Outlook создается новый профиль по указанным настройкам". Но по каким настройкам - неясно. Ок, сбрасываем этот параметр в дефолт, создаем новый файл настроек, восстанавливаем остальные параметры, сохраняем полученный MSP-файл в том же каталоге Updates, убив исходник. Проблему OAB на этом решили, новосозданные конфигурации принимают адресную книгу без всяких проблем. Осталось починить autodiscover, чтобы конфигурации могли создаваться как положено, а не через ввод параметров подключения. Поиск по гуглу вывел на статью в базе знаний MS, вот она: support.microsoft.com/kb/2028193/en-us?fr=1
Целиком и полностью наш случай. Решается установкой хотфикса. Прекрасно, но ставить руками хотфикс на каждую машину утомительно, а через WSUS данная обновка не распространяется. Что делать? Воспользоваться механизмом установки хотфиксов на стадии начальной установки самого пакета. Как? Очень просто - запрашиваем пакет с сайта, распаковываем его, и полученные msp и xml файлы кладем все в тот же каталог Updates в дистрибутиве Office 2010. С этого момента на всех новых установках офиса проблема будет решена. С уже установленными компьютерами - хуже, их придется обработать руками или через скрипт. Последнее предпочтительнее.

@музыка: Grave Digger - Highland Farewell

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

---

VMWare Multicore Virtual Machines

Возможность создания многоядерного процессора для виртуальной машины - это благо. Особенно, когда речь идет о ВМ под различные базы данных, где условия лицензирования, прямо скажем, драконовские, а производительности хочется побольше. Яркий пример - лицензия, привязанная к количеству процессоров на сервере. Стандартный метод повышения производительности - увеличение количества процессоров, влечет за собой расходы на дополнительную лицензию ПО. Что же делать?
Вот тут и приходят на помощь множественные ядра процессора. В ВМ процессор будет один, но более производительный за счет 2 и более ядер. Как же такого добиться?
В базе знаний VMWare есть статья, которая может служить отправной точкой для создания multicore cpu ВМ. Вот она:
Setting the number of cores per CPU in a virtual machine
Ок, следуем рекомендациям, изложенным в данной статье, выставив параметр number of virtual processors равным 1 (один процессор), и cpuid.coresPerSocket равным 2 (нужно два ядра), запускаем машину, и вот что получаем:

Получаем 1 одноядерный процессор. Результат совсем не тот, что ожидался.
Для сравнения, вот что получается, если выставить number of virtual processors равным 2, а cpuid.coresPerSocket - 1:

Видим, что у нас два одноядерных процессора. Такая комбинация настроек сработала так, как и следует. Но опять же, не то, что нам в итоге необходимо.
Делаем фокус - ставим оба параметра равными 2. Получаем прекрасное:

Что и требовалось. Процессор один, число ядер - два.
То есть получаем, что по факту в vSphere 4.1 параметр number of virtual processors определяет не количество самих процессоров, а количество ядер, которое будет отдано в распоряжение ВМ. А число процессоров уже рассчитывается по формуле number of virtual processors / cpuid.corespersocket.
Все вышеуказанное справедливо именно для vSphere 4.1. Как дела обстоят в vSphere 5 - мне неизвестно, пятую версию использовать еще не доводилось.

@музыка: Buck-Tick - Dress (Trinity Blood Mix)

@темы: VMWare, Virtualization

---

Outlook 2007 - Outlook 2010 Transition

Наверное, тег MS Exchange в этой записи не совсем к месту, но пусть будет. В будущем будет проще самому находить запись, если еще понадобится.
Итак, преамбула. Пользователь работает на компьютере под управлением старушки Windows XP 32 bit и Office 2007 с прямым подключением к серверу Exchange. В Outlook настроено порядка 20(!) конфигураций, и да, они все используются.
Фабула - сотруднику меняют компьютер и ставят ящичек под управлением Windows 7 x64 с Office 2010 на борту. Одновременно с этим включается Outlook Cached Mode.
А теперь разбор прошедшего полета под названием 2007->2010.
Поскольку администраторы - люди достаточно ленивые (множество скриптов тому лучшее подтверждение), и я не исключение, то воссоздавать на новом компьютере все это множество конфигураций руками - выше моих сил. Благо, относительно недавно довелось узнать, где Outlook хранит всю информацию о конфигурациях, место их дислокации - реестр:

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\

И там уже множество кустов, по кусту на конфигурацию. Хватаем корневой Profiles, экспортируем его в reg-файл, который позже применяется на другой машине. Эта операция меня выручала уже неоднократно и сбоев не было.
Далее сотрудник открывает свою рабочую конфигурацию, в ней все хорошо. Открывает любую из побочных и нарывается на прекрасное: Outlook не может открыть файл по следующему пути C:\Program Files(x86)\Microsoft Office\Office14\%ConfigurationName%.ost
Где-то на этом месте должен быть смайлик с кодом *shocked*. Зачем офисному приложению, которое никак язык не повернется назвать "диким" (ибо MS же!!!) лезть в программный каталог для хранения пользовательских файлов.
Первое действие - скорее импульсивное, нежели продиктованное хоть каким-то рассуждением - если мы имеем ошибку записи ost-файла (кэша почтового ящика), то стоит этот кэш порубить, тем более, что конфигурация побочная, ее кэшировать бессмысленно. Однако, к нужному результату это не привело, ошибка как была, так и осталась. Уже ради интереса дал сотруднику временно права на запись в этот каталог (да простят меня коллеги-администраторы за подобный шаг). Логично, что все конфигурации заработали. Да, они посоздавали файлы-болванки для кэшей почтовых ящиков, но полностью их стаскивать на локальный диск не стали. Уже хорошо, уже можно работать.
В ходе увлекательной беседы с  Cybeon (кстати, за определение "недостаточно правоверный виндузятник" спасибо отдельное, добавлю в self-intro ) пришли к выводу, что где-то в недрах конфигурации сохранен путь, по которому таки должен сохраняться ost-файл в случае включения Cached Mode. Но где? Все, что касается описания конфигурации и ее параметров, сосредоточено в том самом кусте реестра, указанном выше. Но ни намека на пути там не видно. Однако, небольшое гугление открыло всю глубину моей неправоты. Эти пути там есть, просто они закодированы: Клац!
Я не знаю, чем руководствовались в Редмонде, когда приняли решение о кодировании практически всех параметров конфигурации (безопасность, что ли), но забот они тем самым добавили изрядно.
Но несмотря на все эти изыскания так и не стало понятно, почему Outlook делает попытку сохранения именно в программный каталог. Пока что единственное предположение - в момент создания конфигурации в ней был сохранен путь вида C:\Documents and Settings\%USERNAME%\Application Data\Microsoft\Outlook, а в ОС Vista и выше этого пути не существует. Бедный почтовик, нарвавшись на подобное, решил сбросить все в место, о котором знает наверняка, именно программную папку, куда доступ обычной учетной записи на запись запрещен. К чему это привело - описано выше.
Ну и самое главное - как теперь побыстрее выправить эту ситуацию. Пуск, Панель управления, сменить представление с "Категории" на "список" (иначе настройку почты днем с огнем не сыскать), Почта (32-бит), Конфигурации. Далее выбрать нужную сбойную, Свойства, Файлы данных, Параметры, Вкладка Дополнительно, кнопка Настройка файлов автономных папок. И да, именно там мы и увидим, что в качестве расположения файла выбрана программная папка. Нажать кнопку Не использовать, после чего закрыть все открытые окна до списка конфигураций. И так - все два десятка. В любом случае быстрее, чем создавать их заново.

@музыка: Scooter - Faster Harder Scooter

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

---

SRP #2 - Deal with shortcuts

Итак, скелет этой политики все же сделан. После ковыряния гугла и technet'a найдено решение, как блокировать запуск *.lnk из всех каталогов, кроме необходимых. Причем метод должен работать для любой установки ОС, независимо от диска, версии, языка.
Сутб проста - расположение особых пользовательских каталогов зашито в системном реестре, откуда мы можем их получить и подставить в параметры политики. Таких путей лично я насчитал 10. Рабочий стол, Мои документы, Программы, меню Пуск, и Автозапуск. Пять на пользователя и эти же пять для профиля All Users. Именно их и надо по условиям задачи подставить в исключения. Что ж, раскрываем список Additional Rules и указываем нижеприведенные 10 строк в режиме Unrestricted.

%HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Desktop%*.lnk
%HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Personal%*.lnk
%HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Programs%*.lnk
%HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Start Menu%*.lnk
%HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Startup%*.lnk
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Desktop%*.lnk
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Documents%*.lnk
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Programs%*.lnk
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Start Menu%*.lnk
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Startup%*.lnk

Осталась самая малость: собрать все остальные пути исключения для "дикого" софта, провести тестирование на фокус-группе. В случае успеха в области действия политики можно смело проставить Domain Users, и забыть о таких поганцах, как Skype, QIP, Google Chrome и иже с ними. Кто в курсе, меня поймет.

Track of the Day (TotD): Davol - Jhalinka
Time range: 1:57 - 2:17

Прослушать или скачать Davol Jhalinka бесплатно на Простоплеер

@музыка: Davol - Jhalinka

@темы: Security

---

DFSR Backlogged files

Что такое 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

---

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

Упало в ящик письмо от нашего любимого отдела травокуров (маркетинг, то есть). Мол, сделали рассылку, а назад почему-то вернулся список людей, которым она не дошла. И более того, все эти люди - уже давным давно числятся, как уволенные. В принципе, не дошла, и ладно, но хотелось бы, чтобы их в рассылке вообще не было.
И то верно, зачем нагружать почтовик лишний раз. Запрашиваю имя той рассылки, вспоминая, что при увольнении у нас учетка удаляется из всех групп. Как групп безопасности, так и групп распространения. Тем временем приходит ответ от травокуров с именем той рассылки. Читаю и понимаю, что это динамическая группа, и простым удалением из наших групп распространения тут дело не обойдется. И более того, группа создана в Москве.
Пишу московским админам, мол, так и так - на основании каких критериев формируется данная рассылка. Ответ пришел, из которого стало ясно, что одна из московских же систем определенным учеткам развешивает расширенные атрибуты (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

---

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

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

---

Oneliners #6 - Archiving

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

---

.NET Framework 3.5 Installation

В течение вот уже пары лет нам удавалось избегать этой процедуры. Потому что ставить 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

Event Type: Error
Event Source: Application Management
Event Category: None
Event ID: 101
Date: 16.12.2011
Time: 11:19:15
User: NT AUTHORITY\SYSTEM
Computer: SPB-TESTXP
Description:
Не удалось назначить приложение RGB9RAST из политики Software - NET 3.5. Ошибка: В процессе установки произошла неисправимая ошибка.

Event Type: Error
Event Source: Application Management
Event Category: None
Event ID: 103
Date: 16.12.2011
Time: 11:19:15
User: NT AUTHORITY\SYSTEM
Computer: SPB-TESTXP
Description:
Не удалось удалить назначение приложения RGB9RAST из политики Software - NET 3.5. Ошибка: В процессе установки произошла неисправимая ошибка.

Event Type: Error
Event Source: Application Management
Event Category: None
Event ID: 108
Date: 16.12.2011
Time: 11:19:15
User: NT AUTHORITY\SYSTEM
Computer: SPB-TESTXP
Description:
Не удалось применить изменения для параметров установки приложения. Невозможно выполнить изменения для этого программного обеспечения. Должны существовать предшествующие записи в журнале, содержащие необходимые сведения. Ошибка: В процессе установки произошла неисправимая ошибка.

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1085
Date: 16.12.2011
Time: 11:19:15
User: NT AUTHORITY\SYSTEM
Computer: SPB-TESTXP
Description:
Клиентское расширение групповой политики Установка программного обеспечения не может выполняться. Проверьте ранее выдававшиеся сообщения об ошибках этого расширения.

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

---

KVRT... 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

---

Cached Addresses

Время от времени попадаются заявки о том, что письмо, отправленное через 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

---

Home folders

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

---

Oneliners #5 - Mailboxes of Fired Users

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

---

Forefront Endpoint Security lab.

Вздумалось мне посмотреть, что же из себя представляет тестовая лаборатория от Microsoft с развернутым в ней Forefron Endpoint Protection. Давно хотел оценить, что предлагает МС на рынке защиты конечных компьютеров. Результаты, надо сказать, просто удивительные:

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

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

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

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

---

Task Manager vs Process Explorer

Если кратко, то первый - это анахронизм уже во времена 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

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

---

Сбор логов с Windows-based серверов.

В мире линуксов эта вещь не нуждается в описании - о ней в курсе все. В мире 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.

---

Oneliners #4 - Query Based Distribution Lists

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

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

@темы: PowerShell, Scripting

---

Time Zones

Как всем известно, благодаря инициативе нашего президента 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