Trend Micro Office Scan upgrade

Встала задача - обновить наш антивирус. С версии 10.6 на версию 10.6 Service Pack 1. В принципе, это достигается при помощи внутренних средств обновления, но мне захотелось поднять полностью новый сервер и перевести клиентов на него. Потому как работа старого меня не устраивала, даже бекапы базы данных не делались, валились с ошибкой. Впрочем, это не удивительно, сервер этот был последовательно обновлен с 10 до 10.6. Наверняка уже столько хвостов осталось, что ужас. В общем - чистая установка - как всегда, лучший выход.
С самой установкой и настройкой проблем вообще никаких. С переносом клиентов, которые на текущий момент активны - тоже. А вот что делать с теми машинами, которые могут месяцами не включаться? Их ведь просто так не перетащишь, команду не дашь с административной консоли. Что ж, такую задачу решать уже доводилось - придется воспользоваться сценариями запуска компьютеров. В итоге клиент сам после запуска переползет, куда надо.
Основа сценария - маленькая утилитка IpXFer, которая и пинает клиента в нужную сторону. Выполняется на целевом клиенте с соотвествующими ключами от имени администратора или самой машины (если речь о сценарии запуска). Одновременно с этим не мешало бы проверять - а не переехал ли клиент уже на новый сервер. Ведь если он там - повторно перекидывать его туда не надо.
Начнем с проверки. Кучу своих настроек клиент Trend Micro Office Scan хранит вот тут:
HKEY_LOCAL_MACHINE\SOFTWARE\TrendMicro\PC-cillinNTCorp\CurrentVersion
Нас очень сильно интересует параметр Server, в котором и прописывается "место жительства" клиента. Выполнив команду
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\TrendMicro\PC-cillinNTCorp\CurrentVersion" /v Server
получаем требуемое.
Теперь полученное нужно проверить - что же там лежит. Ради интереса воспользовался вот таким методом:
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\TrendMicro\PC-cillinNTCorp\CurrentVersion" /v Server | findstr "%ServerName%"
Сначала мы получаем значение параметра Server, затем в полученном пытаемся найти имя нашего сервера. Если найдем, все в порядке. Если не найдем - получим ошибку в системной переменной %ErrorLevel%. Следующий шаг - проверка этой переменной. Если она равна нулю - не делать ничего, клиент уже на "месте прописки". Если же не равно нулю - значит клиент у нас бродяжничает, и его пора пришпилить на место.
Отдельный вопрос - x64 системы. У них расположение нужного нам ключа реестра немного отличается:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\TrendMicro\PC-cillinNTCorp\CurrentVersion
Следовательно, нам нужно будет еще проверять, на каком типе систем исполняется скрипт. Ну а потом, после всех проверок, запустить нужную утилитку с кучей параметров.
Целиком весь сценарий будет выглядеть вот так:

echo off
if exist "%systemdrive%\program Files (x86)" (goto x64) else (goto x86)
:x86
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\TrendMicro\PC-cillinNTCorp\CurrentVersion" /v Server | findstr "%ServerName%"
if NOT %errorlevel% == 0 call \\server\share\ipxfer.exe -s %ServerName% -p %HTTP_Port_Number% -m 1 -c %Client_Port_Number%
goto rest

:x64
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\TrendMicro\PC-cillinNTCorp\CurrentVersion" /v Server | findstr "%ServerName%"
if NOT %errorlevel% == 0 call \\server\share\ipxfer_x64.exe -s %ServerName% -p %HTTP_Port_Number% -m 1 -c %Client_Port_Number%

:rest

Обработка напильником - стандартная. Вместо %ServerName%, %HTTP_Port_Number%, %Client_Port_Number% подставить нужные значения и положить обе утилитки ipxfer и ipxfer_x64 в какую-либо общую папку, куда могут обратиться компьютеры домена.

P.S> После обновления клиента у него меняется значок. Кто-то из "бдительных" пользователей это заметил и тут же начал трезвонить в IT отдел - "Помогите, у меня на компьютере вирус под названием Trend Micro Office Scan!". Ирония в том, что сотрудник сам не знает, на сколько же он прав...

