TDSS

Все же довелось столкнуться со зловредом, обозначенным в заголовке. Если быть точным, то с его модификацией TDSS.d. Очередное подтверждение тому, что азиатские антивирусы в нашей стране не могут считаться достаточной защитой.
Интересна ситуация, из-за которой и возникло подозрение на инфицирование чем-либо. При работе в IE 8 очень часто стали появляться сообщения вида:
Из-за проблемы на веб-странице IE закрыл вкладку и открыл ее снова
и перезагрузкой ранее открытой странице в той же вкладке, где она и открыта. А известно, что после двух обнаружений проблем браузер просто закрывает такую страницу и выводит сообщение об ошибке. Проявлялось стабильно на всех открываемых сайтах. Что ж, KVRT в помощь.
Результат - TDSS.d обнаружен в активном виде. Пристрелен. Последующая проверка тем же KVRT и TDSSKiller показала, что пристрелен качественно, рецидивов нет. Хотя есть мысль еще пройти по машине GMER'ом. На всякий случай...

@музыка: Amethystium - Odyssey (2006 - Emblem)

@темы: Viruses and Spam

---

Script run time

Время выполнения скрипта. Весьма важный показатель производительности системы. Ни с того ни с сего некоторые сотрудники начали жаловаться, что при загрузке компьютера уж очень много времени уходит на стадию "Выполнение сценариев запуска". Сценариев этих вообще-то к компьютерам привязано довольно много, и тот факт, что нужное на их выполнение время исчисляется далеко не секундами, а их парой-тройкой десятков - это норма. Но не 10 минут же! К тому же 10 минут - это deadline для системы, по достижении которого она (система) просто прекратит обработку сценариев и продолжит загружаться. Нужно узнать, какой из скриптов тормозит процесс.
Есть два варианта. Первый применим в том случае, если в домене не включена параллельная обработка сценариев - каждый следующий скрипт будет запускаться только по окончании выполнения предыдущего (это настройка по-умолчанию). В этом случае можно просто открыть консоль GPMC, взять интересующую нас систему и собрать с нее результирующий набор политик. Дальше на вкладке с перечисленными параметрами, которые применяются к системе из политик, можно раскрыть раздел сценраиев запуска и просто посмотреть, когда в последний раз был запущен тот или иной скрипт. Учитывая, что запускаются они последовательно - можно сразу увидеть, где узкое место.
Второй метод может пригодиться там, где параллельная обработка сценариев уже включена (это ускоряет процесс загрузки, по понятным причинам). Но для этого придется каждый выполняемый сценарий немного изменить - повесить на него "рамку":

sсript run time

'set file system and shell objects
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set WshShell = CreateObject("Wscript.Shell")

'set output file name
strUserProfile = WshShell.ExpandEnvironmentStrings("%USERPROFILE%")
'strSystemRoot = WshShell.ExpandEnvironmentStrings("%SYSTEMROOT%")
strFileName = strUserProfile + "\SCRIPTNAME.txt"
'strFileName = strSystemRoot + "\SCRIPTNAME.txt"

Set objFile = objFSO.CreateTextFile(strFileName)
objFile.Writeline Now
objFile.Close

'sсript BODY GOES HERE

Set objFile = objFSO.OpenTextFile(strFileName, 8)
objFile.Writeline Now
objFile.Close

'delete all references
Set objFSO = nothing
Set WshShell = nothing
Set strUserProfile = nothing
Set strSystemRoot = nothing
Set objFile = nothing
Эта рамка выведет время выполнения сценария в текстовый файл. Его расположение задается в блоке set output file name - в профиле пользователя (если измеряем производительность скрипта входа пользователя), либо в папке %SystemRoot% - если интересует скрипт загрузки самого компьютера. Естественно, эти пути можно и поменять под свой вкус.
Блок sсript body понятен и без объяснений.
Можно, конечно, обойтись и простым выводом на экран, а не в файл. Однако, учитывая, что лично мне придется эти изменения вносить в боевые версии сценариев, лучше лишний раз пользователям не докучать и выполнять все действия в фоне.

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

@темы: Scripting

---

Windows 2008 x64 Conversion to VMWare

Windows 2008 - единственная из систем, к которой пришлось применять индивидуальный подход при ее переносе с гипервизора XenServer на VMWare. Суть в том, что при удаленном переносе при помощи VMWare Converter Standalone в режиме клиент-сервер этот самый конвертер не может найти дисков исходной системы. Нет дисков - нечего конвертировать. А посему получаем ошибку.
Что делать? Выход прост - установить конвертер прямо на исходную машину и конвертировать ее. В этом случае с дисками будет полный порядок. Веселости начинаются уже после этого.
Итак, исходная система превращена в виртуальную машину, потушена. Виртуалка поднимается, устанавливает все необходимые драйверы, инструменты... Новому сетевому адаптеру назначается старый IP-адрес, сервер видит компьютеры нашей сети, компьютеры способны найти этот сервер и по имени, и по старому IP - все счастливы. А через месяц я вижу, что Windows 2008 радостно сообщает следующее:
0xC004F00F
The Software Licensing Service reported that the hardware ID binding is beyond level of tolerance.

Приехали, система "потеряла" активацию, хотя это и неудивительно. Удивительно другое - почему она не поймала ее заново? Пытаюсь вручную сказать ей, откуда брать всю необходимую информацию:
Elevated Cmd,
slmgr.vbs -skms x.x.x.x
slmgr.vbs -ato
Не выходит каменный цветок, а судя по сообщениям, приходящим в ответ на эту команду, что-то случилось с сервером KMS, который не в моем ведении:
0xC004F039
The software Licensing Service reported that the computer could not be activated. The Key Management Service (KMS) is not enabled.

