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

---

IE 6,7,8

Гром таки грянул. Сколько пришлось попариться для того, чтобы обновить IE на компьютерах домена до версии выше, чем 6 - почти все напрасно. Выяснилось, что один из компонентов используемого бизнес-приложения стабильно работать может только в версии 6. Во всех других он может завесить браузер намертво, что приводит к лишнему расстройству, потери набранных в форму данных (браузер нужно будет перезапустить без сохранения состояния). В общем, обещается много-много неприятного. В связи с чем встал вопрос - как бы версии 7+ снести с порядочного количества компьютеров максимально быстро и по возможности без лишних телодвижений и звонков. Немного ковыряния в предметной области показало, что у приложения Windows Internet Explorer 7/8 есть так называемая строка деинсталляции (в общем и целом, эта строка есть почти у всех продуктов, которые прописываются в апплете "Установка и удаление программ"). Оно и понятно, системе ведь нужно что-то запускать для процесса удаления ненужного приложения.
Что ж, это радикально меняет дело. Строка известна, стало быть нам нужен еще один скрипт, который будет запускаться на нужных компьютерах. В итоге получается следующий vbs-файл:

'Internet Exploer 7,8 Uninstallation
on error resume next
Set WshShell = CreateObject("WScript.Shell")
'Uninstall IE 8
WshShell.Run "C:\WINDOWS\ie8\spuninst\spuninst.exe /quiet /norestart",1,true

'Uninstall IE 7
WshShell.Run "C:\WINDOWS\ie7\spuninst\spuninst.exe /quiet /norestart",1,true

Вот такой небольшой сценарий.
Последний момент - после удаления всех старших версий компьютер нужно перезапустить. Проблема в том, что пользователи на это чаще всего забивают. Что делать? Выход прост - этот скрипт нужно выполнить в момент завершения работы компьютера.
Таким образом получаем довольно простой сценарий: групповая политика, область действия - выбранные компьютеры (а они известны), параметры политики - Shutdown sсript, именно туда нужно будет подставить указанный выше сценарий. Дело за малым, перезагрузить машины - и задача выполнена.

@музыка: Clannad - From Your Heart

@настроение: Scripts are my best friends

@темы: Scripting

---

Support

Есть на этом свете славная компания HTC, выпустившая немало славных коммуникаторов. Дорогих и не очень, навороченных, и менее функциональных. WM-based и Android-based. Вот о последних речь и пойдет.
Недавно возникла задача - подключить коммуникатор сотрудника (HTC Hero) к корпоративной почте. Все бы ничего, но при проверке соединений используется самоподписанный сертификат. Знающие люди поймут сразу, о чем сыр-бор, а для незнающих поясню. Дело в том, что таким сертификатам не доверяет ни одна система. Даже та, которая этот сертификат и подписала для себя. И для того, чтобы она стала ему доверять, корневой сертификат центра сертификации (сорри за тавтологию), должен быть напрямую импортирован в систему. Тогда последняя начнет доверять этому корневому, а следом за ним и всем сертификатам, которые этот корневой подписал.
Чем это неудобно для владельцев коммуникаторов. Эти устройства при обнаружении самоподписанного сертификата просто отвергают соединение с выводом сообщения об ошибке. WM-based коммуникаторы "пролечиваются" очень просто - сертификат копируется на них в их файловую систему, после чего в стандартном Проводнике добавляются в хранилище сертификатов. Все, устройство готово к работе.
В случае Android-based устройства (коим и является HTC Hero) получили самый настоящий геморрой. Дело в том, что у данной конкретной модели просто НЕТ Проводника или любого другого метода просмотра файловой системы. Можно обратиться к музыке, к картинкам, но только через соответствующие программы. Они работают на основе каталогов, которые сами же и составляют. Всякий, кто работал с библиотекой Windows Media Player - меня поймет. Но сертификат, лежащий на карте памяти телефона - это не картинка, не музыка, даже не какой-либо офисный документ. И никакая программа из поставляемых "в коробке" его не видит.
В интернете лежит куча шаманских методов сертификата, но 100%-но работающего нет ни одного. В итоге решил, как самый обычный пользователь обратиться в поддержку компании HTC, благо, на сайте есть специальная веб-форма. По логике вещей, уж компания-производитель должна что-то дельное подсказать. Сказано - сделано, написал, нажал кнопку отправить, и стал ждать. Дождался, ниже привожу запрос и ответ. Это феерия!