@темы: Security

---

Remote Control...

Нет, сегодня речь пойдет не о таких вещах, как RDP или LogMeIn. На днях приехала первая из трех заказанных карт удаленного управления серверами Aten IP8000. Обычная PCI плата, которая добавляет функционал iLO (это если в привычных мне терминах HP), а по-русски - возможность управлять сервером на протяжении всего времени его работы, от самого старта по питанию до выключения этого самого питания. Ну и бонусом приятные штуки как Remote Media и ему подобное.
Все бы ничего, но захотелось настроить авторизацию на этой карте через Active Directory, это банально удобнее. Все необходимые настройки для этого есть. Открываем форму, вбиваем все необходимые данные:

Отличие от этого скрина в том, что галку Enable Authorization я тогда поставил.
Сохраняем настройки, даем рестарт карты... и понимаем, что LDAP-авторизация не заработала. Перепроверяем настройки еще раз - понимаем, что все внесено верно, но не работает. Штудируем мануал и видим, что в мануале раздел LDAP вообще никак не освещен. Что за...
Гугл, запрос. Ответом стала шокирующая информация из инструкции к другому KVM той же компании - для того, чтобы работала авторизация через MS AD, нужно расширить схему AD! Засада, потому что таких прав у меня нет, да и для чего такие сложности, вообще неясно.
Еще более вдумчивое изучение того же справочного файла сказало: отставить панику, сейчас все сделаем. И действительно, все сделали. Теперь по шагам:
1. Выбор между LDAP или LDAPS. Тут все очевидно - что используется, то и нужно выбирать, причем LDAPS предпочтительнее. Негоже пересылать информацию об учетных записях в открытом виде (привет старому доброму PsExec).
2. LDAP Server IP, Port. Тоже все понятно, где LDAP развернут - тот IP адрес и подставляем. Порты в подавляющем большинстве случаев используются стандартные.
3. Timeout. Как долго наша карточка будет ждать ответа от LDAP. Тоже ничего особенного.
4. LDAP Administrator DN. Имя административной учетной записи, от которой будут происходить операции в AD. До сих пор не могу в толк взять, для чего здесь нужно именно административную запись вводить. Ведь карта в самой AD ничего не меняет, а читать из каталога позволено всем. Но делать нечего, вводим учетку в формате:
CN=username,OU=users,DC=example,DC=com
5. LDAP Administrator Password. Все просто - пароль указанной административной учетки.
6. Search DN. Вот здесь уже интереснее. Это имя контейнера, в котором, а также во всех его подконтейнерах, учетные записи будут иметь право логина на нашу карточку.
7. IP8000 Admin Group. Параметр, связанный с предыдущим. Члены указанной группы из AD будут обладать правами администратора и на карточке. Все остальные - только базовыми, об этом чуть ниже.
И остается та самая галочка Enable Authorization. Именно она определяет логику работы карточки с AD. Итак:
1. Параметр включен. Для определения того, кто может зайти, кто не может, а кто является администратором, карточка будет искать среди атрибутов учетных записей два особенных, которые и создаются во время расширения схемы AD.
2. Параметр выключен. На карточку смогут зайти все пользователи, чьи учетные записи находятся в OU, указанном в пункте 6, и будут обладать урезанными правами. Пользователи же, чьи учетные записи находятся в группе, указанной в пункте 7, смогут делать с карточкой что угодно. Изменения схемы в этом случае не требуется.
Таким образом, параметр Enable Authorization я отключил, после чего авторизация через LDAP заработала так, как требовалось.
И отдельно о правах пользователей. Ради теста зашел под специальной технической учеткой, созданной для различного рода проверок, с ограниченными правами на карточке. Каким же было мое удивление, когда я увидел, что такой учетке доступен раздел Power Management и кнопки выключения сервера и его жесткой перезагрузки. Эта засада будет подстерегать тех, у кого административные учетные записи лежат в структуре AD в том же OU, что и обычные учетки сотрудников. Обходится этот момент просто - нужно создать отдельную OU, перенести туда нужные учетки, и именно эту OU прописать в настройках LDAP-авторизации карты. После этого обычным учетным записям зайти на нее просто не удастся, они будут отфильтрованы, а административные учетки будут обладать всеми необходимыми правами.

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

