Безопасность для чайника. Часть 3.

Части один и два и четыре.

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

11а. (Примечание Владимира Безмалого)

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

12. Никогда, повторяю, никогда не делайте расшаренные папки с разрешениями на запись. Даже у хороших людей могут завестись вирусы, которыми они с удовольствием с Вами поделятся.

13. Если Вы сделали запись в общую папку доступной для всех... Что ж... Я провел эксперимент: выставил компьютер с такой папкой в свою домовую сеть. В течении часа там лежал первый вирус. Через сутки их было три. =)

14. В свете предыдущих пунктов встает необходимость использовать онлайн (мы для простоты считаем, что эти сервисы заслуживают доверия. Если Вы считаете иначе, то для Вас услуги фельдъегерской службы =) ) сервисы для обмена файлами. Будьте осторожны и помните, что я написал здесь. Правило 11 работает и в этой ситуации.

15. Открывать онлайн службу на запись так же нельзя. Пусть человек, который хочет передать Вам данные, откроет Вам к ним доступ на чтение.

16. Если Вы все-таки нарушили правила и Вам записали долгожданный файл... Проверьте его антивирусом до того, как открыли. Еще лучше, дайте ему вылежаться сутки-другие и проверьте еще раз. Что объяснить, зачем, я расскажу Вам мини-историю. В процессе исследований (давайте назовем это так =) ) по одному спамерскому письму я скачал к себе (на специально для этого созданную виртуальную машину). Антивирус определил, что в этом файле только через несколько часов.

Продолжение следует.

Безопасность для чайника. Часть 2.

Итак, продолжаем разговор.

6. Ваш антивирус и firewall не должны быть отключены никогда. Ни при каких обстоятельствах. Два исключения: компьютер выключен или сломался. В самых исключительных случаях можно попробовать их отключить, когда Вы не подключены ни к какой сети и не используете никаких внешних носителей. И то… Лучше быть параноиком. =)

Итак, с активной защитой разобрались. Давайте теперь поговорим о пассивной защите, а я бы ее даже назвал проактивной.

7. Ваш пароль должен быть сложным. Реально сложным. Пароль Qq12345678 формально удовлетворяет требованиям безопасности, но он не сложный. V^0bdsdsct%s*.9jNkXr?Vf4 – сложный. Его сложно запомнить, но еще сложнее подобрать. Общее правило – не меньше 8 символов и как можно больше различных групп символов в пароле.

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

9. Я даже говорить не буду про пустые пароли. =)

10. Работайте из под обычного пользователя. Не администратор. Не Power User. Под Vista это просто – спасибо UAC. Поверьте, при нормальных приложениях UAC будет доставать только при настройке ОС и установке приложений. При штатном использовании это происходит очень редко. Вы можете спорить, можете не спорить, но это работает.

И снова продолжение следует… =)

Часть 1

Часть 3

Часть 4

Безопасность для чайника.

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

Возможно, кто-то спросит, насколько методы, которые я сейчас приведу действенны. Ну… Если я вспомню все, то это будет действенный набор. У меня последний живой вирус на компьютере был, не упомню уже когда. =)

Итак, приступим.

1. Антивирус на новый компьютер должен быть установлен первым. До архиватора. Даже до FAR’а. Даже до установки обновлений. Желательно не подключаясь к сети.

2. Первое, что нужно сделать, установив антивирус – обновить его базы. (сеть не забудьте подключить ;) )

3. Антивирус должен быть обновлен максимально часто. Обычно достаточно для этого оставить настройки автообновления по-умолчанию. Не обновленный антивирус равнозначен его отсутствию. Это не шутка. Только за истекший год я неоднократно копировал к себе ради интереса файлы, которые антивирус распознавал только на следующий день. Что уж тут говорить, о защите, не обновленной полгода.

4. Вместе с антивирусом должен быть установлен и настроен сетевой экран (firewall). Так как неопытный пользователь вряд ли настроит firewall правильно (увы, это действительно не всегда просто), то нужно выбирать инструмент, который имеет встроенный профиль, делающий компьютер почти невидимкой в сети. Stealth-режим или еще что-нибудь в этом роде. Не буду рекомендовать какой-нибудь конкретный, чтобы не сочли рекламой. У меня firewall, интегрированный с антивирусом понятно какой фирмы, а дома справляется с задачей встроенный firewall Vista.

5. Обновляйте свой компьютер. Неважно, Vista это, XP или Linux. Если есть возможность – обновляйтесь. Обновляйте не только ОС, обновляйте также и приложения – в них совокупных уязвимостей больше, чем в ОС. В Windows это делается просто, насколько я знаю, в мире разнообразных Linux за последние несколько лет это тоже стало не сложно.

Продолжение следует…

Часть 2

Часть 3

Часть 4

SDDL: Учимся описывать безопасность. Часть 2.

В прошлом выпуске я рассказал, как строится строка SDDL, так что мы теперь можем что-то прочитать на этом замечательном языке.
Пример 1:
В том самом посте, в котором я обещал написать этот (кстати, есть статья знаний, которая более полна, чем мой пост), я приводил такую строчку:
O:BAG:SYD:(A;;0x1;;;<SID>)
Это один  из самых простых примеров, так что с него и начнем.
1.    O:BA – владелец, в данном случае BA = Built-in Administrators
2.    G:SY первичная группа. SY = Local System
3.    D:(A;;0x1;;;<SID>): DACL
    a.    Тип ACE: A = Allow
    b.    Флаги ACE: пусто (;;)
    c.    Разрешения: 0x1 = GR = Generic Read (да-да, разрешения можно представлять и в виде цифровой строки, я об этом говорил в самом начале)
    d.    Object Type: пусто (;;)
    e.    Inherited Object Type: пусто (;;)
    f.    Trustee: наш SID, который мы искали в том посте.
