Ghosts

Привидения. Фантомы, оставшиеся от когда-то существовавших объектов. Подчас их искать довольно утомительно, зато интересно.
Суть ситуации в следующем. При попытке отправки приглашения на встречу через Outlook отправителю приходит уведомление, что данное приглашение не может быть доставлено одному адресату. Вся соль ситуации в том, что этого адресата никто не указывал. Если объяснить на пальцах, то получится, что приглашение было направлено людям A, B, C, D, а не получил приглашение человек Е. Дополнительный разбор полетов (просмотр логов Exchange) показывает, что вместе с основным письмом было направлено еще одно, как раз тому самому Е. Но ни одного следа этого дополнительного письма в ящике отправителя. Забавно, правда? А самое смешное, что учетной записи, куда отсылается второе письмо, уже нет в AD, и само письмо почему-то отправляется не по SMTP-адресу, а по протоколу X400.
Вроде и забавно, но когда с этим сталкивается человек из руководства, становится не до смеха. Это проблема, и ее надо решать.
На первый взгляд все банально - где-то стоит перенаправление. Стоять оно может в следующих местах:
1. Безусловное перенаправление всей почты человека в учетной записи AD
2. Перенаправление писем посредством правила Outlook.
3. Назначение представителей.

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

@музыка: En Voice - Hall of Dreams

@темы: MS Exchange

---

Exchange 2007 CAS

Вчерашний день был из разряда "Срыв покровов". Обсуждалось расположение серверов Exchange 2007 в сети, кто и в каком сегменте сети будет стоять. В голове прочно сидит положение о том, что сервер переднего плана располагается в DMZ. Копаю материалы по установке Client Access Server, который заменяет собой сервер переднего плана. После захода по ссылке: technet.microsoft.com/en-us/library/bb232184.as... волосы встали дыбом. Да и не только у меня. Ключевым моментом статьи было следующее:

Installation of a Client Access server in a perimeter network is not supported. The Client Access server must be a member of an Active Directory directory service domain, and the Client Access server machine account must be a member of the Exchange Servers Active Directory security group. This security group has read and write access to all Exchange servers within your organization. Communications between the Client Access server and the Mailbox servers within the organization occurs over RPC. It is because of these requirements that installing a Client Access server in a perimeter network is not supported.

Проще говоря, в плане установки CAS DMZ теперь в прошлом, подобная организация сети поддерживаться самим МС не будет. А при PSS звонке первое, что будут рекомендовать - перевести CAS в доверенную сеть. Причиной тому работа CAS с серверами почтовых ящиков через RPC, динамические порты с номерами выше 1024. Так что, лучше этот момент учитывать до того, как организация на базе платформы 2007 будет развернута.

@музыка: стук клавиш

@настроение: рабочее

@темы: MS Exchange

---

Windows 2008 Server RODC

RODC - Контроллер домена в режиме "Только для чтения". Новый режим работы КД, появившийся в Windows 2008. Предназначен для установки в филиалы, где нет достаточного уровня безопасности хоста контроллера (читай, самого компьютера). Этот режим выгоден тем, что не хранит на себе пароли пользователей, за исключением специально выбранных - как правило, работников того самого филиала. Чем выгодно? В самом паскудном сценарии - краже хоста (и такое бывает), нужно будет сбросить пароли только тех учетных записей, пароли которых кэшированы на этом контроллере, а не всего домена. Удобно? Удобно.
Еще одно преимущество работы контроллера в таком режиме кроется в самом его названии - Только для чтения. Это значит, что никакие операции над структурой домена с этого контроллера невозможны, он способен только читать информацию, но не изменять ее. Случайное удаление каталогов, атрибутов в этом случае исключается. Опять же - удобно? Да.
Однако, как и довольно часто, при установке такого контроллера есть свои нюансы. Про режим работы леса в целом и отдельных его доменов я говорить не буду. Это расписано в документации по RODC достаточно подробно.
Первый и главный момент - в домене уже должен быть полный КД уровня Windows 2008 Server. Полный - это значит способный записывать информацию в Active Directory. RODC в процессе своей работы будет общаться именно с таким контроллером, на КД предыдущих версий он даже не посмотрит. Если устанавливается новый домен на базе Windows 2008 Server - это требование будет выполнено автоматически. В случае же перехода с КД Windows 2003 Server этот момент нужно учитывать.
Второй момент - перед установкой RODC ко всему лесу нужно применить команду adprep /rodcprep. Эта команда расширяет текущую структуру каталога, добавляя в нее элементы, обеспечивающие репликацию данных с обычного контроллера на RODC. Если этого не выполнить, в процессе установки будет выдана ошибка следующего содержания:

You will not be able to install a read-only DC in this domain because "adprep /rodcprep" was not yet run.

Информативность текста ошибки стопроцентная. Что делать - ясно без подсказок.
И вот тут-то кроется главный подводный камень, рассчитанный на тех, кто переходит с домена 2003 на домен 2008. Для того, чтобы установить RODC в смешанной среде (где есть и КД 2003, и КД 2008), просто выполнить adprep /rodcprep недостаточно. После ее выполнения вы будете снова натыкаться на приведенную ошибку. В документации по RODC описания подобной проблемы мне найти не удалось, решение откопалось на одном из блогов - Клац!
Интерес на этой странице представляет следующий комментарий:
Just adding a Windows Server 2008 DC to the domain doesn’t mean that you can install RODC in it too – actually you can and that’s when you will experience problems. You have to make sure that the Windows Server 2008 DC is configured (and is really functioning) as a GC and the PDC master role has been transferred to it.
Если это перевести на русский язык, то получаем следующее: простой установки КД 2008 в текущую среду недостаточно. Для получения возможности установки RODC в текущий домен на контроллер домена под управлением Windows 2008 Server нужно передать роль Глобального Каталога (GC) и роль эмулятора первичного контроллера домена (PDC Emulator). Только в этом случае установщик RODC опознает текущий домен, как удовлетворяющий всем требованиям, и согласится на установку RODC.
Как всегда - все дело в волшебных пузырьках одной волшебной галочке. Но нужно знать, где ее искать. Надеюсь, кому-то эта информация позволит сэкономить свое время на поиск решения проблемы.

@музыка: Sleepthief - World Gone Crazy

@темы: Security

---

Море между городами - по колено, океан между континентами - по пояс.

Любопытная история. Как всегда - разбор полетов письма, почему не доходит до адресата. Все началось с получения отбойника вот такого вида:
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
В общем-то, все просто и понятно. Письмо задержано, повторная попытка его доставить все таки будет. Проблема в том, что письмо срочное. Выискиваем номер телефона компании, в которую это письмо улетело, и начинаем выцарапывать информацию.
Приятный женский голос в трубке сказал, что по проблеме вряд ли что сказать сможет, ибо не в курсе, но может переключить на специалиста. Ну что же, спасибо, подожду. Разговор со специалистам позабавил. Суть в том, что письмо ушло на ящик [email protected]. На что с той стороны после минутного раздумья (видимо тоже у кого-то справлялся человек, что и как) был задан вопрос: А откуда вы узнали о существовании этого адреса?
Опа! Вот что б я еще знал, откуда наш сотрудник его узнал. На том конце меня просвещают, что все электронные адреса компании имеют вид [email protected], так что можно продублировать письмо, и оно должно дойти до места назначения. Благодарность за информацию и вежливое прощание. Стороны беседой удовлетворены.
А дальше - дальше трубку к уху и вызванивать сотрудника, где и как на адрес в RU домене напали. Ответ порадовал. Девушка на телефоне в той компании, куда письмо летит до сих пор, сообщила, что можно прислать информацию на адрес %login%. А на уточнение по поводу полного адреса был получен ответ вида: "ну %login%, а после собачки - как всегда". Поскольку звонили по России, легко предположить, что и адреса будут российские. Вот и полетело письмо "на деревню дедушке Константин Макарычу".
Люди, когда диктуете кому-то электронный адрес - диктуйте его полностью. Всегда. Это может сократить кучу времени и нервов в дальнейшем.

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

---

IE Error