---

Как теряют клиентов...

История, развернувшаяся буквально на моих глазах сегодня с утра.
Итак, дано - Android Galaxy Tab. Человек, обладающим им, купил(!) в Google Play(!!!) фильм и вздумал его на своем устройстве посмотреть. Я вообще впервые в жизни увидел человека, который в GPlay что-то приобрел, учитывая, что в России этот сервис запустился на полную катушку совсем недавно. Ну ладно, купил и купил. А что с ним дальше делать-то? Известно, что, качать. 1.2 Гб учебного пособия по суициду под названием Анна Каренина. Одна беда - это 1.2 Гб трафика, который на SIM далеко не бесплатен, потому-то человек в наш отдел и пришел, присосаться к местному запароленному Wifi. Ну да ладно, выпустили. Фильм стащился, все замечательно. Нажимаем на нем в списке загрузок, планшет думает секунд 10, после чего с критом вышибает процесс, отвечающий за обработку видеофайлов.
Почесали тыковки, перезагрузили аппарат, мало ли... После перезагрузки ничего не изменилось. Ладно, ок, нельзя вызвать из окна загрузок как в приличном виндовом DDE, не вопрос, откроем в приложении. В качестве этого самого приложения выступает Play: Фильмы. Запускаем его, заходим в учетную запись, вызываем там список уже купленного добра. Добро показано, что только и ждет, когда его просмотрят, и будет ждать еще 1 день и 1 час. Да, да, та самая аренда контента во всем своем великолепии. То есть мы уже на часах, а добраться до контента не можем.
Запускаем фильм оттуда - получаем прекрасное - 521 - Ошибка воспроизведения. И контакты для обращения в службу поддержки Yotaplay. Ну хорошо, напарник расчехляет телефон (я не особо люблю болтать, мне переписка ближе) и начинается цирк.
До поддержки дозвонились быстро. Мальчик бодро отвечает, мол, обновите, пожалуйста, наше ПО до последней версии. Проверяем, действительно, на планшете версия древнее. Обновили. ОК, запускайте. Запускаем, ошибка осталась, но на этот раз тысача-какая-то. Ладно, почистите кэш приложения. ОК, заходим в менеджер приложений планшета, выбираем там нужное нам ПО, открываем его свойства, сносим кэш. Результат - тот же.
Владелец планшета уже нервно хихикает. Я откровенно стебусь над всем этим, как обладатель телефона на андроиде. Коллега на телефоне просто в шоке. Продолжаем диалог с поддержкой, в течение которого проходит рекомендация: снесите все данные этого приложения. Да-да, это означает снести фильм в том числе. Ок, кнопочка Remove Data отрабатывает на ура. Заходим в учетную запись приложения уже с нуля, видим, что ни одного фильма нет, но нам предлагают "Анночку" либо посмотреть в он-лайн режиме, либо скачать заново. Ради интереса по подсказке мальчика из техподдержки включаем он-лайн просмотр и, о, чудо, видим нужное. После чего мальчик радостно заявляет, что поскольку у нас фильм был скачан в предыдущей версии ПО, то после обновления нужно все закачанное снести и перекачать заново уже в новой версии.
Дальше трубку берет владелец планшета и оформляет заявку на возврат средств за непросмотренный фильм, а сам фильм удаляет из учетной записи, благополучно выключая планшет.
Ну и как полагается по законам жанра - вопросы по истории и мораль оной.
Вопросы довольно просты. "Почему?" и "Кто виноват?". Почему при обновлении версии страдает возможность воспроизведения контента, хотя сохранение такой возможности - базовый принцип работы. И кто виноват, что в "production" вылезло такое? Тем более, что за это взимается вполне себе определенная плата во вполне реальной валюте.
А что до морали... думаю, каждый сфомирует ее для себя сам.