Звоню ребятам, обслуживающим этого зверя, докладываю о проблеме, на том конце обещают разобраться. Ну а пока система поживет в grace-period, уж за 60 дней всяко решим проблему, и это еще без учета slmgr.vbs -rearm.
Недавно все же решил еще покопать, что же пошло не так, тем более, что эксперимент по установке нового экзепляра Windows 2008 и активации оного прошел успешно. Следовательно, KMS работает исправно, и проблему надо искать на стороне того самого сервера.
Ipconfig /all, route print - на первый взгляд все нормально. Но ведь не все же. Еще раз для верности ввожу просто ipconfig, без ключа расширенного вывода информации... результат потряс: системе был назначен IP-адрес, была назначена маска подсети, а вот шлюз по-умолчанию - не задан вовсе.
Это что же получается, я, такая умная "маша", тупо забыл поставить шлюз? Вбиваю нужный адрес, после чего выполняю принудительную активацию (сервер активации ведь уже прописан), и система радостно говорит, что ключ найден, получен, установлен, в общем - все просто замечательно. Ладно, ошибся, с кем не бывает.
Настала пора переносить второй сервер, тоже под управлением Windows 2008, причем он довольно капризен, и если что-то пойдет не так - хлопот будет много. Все как и раньше, конвертер на машину, запуск, успешное преобразование, поднятие машины, установка драйверов, назначение старого IP. И двойная проверка шлюза, специально даже на бумажке записал. Рестарт системы и... И шлюза снова нет в списках адресов! Вот же мерзавка Понятное дело, что в этом случае OCS FE просто не запустится, так как не увидит пула серверов. Ладно, хоть знаем, почему так - прописываем шлюз, еще раз перезагружаем сервер, и после этого убеждаемся, что все службы работают, все необходимые данные по сети бегают, а активация уже в автоматическом режиме пройдена.
Больше всего в этой истории смутило то, что несмотря на отсутствие шлюза сервер видел все в пределах нашей сети. Сеть же другого региона была недоступной. Да, о таблице маршрутов и on-link все же стоит помнить.

@музыка: Within Temptation - See who I am

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

---

Exchange 2003 OWA и кириллические учетные данные.

Весьма любопытный случай.
Один из сотрудников жалуется на то, что из дома не может попасть на свой почтовый ящик - система просто не принимает его учетные данные. Провожу тест у себя, сбрасывая пароль на стандартный для таких случаев - все отлично срабатывает. Ну не иначе где-то ошибся человек.
Раз, второй, третий... Умом понимаю, что что-то не так. Ну не может человек настолько упорно набирать пароль неправильно. Тем не менее, проблема заглохла, больше звонков длительное время не поступало.
Недавно эта неприятность снова голову подняла, но уже с другим сотрудником. Этот поступил умнее, пришел в отдел лично. Лично набрал свой пароль на консоли администратора - не пускает. Прямо тут же меняем ему пароль на стандартный - все проходит на ура. Сотрудник меняет пароль на свой собственный - и тут же получает отлуп. Как так?! Посмеялись, потом начали размышлять, что и к чему. В глаза бросился тот факт, что тестовый пароль на английском языке, а сотрудник свой набирал на русском. И задавал его на русском. То есть мы пришли к тому, что OWA по какой-то ей ведомой причине не принимает национальные символы в пароле. Ладно, рекомендовали сотруднику использовать англоязычный пароль, а для себя пометили задачку в выполнению, но не как горящую.
Сегодня все же дошли руки до поднятия ручного Exchange 2003 SP2. Настраиваю OWA, меняю у тестового пользователя пароль на кириллический, жму Enter - и я в ящике этого пользователя. Все чудесатее и чудесатее (с).
Форумы молчат. Есть упоминания о том, что имеется проблема в случае кириллических логинов, но здесь другой случай. На яндекс в подобных вопросах уже давно не надеемся, гугл разводит руками. Полчаса вдумчивого сравнения конфигурации... Затем мысль - а что у нас с настройками регионов и кодовых таблиц. На самом деле региональные настройки не так важны, нам деньги не мерять. А вот кодовые таблицы - это уже любопытно. Оказалось, что на боевом сервере в настройках кодировок для non-Unicode приложений стоит английский язык, на тестовом же сервере - русский. Ну что же - смена на русский на боевом, перезагрузка... Долгие 3 минуты ожидания, смена пароля тестового доменного пользователя, заход на OWA... Success!!!
Exchange 2003 SP2 и настройки не-Юникод приложений - такого я представить себе не мог. Теперь представляю.
Еще одна поставленная галочка, еще один случай в копилку. Надеюсь, кому-то эта запись сэкономит немало времени в подобной ситуации.

UPD. Если конфигурация Exchange 2003 включает в себя два сервера, front-end и back-end, менять кодовую таблицу нужно на front-end-сервере.

@музыка: Rise Against - Help Is On The Way Shift 2 Remix

@настроение: Shocked

@темы: Security, MS Exchange

---

Storage switch

По идее, еще пара седых волос, но все же нет, не такая история, как памятный мне полет KVM.
Итак, дано. Есть файловый сервер, подключенный к СХД по SCSI. Есть другая СХД, подключенная к другому серверу по FC, на которую через DFSR реплицировано порядка 2 ТБ пользовательского контента (да, да, все сетевые диски и тому подобное). Цель всего этого проста - старую СХД проапгрейдить до FC.
День Х, час Ч и... момент переключения хранилищ. В файловик установлен FC HBA, сервер подключен на место дублирующего, запуск.
Тест устройств показывает, что адаптер найден и опознан, ОС поднимается без вопросов. Свойства системы, управление дисками - раздел уже готов к работе, все данные видны, все на месте. Ради полного успокоения души набираю в командной строке: \\SERVER-NAME\... и понимаю, что что-то явно пошло не так. Из порядка 15 общих ресурсов видны всего 5. Админсистративные и пара завязанных на DFSR. Что делать? Без общих папок будет очень и очень много воплей.
В голове проносится мысль о том, что когда-то мне доводилось смотреть на описание общих ресурсов изнутри, в реестре. Вспоминаю, что Windows хранит информацию о конфигурации всех служб за 3 последних удачных старта системы. Что ж, придется покопаться в старине (файловик не перезагружался довольно долгое время):
Regedit, HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\LanmanServer\Shares
Bingo! Описание всех общих ресурсов на месте. Дальнейшее тривиально - экспортировать весь этот куст реестра в файл, заменить там раздел ControlSet001 на CurrentControlSet, сохранить, применить файл, перезапустить сервер. После перезапуска все общие папки вновь доступны.
Возможные потери очевидны - доступ пропадет у тех людей, кому разрешения были прописаны уже после теперь уже предпоследнего запуска файловика. Таких людей немного, и это радует.
Мораль истории - делать резервные копии. В данном конкретном случае - экспортировать куст реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares во всеми подпапками (она будет одна). Эта нехитрая операция поможет избежать несколько неприятных нервных минут.