Итого мы имеем объект, владельцем которого является группа администраторов, а разрешения на нее имеет только пользователь, определенный SID’ом, и только на чтение.
Пример 2:

 
Как здесь прекрасно видно, мы смотрим SDDL строку, назначенную папке c:\temp. Ее текстовое представление:
O:BAG:DUD:PAI(D;CINP;FA;;;LG)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)
Как видите, строка весьма длинная (на самом деле, она весьма короткая, обычно больше, но я специально сделал что покороче =) ), то есть, в отличие от предыдущего примера придется попотеть.
Но приступим:
1.    O:BA – владелец, как и в предыдущем случае это группа Built-in Administrators.
2.    G:DU – Domain Users.
3.    O:BAG:DUD:PAI(D;CINP;FA;;;LG)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;FR;;;BU) – DACL
    a.    P = SDDL_PROTECTED – наследование от контейнеров выше этого заблокировано
    b.    AI = SDDL_AUTO_INHERITED – наследование разрешено вниз, но не вверх, так как выставлен флаг P. На самом деле PAI как раз обычно встречается там, где просто заблокировано наследование
    c.    (D;CINP;FA;;;LG)
        i.    Тип ACE: D = Deny – без комментариев
        ii.    Флаги наследования: CINP
            1.    CI = CONTAINER INHERIT – контейнеры тоже будут наследовать
            2.    NP = NO PROPAGATE: только непосредственные «дочки объекта» будут получать эту ACE
        iii.    Разрешения: FA = Full Control
        iv.    Object Type: пусто (;;)
        v.    Inherited Object Type: пусто (;;)
        vi.    Trustee: LG = Local Guest
    d.    (A;OICI;FA;;;SY)
        i.    Тип ACE: Allow
        ii.    Флаги наследования: OICI
            1.    OI  = OBJECT INHERIT – дочерние объекты, которые не являются контейнерами наследуют эту запись
            2.    CI = CONTAINER INHERIT – контейнеры тоже будут наследовать
        iii.    Разрешения: FA = SDDL_FILE_ALL – все разрешено
        iv.    Object Type: пусто (;;)
        v.    Inherited Object Type: пусто (;;)
        vi.    Trustee: SY = Local System
    e.    (A;OICI;FA;;;BA)
        i.    Тип ACE: Allow
        ii.    Флаги наследования: OICI
            1.    OI  = OBJECT INHERIT – дочерние объекты, которые не являются контейнерами наследуют эту запись
            2.    CI = CONTAINER INHERIT – контейнеры тоже будут наследовать
        iii.    Разрешения: FA = SDDL_FILE_ALL – все разрешено
        iv.    Object Type: пусто (;;)
        v.    Inherited Object Type: пусто (;;)
        vi.    Trustee: BA = Built-in Administrators
    f.    (A;OICI;FR;;;BU)
        i.    Тип ACE: Allow
        ii.    Флаги наследования: OICI
            1.    OI  = OBJECT INHERIT – дочерние объекты, которые не являются контейнерами наследуют эту запись
            2.    CI = CONTAINER INHERIT – контейнеры тоже будут наследовать
        iii.    FR = FILE GENERIC READ – эквивалент Read
        iv.    Object Type: пусто (;;)
        v.    Inherited Object Type: пусто (;;)
        vi.    Trustee: BU – Built-in Users
Все просто. На самом деле бывают более запутанные случаи (скорее уж бывают такие, более запутанные сплошь и рядом), но и с ними Вам помогут справиться следующие материалы:
http://msdn.microsoft.com/en-us/library/aa379567.aspx - основа основ - MSDN. Стартовая страница для серьезного разбирательства. Здесь самые подробные материалы.
http://msdn.microsoft.com/en-us/library/aa374928(VS.85).aspx - «Словарик».
И сообщение в блоге, которое я нашел в процессе подготовки этой статьи:
http://blogs.technet.com/askds/archive/2008/04/18/the-security-descriptor-definition-language-of-love-part-1.aspx
http://blogs.technet.com/askds/archive/2008/05/07/the-security-descriptor-definition-language-of-love-part-2.aspx
Здесь все то же самое, но чуть более подробно, местами, чем у меня. Нашел бы раньше – просто перевел бы.

SDDL: Учимся описывать безопасность.

Я уже дважды обещал рассказать о страшных и жутко непонятных строках вида D:(A;;CCLCSWLOCRRC;;;AU), то есть о SDDL (Security Descriptor Definition Language). Но сначала, конечно же, о том, что это такое и зачем это нужно. Думаю, многим известно, что практически к каждому объекту в современном мире Windows прикреплен некий Security Descriptor, который описывает параметры безопасности, связанные с данным объектом, как то: кто владеет объектом, кто и каким образом может получить доступ к объекту, и что об этом доступе следует записать в журнал аудита. Security Descriptor представляет из себя некую бинарную строку, которую человеку читать можно, но сложно. Для того, чтобы облегчить чтение дескриптора, возможно и был придуман этот язык SDDL. Впрочем, для языка эта структура слишком проста – научиться «разговаривать» на этом языке достаточно просто, хотя и не слишком-то необходимо. А вот читать его и писать на нем хотя бы со словарем я считаю полезным. Иногда еще встречаются ситуации, когда это умение облегчает жизнь. Например, команды SC sdshow/sdset используют именно его. В этом же формате умеет выводить разрешения на объекты файловой системы cacls (Vista и выше) и Get-ACL (PowerShell). Да и мой пост, с которого все это началось, тоже делает такое умение полезным.

Итак, приступим. Представим себе, что мы встретились-таки со строкой вида, указанного выше. Благодаря тому, что Вы прочитали весь предыдущий поток сознания, Вы уже в курсе, что это можно прочесть. Понятное дело, что, раз это можно читать, то можно и разбить на некоторые секции, скажем, «смысловые группы». Этими группами являются:

1. Заголовок (Header). Он содержит флаги, показывающие, как данная строка соотносится с наследованием. То есть, разрешено ли оно, или нет, а также – что именно и как наследуется.

2. DACL (D:) – список собственно разрешений

3. SACL (S:) – список атрибутов аудита