@музыка: Metal Gear Rising OST - LQ84i battle

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

---

Audio redirection.

По причине собственного скудоумия в приступе гнева отослал за предел свои наушники, которыми пользовался дома, сидя за компой. Стало совсем печально, мало того, что за тот же предел ушел жесткий диск со всем медиа-контентом, так и остатки этого контента теперь слушать не на чем. Совсем печально. Есть мелкие наушники капельки, к компе их подключить, в принципе, можно. Однако, после такого финта ушами придется сидеть, практически уперевшить мордахой в экран, так как наушники короткие, и прицепить их можно только к хвосту системника (на морде разъемов для наушников/микрофона нет). Идти в лабаз за новыми наушниками - лениво. Что же делать?
Вспоминаем, что в наличии имеется старый добрый Ведроид. Смартфоны на андроиде - штука очень массовая, значит, программ на него написали уже до одури много, и наверняка есть и то, идея чего мне пришла в голову. Запрос в известный поисковик, клик в маркете на Install, после чего загрузка серверной части... et voila, звук с компы теперь по Wifi перенаправлен в телефон, а с телефона можно слушать при помощи тех самых мелких капелек.
Если кому-то еще придет в голову такая безумная мысль - софт называется SoundWire. Бесплатной версии хватает выше крыши, если не обращать внимания на включающееся раз в 40 минут голосовое объявление "SoundWire - free version".
Ощущения, надо сказать, забавные. Уйти в другую комнату, не прерывая хоть не просмотра, так прослушивания Babylon 5 - да, это что-то новое )

@музыка: Metal Gear Rising: Revengeance - LQ84i battle

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

---

SkyDrive #2

В продолжение предыдущего разбора полетов с Небесным Диском.
Причину рухнувшей синхронизации найти все же удалось. Оказалось, что синхронизация отказывает тогда, когда SkyDrive пытается закачать файл, созданный прямо в веб-интерфейсе, или залитый в облако через него же. И валится синхронизация, когда клиент находится за файрволлом. Поскольку используется TMG, пришлось, вооружившись гуглом, копаться в нем. Ответ найден - всему виной Malware Inspection, если быть совсем точным - параметр "Force content requests (remove HTTP Range header)". Подробно - здесь: Клац!
Отключение этого параметра восстанавливает синхронизацию тут же.

@темы: Security

---

SkyDrive

Во время запуска этого сервиса было много шума. Что ж, место там есть, пора и попробовать его в деле.
Итак, два компьютера, на обоих установлен клиент, версия - последняя. Структура проста: папка Документы, папка Разное. В папке документов лежит все то, что нужно сохранить как бекап. Папка Разное предназначена для обмена данными между двумя компьютерами (лень мне флешку таскать, лень). Папка документов должна синхронизироваться с домашним компьютером. Папка Разное - с домашним и рабочим.
Задача не такая уж и сложная, учитывая, что SkyDrive вслед за Дропбоксом функцию выборочной синхронизации уже представил и внедрил. Настраиваем параметры, видим что на домашнем компьютере синхронизация идет как и полагается. На рабочем же... а вот тут жестокое разочарование - синхронизации НЕТ ВООБЩЕ. Клиент навечно зависает в состоянии Processing changes. При этом папку Разное он видит, даже создает ее на жестком диске рабочего ПК. Ужасно, просто ужасно.
Делаем финт ушами - даем полную синхронизацию всего, что есть в облаке, с рабочим ПК. Затем, когда синхронизация пройдет успешно, поставить выборочный режим. По уверениям Microsoft в этом случае клиент сотрет с компьютера все, что не относится к выбранным для синхронизации файлам и папкам, после чего будет спокойно кушать только выбранное. Сказано - сделано. После включения выборки все "лишние" файлы были послушно удалены с компьютера, но после этого... да, вы правы, синхронизация опять накрывается. Перезапуск клиента эффекта не дает. Включение полной синхронизации процесс обмена файлами восстанавливает тут же. Браво, Microsoft!
Причем "браво" - дважды. И второй раз - за то, как вы вообще прописали логику работы этого приложения. Никогда не думал, что MS сами напишут просто ярчайший пример "дикого софта". Итак:
1. Клиент ставится прямо в профиль пользователя (изменить это НЕЛЬЗЯ)
2. Папка временных файлов создается прямо в корне диска, на котором будет лежать пользовательская папка SkyDrive. Она будет скрытой, называется SkyDriveTemp.
И все это - с вытекающими проблемами, если на компьютере действует жесткое ограничение прав на запись в каталоги вместе с Software Restriction Policy.
За эти два пункта хочется пристально, очень пристально посмотреть в глаза тому человеку, который все это придумал.