Запрос
Добрый день. Хотелось бы уточнить, каким образом можно настроить телефон HTC Hero так, чтобы он доверял самоподписанному сертификату Exchange, используемом в организации. В настоящее время телефон при попытке доступа к серверу через защищенное соединение выводит сообщение о том, что сертификат не является доверенным, и предлагает либо продолжить, либо отменить соединение. При продолжении снова появляется окно о недоверенном сертификате, и так повторяется бесконечно.
В общем случае для решения проблемы нужно импортировать на устройство корневой сертификат, но как это можно сделать на данном телефоне?
Заранее благодарен за ответ.

Ответ
Добрый день!
Спасибо за обращение в HTC.
Коммуникатор на базе ОС Android автоматически прописывает сертификаты. Если Ваш аппарат показал извещение об ошибке сертификата, то обязательно выбирайте пункт "продолжить" и коммуникатор загрузит нужные данные.
Пожалуйста, обратите ваше внимание, что вы можете также связаться с нами по телефону.Для более детальной информации пожалуйста перейдите по ссылке www.htc.com/uk/CA_Hotline.aspx
С уважением, НТС.

Если честно, после подобного ответа у меня не остается никакого другого выбора кроме закрытия запроса. И заодно я уверился во мнении, что если даже когда-то и приобрету себе смартфон, это не будет Android-based.

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

---

Oneliners

Oneliner - сценарий, состоящий из одной строки (one line). Их удобство в том, что для решения какой-то задачи достаточно открыть консоль, набрать нужную команду, запустить ее на выполнение и получить результат. Нет необходимости писать текст скрипта, сохранять его, затем писать команду на вызов этого сохраненного файла. Все просто.

Недавно понял, что нужно привести в порядок в нашем домене ограничения на максимальный размер передаваемого через почту сообщения. У кого-то стоит одно, у кого-то другое, у некоторых вообще десятое. Это неправильно. Два параметра (размер входящего письма и размер исходящего письма) хранятся непосредственно в записях Active Directory, следовательно, вытащить их достаточно просто. Вариантов довольно много, но в итоге я остановился на Powershell и его сторонней оснастке Quest Management Shell. Quest - это отдельный набор команд, облегчающих работу с Active Directory и делающих ее более прозрачной, чем обычные команды Powershell. Сами параметры зовутся так:
SubmissionContLength - размер исходящего сообщения;
DelivContLength - размер входящего сообщения.

После непродолжительного чтения справки удалось набросать сценарий, шаблон которого выглядит так:

foreach ($name in get-qaduser -searchroot 'INSERT IGNORE_ROOT_OF_SEARCH') {set-qaduser $name -objectattributes @{SubmissionContLength='INSERT IGNORE_VALUE';DelivContLength='INSERT IGNORE_VALUE'}}

Пара слов о том, что он делает.
foreach - это команда, которая выполняет определенный набор действий с каждым объектом какой-либо выборки. в общем случае она записывается так:
foreach (selection) {sсriрt}
где selection - это выборка, а sсript - то самое действие (или несколько действий), которые нужно произвести с объектами выборки.
$name - переменная, хранящая в себе имя пользователя.
get-qaduser - одна из ключевых команд сценария. она вытаскивает из Active Directory полную информацию о пользователе, чье имя хранится в переменной $name
-searchroot - модификатор, задающий область поиска. Сюда нужно подставить путь к ветке в Active Directory, в которой сценарий будет искать нужного нам пользователя. Формат записи: 'OU=TestOU,DC=Domain,DC=com'

Таким образом, первая часть сценария создает выборку объектов Active Directory, у которой нужно будет сменить пару свойств. Непосредственно сменой свойств занимается вторая часть скрипта, заключенная в фигурные скобки.
set-qaduser $name - изменить параметры учетной записи, имя которой указано в переменной $name,
-objectattributes @{SubmissionContLength='INSERT IGNORE_VALUE';DelivContLength='INSERT IGNORE_VALUE'} - здесь задается, что именно меняеть, как раз те самые два параметра. Следует обратить внимание, что набор параметров заключается в фигурные скобки.

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

