Fonts

Установка шрифтов - дело весьма нехитрое. Цапнул файл шрифта да бросил его в папку %windir%\Fonts. Только права для этого администраторские нужны, но это уже факт само собой подразумевающийся.
Уже довольно давно была поставлена задача - установить корпоративные шрифты на все компьютеры домена. Компов достаточно много, намного больше одной сотни. Что делать будем? Как что - использовать все те же групповые политики. Раскидаем при помощи сценария запуска компьютера файлы шрифтов куда надо, и дело с концом. Не тут-то было.
Есть в этом процессе одна тонкость. Для того, чтобы операционная система новый шрифт узнала, его мало просто скопировать в папку шрифтов. Сам шрифт должен быть прописан в системном реестре вот в этом ключе: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts. Если установку шрифта производить при помощи Проводника Windows, все нужные записи в этом ключе создаются автоматически, а вот в случае использования сторонних утилит вида Total Commander этого не произойдет. Что делать в таком случае?
Сайт Hey, Scripting Guy! поведал о замечательной функции CopyHere, которая и позволяет запрограммировать взаимодействие с реестром ОС для установки шрифта - Клац!. В общем случае код будет выглядеть так:

Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace(FONTS)
objFolder.CopyHere "FONT-NAME"

Казалось бы, проблема решена. Почти так. Последнее препятствие - уже имеющийся шрифт. В этом случае система выкинет предупреждение, что шрифт уже имеется, и для установки его новой версии нужно снести старый. Этого хотелось бы избежать. Значит, нужно проверять наличие шрифта перед копированием его в папку %windir%\fonts. Сделать это легко:

Set objFSO = CreateObject("Scripting.FileSystemObject")
If not objFSO.FileExists (FONT-IN-SYSTEM) then objFolder.CopyHere "FONT-NAME"

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

Install Corporate Fonts.vbs

'Install Corporate Fonts.vbs
Const FONTS = &H14&

Set WshShell = CreateObject("Wscript.Shell")
Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace(FONTS)
Set objFSO = CreateObject("Scripting.FileSystemObject")

'set fonts directory
strFontsDir = WshShell.ExpandEnvironmentStrings("%SYSTEMROOT%") & "\Fonts\"

'install font
strFontFile = strFontsDir & "MyFont.ttf"
If not objFSO.FileExists (strFontFile) then objFolder.CopyHere "\\NETWORK-SHARE\MyFont.ttf"

Сценарий этот расширяем. Необходимо лишь добавлять блоки 'install font с изменением имени шрифта и пути к нему.
Остальное тривиально - групповые политики, сценарии запуска, подстановка полученного сценария, применение политики, перезапуск системы...

@музыка: Blue Stone - Take Flight

---

Runas command + Internet Explorer 7

IE 6 для администраторов был очень удобен. Тем, что если требуется запустить на клиентской машине несколько программ, от своей учетной записи, не нужно было использовать команду Runas для каждой программы. Достаточно было открыть административный сеанс IE, а в нем уже, набрав, например, С: переместиться к файловой системе компьютера. Типичное применение подобного трюка - установка новых шрифтов в систему, особенно если выгружать сеанс пользователя нельзя, а быстрое переключение выключено (доменная среда).
С приходом Internet Explorer 7 все идет к чертям. Нет, сам браузер по-прежнему можно запустить от административного логина, но возможность ходить по файлам в таком виде компания MS убрала. Зачем - неясно. Но ясен сам факт - дела обстоят не самым удобным для администратора образом.
Логично было бы поступить так: Пуск, Выполнить, и далее ввести команду:
runas /user:< MACHINE or DOMAIN NAME >\< USER NAME > explorer.exe
Но не тут то было. Эта команда не возымеет эффекта.
Решением может стать запуск какой-либо сторонней файловой оболочки, например, того же Total Commander или Free Commander. И в большинстве случаев это даже удобнее. Но есть моменты, где и этот подход бессилен - например, все та же установка шрифтов, простого копирования в каталог %systemroot%\fonts там мало, при установке через проводник происходит еще и регистрация шрифтов в реестре, тот же Тотал на такое неспособен.
Что делать?
Пуск, Выполнить, taskmgr.exe. В появившемся окне Менеджера Задач нужно перейти на вкладку Процессы и завершить процесс explorer.exe, это потушит оболочку, но оставит в фоне все запущенные пользователем программы. Далее необходимо выбрать Файл, Новая задача. А уже там вводить знакомое до боли: runas /user:< MACHINE or DOMAIN NAME >\< USER NAME > explorer.exe. В этом случае открывшееся окно проводника будет в том самом elevated-режиме, то есть с правами того пользователя, от чьего имени было запущено. При этом у нас все так же будет открыто окно диспетчера задач. Его не выключаем. После того, как все административные действия будут выполнены, нажимаем Пуск, Выйти из системы. А после выхода в имеющемся диспетчере задач через меню Файл, Новая задача снова запускаем explorer.exe, но уже в обычном режиме. Все довольны. Пользователь не потерял свои данные и программы, администратор выполнил все необходимые действия с "минимальными потерями".

Еще один вариант решения проблемы кроется в особенности установки IE 7 или IE 8 (если последний был установлен сразу поверх шестой версии). Дело в том, что седьмой и восьмой "ослики" позволяют откатиться назад на шестую версию, и ради обеспечения этой возможности копируют IE 6 в папку %systemroot%\ien, где n - текущая версия IE. И именно оттуда можно достать старый добрый шестой браузер.

@темы: Security

---

WebMarshal 6.x

Что такое WebMarshal? Это контент-фильтр, работающий в паре с прокси-сервером, хотя и сам может выступать в роли последнего. Его задача - более детальное исследование трафика, который идет в Интернет и оттуда, с целью отсечения нежелательного материала. Отличие от обычного прокси в том, что контент-фильтрация режет пользователей не только и не столько по адресам, а по содержанию тех страниц, что пользователи пытаются посетить.
Поработав немного с этой программой и вникнув в ее логику построения правил, нашел ее очень удобной, но есть одна ошибка, которая в последнюю неделю мне попортила изрядное количество крови. Суть ее в следующем.
В своей работе WebMarshal может использовать как свою собственную базу пользователей, так и базу Active Directory. Последнее весьма удобно, не нужно "плодить сущности", как многие говорят. Не буду вдаваться в тонкости организации этой структуры, перейду сразу к делу.
Если пользователь, будучи уже импортированным из Active Directory меняет свое расположение в структуре OU (организационных единиц - читай, в другую перекинули его), при следующем же сеансе обновления информации из Active Directory WebMarshal такого пользователя не найдет. Он упорно будет пытаться найти его в старой OU. Эта ситуация разобрана на самом сайте WebMarshal - вот ссылка на страницу:
Moving Active Directory users between OUs - Клац!