4. Primary Group (G:) – оставлена для совместимости. Не используется до тез пор, пока Вы не работаете с Services for UNIX/Mac.

5. Owner (O:) – отображает владельца объекта.

Соответственно, каждый элемент заголовка сопровождается группой двухсимвольных лексем или SID’ом.

Владелец и Primary Group само собой отображаются в виде SID. Некоторые хорошо известные SID’ы отображаются как акронимы. Например, BA = Built-in Administrators. DACL & SACL представляют из себя строки, которые в свою очередь тоже состоят из различных кусков. Эти куски, заключенные в круглые скобки – ACE, которые (Вы мне не поверите!!! =) ) также дробятся на части. Эти части уже неделимы (разве что на те самые лексемы), отделяются точкой с запятой и содержат следующие параметры:

- Тип ACE (Allow, Deny, AUdit)

- Флаги ACE (наследование и настройки аудита)

- Разрешения

- Тип объекта (в виде GUID)

- Унаследованный тип объекта

- Trustee (кто бы сказал, как это нормально перевести ;). В общем это участник безопасности - пользователь, группа, и так далее)

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

Платформа 2009: начато голосование за доклады.

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

В числе прочих затесалось и четыре моих темы, которые я мог бы и желаю рассказать. Три из них уже видела и слышала аудитория Московского MCP Клуба (впрочем, я не буду читать слово в слово, добавлю в них кое-что – Андрей Бешков подсказал пару идей), а четвертый будет нов даже для них. Так что голосуйте, если желаете послушать эти выступления в моем исполнении. Впрочем, если даже и не пожелаете – меня можно будет найти в секции “Спроси Эксперта”. =)

Мои доклады, которые уже известны узкой аудитории:

NAP: Введение в здоровую сеть.

Windows 2008 AD DS: Что нового?

Построение систем высокой доступности для начинающих.

И новый доклад:

Введение в ForeFront Threat Management Gateway.

Новый подход к назначению разрешений на файловую систему в Win2008/Vista

Мне не так давно (ага, годика пол назад ;) ) поступил вопрос от тогда еще совсем не MVP Александра Станкевича – частого участника посиделок у Паши Нагаева, теперь уже MVP и всегда хорошего человека и специалиста. Вопрос звучал как-то так: «а почему теперь на многих папках в Windows есть пары разрешений для одного и того же объекта и одного и того же участника безопасности?». Я долгое время не мог добраться до ответа, но, в процессе подготовки к выпуску своего поста об SDDL, который скоро опубликую, наткнулся на, как мне кажется, ответ.

Если говорить сначала о самом вопросе, то вот что имеется в виду:

Как видно, здесь есть две записи для каждого пользователя/группы. Если же заглянуть внутрь, то окажется, что одна предоставляет права на саму папку, а вторая уже описывает права на подобъекты и наследование этих прав

 

 

 

  .

Собственно, это и есть ответ (IMHO) на поставленный вопрос: Двойная запись служит для разделения управления разрешениями собственно папки и ее содержимого. То есть одна запись описывает разрешения на саму папку, а вторая те разрешения, которые наследуют от нее дочерние объекты. Разница в данном конкретном случае такая:

Как видно, на саму папку не выдано право изменения подпапок, изменения разрешений и take ownership, в то время, как вторая запись, описывающая поддерево дает полный доступ. В чем плюс? Не дается лишних прав на подобъекты (или наоборот, на сами объекты), унифицируется работа с разрешениями, да и вообще удобнее, если уж приспичит поковырять там что-то. В общем, я, пожалуй, перейму и для себя – надо будет попробовать именно так выдавать пермиции.

В общем, мне кажется, что я ответил на вопрос (кстати, спасибо, Stanky, сам я внимания и не обратил ;) )

Угрозы приватности: только ли от спецслужб и организаций нужно ждать подвоха?

На западе (у нас это пока не так актуально, то есть актуально, но, тем не менее, мало кого интересует) сейчас  многие очень пекутся о приватности и защите частной жизни от вторжения в нее государства, организаций и частных лиц. Что, впрочем, мешает оному вторжению очень мало. Да, можно запретить организациям использовать свою видеосъемку без разрешения запечатленных, установить строгий контроль над силовыми ведомствами в области прослушки и слежки. Но что, скажите на милость, можно предпринять против соседского мальчишки, который с помощью приобретенного "по случаю" чувствительного микрофона записал не только топот таракана по столу, но и разговоры соседей за стеной и выложил запись в своем дневнике? (а обсуждали соседи, скажем, как поедут отдыхать, оставив квартиру без присмотра). Или просто прохожего, который сфотографировал что-то на ходу и так же где-то разместил? А в это что-то по невероятной случайности попали Вы и, скажем, рекрутер конкурентов (которого Вы и знать то не знаете, потому что работа у Вас замечательная, и менять ее никакого желания нет). От этого защиты нет. И не будет, наверное. Просто следствие все повышающейся доступности и мобильности разнообразных средств, могущих Вас абсолютно незаметно и без спроса запечатлеть.

З.Ы. Для любителей поспорить: да, ситуации надуманные и утрированные. Однако, возможные. Кроме того, это сообщение вообще из разряда "мысли вслух" о том, что опасаться следует не только неправомерного государственного надзора.

Про опросы общественного мнения. (Не техническое)

Всех приветствую. Я не виноват, меня попросили!!! =)

В общем, один из будущих докладчиков MCP Club Moscow попросил меня разместить здесь еще один опрос. Думаю, что это оправдано, потому что чем больше мы будем соответствовать ожиданиям аудитории, тем лучше. Итак, снова темы, которые могут быть затронуты этим мистическим докладчиком ;)
Как видите, темы касаются Exchange 2003, но, во-первых, еще далеко не все перешли на новую версию, а во-вторых, докладчик не будет гнать, как я, теорию - все на чистой практике ;) Голосуйте.

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

Опрос1: Какой должна быть детализация технических постов?

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

Порадовал человече, написавший: "Устраивает как есть. Пиши ещё". Спасибо =)