@музыка: Yanni - Vertigo

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

---

Citrix XenServer -> VMWare ESXi

Долго я ждал этого перехода. Наконец, все подготовлено. СХД есть, пусть это все та же Арена, а не что-то монструозное, вроде EMC, сервер в наличии (планируется два для обхода отказа одного хоста), дело за малым - миграция самих машин.
У VMWare есть специальное приложение, называемое VMware vCenter Converter Standalone. Хорошая вещь, но поначалу смутило то, что файлы виртуальных машин, сделанные в Citrix, ей не поддерживаются. Не беда, всегда есть опция Convert this powered-on machine. Забавно, вроде бы машина и виртуальная, но Converter будет трактовать ее как физическую. Для нас же разницы не будет никакой.
Итак, после разбирательств с этой утилитой вердикт следующий:
Перенос машины, основанной на XP SP3 - без проблем.
Перенос машины, основанной на 2003 - без проблем.
Перенос машины, работающей под Windows 2008 x64 - а вот тут веселье. Те же параметры, что при переносе предыдущих типов систем, при нажатии на кнопку Go приводят к появлению окна, в котором написано просто прекрасное: The specified parameter was not correct: ". Да, именно с кавычкой и точкой в конце.
Ну вашу же... И ведь это не первое апреля. Ладно, откат действий назад и подробнейший разбор конфигурации. На странице свойств жесткого диска понимаем, что конвертер этого диска не видит в принципе. Ясна и природа ошибки - переносить-то нечего.
Важная деталь - сама утилита в полном варианте установлена на моей рабочей машине, используется функция переноса удаленной загруженной машины. Как видим - не работает. Ковыряние базы знаний на сайте VMWare дает следующее - попробовать установить конвертер на той машине, которую переносим, и запустить процесс локального переноса. Утилита должна быть запущена с повышенными привелегиями (Run as administrator).
Делать нечего, придется засорять виртуалку лишним ПО (потом удалять). Рассудив, что серверный процесс уже имеется, и можно попробовать поставить только клиентскую часть конвертера, поступаю именно таким образом. Результат не заставил себя ждать - злосчастное окошко все так же мешает процессу. Приходится сносить конвертер вообще, ставить с нуля в полном виде. Дальнейшее - по иструкции - Run as..., выбор параметров, запуск. Да, в такой ситуации все работает. Вроде как еще может помощь отключение UAC, но этот вариант не стал проверять. Хотя, отключить этот функционал и включить его после перемещения - куда быстрее, чем ставить и удалять конвертер целиком... Стоит рассмотреть и этот вариант, но это уже после выходных.

@музыка: David Arkenstone - Ancient Legend

---

Игры с роботами...

Да, снова на сцене мой Ведроид (так я обозвал свой новый телефон) - Ведро для краткости. Поставил на него довольно полезных программ, теперь сижу, играюсь, оцениваю. Набор таков: Dropbox, ES File Explorer, Wyse PocketCloud.
Первая (Клац!) весьма известна в ITшных около-ITшных кругах. Ставим клиент, выделяем на каждом компьютере, где клиент установлен, какую-нибудь папку, и наслаждаемся результатом - эта папка будет синхронизирована между всеми узлами. В том числе и телефонами, если к учетной записи еще и телефон подключен.
Вторая - (Клац!) - файловый менеджер для Ведроидов. Поклонники WMP и его идеологии библиотек могут меня закидывать чем угодно, но лично я предпочитаю, чтобы медиафайлы хранились в организованно дереве папок, мне так удобнее. Теги, конечно, хорошая вещь, но древовидная структура себя изживет очень нескоро. Поскольку по-умолчанию владелец телефона не имеет доступа к файловой системе напрямую, приходится ставить сторонний софт.
Третья - (Клац!) - небольшой наборчик для подключения к удаленным хостам через протоколы VNC и RDP. Веселья было море, когда увидел собственный рабочий стол на мелком (для этих целей) экране телефона. Одно могу сказать точно - работать на пальцеориентированном устройстве в окружении Windows - не самое приятное занятие, но тем не менее - пусть будет. Мало ли, в какие ситуации доведется попасть.
Все три программы есть в Ведроид-маркете в бесплатных редакциях.

@темы: Этот веселый мир, Android

---

Android.

Да, я решил "узнать своего врага в лицо". Купил себе на пробу LG-P500, он же Optimus One.
Прошло уже больше года с того памятного мне дня, как я впервые столкнулся с этой платформой. Если уложиться в несколько слов - она обрела человеческое лицо. Как ни странно, теперь работать с телефонами на базе этой системы стало действительно удобно. Быстрые, функциональные, батарею сильно не кушающие...
Но не все так гладко, как может показаться на первый взгляд. И вот почему:
SMS are intermittently sent to wrong and seemingly random contact.
По ссылке очень много иноязычного текста, рекомендуется к ознакомлению всем обладателям андроидовых телефонов.

Сухая выжимка:
Рано или поздно любой андроидовый телефон может отослать сообщение не тому человеку. Вместо нужного адресата он подставит контакт из вашего списка, и сообщение уйдет именно ему. Что за этим может последовать - просто включите вашу фантазию.
Дата первого сообщения в этом баг-трекере - 28 июля 2010 года. Честно говоря, даже Microsoft покуривает в стороне от такой скорости реакции на события такой степени важности.

Я с этим столкнулся лично. Перерыв кучу материала и проведя несколько тестов пришел к следующему выводу - не отвечать на сообщения, используя область уведомлений. Схема работы этого бага следующая. Вы принимаете сообщение от человека А, читаете его, отвечаете или нет - неважно. Затем вы получаете сообщение от человека Б, при помощи области уведомлений отвечаете на него. Дальше вариантов два: либо сообщение уйдет человеку Б, и все довольны; либо аппарат подставит в качестве адресата того самого бедолагу А, от которого вы получили сообщение ранее, и оба участника получают конфуз.
Баг непостоянен, может проявиться, может нет, но во всех случаях подставлялся именно предыдущий абонент, приславший сообщение, не случайный.