---

Ключи...

... от квартиры, где деньги лежат.
Нет, на самом деле речь пойдет о ключах другого рода, лицензионных. Первое, что приходится учитывать компаниям, это ключи на ОС и офисный пакет, если используется MS Office. И может сложиться такая ситуация, когда нужно быстро собрать информацию о ключах на довольно большом количестве машин. Как это сделать?
На помощь может прийти утилита под названием Produkey. Свободно распространяемое мелкое приложение, которое позволяет узнать ключи Windows, MS Office и некоторых других пакетов. Сама эта утилита содержит в себе возможность сканирования удаленных машин с целью сбора информации о лизензиях. Но есть один момент - компьютер для этого должен быть включен. Другой же вариант решения проблемы - запустить Produkey в момент запуска компьютера. Это можно сделать сценарием запуска машины.
Групповые политики, Параметры компьютера, Сценарии запуска. Сюда нужно будет положить сценарий, шаблон которого представлен ниже:

GetKeys.vbs

'Get Keys on startup sсript
'set network-based Computer name - определяем имя компьютера
Set objNetwork = CreateObject("Wscript.Network")
strComputer = objNetwork.ComputerName

'set WshShell - определяем командную оболочку
Set WshShell = CreateObject("Wscript.Shell")

'Set objFSO - определяем объект "файловая система"
Set objFSO = CreateObject("Scripting.FileSystemObject")

'set local file for output - задаем имя файла, в который будет выводиться информация о компьютере
strOutputFileName = "produkey-" & strComputer & ".txt"

'Disable Security Warning for Network Files - на время отключаем предупреждение об открытии файла из нелокального источника
set oEnv = WshShell.Environment("PROCESS")
oEnv("SEE_MASK_NOZONECHECKS") = 1

'set command to execute - определяем команду, которая и будет выполняться при запуске системы (отчет создается в корне диска С
strCommand = "\\NETWORK-SHARE\produkey.exe /WindowsKeys 1 /OfficeKeys 1 /IEKeys 0 /SQLKeys 0 /ExchangeKeys 0 /stab c:\" & strOutputFileName

'execute command - исполнение команды.
WshShell.run strCommand,,true

'set source for copiyng report - переменная с расположением файла-источника для копирования отчета
strSource = "c:\" & strOutputFileName

'set destination for report - переменная с расположением файла отчета в папке отчетов
strReport = "\\REPORTS-FOLDER-SHARE\" & strOutputFileName

'copy report and delete local file - скопировать файл в папку отчетов и удалить локальный файл
objFSO.CopyFile strSource, strReport, true
objFSO.DeleteFile strSource

'Enable Security Warning for Network Files - возобновить предупреждения об открытии файлов из нелокальных источников
oEnv.Remove("SEE_MASK_NOZONECHECKS")

Что делает этот сценарий? При загрузке компьютера из папки \\NETWORK-SHARE\ вызывается программа produkey.exe с определенным набором параметров. Результатом ее выполнения будет созданный в корне диска С: файл с информацией об установленном на компьютере ПО (в той части, которую "распознает" produkey). Далее этот файл копируется в сетевую папку "\\REPORTS-FOLDER-SHARE\", после чего из корня диска С: файл будет удален. Таким образом в папке "\\REPORTS-FOLDER-SHARE\" создается набор файлов, каждый из которых соответствует одному компьютеру. Этот набор файлов уже можно анализировать в спокойной обстановке.
Отдельно об анализе этого набора файлов. Например, требуется узнать, что творится с ключами ОС (типичная в России ситуация для нового системного администратора на предприятии). Известно, что в отчетах produkey информация об ОС идет первой строкой. Значит, задача сводится к тому, чтобы пробежать по всему набору отчетов, вытащить из каждого отчета первую строку и внести ее в файл итоговой таблицы. Эту задачу можно легко решить при помощи Powershell, например:

$ReportPath = "\\REPORTS-FOLDER-SHARE\"
foreach ($name in ls $ReportPath) {get-content $ReportPath\$name -totalcount 1 | Out-file winkeys.txt -append}

Этот нехитрый сценарий пройдет по всем файлам в папке \\REPORTS-FOLDER-SHARE\, прочитает по одной строке из каждого файла в ней, после чего результат скинет в файл winkeys.txt, находящийся в домашней папке пользователя. Работать с единой таблицей же куда проще, чем с набором файлов.

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

@темы: PowerShell, Scripting, Security

---

Спам и антиспам.

Праздники кончились, начались суровые трудовые будни.
На корпоративную почту свалилось письмо. На первый взгляд - ничем не примечательный спам. Но только на первый. Читаем содержание письма и понимаем, почему оно было пропущено всеми фильтрами:

Spam detection software, running on the system "carin.vtelecom.ru", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details.

Content preview: Bêëaäûâàéòe â ðåkëàìó - áóäåò ìíîãî êëèeíòoâ. Ñeðèÿ èç 3 ìaññoâûõ
ðàñcûëoê (Ìîñkâa è ÌÎ BÑÅÃO çà 5.000 ðóá. PACCÛËKA ïo ëþáoìó PEÃÈÎÍÓ Ðoñcèè
- ÂÑEÃO ça 1.800 póá. Ãoðÿ÷àÿ ëèíèÿ: 92O ____ I9 _ _ 98[/cyrlat] [...]

Content analysis details: (14.7 points, 8.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
[Blocked - see ]
0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
[85.15.81.128 listed in zen.spamhaus.org]
3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
[score: 1.0000]
0.0 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d
2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr
1)
3.2 FH_DATE_PAST_20XX The date is grossly in the future.
0.0 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date
0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS
-0.4 AWL AWL: From: address is in the auto white-list

И приложение к этому письму - другое письмо с уже типичным спам-заголовком "Кризис закончился!".
Признаться, это сообщение на минуту меня ввело в ступор. Все дело в том, что приведенный выше текст - типичный ответ антиспам-системы о том, что письмо, которое вы, якобы, отправили, расценено как спам. И единственное, что мне помогло опознать в этом письме спам - адрес отправителя, потому как в реальных ответах от антиспама будет стоять назначенный адрес этой системы, но никак не сочетание букв вида [email protected].
Вывод - уж если есть необходимость проверки спама - проверять надо все, и очень внимательно.

@темы: Viruses and Spam

---

Symantec Backup Exec

Система резервирования и архивирования информации. Очень мощная, довольно удобная, но требующая серьезной доработки напильником, то есть настройки. Причем настройка процесса резервирования - это отдельная песня, а сейчас хотелось бы рассказать о вот такой напасти:
The job failed with the following error: The media operation was terminated by the user.

Приход отчета с таким диагнозом для меня стал шоком, потому что я не мог физически отменить бекап. У меня доступа к серверу в тот момент не было.
Первоначальное курение мануалов подсказало, что нужно проверить настойки автоматической отмены заданий. Проверил - ничего не включено, все по-умолчанию, то есть работать до конца. Победного или нет, другой вопрос. Что ж, придется ковырять лог более подробно.
Открываем раздел Job History и смотрим, что происходило во время бекапа. Видно, что бекап снялся, но на стадии его проверки прошел какой-то сбой:
Set Detail Information - Backup
Set type: Backup
Set status: Completed

Set Detail Information - Verify
Set type: Verify
Set status: Completed
Error: e0000602 - A query for media on which the data set being read is continued was unsuccessful. Ensure that all media in the family have been inventoried and cataloged.
Byte count: 0
bytesRate: 0,00 MB/Min
Files: 0
Directories: 0
Skipped files: 0
Corrupt files: 0
Files in use: 0

К чему это приводит? К тому, что при формировании задачи восстановления этот бекап не виден среди всех остальных. Он есть, но к нему нет доступа.
Начинаем шерстить по указанной ошибке гугл, и только гугл, яндекс по ней не знает вообще ничего (надеюсь, теперь узнает). Все ссылки ведут на форумы Symantec, где внятного ответа нет в половине случаев, а то и больше. Но из всей информации ясно одно, проблема возникает на стадии составления каталога кассеты. Предлагается сбросить эти каталоги, сказав Backup Exec'у брать информацию непосредственно читая ленты - как это сделать, описано здесь: seer.entsupport.symantec.com/docs/200962.htm Попытка выполнить эту операцию заканчивается неудачей со следующим вердиктом:
Final error: 0xe0000900 - The requested media is not listed in the media index and could not be mounted. To add the media's catalog information to the disk-based catalogs, run an inventory operation on the media and resubmit the Catalog operation.
Получается цикл, в котором я провертелся в общем и целом около месяца, что является непозволительным сроком. Что делать - непонятно. Виноваты ли кассеты, виновато ли ПО, учитывая, что оно работало, может быть всему виной и сбойный накопитель (самый паскудный сценарий). Все это время пришлось полагаться на встроенный ntbackup, который, в принципе, спасает. Одновременно прокуривал форум Symantec на наличие сходных случаев. И только в одном топике натолкнулся на комментарий сотрудника компании Symantec - "проверьте системные логи на наличие ошибок с кодами ... Они говорят о неисправности с оборудованием"
Чем черт не шутит, не питая особой надежд на то, что это поможет (сам накопитель исправен, в этом я был уверен) открыл логи приложений в самой ОС. Каково же было мое удивление, когда причина всего бардака с каталогизацией появилась прямо перед глазами:
Event Type: Error
Event Source: Backup Exec CatErrorHandler Server
Event Category: None
Event ID: 34323
Date: 26.12.2009
Time: 11:10:31
User: N/A
Computer: %servername%
Description:
Update to catalog file C:\Program Files\Symantec\Backup Exec\Catalogs\%servername%\{01F7A24D-8B4B-4F36-9FDD-E627C9FE7575}_1.fh failed.
Reason: There is not enough space on the disk.
r:\corsica\2213r\becat\beplugins\commonfh\fhbuilder.cpp(772)

For more information, click the following link:
eventlookup.veritas.com/eventlookup/EventLookup...

Вот оно! Проблема была действительно на стадии каталогизации, потому что новосозданный каталог просто не мог записаться на диск, места не хватало. Окинув взглядом папку каталогов, понял, что ее жизненно необходимо убрать с системного раздела. Перенес на другой раздел, перезапустил службы, и заставил Backup Exec перестроить каталоги по описанному выше по ссылке методу. Итогом стало то, что все бекапы, которые были сняты за период сбоев, стали доступны. Что и требовалось.

Мораль истории - даже если приложение ведет достаточно подробные логи само по себе, забывать о логах ОС не рекомендуется. Иногда они все же информативнее.
Надеюсь, эта запись поможет людям, обслуживающим Symantec Backup Exec, сберечь много нервных клеток.

@музыка: Uttara - Winter Dance

---

WSUS and SQL Server

Во время развертываения WSUS на сервере в филиале случилось странное - установщик выдал ошибку о невозможности продолжения и послал изучать логи. В логах обнаружилось следующее:
Error 0x80070643: Fatal error during installation
Такая ошибка обычно говорит о том, что у пользователя, выполняющего установку WSUS нет необходимых прав в базе данных, в которую WSUS будет складывать все сведения. Решение довольно простое - добавить этому пользователю роль в базе SysAdmin и повторить установку. Не тут-то было, не помогло.
При повторной установке выянсяется, что, действительно, падение происходит на стадии Configuring Databasе, стало быть, нужно смотреть и логи SQL Express. Читаю и нахожу фееричное - невозможно создать файл базы, так как он уже есть, и он используется. Стереть файл базы так просто не получится, потому что его всегда использует служба сервера баз данных SQL Server. Но можно отключить службу, тогда файл будет освобожден. Проверка состояния службы показала, что последняя действительно запущена. Для верности решаю сделать еще одну чистую установку, только на этот раз не запуская службу. Все устанавливается с пол-пинка.
Сижу, хихикаю, и много думаю... Получается, что в процессе установки WSUS сам запускает службу базы данных, но тогда как быть с тем случаем, если используется не SQL Express, как у меня, а большой SQL, службу которого просто так не остановить...

@темы: WSUS