В статье указывается, что проблема эта была решена в версии программы 6.1.6. Не подтверждаю. Используется версия 6.1.7 - ошибка сохраняется. В качестве решения предлагается связаться с технической поддержкой WebMarshal.
Что ж, разумно. В конце концов, тех. поддержка на то и нужна, чтобы решать такие вопросы. Но ведь хочется самому понять, в чем неприятность.
А неприятность заключается в следующем. WebMarshal не работает напрямую с учетными записями в Active Directory. Он создает их реплику в собственной базе. И именно эту реплику он каждый раз обновляет во время синхронизации с Active Directory. Вот только почему-то если WebMarshal видит, что запись в AD обновлена, у себя он не изменяет существующую запись, а создает новую. И все бы ничего, но если попытаться показать список группы, которая содержит переехавшую учетку, это приведет к чтению базы из WebMarshal с ее одновременным обновлением из AD. А в базе WebMarshal будет прочитан сбойный элемент, которого в AD уже нет на старом месте. После чего программа впадает в ступор и выкидывает сообщение об ошибке.
Ручная очистка базы из консоли WebMarshal нужного результата не дает. Сбойная запись по-прежнему где-то сидит и мешает жить. Наконец, было принято решение на свой страх и риск залезть напрямую в SQL базу. Найдя там таблицу dbo.User и открыв ее, я пришел в ужас. Сколько раз была добавлена та учетка, будучи в разных OU, столько раз она и содержалась в базе, несмотря на все сеансы очистки из консоли. Дальнейшее уже тривиально. Смоделировать еще раз ошибочную ситуацию, выписать ID той записи, что сбоит, и грохнуть ее из всех таблиц, которые к этой записи могут относиться.
Согласен, метод весьма жесткий, но иногда приходится действовать и так.

UPD. Только сейчас пришло в голову, что можно и не удалять сбойную запись, а всего лишь выправить значение в поле Name, там, где указывается DN этой записи. В итоге исправление нужно будет вносить только в одной таблице. А это уже куда проще и приятнее для базы в целом.

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

---

Windows Update Services #5

Итак, имеем рухнувший WSUS. Сервис, который пользователям не виден, о котором большинство даже не догадывается, неработоспособность которого никак не отражается на жизни людей. Но чинить-то надо.
Принято решение перенести этот сервис на другой хост, выделенный. Так оно надежнее. Все подготовлено, ОС установлена, введена в домен, все необходимые сопутствующие программы и службы выставлены и настроены. Этап установки WSUS, завершение копирования файлов. Следующий этап - открытие консоли WSUS (автоматическое) и начальная конфигурация. Не тут-то было. Открытие завершается с ошибкой, предлагается открыть консоль заново и подцепиться к серверу WSUS. Выполняем рекомендации и натыкаемся на очень странную ошибку: The server may be using another port. Естественно, первым делом проверяется указанный порт, он указан верно. Для пущей уверенности лезем в настройки сайта: как был 8530, так и есть. Просмотр логов приложений дает вот такую картину:
Event Type: Warning
Event Source: ASP.NET 2.0.50727.0
Event Category: Web Event
Event ID: 1310
Date: 05/08/2008
Time: 08:06:31
User: N/A
Computer:
Description:
Event code: 3007
Event message: A compilation error has occurred.
Event time: 05/08/2008 08:06:31
Event time (UTC): 05/08/2008 07:06:31
Event ID: 3481465fab33408892a10fa495bf839f
Event sequence: 3
Event occurrence: 1
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/1508003121/ROOT/ServerSyncWebService-89-128623935909687500
Trust level: Full
Application Virtual Path: /ServerSyncWebService
Application Path: C:\Program Files\Update Services\WebServices\ServerSyncWebService\
Machine name:

Process information:
Process ID: 4488
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE

Exception information:
Exception type: HttpCompileException
Exception message: (0): error CS0016: Could not write to output file 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\serversyncwebservice\00648bbe\3d8ad8e4\App_global.asax.k-otecjd.dll' -- 'Access is denied. '

Request information:
Request URL: <вырезано цензурой>
Request path: /ServerSyncWebService/serversyncwebservice.asmx
User host address: <вырезано цензурой>
User:
Is authenticated: False
Authentication Type:
Thread account name: NT AUTHORITY\NETWORK SERVICE

Thread information:
Thread ID: 5
Thread account name: NT AUTHORITY\NETWORK SERVICE
Is impersonating: False
Stack trace: at System.Web.Compilation.AssemblyBuilder.Compile()
at System.Web.Compilation.BuildProvidersCompiler.PerformBuild()
at System.Web.Compilation.ApplicationBuildProvider.GetGlobalAsaxBuildResult(Boolean isPrecompiledApp)
at System.Web.Compilation.BuildManager.CompileGlobalAsax()
at System.Web.Compilation.BuildManager.EnsureTopLevelFilesCompiled()
at System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters)

Ковыряние Гугла на работе дало отрицательный результат (который, впрочем, также является результатом). Решения нет. Есть шаманство. У кого-то помогает простая переустановка WSUS, кто-то переставляет ASP.NET/.NET Framework, кто-то еще что-то...
В моем случае ни одна из этих мер не помогла. А помогла проверка разрешений на каталог %windir%\Temp. В том наборе разрешений, который уже имеется, было следующее:
Network Service. Уровень доступа - нулевой.
Простановка туда уровня доступа Full Access решило проблему в один миг. Да, я знаю, что полного доступа этой службе в данный каталог не требуется, но решил перестраховаться.

Итак, резюме случая.
Ошибка ID 1310 от источника ASP.NET 2.0.50727.0 - нехватка прав. Точка возникновения - каталог %Windir%\temp. Решение - простановка пользователю NETWORK SERVICE прав уровня Modify.
Всем, кто столкнулся с подобным - Hope this help. Удачи!

@музыка: Yasunori Mitsuda - Chrono Cross OST - Voyage, Another World

@темы: WSUS

---

From CNews.

В августе 2009 г. начнется обучение госслужащих работе с продуктами Google Docs, GMail, Mozilla и OpenOffice.org. До ноября 2009 г. не менее 1526 чиновников должны научиться работать с этими программами. Цена государственного контракта на обучение – 9 млн руб.
Клац!

Пара выдержек:
Через неделю после заключения госконтракта учащиеся за 40 часов должны овладеть общими понятиями об информационной безопасности, научиться пользоваться браузером Firefox, почтовым клиентом Thunderbird и службой GMail.
40 часов на FF - это сильно. Хотя дальше по тексту указано время, отводимое на различные части курса, бОльшую часть отъедает OpenOffce.

По итогам каждого этапа обучения чиновники будут сдавать тесты.
Тестовые задания и результаты - в студию!!! )

А вот дальше - серьезно:
По мнению представителя «Яндекса», GMail не является массовым почтовым сервисом ни в России, ни в мире. «Если не хочется выбирать из российских сервисов, то почему не остановиться на Hotmail, например?» - задается вопросом Колмановская.
Любопытный взгляд насчет того, что GM не шибко распространен. Впрочем, возможно у человека есть некоторая аналитика, которой я не располагаю. А вот насчет того, почему не Hotmail - тут как раз все просто. Как я понимаю, это обучение, а впоследствии и внедрение изученного, должно отвязать пользователей от продукции компании МС. Так что неудивительно, что Hotmail обойден вниманием.