Один из сотрудников сегодня "порадовал" ошибкой следующего содержания:
Указанный ключ соответствия не обнаружен ни в одном из активных контекстов активации.

И это при том, что буквально день назад ему был установлена совершенно свежая машина. В логах системы все чисто, ошибок больше никаких. Сеть работает нормально, все ключи на месте. Вопрос - что бы это могло быть...
Быстрое гугление результатов почти не дает. Почти, потому что все сходятся в одном, это ошибка исключительно IE, и после такого его надо переустанавливать. Переустановка! Спрашиваю, КОГДА это начало происходить? Ответ обнадежил - во второй половине сегодняшнего дня. В этот же момент взлядом выхватываю желтенький щит в панели задач. Во второй половине дня проходит установка обновлений через WSUS. А щит говорит о том, что обновления установились, но требуют перезагрузки (на что пользователи практически всегда забивают, что плохо). Перезапускаем систему, вижу, что IE обновился до следующей версии, после чего все исправно заработало.
Вывод из истории - если система говорит о том, что ей надо перезапуститься, лучше предоставить ей эту возможность.

@темы: WSUS

---

Limits.

And I push her to the limit
to see if she will break.
---
(c) Pink Floyd - Take it Back

Согласно политике почта сотрудников, покинувших компанию, не удаляется. Она перемещается из оперативной базы данных в специально выделенную, это снижает нагрузку на сервер. Лимитов на почтовые ящики нет. Пока нет, скоро будут, ибо размеры оперативной базы лично меня уже пугают. Буквально вчера перемещал хороший такой ящичек на 4 Гб весом, смотрю, какие папки перемещаются, сколько писем в них. 19 с плюсом тысяч сообщений, 6 тысяч из них находятся в папке Удаленные. Хочется сказать матерно, но сдержусь. Больше всего повеселил тот факт, что последней была перемещена папка "Важное", в которой находилось всего 14 писем. 14. важных. писем. Из более чем 19 тысяч. Получается, что вся остальная масса сообщений - есть ненужный балласт. Полагаю, после такого есть, над чем подумать.
Люди, пожалуйста, если у вас нет ограничений на размер почтового ящика на работе - не стоит хранить в нем переписку буквально за все время вашей работы. Пожалейте ваших админов, пожалейте ваши серверы, пусть даже вы их никогда не видите, и они железные. Чем больше база писем, тем она медленнее и неповоротливее. Тем хуже она будет проходить резервирование, и тем больше шансы на то, что в случае краха восстановить ДЕЙСТВИТЕЛЬНО важные письма не удастся. Пожалуйста, подумайте над этим.

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

---

Есть компьютеры...

... а есть люди.
Хорошая статья на эту тему - Клац!. Рекомендуется к ознакомлению и осмыслению.

@музыка: Aion OST - Attack the Unsion

---

Mailflow

Слежение за тем, как ходит почта от одного адресата к другому - занятие весьма интересное. Интерес там представляют ошибки, если таковые имеются. Совсем недавно пришлось разбираться с уникальным случаем в моей практике.
Ситуация: звонок сотрудника А с сообщением о проблеме: его письма доходят до стороннего человека Б. Но когда Б нажимает кнопку "ответить" и отправляет ответ, письмо уходит в ящик сотрудника В, о котором Б не имеет никакого понятия.
Вот такая вводная, дальше идет собственно разбор полетов.
Первое - ключевыми словами здесь для меня явились Б нажимает кнопку "ответить", это действительно важно. Те, кто использовал в своей практике почтовик The Bat, и помнят, как там настраиваются учетные записи почты, меня поймут. Для непосвещенных объясню. В The Bat можно менять значение поля Reply-to. Это поле содержит в себе тот адрес, на который будут отсылаться ответы на пришедшее письмо. Если объяснять на пальцах, получится следующее:
Вы настраиваете учетку на работу с адресом [email protected], это ваш основной адрес. В поле Reply-to ставите другой: [email protected]. Все. Ответы на все письма (именно ответы), будут идти к вам на адрес [email protected], в то время как в поле From будет светиться по-прежнему [email protected].
Навскидку я не смогу придумать примеров использования этой схемы, но если ее реализовали, стало быть кому-то это было нужно.
Второе - по уверению сотрудника А, человек Б использует веб-интерфейс Яндекса.
Третье - у нас на предприятии The Bat не используется, стало быть поле Reply-to можно списывать со счетов, тем более, что по-умолчанию оно содержит в себе основной адрес, а я не помню, чтобы хоть для кого-то когда-то его меняли специально.
Четвертое - после проверки учетной записи А выяснилось, что никаких пересылок, перенаправлений и тому подобного добра не установлено. Почта ДОЛЖНА приходить в почтовый ящик А.