Опрос2: Какие темы Вы предпочитаете видеть в этом блоге?

Здесь все менее очевидно, я трактую это как "надо писать больше" =) На самом деле, как я и говорил, этот опрос мало повлияет на мой блог, однако, повинуясь результатам, я просто постараюсь писать больше, то есть про то, что мне не всегда уже кажется интересным, но, будет, по моему мнению, востребованным. Но это после отпуска, который скоро =)

Windows Internals: новому изданию - быть!!!

Уррра! Великая книга будет переиздана. Теперь и с заметками о Windows Server 2008.

Дата выхода - ориентировочно январь 2009, в списке авторов добавился еще и Alex Ionescu - прошу любить и жаловать.

Defenth-in-depth или почему погиб Ахилл.

Еще одно размышление на тему безопасности. Возникла необходимость такое подумать, потому что достаточно часто вижу и слышу типа «а нафига мне антивирус на клиентских компьютерах, если у меня все сервера с антивирусным ПО?» или «у меня все безопасно – все каналы связи зашифрованы, поэтому к черту политики безопасности». Я думаю, что никому уже не надо объяснять, что я негативно отношусь к высказываниям такого рода. Объясню лишь, почему.

Дело не в том, что концепцию «Defence-In-Depth» придумали отнюдь не идиоты и потому ее хорошо бы придерживаться. Это не аргумент абсолютно, ясно даже и ежу. И не в том, что паранойя rules это хорошо. Дело в том, что многие меры безопасности (и деньги, потраченные на реализацию этих мер) могут оказаться совершенно бессмысленными… Нет, вру, они не бессмысленны. Почти любая защита лучше, чем ее отсутствие. Просто эти меры окажутся несоразмерно дорогими по отношению к уровню защиты, которую они обеспечивают. Мы можем обеспечить вязь между офисами компании через VPN, в надежде, что это даст нам защиту от прослушивания и, таким образом, от утечки информации. Однако если на компьютере конечного пользователя нет антивируса и есть Интернет, то на этом самом компьютере есть вирус, а скорее даже Троян. И не один. И совершенно не факт, что эти Трояны давным-давно не слили уже всю информацию конкурентам. «У нас антивирус на прокси-сервере, и поэтому вирусов у пользователя нет», возразите Вы мне? «А у пользователя есть флешка, на которой он таскает трояны всякую фигню из дома», отвечу я Вам. И у Вас нет даже политики, которая запретила бы ему это. Так что никому не нужен Ваш VPN, достаточно просто дать Троян пользователю и все будет, как хочется злоумышленнику. Потому давайте защищаться грамотно, чтоб не было мучительно больно за потраченные на защиту деньги, время и прочие ресурсы.

Детали о защите от случайного удаления в AD

В свое время, когда я делал доклад о новом в Windows Active Directory Directory Services в Windows 2008, и рассказывал об улучшениях интерфейса, была затронута тема о галочке "prevent from accidental deletion". Это новая фишка в консоли Active Direstory Users and Computers (ADUC), которая не позволяет удалить объект до тех пор, пока не снята некая галочка в свойствах этого объекта. В этот момент меня спросили, является ли эта функция всего лишь деталью интерфейса (то есть, можно ли справиться с помеченным таким образом объектом с помощью других средств, например ldp?) или при ее установке в AD происходят какие-то изменения? В тот день я ответил (предположил), что это скорее всего только функция интерфейса (позор мне! =) ), но червячок сомнения остался и грыз меня больше полугода. Наконец-то (буквально вчера) я добрался до проверки ответа на этот вопрос. Естественно, я оказался не прав, иначе не было бы этого поста. Итак, ответ.

Если мы поставили эту галочку, то удалить объект не сняв отметку можно будет только после пляски с бубном. Причем, это работает даже при нахождении в Active Directory 2003 (для этого нужно только поставить RSAT на Vista, чтобы увидеть новый элемент интерфейса в ADUC), несмотря на то, что схема не изменена. Как же это работает, в таком случае? Да очень просто (как все гениальное, ага =) ).

Когда мы помечаем галочкой упомянутый выше чекбокс, на самом деле в разрешениях на изменяемый/создаваемый объект AD выставляются разрешения Deny Delete & Deny Delete Subtree для группы Everyone. Теперь невозможно случайно удалить объект. Да что там случайно, даже для того, чтобы удалить его целенаправленно, придется попотеть:

1) если у Вас стоит RSAT, то нужно будет включить в ADUC «Advanced Features», потом открыть свойства объекта и снять галочку, после чего его можно будет удалить

2) если RSAT нет, то придется так же находить надоевший нам объект и править разрешения на вкладке Security

По умолчанию, когда создание объекта происходит в новой консоли, эта опция включена, что хорошо. Однако для старых объектов, созданных в старой консоли ADUC этого не происходит, потому или нужно быть осторожным или просто пройтись скриптом по дереву и пометить все это дело, как "защищенное от случайного удаления" ;)

Техподдержка Microsoft: инструкция по эксплуатации. Часть2

Продолжаем разговор.

4) Как общаться:

Да как обычно. Они обычные люди, которые не всегда веселы, не всегда способны быстро вникнуть в Ваши проблемы и всегда запрашивают большие объемы информации. Кстати, об информации. Если Вы не готовы предоставить поддержке логи с Ваших серверов, или запустить диагностическую утилиту на машине, имеющей проблемы, то лучше и не пытайтесь обращаться со сложной проблемой - нет информации = нет мультиков нет возможности Вам помочь.

Что может случиться дальше? Много чего. Вам могут предложить передать кейс в Европу или еще куда-нибудь. Плюсы: инженеров там больше, они, зачастую, обладают более высокой квалификацией, потому многое будет происходить быстрее. Минусы: нужно быть готовым общаться на английском. Иногда по телефону, всегда по почте. И не беспокойтесь о телефонных счетах: звонить будут они.