@музыка: Christopher Franke - Flower Hill Trail

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

---

Windows Update Services #4 (продолжение банкета)

Итак, Client-side targetting. А если по-русски - клиент сам лезет в назначенную ему группу на сервере WSUS, а не администратор его туда определяет руками. Как этого добиться?
1. Создать все требуемые группы на WSUS. Сами они создаваться не будут.
2. При помощи групповых политик назначить компьютерам их группы.
3. Перевести сам WSUS в режим Client-side Targetting, задав еще пару параметров автоматического одобрения обновлений (немаловажный процесс, кстати).
Создание групп на WSUS - дело тривиальное, щелкай себе правой кнопкой в списке групп да имена новосозданным задавай. Переключение режима работы WSUS - не сложнее: Options - Computers - Use Group Policy or Registry setting on computers.
С назначением же групп компьютерам интереснее. Не то, чтобы процесс сильно сложен, просто нужно учитывать один момент, который из моей дырявой головы все же вылетел. Назначение групп политиками делается все там же, где и вся остальная работа с GPO домена - оснастке групповых политик. В том GPO, который регулирует механизм автоматического обновления нужно лишь включить параметр Enable Client-Side Targetting. Там же задается и имя группы, куда будут помещены компьютеры, к которым данная политика применяется. Путь к этой настройке выглядит так:

Computer Configuration, Administrative Templates, Windows Components, Windows Update, Enable Client-Side Targetting.

После того, как политика будет применена к группе компьютеров, все они во время следующего сеанса связи с WSUS переползут в определенную им группу. Все просто. А теперь о том нюансе, который важно не забыть.
Если до включения рассматриваемой настройки компьютеры уже были распределены по группам руками, а после применения оной для определенного числа компьютеров группа оказалась не заданной, то все эти сиротливые машины вовсе не останутся на своих местах (на что я, признаться, очень надеялся). Они довольно быстро переползут в стандартную группу под названием Unassigned Computers, где и будут находиться вплоть до момента назначения им какой-либо группы на WSUS. Признаться, для меня было довольно неслабым шоком, когда я увидел, что все серверы из группы Servers куда-то подевались, а на месте осталась лишь файлопомойка - она просто не успела по-тихому смыться. Пришлось политиками перетаскивать их за шкирки назад.

@музыка: Roxette - Fireworks

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

---

Windows 7

Установлена, настроена. Введена в местную комнатную сеть. И первая же неприятность - нельзя просмотреть список моих сетевых папок. Вообще нельзя, нет их. Хотя в системе заявлено, что они есть. О доступе на администраторские ресурсы и разговор не идет.
Ковыряния с этой проблемой привели в знакомую до боли еще по временам настройки XP оснастку gpedit.msc.

Local Computer Policy, Computer COnfiguration, Windows Settings, Security Settings, Local Policies, Security Options.
Параметр Network security: LAN Manager authentication level. Читаю его описание и понимаю, что либо врет описание, либо найден баг, и довольно серьезный. Склоняюсь ко второму варианту. В описании указано вот что:

Default:
Windows 2000 and windows XP: send LM & NTLM responses
Windows Server 2003: Send NTLM response only
Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2: Send NTLMv2 response only

На практике же этот параметр по-умолчанию не задан вовсе. Такая настройка просто не позволяет ОС осознать, какой же протокол использовать при аутентификации пользователей сети. Принудительно выставил в Send NTLM response only. После этого сетевые папки стали видны. Одна из частей проблемы устранена, но остается решить, как же включить административные ресурсы.
При попытке доступа на заветный \\COMPUTER-NAME\C$ удаленная система получает отлуп - неверные логин и пароль. В то же время в Управлении Компьютером на Windows 7 показывается, что мой административный пользователь успешно авторизовался и держит открытым сетевой сеанс. Снова бомбим Google поисковыми запросами, в результате чего на одном из форумов натыкаемся на любопытную заметку: Клац!
Суть в том, чтобы создать в реестре парметр LocalAccountTokenFilterPolicy (тип DWORD) по следующему пути: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System. Значение параметра - единица.
После перезагрузки доступ к административным ресурсам появился как по волшебству.

Любопытен тот факт, что согласно заметке на форуме, эта проблема тащится еще со времен ОС Vista, но лично я с ней там не сталкивался...

@музыка: Blue Stone - Dreamcatcher

@темы: Security

---

Windows Automatic Updates #3

Снова WSUS, будь он неладен. Хотя нет, WSUS-то как раз спокойно работает, раздает обновки и есть не просит. А вот тот самый разношерстный бардак на клиентской стороне...
Windows XP Service Pack 3, SP3 в просторечии так же, как и обычные мелкие заплатки может быть распространен посредством системы обновлений. Но поскольку эта "запчасть" весьма немалая, с ней могут возникнуть проблемы. Одна из таких, весьма неприятных, выглядит следующим образом. Клиент закачивает к себе файлы обновления, ждет условленного времени на установку. После наступления минуты "Х" начинает инсталляцию и буквально сразу прерывает ее, снова становясь в режим ожидания следующего интервала установки. В журналах при таком развитии событий пишется ошибка с кодом 0x80070005. Код этот обозначает нехватку прав.
МС написали по данной проблеме весьма подробную статью в базе знаний, вот она:
При попытке установить пакет обновления 3 (SP3) для Windows XP выводится сообщение об ошибке: "Отказано в доступе" или "Установка пакета обновления не завершена" - Клац!

Сценарий, описанный в третьем способе, сбрасывает разрешения на реестр и файлы на "заводские". Это и обеспечивает неограниченный доступ службы обновлений к нужным ей ресурсам.
Все бы ничего, но указанный скрипт некорректен для Windows XP. В нем указывается файл defltbase.inf, которого в системе просто не существует. Как быть? Поиски во всемирной сети снова дали свой результат, скрипт преобразился вот к такому виду:

Reset.cmd

subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f /grant=system=f
subinacl /subkeyreg HKEY_CURRENT_USER /grant=administrators=f /grant=system=f
subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f /grant=system=f
subinacl /subdirectories %SystemDrive% /grant=administrators=f /grant=system=f
subinacl /subdirectories %windir%\*.* /grant=administrators=f /grant=system=f
secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose

Как это все запустить? Прежде всего, понадобится установочный диск с Windows XP. В дистрибутиве есть хороший набор утилит, называемый Windows Resource Kit. Устанавливаем этот набор, после чего копируем из него одну программу - subinacl.exe Именно она и является ключевым инструментом. Создаем cmd-файл, приведенный выше, сохраняем его рядом с subinacl.exe. Пакет для ремонта разрешений готов. Осталось только его запустить на том компьютере, где наблюдается проблема. Исполняться сценарий будет довольно долго, до десятка минут.

@музыка: G.E.N.E. - Faru Love Affair

@темы: WSUS, Security