На всякий случай, информация о телефоне:
LG-P500
ver. 2.2
Kernel 2.6.32.9
Build FRF91

На сегодняшний день все, что мы имеем по этому инциденту, это признание компанией Google проблемы и обещание выпуска заплатки в ближайшее время:
www.bbc.co.uk/russian/science/2011/01/110107_go...
Смотрим на дату новости - 8 января.

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

---

Localization is EVIL (part 2)

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

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

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

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

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

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

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

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

@темы: Scripting

---

Trend Micro Office Scan vs Symantec Backup Exec

Переезд серверов завершен, хоть и с потерями (сижу дома и болею), надо до конца разобраться с резервированием информации. На очереди задача подружить Symantec BE и Windows 2008-based контроллер домена. И все бы хорошо, два программных продукта узнали друг друга, пожали руки и сказали - будем дружить; но не тут то было. При попытке загнать в бекап состояние системы на контроллере получили ошибку:
V-79-57344-65245 - A failure occurred accessing the object list.

Ковыряние сайта поддержки Symantec дало любопытный результат в виде статьи об антивирусе Trend Micro - Клац!
Если пересказать сжато, то проблема возникает из-за очень специфичного объявления пути к файлу одной из служб антивируса:
"C:\Program Files\Trend Micro\OfficeScan Client\..\BM\TMBMSRV.exe" (в статье рассматривается другая версия тренда, но суть та же)

После небольшой правки в реестре этой строки и домашнего каталога службы все заработало как надо. Но остался вопрос - кому и зачем понадобилось именно таким образом объявлять путь к файлам служб?

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

---

NLA - Network Layer Authentication

Признаться, когда только вышел SP3 для Windows XP, я не до конца понимал, что же это за опция такая. Полностью ее прелесть осознал только теперь, когда появилась возможность в спокойной обстановке поковырять веб-доступ до опубликованных на сервере терминалов приложений. Суть в следующем. При попытке запустить любое из приложений TS Web App, пользователь вынужден ввести свой логин и пароль, даже несмотря на то, что в системе он авторизова. А как мы помним, Active Directory на том и стоит, что пользователь, прошедший авторизацию уже должен иметь доступ ко всем ресурсам, на которые у него есть права. SSO - Single Sign-On - так зовется этот замечательный механизм. Повторный ввод пароля же обусловлен тем, что RDP клиент, который и используется при работе с TS Web App, SSO в Windows XP не поддерживает.
SP3 поменял расстановку сил, но даже установив этот пакет обновлений, просто так SSO не получить. Для этого нужно как раз включить ту самую опцию - NLA. Именно на сетевом уровне аутентификации Windows и будет передавать учетные данные.
Сам по себе процесс включения NLA довольно прост, нужно лишь изменить два параметра в реестре каждой системы, на которой будет использоваться веб-доступ к терминальным приложениям (а в идеале - для всех рабочих станций с Windows XP SP3). Очень подробно все это описано вот тут: MS Knowledge Base. При помощи групповых политик результат достигается очень быстро и просто.
Однако, не было бы этой записи, будь все так гладко. Убеждаюсь, что рабочие станции удовлетворяют требованиям для включения NLA - сделано (долго ли проверить две тестовые виртуальные машины). Требования там, кстати, следующие:
- наличие RDP-клиента версии 6 и выше (выполняется автоматически при установке SP3)
- наличие клиентских расширений групповых политик (без этого система не получит сведения о модификации реестра). Взять эти расширения можно здесь: MS Download Center.
Пробую запустить любое приложение. И получаю вот такое:

an authenication error has occured code 0x507

В то же время тестовая Windows 7 спокойно заходит на терминал, спокойно может запустить любое из опубликованных приложений. Значит, что-то не так с включением NLA. Пробегаюсь по политике и настройкам терминального сервера. В настройках сервера было указано следующее: Allow connections from computers running any version of Remote Desktop. Рассудив, что в тестовом домене все компьютеры теперь поддерживают NLA, устанавливаю следующее: Allow connections from computers running verision of Remote Desktop with NLA. Подтверждаем изменения.
В политике же ревизия показала следующее - по идее, в параметры Security Packages и SecurityProviders нужно дописать названия соответствующего пакета и библиотеки. Однако, политика старалась дописать в значение еще и то, что там было раньше. Неверно, так как может привести к дублированию информации. Устанавливаю действие "Заменить", а в значения прописываю все то, что там должно быть. Сохраняю изменения, даю команду двум машинкам с XP SP3 на обновление политик, после чего перезагружаю их.
После всех этих операций искомый результат был получен - пользователи компьютеров под управлением Windows XP SP3 получили возможность запускать терминальные приложения в режиме прозрачной аутентификации (привет клиентам Citrix и режиму pass-through ).
Ради интереса снова переключил терминальный сервер в режим разрешения подключений от любых клиентов Remote Desktop - все прекрасно работает.

@музыка: Ryan Farish - Shine

@темы: Security

---

Software Restriction Policy

Три слова, которые могут очень многое. А впридачу к ним - очень познавательная статья об этой самой политике:
The Six Dumbest Ideas in Computer Security
Настоятельно рекомендую к прочтению и осмыслению всем тем, кому по должности приходится следить за порядком в корпоративных компьютерных сетях.

@музыка: Peter Sterling - Forever and a Day

@темы: Security

---

DFS