@музыка: One More Time - Here comes the ghost

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

---

Parse and sort

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

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

server: DNS-fqdn
Address: DNS-ip

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

foreach ($line in $Var) {
		#CO found
		if ([regex]::ismatch($line,"10\.10\.(3|4|5|6)")) {move to CO}
		
		#Filial 1 found
		if ([regex]::ismatch($line,"10\.20\.1")) {move to filial 1}
		
		#Filial 2 found
		if ([regex]::ismatch($line,"10\.20\.2")) {move to filial 2}

		#Filial 3 found
		if ([regex]::ismatch($line,"10\.20\.3")) {move to filial 3}
	}

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

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

@темы: PowerShell, Scripting

---

Windows Distribution Point #2

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

$colupdates = get-childitem E:\WinXP-Update-Pack\
foreach ($update in $colupdates) {
    $cmd = "E:\WinXP-Update-Pack\$update"
    $args = "/passive /integrate:d:\winxp"
    write-host "Integrating $cmd"
    start-process $cmd -argumentlist $args -wait 
}

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

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

@темы: PowerShell, Scripting

---

Windows Distribution Point.

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

$colISO = get-childitem D:\temp\архивы\*.iso
cd "C:\Program Files (x86)\DAEMON Tools Lite"
foreach ($iso in $coliso) {
    write-host "mounting $iso"
    $args = "-mount 0,$iso"
    $cmd = "dtlite.exe"
    start $cmd -argumentlist $args
    start-sleep 5
    foreach ($dir in (get-childitem g:\)) {
        #get win7 x86 rus updates 
        if (test-path g:\$dir\Windows7\x86\rus) { 
        copy g:\$dir\Windows7\x86\rus\*.* E:\Win7\x86\rus}
        
        #get Win7 x86 neu updates
        if (test-path g:\$dir\Windows7\x86\neu) { 
        copy g:\$dir\Windows7\x86\neu\*.* E:\Win7\x86\neu}
        
        #get Win7 x64 rus updates
        if (test-path g:\$dir\Windows7\x64\rus) { 
        copy g:\$dir\Windows7\x64\rus\*.* E:\Win7\x64\rus}
        
        #get Win7 x64 neu updates
        if (test-path g:\$dir\Windows7\x64\neu) { 
        copy g:\$dir\Windows7\x64\neu\*.* E:\Win7\x64\neu}

        #get WinXP x86 rus updates
        if (test-path g:\$dir\WindowsXP\x86\rus) { 
        copy g:\$dir\WindowsXP\x86\rus\*.* E:\WinXP\x86\rus}
    }
}

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

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

@темы: PowerShell, Scripting

---

HP Printing and scanning software.