---

Windows Automatic Updates #2

Итак, после атаки Kido эту службу требуется снова поднять из пыли, отряхнуть и поставить на место. Проблема решаема при помощи принудительной установки типа запуска службы в "Автоматически". В этом случае после перезагрузки компьютера служба поднимется сама.
Easier said than done. На выходе получаем ошибку следующего содержания: Ошибка 0x80004015: Класс настроен на использование идентификатора безопасности, отличного от используемого вызывающей стороной.
После чего служба послушно становится автоматически запускаемой, но запускаться не желает, в списке служб гордо красуется надпись Stopped.
С этой проблемой я столкнулся еще ранее, как раз пытаясь службу включить принудительно, но поняв, что политика рушит функционал, просто снял ее, тем самым восстановив статус-кво. На этот раз надо все же докопаться до причины. В прошлый раз у меня на руках не было кода ошибки, теперь же он есть.
Что делать? Правильно, спросить решение у всемогущего Google. Великий и тут не подвел, ответ нашелся довольно быстро:
WU client failed to initialize with error 0x80004015 - Клац!
Если по-русски, то получается следующее.
При принудительном включении службы через доменные политики изменяется набор прав на эти самые службы. Политика по умолчанию предлагает проставить следующие разрешения:
Система (System) - полный доступ;
Администраторы (Administrators) - полный доступ;
Интерактивный вход (Interactive, читай, зашедший пользователь, не относящийся к первым двум категориям) - только чтение состояния.
Все. А на деле нужно проставить еще одну сущность, имя которой NetworkService:
В результате должно получиться:
System - полный доступ;
Administrators - полный доступ;
NetworkService - полный доступ;
Interactive - только чтение состояния.
Дальнейшее - тривиально. Определить область действия политики, подключить ее к домену и просто подождать, пока перезагрузятся системы.

Важно! Функционал автоматического обновления системы использует в своей работе две службы - Automatic Updates (Автоматическое обновление) и Background Intellegent Transfer Service (Фоновая интеллектуальная передача данных). Соответственно, принудительно включать надо их обе.

@музыка: Nickelback - If Today Was Your Last Day

@темы: WSUS, Security

---

Kido #4 - Предупреждение.