На этот раз просто DFS - Distributed File System, слава вышним, без R - Replication.
В кои-то веки решил сделать все, как говорится, по фэн-шую, чтоб красиво было:
dc-01 с адресом вида x.x.x.11
dc-02 с адресом вида x.x.x.12
Проблема в том, что второй контроллер назывался не вторым, а третьим, хотя адрес у него был уже тот, что хотелось. Вечером, когда пользователи уже покинули свои рабочие места, открыл RDP сеанс, ввел все необходимые команды для переименования компьютера (контроллеры начиная с Windows 2003 Server переименовываются так же, как и обычные члены домена), перезапустил сервер. Ожидаемо получил переключение своей машины на работающий первый контроллер, подождал, увидел, что dc-02 теперь стал именно dc-02 и уже вовсю обрабатывает запросы. С чувством выполненного долга, а так же прекрасного, ушел домой...
Наутро осознал всю глубину своей неправоты. Очень много звонков, и все с одной и той же проблемой - нет сетевых дисков. Ну два, ну три, ну пять таких звонков - это в порядке вещей, старое железо, будь оно неладно. Но когда их число перевалило за два десятка...
Начинаю вспоминать, что и как. Сетевые диски цепляются через систему DFS. DFS ссылки хранятся в AD, но обращение к ним идет через так называемые DFS Name Servers, в которые входят и наши контроллеры домена. Если клиент не может подключиться к ресурсу по DFS пути, при условии, что все права у него есть, и сеть тоже в наличии, значит он попал на Name Server, который в данный момент недоступен. В обычных условиях это допустимо, DFS такого клиента просто переключит на другой сервер, хотя на это нужно время. Но ведь все серверы активны!
Открываю оснастку DFS и понимаю, что все, да не все. Среди Name Servers по-прежнему значится dc-02, но под своим старым именем, что плохо. Ведь он по нему уже недоступен. Решение простое - удалить из списка этот сервер и добавить его заново. Удалил. А дальше - ступор, потому что повторное добавление заканчивается ошибкой. DFS говорит, что этот сервер уже является частью пространства имен, и добавить его вторично нельзя. Мол, воспользуйтесь оснасткой DFS для удаления сервера или используйте другой сервер. Приехали... Радует лишь то, что поскольку из списка DFS серверов убран сбойный - у пользователей проблем больше не будет. Но ведь надо его загнать назад, надо же все по фэн-шую...
Active Directory утверждает, что dc-02 не является частью DFS, сервер говорит ровно об обратном. Кому верить? Ответ очевиден - если DFS работает исправно, значит надо верить Active Directory. А в этом случае, нас ожидает приятное времяпрепровождение с утилитой dfsutil.exe:

dfsutil root remove <\\server\share>

Как бы не так. Ошибка выполнения и невозможность удаления DFS-ссылок. Придется действовать более жестко:

dfsutil diag viewdfsdirs < drive letter > removeresparse

Команда была выполена успешно. Все 6 ссылок убиты. Но и это еще не все. Открываем regedit и удаляем разделы по следующим путям:
HKLM\SOFTWARE\Microsoft\Dfs\Roots\Domain\DFS_ROOT
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\DFS_ROOT
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\Security\DFS_ROOT

Поскольку в этот момент мы производим "настройку" сетевых папок через реестр - для применения изменений придется перезапустить сервер. Делать нечего, перезапускаем, после чего уже спокойно делаем его полноправным сервером пространства имен в многострадальной DFS.

Фэн-шуй, говорите? Может быть оно и хорошо, но все трижды проверять никогда не помешает.

@музыка: Peter Sterling - Midnight Sun

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

---

Localization is EVIL.

Меня иногда спрашивают, мол, почему я с пренебрежением отношусь к русской версии Windows XP. Все просто. Я - админ. Человек, который с консолью подчас работает гораздо больше, чем с графическим интерфейсом, который при многократном выполнении одной операции проигрывает консоли прежде всего по скорости. Еще один плюс консоли - она работает скрытно, пользователь, компьютер которого подвергается настройке, ничего не видит и даже не догадывается, что систему потрошат.
Однако, есть проблема. Такие замечательные программы, как psexec, netsh и подобные, очень, ОЧЕНЬ плохо работают с русским языком. Вместо нормальных диагностических сообщений выводится сплошная абракадабра, кодировка страдает (ниже будет пример). А эта диагностика ох, как важна. Ради примера - текущая задача: необходимо на некоторой выборке компьютеров перенастроить DNS серверы в свойствах сетевого соединения. В связи со сменой IP адресов этих самых серверов. Кто-то может возразить, мол, а как же DHCP? Возразит, и будет прав, но лишь отчасти. Потому что есть ситуации, где DHCP просто отсутствует.
Продолжаем перечислять исходные данные. Сетевое соединение на всех тех компьютерах называется вот так: "Подключение по локальной сети". Ну и номер в конце, где-то он есть, где-то его нет.
Собственно, на этом все.
Сценарий работы, по идее, весьма прост. При помощи psexec подключиться к удаленной системе, открыть там сеанс cmd и в нем вбить следующее:

netsh interface ip set dns name="Подключение по локальной сети" source=static addr=a.a.a.a
netsh interface ip add dns name="Подключение по локальной сети" b.b.b.b index=2

Первая команда сносит текущие настройки и ставит первый DNS, вторая добавляет еще одну запись.
Но не тут-то было. psexec просто не примет русскоязычное название сетевого интерфейса. Что делать? Пытаться воспользоваться ключом -r в самом netsh, но и тут засада - при работе в удаленном сеансе netsh не поддерживаются команды настройки DNS, только просмотр. По вполне понятным причинам. Опять таки, что делать?
Решением стало следующее. Поскольку на предприятии используется пакет DNTU, открываем его, открываем тамошний RCmd в режиме Open View, цепляемся к удаленной машине и смотрим на то, как будет обозвано сетевое соединение в этой консоли (помним, что оно называется "Подключение по локальной сети")
Консоль выдаст следующее:
"Џ®¤Є«о祭ЁҐ Ї® «®Є «м­®© бҐвЁ"

Да, да и еще раз ДА! Именно так это соединение и будет называться. Кучей иероглифов. Если бы оно называлось английскими символами, 90% тех неприятностей, которые мы имеем сейчас, просто бы не возникли. Что ж, главный фокус. В командной строке открываем контекст netsh:

netsh interface ip, жмем Enter.

А дальше поочередно вбиваем вот такие конструкции:

set dns name="Џ®¤Є«о祭ЁҐ Ї® «®Є «м­®© бҐвЁ" source=static addr=a.a.a.a
add dns name="Џ®¤Є«о祭ЁҐ Ї® «®Є «м­®© бҐвЁ" b.b.b.b index=2