Все же есть свои плюсы в состоянии вертиго. Есть. Просто надо суметь их разглядеть, хотя само по себе это состояние не шибко приятное, но если уж голова начинает работать, то, похоже, работает те самые одиозные 146%, не иначе.
Проблема с неожиданно отказывающим ПО от компании HP преследует меня практически все годы, что я работаю на текущем месте. Ибо именно здесь приходится особенно плотно работать с этим... поделием, назовем его так. Суть проблемы проста: есть МФУ моделей HP LaserJet 305x. Да, я знаю, что они уже сняты с производства и, похоже, поддержки тоже, но "берем то, что дают" (с). Есть для этих МФУ пакет программ, одна из которых обеспечивает сканирование документов с этих МФУ по сети. Весьма полезная штука, но и капризная до ужаса. В один "прекрасный" день вот эта мелкая программа по сканированию просто отказывает. Причины - непонятны. Симптомы - запускается процесс hpqscnvw.exe (он-то и выполняет всю работу по сканированию), отъедает 27 Мб памяти, после чего просто висит в памяти, создавая нулевую нагрузку по части CPU. Признаков какой-либо активности - нет.
Журналы системы - пусто, ошибок - никаких. Режимов отладки - тоже. Ладно, наша еще и не там не пропадала - весь этот комплекс ПО переустановить не так долго. Сказано - сделано, программы удалены, подготовлен дистрибутив оных, распакован, запущен инсталлятор. Последний проводит все проверки, убеждается, что места на жестком диске хватает, копирует все файлы, начинает процесс установки... и натыкается на нечто, в результате чего на экране появляется ненавистное "Обнаружена неустранимая ошибка". И маленькая ссылочка, мол, нажмите сюда, будет загружена документация, как это бороть.
Почему эта ошибка ненавистна? Потому что встречалась уже неоднократно, даже не так - ОЧЕНЬ неоднократно. И никакой диагностической информации. Окей, хорошо, я не администратор, я всего лишь начинающий эникей, поэтому будь добра, скачай то, что рекомендовано и запусти.
Скачиваем, запускаем, видим буквально следующее:
Ошибка #27 - Файл не помечен к установке.
Какой файл - не скажем, почему не помечен к установке (во формулировка-то!) - догадывайтесь сами.
И далее следует такое решение - снести все, что программа уже успела поставить, после чего... запустить установщик заново.
Честно, день, когда я эту ошибку победил, я с полным правом буду рассматривать, как самый позорный день в жизни. Накипело, просто накипело и все тут. Стол выдержал, хорошо сделан. Потери - небольшой ушиб ребра ладони. Позор в том, что это на глазах сотрудника, ибо я просто устал от всего этого идиотизма, когда нас, пользователей (всех) производители держат за полных дебилов и скармливают нам только крохи информации, отсылая в поддержку по любому поводу.
Ладно, отступление кончилось.
Для очистки совести я выполнил все те "рекомендации", что были указаны в файлике-помощи. Как можно догадаться, к положительному результату это не привело. А обращаться к безотказно рабочему методу - полной переустановке всей ОС очень не хотелось, компьютеру всего 3 недели с небольшим, его физически не успели еще загубить. Да, как было верно подмечено на одном из блогов - русские администраторы не гнушаются лишний раз переустановить Windows, если понимают, что это будет банально быстрее, чем искать причину проблемы - время нынче очень дорого на предприятиях.
Окинул взглядом еще раз всю систему после того, как деинсталлятор подчистил за собой следы неудачной установки всего ПО, на всякий случай проверил службы. И вот тут-то обомлел. Потому что даже после сообщения о том, что ПО полностью удалено, в системе весело работает пара служб от HP - Net Driver HPZ12 и Pml Driver HPZ12.
Что ж, с этими двумя разговор будет очень коротким:
sc stop "Net Driver HPZ12"
sc delete "Net Driver HPZ12"
[SC] DeleteService SUCCESS

