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

---

Office Communicator 2007 + Outlook

При развертывании клиента Office Communication Server 2007 R2 столкнулся со следующей проблемой. Клиент нормально стартует, показывает список контактов, но говорит о том, что не может интегрироваться с моей учетной записью Outlook. Выглядит это вот так:
"There was a problem connecting to Microsoft Office Outlook. Your Outlook profile is not configured correctly. Contact your system administrator with this information."
Как было замечено на том же social.microsoft.com: the problem is... i'm system administrator. В результатах выдачи гугля много решений, и ковыряние реестра, и переустановка всего Office, и перенастройка профиля пользователя. Однако в большинстве случаев идут отписки, что ничто из этого не помогает. Как быть?
На одном из форумов нашлось решение, которое помогло лично мне. Оно до безобразия простое:
1. Закрыть Outlook и Communicator;
2. Выполнить в командной строке fixmapi.exe;
3. Снова запутить Outlook и Communicator.

После этого ошибка исчезла, коммуникатор смог предоставить весь функционал работы с Outlook.

@музыка: En Voice - Orange Moon

@темы: MS Exchange

---

Cached Files

Кэш. Не тот, что наличный, а тот, что временное хранилище файлов. Хорошая вещь, помогающая сэкономить на трафике, но только в том случае, если за ним следить. А пользователи, как правило, вообще не в курсе, что это такое, зачем оно нужно. Более того, они не в курсе, что он вообще существует. Но обязанности следить за ним это не отменяет.
Если не ограничивать в размерах временные папки - они склонны раздуваться, раздуваться и раздуваться. Плодитесь и размножайтесь, так вроде было? Значит, нужно как-то эти папки чистить, потому что пользователя не допросишься это делать.
Основные два рассадника "времянки" - браузер и почтовый клиент - IE и Outlook. И если в первом еще можно размер обозначить, то второй чрезвычайно любит покушать. Суть идеи проста - удалять содержимое этих хранилищ когда пользователь выходит из системы. Расположения кэшей известны:
C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\Content.IE5\ - браузер
C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\Content.Outlook\ - Outlook 2007
C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\OLK*\ - Outlook 2003

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

Clean Cache.cmd

Clean Cache.cmd

rem delete IE cache
del /f/s/q "C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\Content.IE5\*.*"

rem delete outlook 2007 cache
del /f/s/q "C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\Content.Outlook\*.*"
rd /s /q """C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\Content.Outlook"""

rem delete outlook 2003 cache
for /d %%a in ("C:\Documents and Settings\%username%\Local Settings\Temporary Internet Files\OLK*") do (
del /f/s/q "%%a\*.*"
rd /s /q """%%a"""
)

Одним из плюсов постоянной очистки, по крайней мере, кэша браузера видится тот факт, что это позволит стирать с жестких дисков пользователей всякую вредоносную дрянь, которая сидит в Temporary Internet Files, и запускается c User-level правами на старте системы. Антивирус все же не панацея.

@музыка: Moya Brennan - Tara

@темы: Scripting

---

Oneliners #2

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

@темы: PowerShell, MS Exchange

---

Kido #5 - Aftermath

Уже год, как отгремела волна заражений поганцем Kido. Эпидемия сошла если и на нет, то количество инцидентов уж точно значительно снизилась. Тем не менее, периодически то тут, то там еще видно сообщения о том, что нашелся зверь и пытается пакостничать. Как же выяснить, откуда прет зараза?
Антивирусные средства видят факт попытки заражения и успешно отстреливают вредоносные файлы, но источника не показывают, а ведь он и нужен. На помощь может прийти лог контроллера домена - ведь в нем фиксируются все попытки авторизации под какой-либо учетной записью (компьютера, пользователя - не имеет значения). Нужно лишь суметь этот лог настроить и проанализировать.
Первое, что нужно сделать - это включить регистрацию о неуспешных попытках авторизации, об этом уже было написано. Второе - собственно наблюдение. Нужно вывести лог безопасности контроллера домена, а для облегчения работы настроить в нем фильтр следующим образом:

Event types - Failure Audit
Event ID - 680

А дальше смотреть на ошибочные записи. Если Кидо пытается пролезть по сети, то все его проваленные попытки будут формировать событие именно с кодом 680. Причем таких событий в секунду будет очень много (до 20). Дальнейшие действия тривиальны - раскрываем любое из таких событий, смотрим, какая система их генерирует, и идем выкорчевывать поганца.

P.S. И снова повторюсь, реалия сегодняшнего дня - не должно быть ни одной машины, где не установлены заплатки, описанные в бюллютенях безопасности MS08-067, MS08-68, MS09-001.

@музыка: Moya Brennan - Tara

@темы: Viruses and Spam