И это сработает.
А теперь сравните, чем можно было бы обойтись, будь соединение с англоязычным именем:

C:\psexec \\x.x.x.x cmd
netsh interface ip set dns name="LAN" source=static addr=a.a.a.a
netsh interface ip add dns name="LAN" b.b.b.b index=2
Никаких иероглифов, никаких лишних в данном случае DNTU, только то, что нужно.

Вас еще интересует вопрос, почему же я отдаю предпочтение английским версиям ОС?

На вкусное, как переименовать русскоязычное соединение в удобоваримый вариант:
netsh interface set interface name="Џ®¤Є«о祭ЁҐ Ї® «®Є «м­®© бҐвЁ" newname="NewLan"

@музыка: Tomoko Tane - Let Me hear

@темы: Scripting

---

Hardware...

Прошедший понедельник стоил мне пары седых волос, не иначе.
Если пытаться обрисовать ситуацию двумя словами - хрень нереальная, других определений не находится, потому что такого на моей памяти не случалось никогда.
Вполне невинная процедура - вывод из домена сервера, предназначенного к полной переустановке операционной системы (плановый апгрейд до windows 2008), операция, проведенная за всю жизнь уже очень большое количество раз, ошибиться в которой можно только в одном случае - выведя из домена не тот сервер.
Выглядело все это следующим образом. Спуститься в серверную, на KVM переключиться на нужный сервер, отдать все необходимые команды для вывода из домена, перезагрузить его. А пока перезагружается, подключить почему-то неиспользуемый порт iLO (какая расточительность, однако).
Где-то в середине процесса в серверную поступает звонок из админской и вопрос - "что у нас за апокалипсис?".
В самой серверной все неизменно, только теперь уже бывший контроллер домена пущен в рестарт после вывода из домена. После этого сообщают, что по сети недоступны первый DC, почтовый сервер, шлюз. Смотрю на передние панели указанных хостов и понимаю, что двое из них - контроллер и шлюз, уже спят. Переключаюсь на почтовик, и вижу, что он в состоянии выключения операционной системы. Что за ересь?! В довершение всего этого дела намертво повисает KVM, лишая нас консольного доступа к серверам.
Ладно. DC у нас в домене не один и не два. Проживем. Шлюз - уже критичнее, почта - совсем критично. Запускаю шлюз, запускаю почтовик, запускаю DC. Первый и третий поднимаются довольно быстро. Почтовик же задумался. Дожидаюсь вывода на экран стандартного приглашения на ввод логина и пароля, и в трубку: "Проверяй, почтовик поднялся". Ответ убил - коннекта от Outlook до Exchange не наблюдается, но пинги есть. Плохи дела. Ctrl+Alt+Delete, и у меня волосы встают дыбом - Exchange выпал из домена.
Что за этим может последовать, лучше и не думать. Провести ночь в серверной борясь с конфигами, со структурой в AD, не хотелось абсолютно. Абсолютно не понимая, почему такое могло произойти, захожу под локальным админом, лезу в логи. Параллельно открываю консоли контроллера и шлюза. Офигеваю от того, что шлюз тоже вне домена. А в логах видно, что и шлюз, и почтовик выпали из домена в результате штатной операции, выполненной... мной же! Я в ауте... В голове всплывает один из давным-давно прочитанных документов о повторном присоединении рабочей станции к домену под существующим именем. Вот и появилась возможность проверить эти сведения на практике, хотя я и предположить не мог, что проверять это все буду на Exchange, для которого членство в домене - это альфа и омега.
ADUC, Find Computer, Reset Account. После чего на почтовике выполняется штатная операция присоединения к домену и рестарт. Долгие пять минут ожидания, вопрос в трубку "ну как?" и ответ: "У Егорыча почта поднялась!".
Все выдохнули. С этого момента Outlook'и медленно, но верно начали находить сервер и штатно работать с почтой. По аналогичному сценарию добавляем в домен шлюз, после чего работа сервисов нормализуется. А у нас теперь великий геморрой - найти причину этого бардака.
Логи контроллера, логи почтовика, логи шлюза, гугл. И при помощи этого всего нашли причину. Ей оказалась та самая несчастная KVM, через которую я и выводил из домена нужный сервер. Эта, с позволения сказать, железка, в результате какого-то одной ей ведомого сбоя ретранслировала все, что я вводил с консоли на нужный сервер, еще на три порта. А потом вылетала напрочь. Судя по логам всех участвующих в представлении серверов, на все 4 машины в одно и то же время были посланы одни и те же команды, в одно и то же время. У меня все же не 4 пары рук и не 4 головы, чтобы подобное вытворить. Даже комментарий к операции перезагрузки был на всех 4 машинах одним и тем же - "12". Контроллеру домена повезло, его из домена так просто не вышибить, потому он просто перезагрузился и заработал в обычном режиме. А вот почта и шлюз оказались уязвимы.
Что ж, по крайней мере, теперь точно известно, что случайный вывод Exchange-сервера из домена (дико звучит, но все же) не является фатальным. Заодно стало понятно, почему при выводе рабочей станции из домена не удаляется ее учетная запись из базы данных, и как эту учетную запись можно использовать.
Но все же иногда эти знания даются слишком дорогой ценой...

@музыка: Stone Age - Sellet

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

---

Exchange Mailbox Permissions

"Не удается открыть набор папок."
С этими словами, наверняка, хоть раз сталкивался любой из администраторов Exchnage. Когда Outlook пользователя, до какого-то момента исправно работавший, вдруг выдает подобное сообщение, становится несколько неуютно. И как всегда, сама ситуация возникает именно в тот момент, когда почта пользователю нужна просто до зарезу, чуть ли не многомиллионных контракт горит.
В моей практике на текущем месте работы это происходило дважды. У разных сотрудников, с ящиками в разных базах данных (только сервер один). Сами базы в порядке, сервер - тоже. Никаких дополнительных проблем нет, у всех все замечательно. Кроме одного бедолаги.
Думал, что проблема заключается в том, что компьютер по каким-то причинам не может до сервера достучаться - как бы не так, все отлично видно. Решил проверить права на этот ящик - тоже все в порядке. SELF на месте, все службы и сервисные учетки - аналогично. Я до сих пор не могу понять, откуда у меня возникла мысль удалить учетную запись SELF из списка доступа, после чего восстановить ее в правах, но именно это и позволило сотруднику получить доступ к своему ящику и продолжать работать, как ни в чем ни бывало.
Когда подобная ситуация повторилась с другим (через пару недель после первого инцидента), помогло ровно то же самое. Что ж, буду иметь в виду на будущее.