Trend Micro.Inc - New Version of Conficker
Покой нам только снится. С недавних пор я достаточно часто бываю на сайте своего антивирусного вендора (странно, да? , отслеживаю изменения версий антивирусных баз и движка сканера. Все жду, когда же версия выше, чем 8.911 появится на серверах ActiveUpdate. Пока что нет.
Внимание привлек заголовок с уже ставшим ненавистным словом - Conficker. Ссылка на статью выше. Если вкратце - 7 апреля обнаружена новая версия вредоноса, судя по тому, что она попалась в ловушку компании Trend Micro - пятое поколение червя снова научили размножаться (версии С и D не распространялись по сетям). Пути распространения остались теми же - уязвимость, флешки, P2P-соединения.
Паниковать не стоит, но быть в курсе - обязательно.

P.S> На момент составления записи страница с новостью не отзывалась, выдавая ошибку базы данных - Error establishing a database connection. Видимо, популярной оказалась.
P.P.S> 10.04.2009 - статья доступна для ознакомления. Так что рекомендую.

@музыка: Nickelback - If Today Was Your Last Day

@темы: Viruses and Spam, Security

---

Categorizer

Нет в мире справедливости. Стоило вылечить сеть от Conficker'a, заболел сам. В итоге сегодня весь день оклемываюсь от температуры под 38. Вроде восстановился.
Но запись, в общем-то, не этому посвящена. Посвящена она проблеме, которая занимает меня уже порядочное время. Имя ей - Exchange Categorizer.
Категоризатор, как его иногда переводят, это механизм Exchange, где письмо проходит проверку на спам, вирусы и тому подобную дребедень. Проблема в том, что влиять на этот процесс никак нельзя, а логов, по которым можно судить о процессе "категоризирования" - у Exchange не допросишься. Ну да где человек ни пропадал, правильно сказано, что мечом и добрым словом можно добиться большего, чем просто добрым словом. В роли меча на этот раз выступает реестр.
Message Submitted to Categorizer - then ends - Клац!
Хорошая вещь в статье указана. Суть в том, что при помощи обычной оснастки можно задать уровень протоколирования операций категоризатора от нуля (полное отсутствие логов) до пятерки (максимальный уровень). Но там же указано, что на категоризатор это не оказывает никакого воздействия. Для того, чтобы вывести поганца на чистую воду, нужно лезть в реестр и ковырять тамошние значения, выставляя уровень аж в 7 (Field engineering), который из оснастки недоступен. С этого момента в логах системы в журнале "Приложения" будут доступны сообщения об ошибках несчастного категоризатора. А уж их можно использовать для определения проблемы и поиска решений.

@музыка: Koto - From the Dawn of Time

@темы: MS Exchange

---

Kido #3 - Исцеление

Собственно, как с этой заразой бороться в случае заражения сети. Исходные данные следующие:

- Доменная сеть, серверы на Windows 2003, клиенты на XP x86 SP2 или SP3 (rus, eng).
- Антивирус есть, обновленный, но активную заразу не выкорчевывающий, хотя новую заразу отстреливает исправно.
- Активная зараза есть, пытается пробиться на другие машины.
- Серверы вычищены.
- Клиентов много, речи о том, чтобы лечить каждого руками не идет в силу их географической разбросанности.
- Вариант административного заражения сети исключен.

На помощь приходят две политики. Первая - расстановка всех нужных обновлений. Как уже было написано, их три: MS08-067, MS08-068, MS09-001. Тащим с сайта MS версии этих заплаток для всех языков, которые используются. В нашем случае их два - русский и английский. Все скачанное складываем в отдельную сетевую папку. В итоге получаем нечто вроде этого:
Каталог \хр.
Подкаталог \ms08-067. Файлы WindowsXP-KB958644-x86-ENU.exe и WindowsXP-KB958644-x86-RUS.exe
Подкаталог \ms08-068. Файлы WindowsXP-KB957097-x86-ENU.exe и WindowsXP-KB957097-x86-RUS.exe
Подкаталог \ms09-001. Файлы WindowsXP-KB958687-x86-ENU.exe и WindowsXP-KB958687-x86-RUS.exe

Материал для расстановки подготовлен. Теперь пишем сценарий установки:

Update.vbs

'Set WshShell
Set WshShell = CreateObject("Wscript.Shell")

'Disable Security Warning for Network Files
set oEnv = WshShell.Environment("PROCESS")
oEnv("SEE_MASK_NOZONECHECKS") = 1

'Define OS Language
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colOperatingSystems = objWMIService.ExecQuery _
("Select * from Win32_OperatingSystem")
For Each objOperatingSystem in colOperatingSystems
If objOperatingSystem.OSLanguage = "1033" then strLang = "ENU"
If objOperatingSystem.OSLanguage = "1049" then strLang = "RUS"
Next

'Run MS08-067 Patch
Description = ""
Description = WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Updates\Windows XP\SP4\KB958644\Description")
If Description = "" Then
strCommand = "xp\ms08-067\WindowsXP-KB958644-x86-" & strLang & ".exe /passive /norestart"
WshShell.Run strCommand,,true
Restart = 1
End if

'Run MS08-068 Patch
Description = ""
Description = WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Updates\Windows XP\SP4\KB957097\Description")
If Description = "" Then
strCommand = "xp\ms08-068\WindowsXP-KB957097-x86-" & strLang & ".exe /passive /norestart"
WshShell.Run strCommand,,true
Restart = 1
End If

'Run MS09-001 Patch
Description = ""
Description = WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Updates\Windows XP\SP4\KB958687\Description")
If Description = "" Then
strCommand = "xp\ms09-001\WindowsXP-KB958687-x86-" & strLang & ".exe /passive /norestart"
WshShell.Run strCommand,,true
Restart = 1
End If

'Start AU Service
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colServiceList = objWMIService.ExecQuery _
("Select * from Win32_Service where Name='wuauserv'")
For each objService in colServiceList
errReturn = objService.StartService()
Next

'Start BITS Service
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colServiceList = objWMIService.ExecQuery _
("Select * from Win32_Service where Name='bits'")
For each objService in colServiceList
errReturn = objService.StartService()
Next

'Start Error Report Service
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colServiceList = objWMIService.ExecQuery _
("Select * from Win32_Service where Name='ersvc'")
For each objService in colServiceList
errReturn = objService.StartService()
Next

'Final Warning
If Restart = 1 then
Wscript.echo "На ваш компьютер были установлены обновления безопасности операционной системы. Рекомендуется как можно быстрее перезагрузить компьютер для их применения."
End If

'Enable Security Warning for Network Files
oEnv.Remove("SEE_MASK_NOZONECHECKS")


Вот так он выглядит. Сам файл сценария надо будет положить в каталог xp. После чего создается новый объект групповой политики, который привязывается к группе Domain Computers, а группа серверов исключается из области действия. В этой политике нужно будет задать в Параметрах компьютера сценарий загрузки. Сам сценарий представлен выше.
Что он делает. По-очереди проверяет наличие каждой заплатки в системе. Если не находит какую-то - устанавливает. После установки обновок выполняется принудительный запуск служб Автоматического обновления, Фоновой интеллектуальной передачи данных, и службы отправки сообщений об ошибках. Эти три службы блокируются заразой во время ее действия.

Обновления установлены. Следующий шаг - вынести заразу из памяти компьютера, если она там есть, и из места ее хранения - system32. Попутно вынести ключи реестра, которые ее запускают. В этом помогает, как уже тоже было написано, утилита от Касперского - Kkiller версии 3.4.1. Но с ней есть одна тонкость. Она категорически отказывалась работать вне пользовательского окружения. Иными словами - корректно у меня она срабатывала только тогда, когда пользователь уже зашел в систему. Здесь засада - для манипуляций с каталогом system32 нужны административные права, а у пользователя их нет и быть не должно. Получается, что запускаться Kkiller должен от имени администратора, а как такое можно обеспечить в момент захода обычного пользователя? Простое добавление в автозагрузку не поможет, назначение обычного сценария загрузки - аналогично, потому что все эти средства запускают приложения от имени того пользователя, что сейчас выполняет вход в систему. Казалось бы, ситуация не самая хорошая. Спасибо коллеге из Москвы, поведал он мне про утилиту lsrunase.exe, которая, будучи запущенной с определенным набором параметров, позволяет запустить какое-либо приложение от имени другого пользователя. Благодаря ей задача сводится к достаточно простой групповой политике, в которой будут участвовать следующие компоненты: сценарий входа в систему для пользователя, утилита lsrunase, файл kkiller.exe. Все три компонента нужно будет положить в сетевую папку, подобно обновлениям, описанным выше. Сценарий входа пользователя будет выглядеть примерно так:

RunKiller.bat

\\%NETWORK-SHARE%\lsrunase /user:%USER-NAME% /password:%ENCRYPTED-USER-PASS% /domain:%USER-DOMAIN% /command:"\\%NETWORK-SHARE%\kkiller.exe -f

Как видно, сценарий прост до безобразия. Однако, есть один момент, кроется он в шифровании пароля пользователя - Encrypted-user-pass. Как зашифровать пароль? Ответ прост. Вместе с утилитой lsrunase распространяется и утилитка LSEncrypt.exe. Она-то и позволяет зашифровать любую текстовую информацию. Шифрованную же строку можно будет использовать в сценарии.
Мой подход базируется на следующем. Сценарий входа будет выполняться при каждом входе каждого пользователя, к которым будет применена политика. Что называется - параноидальный режим, а иначе нельзя. Само собой, что во время сканирования утилитка будет кушать какую-то часть ресурсов компьютера, но с этим придется мириться.
Должен сказать еще пару слов о самой lsrunase. Эта утилита является платной. Поэтому ссылок на ее загрузку здесь дано не будет. В качестве light-версии оной распространяется программа lsrunas - делает абсолютно то же самое, но с одним ограничением - она пароль не шифрует. Это значит, что в сценарии он будет прописан в открытом виде, равно как в таком же виде будет передан по сети. Если есть уверенность в том, что шифрование не столь важно - можно использовать ее: Страница разработчика.
После того, как сценарий подготовлен, прописываем его в групповой политике как сценарий входа пользователя. А затем остается только ждать, когда будет перезапущен компьютер. После этого произойдет установка необходимых заплаток, что исключит возможность повторного использования уязвимости, а затем, когда в систему войдет пользователь, запустится утилита Kkiller, которая уничтожит зловреда в памяти и основных местах его "обитания". После этого уже можно будет дать команду основному антивирусному средству на полное сканирование системы для очистки от всей остальной заразы.

Если приведенная выше информация кому-то поможет справиться с заражением сети, значит не все напрасно. Что до меня - мне остается только ждать понедельника и смотреть на логи контроллеров домена.

@музыка: Guano Apes - No Speech

@темы: Viruses and Spam, Security

---

Kido #2 - Противодействие

Лечение сети. Как уже ранее было написано, первое - это серверы. Их еще три. Впрочем, это уже намного меньше, чем в начале вакханалии. Основная проблема кроется даже не в самой процедуре лечения, не в том, что нужно еще найти, как убивать вредоноса. Нет, проблема в пользователях. Самое парадоксальное - их и винить не в чем, в конце концов, тот факт, что блокировка учетных записей идет почти непрерывно - всецело "заслуга" IT отдела. Поэтому приходится из двух зол выбирать то, что меньше буянит - то есть отключение блокировки учеток. Данная мера снижает безопасность сети в целом, но о какой безопасности может идти речь в такой ситуации. Пароли административных записей сменены, нужно обеспечить работу предприятия в целом.
Итак - как это сделать. Снова уже до боли знакомые нам групповые политики.
Создать новую, прицепить ее к корню домена. Областью действия назначить Authentificated users (в русской версии - Прошедшие проверку). Далее настройка самой политики:
Computer Configuration - Windows Settings - Security Settings - Account Policies - Account Lockout Policies.
Параметр Account Lockout Threshold выставить в 0. Два оставшихся держим как Not Applicable (Не задано)
После чего - ждем полтора часа. Это время, в течение которого политика применяется к клиентским компьютерам. В течение этого промежутка времени блокировки еще будут проходить.

С блокировками более мене понятно, после этих мер по крайней мере не будут отвлекать от работы. Остается другая проблема - безумная активность сети. Небольшой факт - за пару минут червь способен заблокировать более 70 учетных записей при минимальном количестве включенных компьютеров (относительно дневного времени, конечно). Соответственно, проблема в медленной работе сети в целом. Можете себе представить, каково приходится контроллерам домена, которые вынуждены обрабатывать лавину запросов. Нужно это как-то остановить. Если сеть большая, и поражена немалая ее часть - спасает только массовая проверка в режиме максимальной злобности. Если же есть уверенность, что точек заражения немного, то можно очень быстро их локализовать. В этом нам помогут политики контроллеров домена.
Работа в домене имеет одну особенность - практически любая активность пользователя порождает событие, которое контроллер может зафиксировать у себя в журнале. В случае борьбы с Kido - незаменимый инструмент. Критерием отбора пораженных машин будет постоянный поток сообщений о непройденной регистрации в домене. Нужно лишь включить регистрацию подобных событий. Как сделать:
Новая политика контроллеров домена - Computer Configuration - Windows Settings - Security Settings - Local Policies - Audit Policy
Включить параметр Audit Account Logon Events, Failure
Включить параметр Audit Logon Events, Failure
Применить политику к контроллерам домена, после чего ждать 5 минут. В течение этого времени политика применяется ко всем контроллерам.
После того, как политика будет применена, нужные нам сведения можно будет отыскать в Журнале Событий контроллера домена в журнале Безопасности. Там все будет достаточно прозрачным.

Ну и последнее на сегодня. Между моментом создания политики отмены блокировки учетных записей и моментом ее применения проходит весьма значительный промежуток времени, за который в домене могут снова появиться заблокированные пользователи. Как от таких избавиться? Искать их руками занятие бессмысленное. Гораздо проще воспользоваться скриптом, которых находит в домене все заблокированные учетные записи и сбрасывает с них флаг блокировки. Сам сценарий выглядит вот так:

Unblock Users in Domain.vbs

Unblock Users in Domain.vbs

' Constants for the NameTranslate object.
Const ADS_NAME_INITTYPE_GC = 3
Const ADS_NAME_TYPE_NT4 = 3
Const ADS_NAME_TYPE_1779 = 1

' Determine DNS domain name.
Set objRootDSE = GetObject("LDAP://RootDSE")
strDNSDomain = objRootDSE.Get("defaultNamingContext")

' Use the NameTranslate object to convert the DNS domain name
' to the NetBIOS domain name.
Set objTrans = CreateObject("NameTranslate")
objTrans.Init ADS_NAME_INITTYPE_GC, ""
objTrans.Set ADS_NAME_TYPE_1779, strDNSDomain
strNetBIOSDomain = objTrans.Get(ADS_NAME_TYPE_NT4)
' Remove trailing backslash.
strNetBIOSDomain = Left(strNetBIOSDomain, Len(strNetBIOSDomain) - 1)

' Find locked out user accounts in domain
' create array of sAMAccountName's
Set objDomain = GetObject("WinNT://" & strNetBIOSDomain)
objDomain.Filter = Array("user")
k = 0
For Each objWinNTUser In objDomain
If (objWinNTUser.IsAccountLocked = True) Then
objWinNTUser.IsAccountLocked = False
objWinNTUser.SetInfo
k = k + 1
End If
Next

If (k = 0) Then
Wscript.Echo "No user accounts locked out in domain"
Wscript.Quit
Else
Wscript.echo "All locked out users are unlocked (" & k & " accounts)"
wscript.quit
End If

Копирайт не мой.

Я искренне надеюсь, что никому его не придется применять. Борьба с Kido - вещь все же выматывающая.

@музыка: Madonna - Rain

@темы: Viruses and Spam, Security

---

Kido - Знакомство

Kido. Donwadup. Conficker.
Я его называю по первому имени, потому как впервые вредонос мне попался именно под ним. Все вышеперечисленное - это он же, у разных антивирусных программ он определяется по-разному.
В последние несколько месяцев этот червь стал настоящим бичом интернета и компьютерных сетей вообще. Сейчас я постараюсь сжато описать все то, что мне про него известно, впрочем, более развернутую информацию в Сети найти труда не составляет.
Итак, червь. Представляет из себя DLL файл, размеры от 150 до 160 кб. Векторы атаки:
1. Главное - использование уязвимости в службе Server компьютера. Успешное использование которой дает зловреду возможность окопаться в системе абсолютно прозрачно для пользователя. Подробность - злоумышленник получает доступ к ресурсу $ADMIN компьютера, который ведет прямиком в каталог Windows\system32. Именно там червь и старается положить копию самого себя. После этого создается запись в реестре, которая определяет на компьютере новую службу с именем, состоящим из произвольного набора символов. Это обеспечивает автоматический запуск червя при старте системы.
Обеспечение запуска - использование "Планировщика задач". Создаются задачи с именами atxxx, где ххх - порядковый номер задачи. Отсчет идет с нуля. Задачи повторяются каждый час, именно они запускают червяка в системе.
2. Использование флешек и сетевых дисков. Задействован механим автоматического воспроизведения (Autorun). В случае успешного исполнения - см. пункт 1 в части каталога System32 и далее.

Признаки заражения.
Первое и главное - невозможность выйти на сайт практически ни одного производителя антивирусного ПО. Microsoft в том числе. Если на компьютере "вчера все работало, а сегодня - нет" - можно "поздравить" - заражение прошло. Требуется еще уточнить момент, идет ли работа в интернет через прокси. Если нет, заражение стопроцентно. Если да - то возможно заражен и прокси-сервер. Именно с такой ситуацией довелось столкнуться мне.
Второе. Червь во время работы блокирует запуск служб Windows: Automatic Updates, Background Intellegent Transfer Service (BITS).
Третье (справедливо для доменых сетей). происходят практически постоянные блокировки пользовательских учетных записей и-за того, что червь все время пытается подобрать их пароли для дальнейшего распространения. Это также приводит к замедлению работы сети в целом из-за многократно возросших объемов передачи данных.
Четвертое. Наличие новых задач в планировщике. Как указано выше - задачи с именами atxxx - следствие атаки на компьютер.

Как бороться с активным заражением.
Если есть возможность - отключить зараженную систему от сети.
В первую очередь, необходимо нейтрализовать червя, если он уже находится в памяти. В этом может помочь утилита от Лаборатории Касперского - Клац!. По ссылке находится также инструкция по ее применению. Подобные утилиты появились и у других вендоров. Утилита Касперского уничтожает вредоноса в памяти, вычищает из реестра информацию о службе, которую червь прописывает в систему, удаляет вирусное тело из каталога System32, а также еще нескольких каталогов, где червяк может содержать свои резервные копии.
После нейтрализации червя следует как можно быстрее установить на компьютер исправления, описанные в бюллютенях безопасности MS08-067, MS08-68, MS09-001. Без этого ни одна мера противодействия не будет эффективной. Установка данных обновлений закроет основной канал доставки вредоноса. После патча системы нужно включить службы автоматического обновления и фоновой интеллектуальной передачи данных (BITS), если они отключены.
Следующий шаг - предотвращение повторного заражения. Отключаем автоматическое восстановление системы, полностью обновляем текущее антивирусное ПО, базы должны быть самыми свежими. Проводим полное сканирование системы. Все найденное и имеющее отношение к вредоносу удаляем сразу и без вопросов. Примечательно, что Касперский может вылечить DLL-файл от вируса. Лечить там нечего.

Проактивная защита или предотвращение заражения
Нужно отключить неиспользуемые службы операционной системы. Так, если у вас нет сети, в которой вы делаете какие-то свои данные доступными для всех - можно остановить службу "Server", которая как раз и ведает общими ресурсами: файлами, папками, принтерами (а именно она и является основным каналом заражения). Однако необходимо помнить, что если появится необходимость использования общих файлов и папок, службу придется снова включить. И также нужно помнить, что список таких ненужных служб всецело определяется задачами, решаемыми на компьютере.
Следующее - отключение автоматического воспроизведения. Об этом мне уже доводилось писать.
Еще одна мера - блокировка реестра. Предупреждение: выполнять эту процедуру следует только людям, имеющим опыт работы с реестром системы и способным восстановить его в случае некорректной работы.
Червь внедряется в пространство сетевой службы Svchost, делая запись об этом в следующем ключе реестра

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost

в параметре netsvcs. Если раскрыть этот параметр и прокрутить список вниз, при заражении там будет стоять запись о новой службе с именем, состоящим из произвольного набора букв. Следовательно, можно не дать червю прописаться в системе, заблокировав для изменения приведенный выше раздел реестра. Для этого нужно нажать на его имени правой кнокой, выбрать пункт разрешения и в появившемся окошке убрать флаг полного доступа для Администраторов компьютера и Системы, оставив режим чтения. Само собой, делать это нужно, если заражения в системе нет.

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

И главное.
Правило номер один. Windows - весьма сложная система, поэтому ошибки в ее работе были, есть, и скорее всего будут. Именно поэтому важно вовремя ее обновлять, устраняя неисправности и уязвимости. Механизм автоматического обновления как раз помогает в этом.
Правило номер два. Не пренебрегайте антивирусной защитой. Даже устаревающий сейчас сигнатурный метод обнаружения все еще не стоит сбрасывать со счетов.
Правило номер три, которое большей частью народа (каюсь, мной тоже) начисто игнорируется. Пользователь с административными правами не предназначен для постоянной работы в системе. Заведите себе учетную запись обычного пользователя и работайте под ней, это убережет вас от многих напастей. Не всех (Kido тому пример), но многих.

@музыка: Gamma Ray - Send me a sign

@темы: Viruses and Spam, Security

---

Files and Space

Можно сказать, экзамен выдержал. Очередная проблема с Exchange, хоть и предвиденная, очередная серия экспериментов в VM перед применением решения. Очередные выходные на работе, что вообще-то было в последний раз больше года назад, историю про перенос того же почтовика в Балте в расчет не беру.
Суть проблемы - свободное место. Оно просто кончилось. Фраза "И время мы измеряем в мегабайтах" стала ключевой на всю прошедшую неделю. Раскладка такова: 3 базы по 150 Гб, и еще две по 80 Гб. Плюс папка логов, но это уже сущие мелочи по сравнению с тремя первыми колоссами. Места под них было выделено еще на этапе проектирования сервера и его структуры - как раз 450 Гб, отдельный диск для логов, и отдельный диск для бекапов. Господа удавы, заявляю, время можно измерять в мегабайтах, особенно когда каждый день у тебя начинается с проверки, а сколько же там свободного места осталось. И постоянные мысли - дотянуть бы до выходных, потому что выключить Exchange в рабочий день нереально. А выключать придется. Дотянули. На момент начала работ места там оставалось без малого 500 Мб. Критика, да и только.
Суть действий - перебить RAID-массив на внешнем хранилище, конфисковав место от первой файлопомойки и даровав почтовику еще 1.9 Тб. Это убьет файлопомойку, но она нам уже не так нужна, почта важнее. Сказано, сделано - в 11 часов субботы базы почтовика были выключены.
Сама по себе процедура подготовки перенесения баз не так уж и сложна. Вкратце ее можно обрисовать следующим образом:

- последовательное отключение каждой базы в каждой группе хранения (как базы ящиков, так и базы общих папок)
Этим достигается консервация баз и предотвращение любых изменений.

- проверка состояния баз программой eseutil
Eseutil /mh
Проверять нужно каждый файл. На этом этапе интересуют параметры
State: Clean Shutdown (чистое отключение)
Log Required: 0-0 (0x0-0x0) (непримененные логи)
О состояниях чистого или грязного отключения и непримененных логах мне уже писать доводилось. Из личного опыта: в состоянии чистого отключения непримененных логов нет.

После отключения баз и проходит их перемещение туда, где они и будут жить, перемещаются файлы *.edb и *.stm. Опять же из личного опыта: базы в чистом отключении при переносе не требуют для себя ни перемещения логов, ни перемещения chk-файла всей группы хранения. Это добро будет создано заново. Тем не менее, наличие резервной копии - ОБЯЗАТЕЛЬНОЕ условие для проведения операции в целом, мало ли что.

В общем и целом, большую часть времени (что в субботу, что в воскресенье) мы провели тупо медитируя на прогресс-бар перемещения баз. Шутка ли, полтерабайта тащить из одного каталога в другой. Да еще прибавить к этому время на переразбиение RAID - но это уже ночью, слава всему святому, что за ночь эта операция прошла успешно. Объясню, почему.
На время работ с внешним хранилищем базы надо куда-то девать. Тащить их по сети в режиме Ethernet 100 - убиться, скорость нас будет тормозить. Поэтому решили содрать их на USB харды. Две штуки по 400 Гб нам хватит. Подключили два харда, слили на них базы (вся суббота на это и ушла), после чего поставили на Expand RAID-массив. И вот тут наши челюсти на пол и упали. Скорость расширения массива - 1% за полчаса. Прикинули - 100% за 50 часов, это получится, что только к понедельнику, к вечеру, и то не факт, у нас завершится подготовка массива. А ведь в понедельник почта уже должна работать.
Кто-то может предложить, а почему эти базы за ночь не слить куда-то в сеть и подключить их по сети к самому Exchange. Отвечу, когда-то давно у меня тоже такая мысль была, но Экс - штука весьма разборчивая. Его базы могут храниться только на DAS-устройствах. DAS - Directly Attached Storage. В эту категорию попадают собственно обычные харды, устройства, подключенные через SCSI-интерфейс, и USB устройства. Из этого многообразия у нас было все, но:
1. Хард самого сервера - это SCSI диск на 45 гигов.
2. SCSI-хранилище - оно сейчас как раз в стадии переразбиения.
3. USB-харды. Дааа, вот тут интересно, поскольку уже на полном серьезе прорабатывали возможность поднятия Exchange "на флешках". Подобной жести у меня в жизни еще не было, и в самом страшном кошмаре не снилось. Почему кошмар? USB-хард, подключенный по проводу к серверу - не шибко надежен. А о том, что случается, когда сервер Exchange вдруг во время работы теряет связь с почтовыми базами, я уже тоже писал, кажется.
В общем и целом, в воскресенье я шел на работу в полной уверенности, что этот кошмар прорвется в жизнь. Нет, повезло, массив переразбился, свободное место получено, можно и заливать базы назад.
Дальнейшее - тривиально: определение того, где будет лежать каждая база, подключение баз в оснастке Exchange, небольшая донастройка всего хозяйства (переименование групп хранения, небольшая их переконфигурация), проверка работоспособности почты.

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

@музыка: Dagda - Anthem Of The Gods

@темы: MS Exchange

---

Autorun

За вполне безобидным и даже удобным механизмом Windows скрывается весьма и весьма сильная головная боль неподготовленных пользователей, а порой и админов. Автозапуск. Да, да, тот самый авторан, который автоматом проигрывает наши CDA диски, сразу же начинает просмотр галерей на флешках и т.п. Само собой, что этот механизм можно использовать и в не совсем добрых целях.
Стандартная мера отключения данной напасти в домене - групповые политики и запрет функции Autoplay на всех дисках. Но есть один подводный камень - этого недостаточно. Блуждая по страницам форумов наткнулся на очень хорошее описание того, что еще можно порубить, дабы оградить себя от атаки классических файловых вирусов:
Клац!
4 ключа реестра, и автозапуск затыкается навсегда.
Единственное, что я еще пока не применил к домену - это удаление ключей MountPoints. В силу того, что я не знаю, как оно работает, и как найти все экземпляры данного параметра на уровне скрипта - пока не рискую. Тем не менее, и вышеприведенных 4 ключей хватило для того, чтобы остановить волну заражений вирусом Sality.aa, вирусом, который именно через авторан и выживает.
Кстати сказать, классические файловые вирусы в наше время ох, как редки. За последние года полтора я вообще не встречал представителей данного класса.

@темы: Viruses and Spam

---

OWA

Outlook Web Access. Весьма удобная функция в составе Exchange, которая мне рушила мозг на протяжении всей прошлой недели. Знать бы, что решение столь простое.
Вводная. После ввода логина и пароля на сайте OWA творится нечто непонятное. Стили улетели в теплые края, список сообщений не загружается, элементы интерфейса aka кнопки "Создать", "Адресная книга" и т.п. не работают. В общем и целом, вместо удаленного доступа к своему почтовому ящику получаешь кукиш с маслом. Это если в Mozilla Firefox, там до писем достучаться все же можно, хоть и криво. В IE нет даже этого, тупая табличка "Loading..." и ничего больше. Вся эта котовасия началась после установки Service Pack 2.
Самое интересное в том, что не мы одни такие несчастные. Интернет просто пестрит постами на форумах с такой же проблемой. Предлагается и просто огромное количество решений, начиная от простой перезагрузки и заканчивая переустановкой SP2. Ни один не помог. Сброс виртуальных каталогов OWA - безрезультатно. Перерегистрация библиотек, отвечающих за обработку XML - туда же. Что за напасть...
И самое интересное, почему в Mozilla Firefox хотя бы часть функционала работает, в то время как в ослике - вообще ноль.
И только сегодня удалось раскопать статью в базе данных MS о том, почему такое могло произойти. Вот она:
Users receive a "Loading" message when they use OWA to access their mailbox after you apply a hotfix or a service pack to Exchange Server 2003 Клац!
Решение просто тривиально... Скопировать один (!) каталог с одного сервера на другой и забыть об этой проблеме...

В то же время так и не понятно, почему в Огнелисе хоть что-то, но работало...

@музыка: David Arkenstone - River Crossing

@темы: MS Exchange

---

Magical 1008 number

После марафона с еще одним восстановлением почтовых ящиков после вторичной аварии на сервере (многовато их что-то) наконец-то начал разгребать весь бардак по резервированию и архивированию информации с Exchange. И нашел в этом одну загвоздку.
Бекап всей информации у нас длился почти 1.5 суток, это очень много. И завершился он в очередной раз неудачей, что для всех, кроме меня, было уже привычным. Стал разбираться, в чем дело. А дело в том, что в процессе резервирования информации почтовые базы данных отключились, то есть стали недоступными. Ни для админов, ни для пользователей, ни для программы архивации. Попытки выяснить причину полного отключения всех баз вывели меня на вот эту статью в базе знаний MS - Клац!
Суть в следующем - при начале архивации базы последняя блокируется для любых изменений на все время архивирования. Все действия, которые должны быть с базой выполнены, сохраняются в файлах логов, которые получают статус Uncommited - непримененные. В системе есть жестко закодированное ограничение на количество таких логов - 1024 штуки (как всегда - по степени двойки). Однако, если этот лимит достигнут, сохранность баз будет под вопросом. Поэтому, если количество непримененных логов достигает 1008 - Exchange самостоятельно принимает попытку сохранения баз данных от повреждения и выполняет т.н. мягкое отключение, базы переводятся в состояние Clean Shutdown, в котором могут быть снова подключены в любой момент. В противоположность этому есть термин "грязное отключение" (Dirty Shutdown), в состоянии которого подключение базы сопряжено с дополнительными действиями, такими, как приведение ее в согласованное состояние и опять же, приведение ее к состоянию Clean Shutdown.
Что же происходит у нас. После того, как на вторые сутки количество непримененных логов превысило критическую величину, базы отключились. Программа архивации, которая до этого момента исправно сливала информацию в бекап, натыкается на недоступность баз, офигевает от такого поворота дел, и отказывается работать дальше, рапортуя об ошибочном завершении задания. В итоге бекапа фактически нет, а та часть, что уже слилась - непригодна для использования в случае краха.
Единственным методом решения данной проблемы является уменьшение времени, необходимое для выполнения всей процедуры резервирования. А вот как этого добиваться, уже вопрос. Лично я пока решил делать резервные копии всех баз, но по-отдельности - одна база за день, это больше, чем трехкратное снижение объема информации. В понедельник - тестовый запуск. Если отработает - распространяю расписание на всю неделю, после чего останется только распланировать сброс архивных копий на ленту и забыть об этой проблеме.

@музыка: Dan Gibson - Whispering Pines

@темы: MS Exchange