sc stop "Pml Driver HPZ12"
sc delete "Pml Driver HPZ12"
[SC] DeleteService SUCCESS
И на всякий случай посмотреть, какие файлы отвечают за эти службы. Сейчас уже не вспомню их имена точно (их два), но начинаются они на HPZ и расположены в каталоге %SystemRoot%\system32. После остановки и удаления служб снова пытаюсь поставить все нужное ПО, но нарываюсь на ту же ошибку. Как же так? А вот так - службы удалены, да, но файлы-то остались. Заходим в %SystemRoot%\system32 и видим с десятка полтора файлов с префиксом HPZ, среди которых есть и файлы этих несчастных служб. На всякий случай не удаляю их, а переношу в другой каталог, после чего перезапускаю систему и пытаюсь поставить ПО. Результат удивителен - все поставилось без малейших ошибок.
3 с лишним года. "Неустранимая ошибка", чтоб вам всем в компании HP одна реклама в интернетах, по телевизору и радио была, forever and ever 'till the end of time.
Итак, краткое резюме по проблеме.
При переустановке полного набора драйверов и программ от МФУ серии HP LaserJet 305x необходимо:
1. Удалить текущую инсталляцию ПО.
2. Остановить остающиеся после удаления службы Net Driver HPZ12 и Pml Driver HPZ12.
3. Удалить из каталога %systemroot%\system32 файлы, отвечающие за две вышеуказанные службы.
4. Удалить сами службы при помощи стандартной команды sc delete < service name >
5. Перезапустить систему и установить нужное ПО начисто.

@музыка: Tom Cruise - Pour some sugar on me

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

---

Office read-only files

UPDATE @ 09.10.2012. Продолжение расследования, принесшее весьма любопытные результаты.
"Профиль - смотри профиль, ответ там." (с) Hikedaya
После очередного возникновения подобного непотребства снова запустил File Monitor и изучил его результаты более вдумчиво. Нашел следующее:
Запрос пути: C:\Documents and Settings\%username%\Local Settings\Temp
Результат: not found.
Что за черт? Раньше это почему-то в глаза не бросилось, а вот теперь... И что примечательно, почти сразу после этого сообщения идет следующее:
Запрос пути c:\Windows
Действие: создание файла
Результат: Access Denied.
Налицо неспособность Excel найти временный каталог для создания tmp-файла. Что за черт... Лезу в C:\Documents and Settings\%username%\Local Settings и вижу, что каталога Temp там действительно нет. Все становится понятно. Excel пытается создать файл по требуемому пути, видит, что этого пути не существует в принципе, после чего ломится, как яркий представитель "дикого" софта, в системный каталог, который уж по всякому будет на месте. И уже там получает отлуп, после чего обиженным тоном сообщает, что файл, который мы хотим открыть, "может быть предназначен только для чтения или быть зашифрован".
Любопытнее всего тот факт, что, как уже и было написано, файлы формата Office 2007 продолжают спокойно открываться. А все потому, что тот же Excel 2007 при открытии таких файлов располагает временные документы вовсе не в C:\Documents and Settings\%username%\Local Settings\Temp, а в C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\Content.MSO. И самое смешное - даже если этого каталога нет, он будет создан по требованию, в отличие от предыдущего, который автоматически создается только один раз - при создании профиля.
В общем, как только руками в профиле пользователя был воссоздан каталог Temp, функционал работы с файлами legacy-форматов восстановился тут же. Ради интереса уничтожил каталог Temp у себя на машине. Результат предсказуем, я получил ровно то же самое поведение, что и на проблемной машине. Создал каталог заново - проблема исчезла.
Осталось понять, при каких обстоятельствах может исчезать, причем целиком и сразу, прямо во время работы, каталог Temp. Ведь там постоянно есть какой-нибудь файл, занятый каким-либо процессом. Следовательно, сначала надо тушить процесс (и еще узнать, какой именно), а потом уже удалять каталог. Но это уже тема отдельного расследования, с привлечением аудита файловой системы. Есть подозрение, что виной всему некорректная установка какого-либо обновления.
Ох и разрастется лог Security на машине-жертве...
Ну и галочка на будущее - если вы озаботились чисткой пользовательских профилей - удостоверьтесь, что в любой момент времени, когда пользователь работает в системе, каталог, обозначенный в переменной %TEMP%, действительно существует.

UPDATE @ 01.10.2012. Отбой. Все указанное ранее не является гарантированным решением. Сегодняшний день убедил меня в обратном, придется копать дальше...