Еще могут предложить Вам открыть сессию Easy Assist. Это что-то вроде сеанса удаленного помощника. В этом сеансе могут попросить контроль над Вашим рабочим местом. Вы можете отказаться, и это будет воспринято нормально, специалисты поддержки прекрасно понимают словосочетание Security Policy, хотя это и увеличивает время, затрачиваемое на разбор полетов.

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

Чего они не могут сделать, так это попросить еще денег, сказать, что Ваша проблема ерундовая и решать они ее не будут и вообще послать Вас подальше.

5) Чем все это закончится.

А вот тут уже вариантов масса. Причем с подвариантами.

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

б) Пока они там просеивали те гигабайты логов, что Вы им выслали, проблема была решена собственными силами. Вы звоните сотруднику, который общается с Вами по кейсу, и недовольным голосом сообщаете ему об этом. У меня такой финт ушами в подавляющем большинстве случаев вызывает следующие последствия:

• Меня поздравляют
• Спрашивают о способе решения (не жлобитесь - поделитесь =) )
• Извиняются, что не помогли
• И... Не списывают с меня инцидент. То есть я могу еще раз обратиться в поддержку бесплатно.

в) После долгих ковыряний выясняют, что это баг, которого нет в базе знаний. Тут тоже возможны варианты. Первый: Вам сообщают обходной путь решения проблемы. Второй (может комбинироваться с первым): сообщают, что патч будет выпущен в ближайшее время/в следующем пакете обновлений/когда-нибудь. Третий: быстро сварганят патч и выдадут его Вам. Третий вариант редкий, со мной, по крайней мере, такого не случалось. Второй вариант без первого - самый печальный. Именно так было со мной в случае с MS Outlook & RSS (Кстати, возможно эта проблема была решена. Я попробую это решение, когда выдастся свободная минутка). В этом случае останется только смириться, если Вы не сможете доказать, что Ваш случай business critical. Ни одного раза с меня в случае варианта в) не списали тикет.

Вот, вроде и все, что можно сказать, основываясь на моем личном опыте.

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

Техподдержка Microsoft: инструкция по эксплуатации.

Перечитывал некоторые обсуждения на форумах TechNet. Много думал. Нет, мне не приходят в голову мысли об обоснованности или необоснованности требования поставщиков ПО - "заплати!". В конце концов, это просто фетиш - бранить программистов за желание заработать. К такому же желанию певцов, писателей и прочих артистов привыкли, так что и к этому привыкнут, если раньше не проявятся и не станут сильно распространенными и выгодными другие модели лицензирования. Да и написать я, собственно, желаю совсем о других вещах. Одним из аргументов с обеих сторон является техническая поддержка. Одни говорят, что заплати и пользуйся нашей замечательной службой, другие, что, мол, дрянь эта ваша поддержка. И дорого (называются какие-то несусветные цифры в тысячи долларов) и не помогает. Я бы хотел, как человек относительно технически грамотный с одной стороны и общающийся с этой самой службой поддержки на регулярной основе с другой стороны, рассмотреть эти высказывания. Развеять мифы и уточнить истину, так сказать.

Отречение: я говорю на основании своего опыта, потому могу где-то ошибиться.

Отречение от отречения: опыта у меня предостаточно. Только в этом году я открыл более полудесятка кейсов и большинство из них уже закрыто. Большая часть удовлетворительно. Так что ошибаюсь я едва ли. =)

Говорить я буду в основном о поддержке Professional, если не оговорено обратное, потому что с Премьер поддержкой пока опыта не набрался достаточного.

Итак, техническая поддержка.

1) Что нужно сделать до обращения в службу поддержки?

Ну… Во-первых нужно попасть в проблему. Шутка, но в ней, как всегда есть доля шутки. Не всегда Ваши проблемы являются таковыми. Возможно, это поведение системы by design, возможно просто следствие какой-то неправильной настройки или просто временное состояние после падения канала. Нужно попытаться своими силами найти решение проблемы на сайте http://support.microsoft.com. Это важно не только с точки зрения финансов (даже если у Вас "бесплатный" запрос, об этом я расскажу позже в этой статье), но и Вам самим будет полезно. Конечно же, если у Вас упало что-то жизненно важное и ежечасные потери исчисляются тысячами и более долларов, то необходимо срочно обращаться в службу поддержки. Правда при этом не оставлять попыток решить проблему своими силами (это тоже может помочь сэкономить, даже если обращение уже зафиксировано).

2) Кто имеет на нее право, и в каком объеме? Это наиболее сложный для меня вопрос. Так как я последние годы работаю в золотых партнерах Microsoft, то у меня есть доступ к пяти бесплатным инцидентам в год. Плюс к этому у меня есть еще корпоративные подписки TechNet & MSDN. Каждая из них предоставляет еще по паре инцидентов. Плюс есть еще личные подписки, которые я получил как MS MVP и как участник программы IT Pro Momentum. В общем, я весь в шоколаде у меня этим делом почти идеально. "Почти" потому, что все эти богатства не дают мне волшебной палочки поддержки 24х7 (Об этом чуть позже). Другим, я думаю, может быть сложнее, однако, каждый, кто купил не ОЕМ версию ПО имеет право запрос в поддержку. Насколько эта поддержка отличается от профессиональной, и какие вопросы можно в ней решать я сейчас выясняю – напишу позже. Те же счастливчики, которые воспользовались Software Assurance на достаточно крупную сумму (увы домашним пользователям) имеют еще и тикет на поддержку 24х7. На самом деле эти категории уже очерчивают достаточно широкую аудиторию. Хотя и не всех. Для всех остальных действует правило а позолоти ручку, красавчик «деньги вперед». Правда, для корпоративного пользователя деньги на самом деле не очень большие. Что-то около 150 долларов за Профессиональную поддержку и немногим меньше 500 за Премьер (24х7 стоят денег, ага =) ). Так что никаких многих тысяч. Кстати, как минимум премьер поддержку можно оплатить прямо во время звонка при помощи пластиковой карты. Насчет профессиональной не знаю. Итак, с доступностью в смысле финансов разобрались. А что у нас с просто доступностью?