Что ж, проводим следственный эксперимент. Отсылаю тестовое письмо с ящика А на свой собственный, расположенный на стороннем сервере. Письмо приходит. Давлю кнопку "ответить", вбиваю "Тест" в тело сообщения, жму "Отправить". Письмо падает в ящик А, как ему и положено. Уведомляю сотрудника, что с его учетной записью все в порядке, и он может спокойно отсылать почту. А сам думаю, ЧТО было не так.
Для того, чтобы письмо попало в какой-либо ящик вообще, необходимо, чтобы в этом письме было хоть одно упоминание адреса, куда это письмо доставить надо. В тексте письма нигде ящик В не встречался, но ведь текст - это еще далеко не все.
Опять же - спасибо почтовику The Bat и его полезнейшей функции Исходное Сообщение. Знаем, помним, любим. Благо, мой сторонний ящик поддерживает эту возможность - открываю код сообщения и в поиск вбиваю адрес ящика В. Нашелся. Угадайте, где. В ПОДПИСИ СОТРУДНИКА А!
В подписи по стандарту компании указывается электронный адрес каждого сотрудника. Обычно это ссылка почтового стандарта mailto:. Как правило пользователи не в курсе, что ссылка состоит из двух частей - текста ссылки и цели ссылки. В нашем случае текстом в подписи был прописан ящик А, а целью был ящик В. После того, как это было замечено в коде письма, все стало ясно.
Вот честно, я бы очень, ОЧЕНЬ хотел посмотреть на человека Б, который утверждал, что отсылал ответ на письмо А, используя функцию "Ответить". НЕ ИСПОЛЬЗОВАЛ ОН ЕЕ, ни разу. Он тупо клацал мышкой на ссылке в конце письма от А, а ссылка, как выяснилось, была битой.
И второй вопрос - кто и как настраивал распроклятую подпись у сотрудника А? Этого узнать, к сожалению, не удалось, хотя обычно сотрудники сами себе подписи ваяют...

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

@музыка: Rian Farish - Breakthrough

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

---

PsExec

Программа PsExec является частью пакета PSTools, разработанного компанией SysInternals. Представляет собой утилитку, которая способна запускать произвольные процессы на удаленной системе, чем и полюбилась системным администраторам. Ее удобство может превзойти разве что ssh протокол. Но есть и несколько подводных камней, одним из которых является вот такая ошибка:

Error establishing communication with PsExec service on XXX:
All pipe instances are busy.

Меня эти слова преследовали полтора года. Самое удивительное, что утилита процесс на удаленной машине запускает, но результат выполнения получить не может. А чаще всего именно результат и важен. Ковыряние интернета и гугля выдало одну из возможных причин: блокирование данной программы антивирусными средствами. В целях проверки истинности предположения антивирус на целевом компьютере был снесен, после чего была выполнена чуть ли не классическая команда:
psexec \\xxxx ipconfig

Результатом стали все те же строки об ошибке. Что за дьявольщина? Затем вспомнилось, что многие антивирусы считают практически весь набор PsTools зараженным вирусом вида Remote Admin. Вирусов там нет, но сами программы как раз и являются средствами удаленного администрирования. Дальше взгляд упал на красную букву K в системном трее на исходном компьютере, после чего файл psexec.exe был внесен в список доверенных. Ошибка исчезла.

Полтора года со мной был касперский. Полтора года он меня защищал от всякой напасти. Надо сказать, хорошо защищал )

@музыка: Runestone - The Well of Secrets

@темы: Security

---

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