@музыка: Australis - Vanishing point

@темы: MS Exchange

---

Windows System Logs

Недавно мне уже доводилось писать о том, что пропуск лог-файлов при полном бекапе сервера под Windows 2003 Server имеет место быть. Сегодня дошли руки произвести эксперимент по полному резервированию и восстановлению уже Windows 2008 Server. Здесь все куда лучше - логи сохранились в бекапе и при восстановлении системы оказались на своем законном месте. Это радует.

@музыка: Ronald Jenkees - Guitar Sound

@темы: Security

---

Chain of Earth -> Stone Shock.

Да, да, именно шок.
Преамбула - поставлена задача: найти, кто сидел за конкретным компьютером в определенный промежуток при условии, что сотрудники могут пересаживаться. Казалось бы, что сложного, открываем журнал Security и смотрим логи. Проблема в том, что требуемый промежуток - это уже довольно дальнее прошлое, в текущих логах уже давным давно стертое. Ладно, есть бекапы. Открываем их, лезем в заветную папку %windir%\system32\config, ищем там secevents.evt... и понимаем, что в полном бекапе контроллера домена этого лога нет. Как нет и любого другого из системного журнала событий. Вдумчивое ковыряние гугла подтверждает мысль - ntbackup даже при полном резервном копировании не сохраняет логи. Это касается Windows 2003 Server, платформу 2008 на это еще не тестировали (есть повод создать новую виртуальную машину и поиздеваться над ней).
Что ж, задачу удалось решить, но несколько иным и довольно кривым методом, но осадок остался. Одновременно с этим встал вопрос - что делать с бекапом логов. В итоге был найден и доработан напильником вот такой скрипт:

Backup Security Events.vbs

Backup Security Events.vbs

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate,(Backup)}!\\" & _
strComputer & "\root\cimv2")

'получаем коллекцию событий из журнала Security
Set colLogFiles = objWMIService.ExecQuery _
("Select * from Win32_NTEventLogFile where LogFileName='Security'")

'определяем имя переменной, хранящей имя компьютера
Set objNetwork = CreateObject("Wscript.Network")
strComputerName = objNetwork.ComputerName

'определяем путь к бекап-файлу (в имени будут использоваться текущий день, месяц и год)
strBackupFileName = "\\server-share\" & strComputerName & "\Security-" & cint(day(date())) & "-" & cint(month(date())) & "-" & cint(year(date())) & ".evt"

' непосредственно сброс выбранной коллекции в файл
For Each objLogfile in colLogFiles
errBackupLog = objLogFile.BackupEventLog(strBackupFileName)
If errBackupLog <> 0 Then
Wscript.Echo "The Security event log could not be backed up."

Else

End If
Next

Далее - Планировщик задач и задача по созданию резервной копии журнала на регулярной основе.

@музыка: Alice in Videoland - Ladykiller

@темы: Scripting, Security

---

Scheduled AU in Windows 2008

Когда я только пришел на текущее место работы, мне рассказали много страшных историй о том, к чему приводила установка пакетов обновлений на серверы. В частности, позабавила байка о том, что после установки очередного апдейта на Exchange у пользователей слетели права на общие почтовые ящики (да, были и такие). С тех пор заплатки на серверные системы у нас ставятся исключительно руками и очень выборочно. А если уж говорить прямо - их всего 4 штуки: последний Service Pack для какой-либо платформы, и те самые три заплатки против Kido, без них уже никуда и никогда.
На прошлой неделе мне этот факт все же надоел. Проверив политику обновлений, нашел, что ее текущий вид полностью удовлетворяет моим требованиям на данный момент: уведомлять о загрузке доступных обновлений, уведомлять об установке загруженных обновлений. В этом режиме сервер никаких действий сам по себе не исполняет, а ждет команды от администратора. Таким образом я собирался по одному пройти все серверы, поставить обновления, убедиться, что функционал не нарушен. Политика в норме, осталось только на WSUS одобрить все имеющиеся обновки для серверов, чтобы последние могли их увидеть. Сказано, сделано. Было это под вечер.
На следующее утро я был шокирован. С самого начала рабочего дня поступило довольно много звонков с одной и той же проблемой - нет ни одного сетевого диска. Такая ситуация может быть обусловлена двумя факторами - сбоем в работе AD или сбоем (серьезным) в работе файлового сервера, папками которого наши сетевые диски и являются. Так оно и было, на пинги файлопомоечка не отзывалась. Спускаюсь в серверную, смотрю на экран, вижу, что scandisk уже в течение 6 часов весело проверяет на ошибки диск, лежащий на подключенной к этому серверу СХД (2 Тб данных), понимаю, что это надолго - 56% проверки индексов (и только лишь!). Прерываю проверку, перезапускаю сервер и отменяю ее на старте. Файлопомойка поднимается, пользователи довольны. Вернувшись к себе проверяю, почему файловик ушелв перезагрузку. А в голове вертится подозрение о причине. Оно и подтвердилось. Обновления. Одновременно с этим проверил мелкую файлопомойку (тоже под Windows 2008 работает), понимаю, что перезагружалась и она. Получается просто безумная картина. Политика обновлений (параметры были указаны выше) действует на все серверы вне зависимости от их платформы. Те серверы, что крутятся под Windows 2003, как им и предписано, ждут команды. А вот те, что работают под Windows 2008, решили, что политика им не указ, и стали действовать согласно базовому расписанию обновлений, каждый день в три часа ночи. Перезагрузка, если она нужна, выполняется автоматически.
Дела, однако. Причину такого их поведения я пока не выяснил, но для себя все же решил, что обновлять серверы надо. Просто НАДО. И с перезагрузкой придется мириться. Выделю им какой-либо день на неделе, и пусть веселятся.
Занимал только один вопрос - что делать с файловым сервером, который при каждом своем старте порывается проверять раздел на СХД, который он считает сбойным (да, был факт нештатного отключения). Пять минут поиска - и решение найдено:
chkntfs /x %Drive letter% - это исключит нужный нам диск из списка проверки scandisk при старте системы. Как раз то, что нужно.