3) Как воспользоваться:

Очень просто. Позвонить по телефонам +7 495 916 71 71 или 8 800 200 80 01 и сказать, что Вы желаете воспользоваться технической поддержкой и на основании чего Вы имеете на это право. Если Вы пользуетесь поддержкой впервые, то нужно будет пройти некоторые формальности, но это не долго (Вы же помните, что звонок на второй телефон бесплатен с любого стационарного аппарата в России?). А при повторном обращении спрашивают и того меньше. Еще можно написать письмо, но я предпочитаю звонок. Со звонком одна проблема: русская служба поддержки работает пять дней в неделю и в рабочие часы (8:00-20:00. Московское время, увы). Если Вы позвоните в нерабочее время, будет предложен вариант пообщаться с поддержкой, которая работает в данное время. Обычно за океаном, так что английский - к бою.

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

Продолжение следует...

ISA 2006 Service Pack 1. Обзор. Часть2

Продолжаем наш практический обзор. Памятуя о предыдущей части, напомню, что успешное прохождение теста правила Web-публикации не означает автоматически, что все хорошо (а то задают уже вопросы). Тест может быть удачным, а правило работать при этом не будет. В частности, проверяется не успешность аутентификации, а совпадают ли методы аутентификации, сконфигурированные на IIS и в listener на ISA.

Теперь к фичам, которые еще не освещены независмой прессой мной.

Пряник #3: Traffic Simulator.

Все очень просто. Вводите откуда идет трафик. Вводите куда идет трафик. Жмете Start и получаете правило, которое разрешает или запрещает данный трафик. Великолепная вещь. Просто супер. Проверяет четыре типа трафика:

1. Web Access
2. Non Web Access
3. Web Publishing
4. Server Publishing

Без комментариев, в общем-то - все понятно и так. Выглядеть может вот так:

Или вот так

В общем, пользоваться не напользоваться. Однако тоже не панацея, хотя и здорово облегчает жизнь. Не панацея, потому что может ошибаться в различных ситуациях. Например, не определяет ситуации, в которых трафик будет заблокирован фильтром приложения. Напарывался уже, рекомендую быть внимательным =)

Пряник #4: Diagnostic Logging

Одна из немногих фич нового SP, которые я самолично пока не попробовал - просто не было повода. Но для глубокого траблшутинга должно быть очень не плохо. полная информация обо всем, что происходило с пакетами внутри ISA. Очень информативно и, как мне кажется, может быть весьма полезным.

Остальные пряники больше касаются внутренних изменений. О них в следующем выпуске. =)

Я не менеджер...

... и не очень-то стремлюсь им быть (ну максимум - team leader :) ), но вот это оценил. Это нужно смотреть каждому, кто имеет в подчинении хотя бы одного человека. А еще лучше ДО того, как он станет хоть мелким, но руководителем. =)

Менеджер-снежинка

view presentation (tags: project management)

Взято у товарища Панкратова.

Как дать пользователю право на чтение Event Log?

Очередная относительно типовая задача: нужно дать пользователю право на чтение Event Log, при этом, не дай бог, права эти нужны на котроллере домена или на другом критичном для безопасности сервере, и предоставить полномочий больше чем нужно мы не желаем ни в какую. А, если мне память не изменяет, для удаленного просмотра логов пользователь должен быть как минимум power user (поправьте меня, если я не прав). GUI по моим данным для такой задачи нет, CLI тоже, так что остается старыми дедовскими методами, то есть ручками. Что нам для этого нужно? На самом деле произвести достаточно простые процедуры:

1) определить SID пользователя, которому мы желаем предоставить права. Есть утилиты навроде user2sid, а я пользуюсь PowerShell. Например, и

Get-User "Vasya Pupkin" select name, sid

и

Get-QADUser "Vasya Pupkin" select name, sid

дадут нам табличку из имен подходящих учетных записей и их SID'ов. Наливай да пей Выделяй и вставляй.

2) Поправить реестр.

----------------------------------------------------------------------------------

Предупреждение. При неправильном использовании редактора реестра могут возникнуть серьезные неполадки, требующие переустановки операционной системы. Корпорация Майкрософт не несет ответственности за неправильное использование редактора реестра. При изменении реестра полагайтесь на свой опыт и знания.

----------------------------------------------------------------------------------

Собственно, нужно найти ветку

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\

(предполагая, что мы даем права на application log) и найти там ключ CustomSD. Он выглядит приблизительно вот так:

O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)

К этому ключу нужно добавить (повторяю, добавить, не заменить его!!!) запись вида (A;;0x1;;;<SID>), где SID это как раз то значение, которое мы выяснили на первом шагу.

Если этого ключа не существует, то можно его создать, тогда он будет выглядеть так:

O:BAG:SYD:(A;;0x1;;;<SID>)

Вот такая вот ерундовина. А об этих страшных буквах (D;;0xf0007;;;BG) я напишу чуть позже - понимать, что они означают, может быть полезным навыком.

P.S. Работает как на Windows 2003, так и на Windows 2008.

ISA 2006 SP1. Обзор. Часть 1

Многие, посмотрев на заголовок поста воскликнут "Фу, какой баян" и будут абсолютно правы: это обновление вышло достаточно давно, чтобы не быть новостью. Однако многие ли из Вас уже протестировали его? А многие ли внедрили его в боевую сеть? Предвижу, что ответ отрицательный. А зря. Этот SP реально заслуживает, чтобы его использовать на полную катушку. Заявляю не понаслышке. =)

На данный момент, я не столкнулся ни с какими проблемами, вызванными применением ISA Server 2006 SP1 в промышленной эксплуатации, да и не слышал о таковых. Потому, учитывая предоставленные вкусности, считаю его почти что необходимым к внедрению.

Ну а теперь более подробно уже о самих "пряниках".

Пряник #1: отслеживание изменений.

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

Выглядит использование этой возможности так:

Вывод можно фильтровать по имени пользователя, внесшего изменения и по ключевым словам.