Какое-то время назад на нашу компанию навалилась странная напасть. То на одном ПК, то на втором, то на третьем офисные приложения версии 2007 и выше начали выдавать странное. Им абсолютно не по нраву были попытки открыть файлы формата Office 2003. И именно 2003, потому что документы формата 2007 и выше продолжали открываться без проблем. И если Word выдавал что-то несуразное насчет повреждения файла, то Excel в таком случае радовал следующей ошибкой:
Excel cannot access %filename%. The document may be read-only or encrypted.
Когда это появилось на одной машине, я склонен был списать все на нестабильно работающий офисный комплект. На двух - заставило призадуматься, на трех - уже пора задуматься очень серьезно.
Первое. На шифрование вирусом это не похоже, потому что файлы все же открываются на других компьютерах.
Второе. Настойчивое гугление показало, что проблема может крыться в том, что у пользователя слетели права на файлы в его же профиле. Решение - переназначить права на каталог %userprofile% и ниже, уровень доступа - полный с заменой и наследованием прав от самого %username%. Этот вариант сразу же был отметен, как неработоспособный, потому что поражались только файлы office 2003. Лежащие буквально рядом office 2007 - открываются без проблем.
Третье - проблема лечится, но способ лечения радикальный: убить пользовательский профиль, создать новый, скопировать документы назад. Какое-то время именно этим способом и решал проблему, по крайней мере сотрудник после этого может работать, у меня появляется больше времени на ковыряние ситуации в целом.
В чем же причина и как бороть, если не перебивкой профиля? Апдейты ОС? Вряд ли, специально затормозил одобрение новых, поднял новую систему, накатил на нее все обновки, что есть, отдал сотруднику. Два дня нормальной работы, после чего бедолага попал под ту же раздачу. Значит, стопроцентно не апдейты.
Профиль... Перебивка спасает, значит само ПО не портится. Файлы тоже не портятся. Что может быть в профиле такого, что блокирует запуск файлов формата Office 2003 на приложениях новых версий?
Запуск SysInternals File Monitor, ковыряение результатов. При открытии файла Excel старается записать временный файл прямо в каталог %systemroot%, где нарывается на законный Access denied? Что это за дрянь? Теста ради запускаю тот же механизм наблюдения на "здоровом" ПК, вижу ТОТ ЖЕ результат. Значит, дело не в этом, но в уме галочку себе поставил. А голове все так же не дает покоя мысль: профиль - смотри профиль, ответ там. Но где?
Что у нас хранится в профиле? Настройки, всякая мелкая шушера из той же оперы да временные файлы. СТОП!
Однажды мне уже довелось раскапывать очень непонятное поведение Outlook: в какой-то момент он просто отказывался открывать любые вложения. Решением стала банальная чистка временного каталога оной программы. А поскольку примерно в то же время я озаботился вычисткой от всякого хлама пользовательских профилей вообще... Вот тут все это расписано подробнее.
Итак, временные файлы. А что если грохнуть все то временное месиво, что скапливается в пользовательских профилях, да посмотреть, откроются ли те злосчастные файлы? Сказано, сделано, тем более что и очередной "клиент" "подоспел".
rem clean office temp dirs
del /f/s/q "C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\Content.MSO\*.*"
del /f/s/q "C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\Content.Word\*.*"
Результат не заставил себе ждать - файлы открылись тут же. Можно выдохнуть. А в сценарий выхода пользователя из сеанса добавить вышеприведенные пару строк.
К сожалению, причина, по которой происходит вот такой затык в работе, пока что осталась неизвестной, впрочем, само существование файлов во временной папке после завершения приложения - уже достаточный глюк со стороны оного приложения, который не лечится уже много версий подряд.

P.S. Много думаю над тем, чтобы сократить команду очистки до следующей:
del /f/s/q "C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\*.*"
Но пока еще все же думаю...

запись создана: 30.09.2012 в 22:31

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

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

---

Users in groups...

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

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

@темы: PowerShell, Scripting

---

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