@музыка: Louisa John-Krol - The Witch In The Wood

@темы: WSUS

---

MS Exchange 2003 Log files

Потихоньку прихожу в себя от сегодняшней мозголомки. Умом понимаю, что такие проблемы, как эта, надо ценить и коллекционировать. Когда становится бессильным даже гугл - that's a challenge. Впрочем, обо всем по порядку.
Итак, есть задание - перенести базы с одной системы хранения данных (назовем ее ареной), на другую такую же систему. Первая арена предназначена под тотальный апгрейд и переконфигурацию. Обе арены подключены к серверу Exchange, разделы сконфигурированы и видны, как диски. Все готово для переноса, процедура которого весьма обыденна - нужно отмонтировать нужную базу данных и перебросить ее файлы в нужный каталог. С этим проблем не возникло никаких. База успешно поднимается, лежа уже в новой папке на новой арене.
После копирования файлов базы было решено сразу же завершить копирование группы хранения, в которой эта база находится. Это включает в себя перенесение chk-файла и файлов логов группы. Сказано, сделано. Подготовлены каталоги, отдана команда на перенесение одного, потом другого. Все успешно. Курсор мыши зависает над пунктом Mount Database. Один щелчок кнопкой, и...
Произошла внутренняя ошибка обработки. Попробуйте перезапустить диспетчер Exchange System Manager или службу Microsoft Exchange Information Store, или обе службы.
Код события: c1041724
Exchange System Manager

Первый звонок о том, что что-то пошло совсем не так, как планировалось. О перезапуске Information Store речи не идет, downtime будет не запланированным, отчего по голове не погладят. Первым делом смотрим в логи. Computer Management, Event log, Application...

Description: "Information Store Unable to read the header of logfile Exx.log. Error -530

Много непечатного. Очень много. Потому что весь интернет с MS во главе при такой ошибке дают два варианта действий: либо восстановление из бекапа, либо... eseutil /p, о котором мне писать уже доводилось. Спасибо, не надо, это долго. Да, я знаю, что у меня проблема с базой, но это не основная база, потому есть время на размышления.
Первым делом предпринял попытку вернуть логи назад... к моему великому удивлению - база примонтировалась и спокойно заработала без каких-либо ошибок. Мистика. Повторное отключение и перенос на новую арену. Результат описан выше. Снова возвращаю логи в исходную папку. Работает. Мистика дважды. Ради интереса переношу логи на системный раздел сервера Exchange - все работает. Возвращаю назад и логи, и базу (копия осталась в исходной папке) и ложусь спать, потому что время на тот момент было уже два часа ночи (работал из дома).
По приходу на работу утром предпринимаю еще одну отчаянную попытку переместить логи на новое место, только создал для этого тестовую группу хранения с тестовой базой внутри. Как легко догадаться, за ночь ситуация лучше не стала. База отключена, состояние - Clean Shutdown, то есть для ее работы логи в принципе не нужны. Что ж, копирую их в безопасное место, после чего уничтожаю их на новой арене, проверив, что сам Exchange будет их искать там. Расчет был на то, что даже если файлы и портятся при копировании, сервер просто создаст новые логи на новом месте. Это вполне допустимо, если есть резервная копия (она есть). Хотя и непонятно, почему при обратном копировании все работает, ведь файлы могут быть повреждены. К моему великому удивлению, логи создались на новой арене без проблем и вся база данных успешно примонтировалась.
Следующая стадия эксперимента - перенесение этих новых логов с новой арены в какую-нибудь папку на старой. Неудача. Та же самая ошибка, и то же самое восстановление работоспособности после перенесения их в их "место рождения", то есть на новую арену. Ради интереса переношу их на системный раздел, ожидая увидеть ошибку. Не ошибся.
Получается очень интересная ситуация. Логи, созданные вне новой арены, можно таскать куда угодно, но только не на новую арену. Логи же, созданные на новой арене, можно таскать как угодно на этой арене, но вне ее база работать отказывается. Чувство, что файлы на арене кодированы, но никто никакой кодировкой не занимается.
Дальше идет несколько часов курения гугла, всевозможных манов, форумов и им подобного. И везде одно и то же - бекап, eseutil. В голове третий вариант об отказе от старых логов для всех групп хранения и создании их на новой арене. Но это неправильно, потому что в прошлый раз при перенесении баз ничего подобного не было.
Под конец дня решил повнимательнее присмотреться к логу, который выдается, как сбойный. Файл как файл, MD5-хэши одни и те же, значит он не меняется и речи о повреждении не идет. Тогда что мешает? Unable to read the header of logfile. Но это Information Store не может прочитать. А что если взглянуть на файл под микроскопом?
eseutil /ml exx.log

Результат огорошил:
Operation terminated with error -546 (JET_errLogSectorSizeMismatch, the log file sector size does not match the current volume's sector size)

О таком я не слышал никогда. Чтобы лог файл не мог прижиться на новом устройстве, размер сектора которого отличается от размера сектора диска, где лог был создан. Эксперимента ради рассмотрел живой лог и на старой арене, и на новой. Результат сказал обо всем:
Env Log Sec size: 512 - на старой.
Env Log Sec size: 4096 - на новой.

Разделы и на одной арене, и на другой, создавались без меня. И никто не придал значения параметру Sector Size в настройках слайсов рейд-массива, сомневаюсь, что сам бы это сделал. Однако, значение это имеет, и довольно большое. Проблема лишь в том, что массив перебивать уже нельзя.
В итоге все же решили остановиться на варианте создания новых логов, это будет быстрее. И как всегда, бекап, бекап, бекап.
До сути проблемы докопались, это уже хорошо. Урок и полезная информация на будущее. Надеюсь, что кому-то она сэкономит много нервных клеток.

@музыка: Fowler and Branca - Windy Sky

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