А еще можно использовать ее, не запуская консоль управления - из веб-странички, о чем подробно написано тут.

Да, кстати, теперь, когда Вы нажимаете кнопку Apply, чтобы ввести измененный конфиг в строй, появляется еще одно окно, которого не было раньше и в котором есть возможность ввести комментарий к сделанным изменениям (рекомендую) и экспортировать текущую конфигурацию (настоятельно рекомендую). Предвидя вопросы на эту тему, уточняю: экспортируется при этом вся конфигурация. То есть если у Вас даже Enterprise Edition, то экспортируется конфигурация всего предприятия.

Пряник #2: кнопка Test Rule

Собственно почти без комментариев. Только расскажу, какие правила можно проверить и как происходит проверка. Проверить можно правила веб-публикации. А проверяется соответствие настроек, заданных в правиле, настройкам веб-сервера. Если чуть подробнее разобрать, что при этом происходит, то последовательность будет такой:

1. ISA Server пытается разрешить доменное имя публикуемого сервера.

2. Потом он устанавливает соединение с этим сервером. Если правило заставляет ISA связываться с публикуемым сервером по защищенному соединению, то выясняется валидность сертификата веб-сервера.

3. Шлется запрос HTTP GET, после получения ответа на который

4. Проверяется соответствие требований к аутентификации, требуемой сервером требованиям, заданным в правиле.

Результат:

Есть всякие тонкости, связанные с различными настройкам правила публикации, но за ними уже в этот документ. =)

А продолжение следует. И, поверьте, дальше все ничуть не менее вкусное =)

Phishing: почему он есть и как с ним бороться.

Пока крайняя мысль на тему фишеров и прочих лишенцев. Давайте рассмотрим, собственно, возможные способы борьбы с этим делом. Для начала лично я попробовал просто подумать (анализом это не назвать) как письмо фишера появляется в почтовом ящике пользователя. Что приводит к тому, что этот вид мошенничества так распространен?

1) Рассылка таких писем становится кому то выгодной (да-да, прошли те благородные времена, когда пиратствовали по зову сердца ;) ). В первую очередь выгодна она людям, которые и являются фишерами, во вторую - владельцам спам сетей, о которых мы вспомним еще чуть позже в этой публикации. Бороться с выгодностью можно разными способами. Например, обучать пользователей. Обученный пользователь с меньшей вероятностью засветит свою кредитку на подложном сайте, тем самым снизив рентабельность фишера. Другим способом являются создание различных международных договоров, организаций и прочих нормативных актов, способствующих поимке и наказанию мошенников (а мы ведь помним, что фишер с точки зрения УК это банальный мошенник, отличающийся от лохотронщика только инструментарием). Международных потому, что фишер, сидя в России, может наносить ущерб швейцарским клиентам американского банка. Создание такой "противорыбачной" сети так же снизит прибыльность предприятия. Трудно ведь назвать прибыльной операцию, принесшую несколько десятков тысяч долларов, за которую придется отсидеть пару лет. А то и не пару.

2) Фишерскую атаку легко организовать. Для нее есть отличный транспорт: спам-сети, о которых я уже упомянул. Дешево и массово. Нет, я видел случаи комбинированных атак, когда в почтовый ящик кидают обычное письмо, просящее зайти на страничку в интернете и "подтвердить" свои данные путем ввода реквизитов банковской карты и PIN кода. Слышал я и о полностью "бумажных" аферах, когда просто требуют перечислить некую сумму на банковский счет, потому что иначе "все будет плохо и банк Вас заблокирует". Но это как раз дорого и не массово, а, следовательно, плохо удовлетворяет пункту 1. Таким образом, мы приходим к мысли о борьбе фишерами и прочей нечистью путем борьбы со спамерами, которые и сами по себе являются злом (кто-нибудь не знает, что до 95% почтового трафика в мире является спамом?). Нет спама - нет фишерских писем в ящике, значит, нет прибыли. Остаются другие способы доставки, но на то она и безопасность, чтобы быть забегом наперегонки со злоумышленником. Да и не такие они выгодные эти другие каналы доставки. Одна беда: победа над спамом, похоже, является лишь несбыточной мечтой. Пока. Есть разные идеи, например, идея Эльдара Мусаева или Sender ID от MS. Но эти идеи требуют всеобщего внедрения. Частными инициативами здесь ничего не добьешься.

3) Пользователи. Я всегда говорил, что не было бы пользователей - не было бы проблем. =) Но, увы, мы живем в не идеальном мире, в котором пользователь не верит всякому письму "счастья", электронному или бумажному. Где пользователи сначала думают, потом… Ну, хватит мечтать. Этим делу не поможешь. Если письмо с просьбой нажать красную кнопку, под которой написано «Self Destruction» попало в ящик пользователя, то пользователь эту кнопку нажмет. Исходить нужно, увы, из этого предположения. И повлиять на это можно только обучением пользователя или отчуждением его от канала распространения атаки.

Ну, а вкратце, подводя итоги всей этой писанины можно сказать, что Путь Меча проходит лечение данной проблемы должно быть комплексным (удивил, да? =) ) и включать в себя 1) технические и организационные меры по уничтожению каналов доставки вредоносных писем

2) создание нормативно-правовой базы и международных организаций для борьбы с киберпреступлениями. (кстати, может уже есть такие организации кроме ИнтерПола, кто-нибудь знает?)

3) обучение конечных пользователей. Мне за назойливое повторение этой истины скоро памятник поставят из навоза, но я по прежнему убежден: пользователь должен быть обучен. Иначе никакие ухищрения не спасут. Должна постепенно зарождаться культура информационной безопасности, такая же как культура поведения за столом или культура пития.

Вот такой вот набор банальностей ;)

Опрос о блоге

Как знают постоянные читатели этого блога (если они есть, конечно же), мои сообщения можно поделить на три категории:

1. Технические публикации
2. Публикации о Московском MCP Клубе
3. И сообщения "за жизнь", в которых преобладают различные мои измышления и наблюдения на тему компьютерной и не очень безопасности.

Вы думаете, что угадали тему опроса? Ну... Почти. На самом деле, опросов будет два, и тот, о котором подумалось сразу (Вы ведь подумали об опросе "какая из трех тем Вам больше нравится?"? Так ведь? Нужно не забыть устроить опрос на тему "что Вы подумали" ;) ), на самом деле второстепенный для меня. Нет, не то чтобы меня не интересовало, что Вы по этому поводу думаете, просто это вряд ли сподвигнет меня на какие-то радикальные изменения в блоге: если я не умею писать про программирование, то я и не буду, появившаяся в моей голове мысль о безопасности все равно получит выход здесь. А если мысли не будет, то и писать будет не о чем. Правда, если будет определенный перекос в сторону одной из тем, то я постараюсь делиться по этой теме более широким кругом мыслей, то есть опущу планку самоцензуры (Beware! Ogre Flood approaches ;) ).

Короче, вторым вопросом будет именно "какой из трех топиков Вы предпочитаете" и не стесняйтесь указывать четвертый и пятый, равно как и детализировать внутренности топиков (хочу больше знать про продукт Х).

А вот первый опрос будет иметь однозначный практический выхлоп: "насколько бы Вы желали, чтобы я детализировал технические посты"? Если разбирать на примере моего последнего поста про Data Protection Manager, то желаете ли Вы, чтобы я подробно и со скриншотами (video?) рассказал о том, как выполняются все процедуры, которые я там мимоходом упомянул (например, восстановление базы данных в любой instance). Причем, повторюсь: все процедуры. То есть, те, кто уже радостно готовы завопить "ДА!!!" должны себе ясно представлять, что это понесет в себе и минусы: объем статьи, время на ее подготовку и все такое. Впрочем, у меня есть пара мыслей о том, как бороться с объемом, но это добавит еще больше времени на подготовку и, может таким образом уменьшить (куда уж меньше...) количество самих статей. Ну и есть как всегда третий вариант, который требует чуть меньше времени и сил: указывать только линки по теме (на самом деле это базовый вариант, вариант номер один это пока что только моя забывчивость). Вот такое вот первое голосование. Кстати, не стесняйтесь указывать свои идеи по этому вопросу в графе "другое".

Ну и сами опросы (можно выбирать больше одного варианта и указывать свои в комментариях или поле "другое"):

1. Какова должна быть детализация материала, описываемого в моих технических публикациях?

1. Какие типы публикаций Вам интереснее видеть в моем блоге?

DPM: Продолжение полета.

Первые плохие новости. В принципе, не то чтобы совсем плохие, просто мелкие неудобства, но судить читателю, разумеется.

Суть приблизительно в следующем. Предположим, есть у нас SQL сервер, установленный на Windows 2008. И захотелось мне, по какой-то одному мне ведомой причине восстановить базу данных, работающую на этом сервере на другой SQL сервер, который, однако, работает под управлением Windows 2003. Ну вот блажь напала, или, что вероятнее, потестировать захотелось что-то на базе, идентичной натуральной боевой. Казалось бы, чего проще: три клика мышкой и база восстановлена на любом instance и работает. Однако, действительность не так приятна, увы. При попытке восстановления в такой ситуации возникает ошибка "Operation Failed Because DPM Encountered An Unexpected VSS Error. (ID 30218)"

"Ну это же ерунда!!!", воскликнет многоуважаемый All и отправит меня в службу технической поддержки. Ну на самом деле не отправят, не привычен народ у нас требовать свое железной рукой обращаться в техническую поддержку. А я, грешным делом уже звоню им даже не как себе домой (не звоню я домой вовсе, обычно), а много чаще, позвонил и на этот раз. Так вот, самое печальное, это то, что ответ службы поддержки звучал приблизительно как "увы, это проблема совместимости и пока нет никакого workaround" =(

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

Итак, подведем итоги.

Минусы:

1) Не так удобно, как было бы, если бы все работало. Больше места для ошиби и времени для восстановления.

2) Пункт один подталкивает к скорейшему переводу серверов на Windows 2008. А перевод, например, кластера высокой доступности на новые рельсы обещает быть задачей не слишком тривиальной и, что самое омерзительное, связанной с простоем сервисов.

Плюсы:

1) Даже такое восстановление несколько легче стандартных методов и почти на порядок быстрее.

2) А кто сказал, что переход на 2008 это плохо? наши первые ощущения от эксплуатации Windows 2008 (а нам уже есть что "ощущать" ;) ) более чем благоприятные.

3) Нетривиальная задача? Зато как интересно это сделать!!! Правда простой испортит настроение, но лишь на чуть. Кстати, можно сделать задачу простой, если железо позволяет: взведите рядом второй кластер и просто перенесите на него базы.

4) UPD: Вот прямо в тот момент, когда верстался номер писАлись эти строки, пришло письмо от поддержки: тема бага раскрыта не полностью, потому я продолжу свое общение с разработчиками на благо индусского народа сообщества до полного излечения оного (бага, то есть). Есть, есть свет в конце тоннеля =)

 

В общем, позитиFF, да и только =)

Что будет интересно посмотреть/послушать аудитории на заседаниях Клуба? Напоминание.

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

Если присмотреться, то становится ясным распределение интереса к темам, потому, почти наверняка следующая встреча будет посвящена миграции на Windows Server 2008... Потом... Что будет потом, мы разберемся потом. =)

Я еще могу добавить теперь некоторую информацию по DPM, но эта тема вряд ли будет пользоваться такой же популярностью, так что оставим ее на закуску ;)

Помимо указанных мной в опросе тем были еще три заявки:

1) Миграция единственного Exchange 2007 c Server 2003 на 2008

2) Exchange 2007/2003

3) Integration between NPS and NAP

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

Ну и напоследок: кто не проголосовал - ссылка ниже, голосование все еще ведется ;)

 
Alexander Trofimov: Что будет интересно посмотреть/послушать аудитории на заседаниях Клуба?