Konstantin 的个人资料Konstantin Leontiev's We...照片日志列表 工具 帮助

日志


5月21日

История успеха ОГК-4: Или еще один пример того, как работает Microsoft Consulting Services совместно с партнерами.

Недавно на публичном сайте Microsoft Россия был опубликован окончательный вариант (видео-ролик и текстовка) истории успеха внедрения в ОГК-4 Active Directory и других продуктов Microsoft.

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

Этот видео-ролик и историю успеха некоторые уже могли видеть ранее в составе нашего с Сашей Суховеем доклада на “Платформе 2009”, о чем я уже писал в своем блоге.

image

Данная история успеха примечательна тем, что это не просто описание того, как удачно технологии Active Directory, Systems management Server 2003 и System Center Operations Manager 2007 решают задачи Заказчика (ОГК-4), но и как эти задачи решались Исполнителями проекта: совместно Microsoft Consulting Services и компанией КРОК.

Так же примечательно, что в этом ролике впервые публично фигурирует созданная усилиями российского подразделения консалтинга технология автоматизированной миграции рабочих станций Windows Automated Migration Suite (WAMS).

5月5日

Путь к вершине… или как я стал Microsoft Certified Master и Microsoft Certified Architect.

Путевые заметки сертифицированного странника.

Константин Леонтьев, Москва, февраль 2009 года.

image image Часть 1: Зарождение сертификации нового поколения.

После того как я успешно завершил свой путь к наивысшей профессиональной сертификации Microsoft и стал первым в России и странах СНГ обладателем сертификации Microsoft Certified Master: Windows Server 2008 Directory и Microsoft Certified Architect: Windows Directory мои друзья, знакомые и просто хорошие люди задают мне много разных вопросов по этому поводу. Если суммировать и проанализировать все эти вопросы, то получится два основных:

1)      Что такое эта сертификация Microsoft Certified Master и Microsoft Certified Architect, что она дает и вообще нужна ли она?

2)      С чего начинался путь к сертификации Microsoft Certified Master и Microsoft Certified Architect, как много сил и времени ушло на него?

Безусловно, ответить на оба вопроса подробно и развернуто непросто, но я постараюсь это сделать на столько, на сколько у меня хватит возможностей и красноречия.

Для начала немного истории сертификации Microsoft.

Вы вероятно уже заметили, что 10 февраля 2009 года на сайте Microsoft в разделе обучения и сертификации (http://www.microsoft.com/learning/mcp/) произошли кардинальные обновления. Я хочу рассказать вам историю, непосредственным участником которой мне посчастливилось быть и приведшую к этим изменениям. Современная часть этой истории основана на личном опыте и моем общении с людьми, непосредственно отвечающими в корпорации за развитие программ сертификации, часть же истории до 2006 года основывается на свидетельствах очевидцев и исторических записях в Интернет.

История сертификации Microsoft начинается в 1992 году, когда мировому сообществу профессионалов в области информационных технологий была предложена сертификация Microsoft Certified Professional (MCP), а чуть позже Microsoft Certified Systems Engineer (MCSE) и Microsoft Certified Solution Developer (MCSD). В то далекое время сертификационные статусы необходимо было подтверждать в течение 12-18 месяцев после выхода новых версий продуктов.

С выходом новой операционной системы Windows 2000 в самом конце 1999[1] года появляется четкое понятие специализаций по версиям продуктов MCSE on Windows NT 4.0 и MCSE on Windows 2000. Это было сделано для того, чтобы с одной стороны не требовать от профессионалов сдачи экзаменов по новым продуктам в слишком короткий срок в том случае если им нет необходимости в работе использовать новые технологии Windows 2000. С другой стороны специализация позволяла бы работодателям и другим профессионалам четко понимать экспертом в какой именно версии продуктов Microsoft является тот или иной сертифицированный специалист. Кроме того в 2000[2] году появилось понятие переходных или upgrade–экзаменов, которые позволяли ИТ-специалистам не начинать сдачу сертификационных экзаменов с нуля, а «сдать разницу» и получить подтверждение знаний новых технологий максимально сохранив свои инвестиции сделанные в предыдущую сертификацию.

Вообще говоря, различные не очень значительные изменения в своей линейке сертификации Microsoft делала и ранее, например, в результате бурного развития Интернет в 1996 и 1997[3] годах у профессиональной сертификации Microsoft появилась дополнительная специализация Internet (сначала MCP+I, потом примерно через год MCSE+I). Эта специализация прожила примерно 4-е года. В конце 2001 начале 2002 году ее отменили, а параллельно на свет появилась промежуточная и более популярная и долгоживущая сертификация Microsoft Certified Systems Administrator (MCSA).

В 2003 году почти параллельно с выходом новой операционной системы Windows Server 2003 и соответственно сертификации MCSE on Windows Server 2003 и MCSA on Windows Server 2003 для сертификаций MCSA и MCSE ввели специализации: Messaging и Security. Эти специализации относились к направлению инфраструктурных решений и технологий. Для разработчиков, администраторов баз данных (MCDBA), сертифицированных тренеров (MCT) и других сертифицированных специалистов Microsoft очень существенных изменений в программе сертификации не делалось. Кроме того, сертификации для тренеров, администраторов СУБД и разработчиков не входят в круг моих интересов, а потому повествование о них я предпочту доверить кому-нибудь другому.

Параллельно с ростом популярности[4] профессиональной сертификации Microsoft росло и число «бумажных специалистов». Появлялись сообщения о детях школьного возраста успешно сдавших сертификационные экзамены. В основном это было обусловлено тем, что для получения статуса сертифицированного специалиста достаточно было сдать один или несколько экзаменов в ближайшем тестовом центре. Экзамены сдавались (и сдаются сейчас) за компьютерами в виде тестов. Такой подход позволял нечистым на руку центрам тестирования и недобросовестным экзаменующимся вопреки подписанному соглашению создавать так называемые дампы экзаменов (списки вопросов с правильными ответами). И размещать такие дампы в сети Интернет (иногда даже за деньги). Таким образом, любой желающий мог получить подобные материалы и, вызубрив от 80 до 250 экзаменационных вопросов, достаточно успешно сдать экзамен, даже не видев ни разу в жизни соответствующий продукт Microsoft.

Безусловно, такое положение дел с «девальвацией статуса» сертифицированного специалиста не устраивало компанию Microsoft и в 2005[5] году активно начала разрабатываться концепция сертификации нового поколения. Развитие концепции шло непростым путем, было много споров и проблем. Однако, выход новых продуктов Microsoft SQL Server 2005, Visual Studio 2005, BizTalk Server 2006, затем hosted-решений на базе Windows Server 2003 и Exchange 2003/2007[6] активно двигал дело по преобразованию сертификации. Наконец выход флагманских продуктов Windows Vista, и Windows Server 2008 поставил окончательную точку в спорах о концепции новой сертификации и твердо закрепил новую модель – Сертификацию Нового Поколения (Certification New Generation).

Надо отметить, что в процессе эволюции сертификации и экзаменов в попытках борьбы с «бумажными специалистами» делались различные нововведения. Например, создавались адаптивные тесты, в 2005[7] году появилась первая технология симуляции действий специалистов с реальным продуктом (Performance Based Test) и наконец, в конце 2008 года был опробованы экзамены 83-640 и 83-760 с технологией тестирования на базе виртуальных машин, то есть экзамен в режиме эмуляции, а не симуляции. Фактически это мини лабораторная работа с реальной виртуальной машиной по заданию экзамена, но ничем не ограниченная с точки зрения пути достижения цели[8].

В итоге, в прошедшем 2008 году весь процесс сертификации Microsoft был полностью и окончательно пересмотрен, а на свет появилась та структура и идеология Сертификации Нового Поколения (Certification New Generation)[9], которую мы сейчас и имеем. При этом сменились не только экзамены и названия сертификаций, но и поменялся цвет сертификации. Теперь у всех логотипов сертификации нового поколения вместо прежнего голубого цвета будет приятный зеленый цвет. Сертификация нового поколения официально и полностью заменит все старые программы сертификации начиная 31 марта 2009 года.

image

Ключевыми нововведениями в Сертификации Нового Поколения являются:

1)      более четкая ориентация специалистов на конкретные продукты и технологии (специализация);

2)      более четкая специализация и привязка сертификации по выполняемым в организации функциями и служебным задачам;

3)      еще более глубокая фокусировка вопросов экзаменов на конкретные практические знания текущей версии продукта или технологии;

4)      более глубокую иерархичность сертификации, теперь сертификация предусматривает три базовых уровня (MCDST, MCTS, MCITP) и два высших уровня (MCM, MCA);

5)      постепенный переход от простых тестов к Preformance Based экзаменам, наиболее продвинутыми среди которых являются экзамены серии 83-XXX с использованием виртуальных машин.

Первые шаги сертификации Microsoft Certified Architect.

Но вернемся к программе Microsoft Certified Architect (MCA). Как вы уже поняли, сертификация эта была публично объявлена 2005 году, хотя в бета версии она существовала аж с конца 2003 года. Кроме того, в конце 2005 начале 2006[10] года в недрах Microsoft стартовала программа Exchange Ranger, начавшись с Microsoft Exchange 2003 и несколько позже влившаяся в программу MCA. Изначально эти программы имели не много общего и каждая преследовали свои цели.

Программа сертификации Microsoft Certified Architect (MCA) должна была стать вендор-независимой индустриальной сертификацией, где архитекторы сертифицировали бы архитекторов на основе проведения специальной квалификационной комиссии – Review Board, члены которой в итоге принимали бы решение по ряду формальных критериев о том, присуждать ли сертификацию MCA или не присуждать тому или иному кандидату. Уже в тот момент была введена существенная плата за право участия в этой программе (в настоящий момент она составляет $5 000 + Application Fee в размере $125), так же довольно быстро произошло деление на две специализации MCA: Solutions и MCA: Infrastructure. Эта сертификация была первым ответом рынку профессиональных специалистов, который на тот момент уже четко сформировал мнение о дискредитации сертификации MCSE, как высшей сертификации Microsoft.

Первая специализация MCA: Solutions подразумевала сертификацию архитекторов-разработчиков ПО в основном с применением технологий .NET Framework и других сопутствующих .NET платформе решений для разработки Microsoft. Но при этом, совершенно не исключала знаний и умений по интеграции этих решений с третесторонним ПО и технологиями других вендоров.

Вторая специализация MCA: Infrastructure была больше ориентирована не на разработку решений, а на создание ИТ-инфраструктуры с применением технологий Microsoft и технологий других вендоров.

Обе эти сертификации (MCA:Solutions и MCA:Infrastructure) подразумевали у кандидатов наличие статуса MCSE или MCSD и достаточно большого, подтвержденного резюме опыта работы в ИТ и в частности в роли архитектора (эти факты проверяются в процессе подачи заявки и документов на участие в программе). Других предварительных требования эти программы не имели, и не имеют и по сей день.

К моменту проведения квалификационной комиссии (MCA Review Board) кандидаты должны подготовить не только свое резюме, но и описание уровня семи своих компетенций, которыми, по мнению Microsoft, должен обладать настоящий Архитектор[11]. В список этих компетенций входят: Лидерство, Стратегическое мышление, Коммуникационные навыки, Тактическое и процессное управление проектом, Широта технических знаний, Глубина технических знаний, Понимание и умение влиять на организационные особенности. Подробное описание компетенций и суб-компетенций можно найти на сайте программы MCA. Кроме того, кандидат готовит презентацию (на основе шаблона), в которой на примере одного из своих выполненных проектов демонстрирует указанные выше 7 компетенций для квалификационной комиссии, состоящей обычно из 4-6 человек.

Проведение квалификационной комиссии (MCA Review Board) подразумевает собой 2-х часовое собеседование. Первые 30 минут кандидат тратит на презентацию, в рамках которой он представляет свои семь компетенций для членов комиссии на примере одного из выполненных им ранее проектов. Далее, после небольшого перерыва, идет 40 минутная сессия вопросов и ответов по теме презентации и по компетенциям кандидата. После сессии вопросов и ответов устраивается небольшой перерыв, а затем проводиться 40 минутная ролевая игра, где кандидат выступает архитектором, а члены квалификационной комиссии выступают в роли различных представителей Заказчика: начиная с CIO и кончая пользователями, рядовыми администраторами и проджект-менеджерами. К окончанию ролевой игры кандидату необходимо прийти к пониманию ситуации и проблем Заказчика и предложить концепцию решения описав на базовом уровне проектный подход, который позволит успешно решить задачу.

В таком виде процесс сертификации MCA сохранился и до настоящего момента. Может создаться впечатление, что процесс сертификации субъективен, однако для решения этого вопроса Microsoft приложила ряд существенных усилий. Во-первых, MCA Review Board состоит не только из сотрудников Microsoft. В комиссии постоянно участвуют независимые представители мирового сообщества Архитекторов. Во-вторых, все новые члены комиссии проходят обязательный тренинг по проведению MCA Review Board, где их учат правильно задавать вопросы кандидату, выделять и классифицировать в его ответах необходимые семь компетенций и их суб-компетенции. Наконец, в-третьих, в процессе есть два независимых модератора (секретаря) ведущих запись всего, что происходит в комнате, следящих за временем, членами комиссии и кандидатом. Результат прохождения кандидатом квалификационной комиссии определяется путем голосования членов комиссии.

Откуда же произошла сертификация Microsoft Certified Master?

Итак, как я упоминал ранее, в 2006 году была создана внутренняя программа Exchange Ranger, которая была призвана создать этаких мега-гуру в области нашего флагманского продукта – Microsoft Exchange. Эта программа должна была подготовить сообщество ключевых специалистов-экспертов по этому продукту к переходу на Exchange 2007. Одним из вдохновителей программы[12] был Terry Myerson – вицепрезидент MS по Exchange. Программу решили делать по образу и подобию MCA, но включить в ее состав обязательное обучение (это позволило бы подготовить аудиторию к новым версиям продукта). В это обучение должны были входить не только лекционные занятия, но и много практических лабораторных работ, причем не в режиме пошагового исполнения (как на обычных официальных курсах MOC), а в более «творческом» стиле. Кроме того, обучением рейнджеров занимались продакт-менеджеры различных подсистем Exchnage и инженеры самых высоких уровней поддержки продукта (имеющие доступ к исходным кодам). Выпускники этой программы должны были не только превосходно знать продукт с технологической точки зрения, но и уметь грамотно доносить его преимущества Заказчикам на разных уровнях компетенции (от менеджеров высшего звена до администраторов). Для этого в программу сдачи экзаменов были включены: обычные тесты (только вопросы в них были существенно сложнее), квалификационная лабораторная работа и завершающая сертификацию квалификационная комиссия (Ranger Review Board), аналогичная двум предыдущим программам MCA. Правда, упор в рамках этой Ranger Review Board был исключительно на Exchange и его архитектуру. Довольно быстро решили квалифицировать эту программу как Microsoft Certified Architect: Messaging[13]. Весь процесс обучения и сдачи экзаменов длился 4-е недели.

По прошествии короткого времени стали понятны основные достоинства и недостатки этой программы. Несомненным плюсом программы было, конечно же, очное обучение, но организовать и провести обучение на таком уровне можно было только в Редмонде. Представьте себе, что значит для корпорации вывезти продакт-менеджеров работающих над флагманским продуктом куда-нибудь в Европу на пару недель. Это фактически сорвать разработку продукта на это время. Поэтому обучение решили проводить прямо в Редмонде в кампусе компании Microsoft, чтобы преподаватели могли за 10 минут добраться от своего места работы до лекционного класса. Кроме того, в программе было занято, как вы уже поняли, много разных преподавателей, каждый из которых был наиболее компетентен в своей области. Получалось так, что за каждым преподавателем закреплялось от половины до двух дней лекционных и практических занятий – не больше. Таким образом, общее количество преподавателей на время обучения составляло около 10. Естественно могли случаться форс-мажорные обстоятельства, а найти замену преподавателям в Редмонде среди их коллег было проще.

Со стороны же кандидатов это было непростым испытанием, т.к. полностью оторваться от работы на четыре недели было очень непросто, да тем более и при условии, что нет 100% вероятности успешно сдать финальные экзамены. Все обучение разбили на ротации – классы из 17-25 человек, которые одновременно учились по полному курсу программы. Ротации организовывались примерно раз в квартал. На первых порах учениками бета-тестерами программы в основном были сотрудники Microsoft и в основном сотрудники подразделений Консалтинга и Премьер поддержки (специалисты работающие напрямую с Заказчиками). Постепенно в программу приглашались лучшие представители компаний-партнеров Microsoft и MVP. В итоге, отзывы кандидатов, их непосредственных руководителей и клиентов превзошли ожидания и стало понятно, что не смотря на все трудности организации программы MCA:Messaging, вызванные необходимостью очного обучения, она приносит отличный результат. Специалисты прошедшие программу Exchange Rangers не только повышают успешность проектов по внедрению Exchange в которых они участвуют, но так же повышают отдачу от продукта для тех Заказчиков с которыми они работают, а так же дают очень конструктивные отзывы на продукт продуктовой группе. Множество изменений в Exchange 2007 и первом сервис-паке к этому продукту было произведено именно под влиянием Exchange Ranger-ов.

Тогда, по прошествии примерно года с момента старта программы Exchange Ranger, в начале 2007 года и был дан зеленый свет на создание по образу и подобию других программ рейнджеров по другим продуктам Microsoft. Следующей программой после Exchange Ranger стала программа SQL Ranger. А в конце 2007, начале 2008 года в этом списке появилась программа Windows Directory Ranger. Эти три программы и легли в основу будущей Master-серии сертификации Microsoft (Microsoft Certified Master). Как это произошло, читайте далее… 

Простое улучшение программы Ranger-ов привело к появлению MCM и нового типа MCA…

Разработка программы Directory Ranger велась уже в ситуации, когда был накоплен приличный опыт проведения ротаций по Exchange и какого-то количества ротаций по SQL. К этому моменту назрело желание корпорации решить проблему длительного очного обучения. В начале было принято, как тогда казалось, довольно элегантное решение – разделить все курсы Ranger программ на 2-а этапа. Выделить из них общую составляющую и сделать ее первой частью обучения, а все специфические для остальных программ сведения оставить в отдельных независимых блоках, приступить к изучению которых можно было бы только после обучения и успешной сдачи экзаменов базового блока. Таким образом, и возникла программа Advanced Infrastructure Masters. Она просуществовала всего две ротации, а ваш покорный слуга принял участие в первой из них (т.н. Alpha версии). Основными темами, которые преподавались в рамках этой программы, были: внутреннее устройство Windows, PKI на Windows Server 2008, «основы» Active Directory на Windows Server 2008, сетевое взаимодействие и его анализ с использованием сетевых сканеров для систем на базе новых версий Windows, IPSec, IPv6, новые технологии безопасности Windows Vista и Windows Server 2008, написание скриптов и сценариев на VBScript, cmd и PowerShell, Failover Clustering и система ввода/вывода Windows, основы MSF/MOF, виртуализация Hyper-V и, наконец, Network Access Protection.

Уже после двух ротаций стало очевидно, что такой подход сильно усложняет работодателям и кандидатам процесс обучения, появляется больше точек нестабильности, а стоимость всей суммарной программы возрастает. Наконец, самым важным фактором является то, что на подходе были и другие программы Ranger-ов, и все они в разной степени нуждались в знаниях базовых технологий инфраструктуры для их кандидатов. В итоге программу Advanced Infrastructure Masters (как ее в шутку назвали участники первой ротации Infrastructure Ninjas) решили заморозить до поры до времени и, возможно, в будущем выпустить отдельную Master-сертификацию на ее основе.

Но вопрос длительности очного обучения так и остался основным камнем преткновения. Формально к участию в Review Board допускались лишь те кандидаты, кто успешно сдал квалификационную лабораторную работу и все письменные экзамены, проводимые в ходе обучения еженедельно. Проверка результатов квалификационной лабораторной работы так же занимала определенное время. Самый очевидный и неприятный момент был в том, что прежде чем принять участие в Review Board, нужно было подготовиться: сделать презентацию, потренироваться и т.п. на это уходило минимум 3-4 дня. И все это время кандидат должен был оставаться в Редмонде. После анализа всех особенности программы и отзывов кандидатов корпорацией было принято решение разделить очное обучение и сдачу квалификационных экзаменов от проведения Review Board. Именно в этом момент и произошло окончательное отделение Master-серии сертификации от сертификации Architect-серии. В настоящий момент действуют 5 направлений (компетенций) сертификации Microsoft Certified Master – MCM: Microsoft Exchange 2007, MCM: Microsoft SQL Server 2008, , MCM: Windows Server 2008 Directory, MCM: Microsoft Office SharePoint 2007, MCM: Microsoft Office Communications Server 2007.

MCM + Review Board = MCA:Techology

Итак, в конце 2008 года, по прошествии более чем двух лет с момента основания программы Ranger-ов, она превратилась в две сертификационные серии. Первая серия – это Master-серия сертификации, которая является наивысшей технической сертификацией Microsoft. Вторая серия – Architect-серия, куда вошли прежние две сертификации MCA: Solutions и MCA: Infrastructure, а так же новое направление MCA: Technology. Таким образом, новая сертификация MCA: Technology это сертификация кандидата по одной из программ Microsoft Certified Master и его последующее успешное прохождение MCA Review Board по той технологии(продукту) который был выбран для сертификации Master-серии.

Что же сейчас представляют собой новые сертификации MCA:Technology и MCM? Итак, начнем с Microsoft Certified Master. Сейчас сертификация MCM имеет пять специализаций (компетенций). Ранее я уже упоминал о них. Для того, что бы начать свой путь сертификации по Master-программе вы должны иметь актуальный статус MCSE и один или несколько сданных экзаменов соответствующих вашей специализации, далее заполнить application-форму и приложить к ней свое резюме. Далее оплатить сбор в размере $125, после чего ваше резюме будет рассмотрено и проверено. Каждая специализация подразумевает свою собственную программу обучения и набор предварительно сданных сертификационных экзаменов Microsoft. Программа очного обучения рассчитана на 3и недели. Стоимость прохождения обучения составляет $18 500 (не включая стоимость проживания в Редмонде). В ходе обучения каждому кандидату предоставляется выделенный сервер с Microsoft Hyper-V для работы с собственной виртуальной средой и выполнения ежедневных лабораторных работ и ноутбук в качестве средства доступа к серверу по протоколу RDP и рабочей станции. По завершении каждой из 3-х недель обучения проводиться письменный экзамен по материалу прошедшей недели. Вы должны успешно сдать все три письменных экзамена для того, что бы быть допущенными к финальной квалификационной лабораторной работе. Финальная квалификационная работа длиться в зависимости от специализации Master-программы различное время – от 4-х до 10 часов. При выполнении квалификационной лабораторной работы вы получаете новый чистый выделенный физический сервер с Hyper-V на котором настроена стартовая лабораторная среда из виртуальных машин. Так же вы получаете запечатанный в конверт набор документов, среди которых: описание лабораторной среды и список заданий (deliverables), которые вам необходимо реализовать для завершения лабораторной работы. Лабораторная работа представляет собой виртуальную среду с множеством виртуальных машин, на которых развернута и настроена система соответствующая вашей специализации (организация Exchange, среда MS SQL серверов, служба каталогов Active Directory, ферма SharePoint или организация OCS). В ходе выполнения лабораторной работы вы обязаны фиксировать все изменения, которые вносите в конфигурацию виртуальных машин, в специальный файл – change log. Основанием для оценки вашей лабораторной работы будет не только реально выполненная настройка или исправленная проблема, но и соответствующая запись об этом в change log-е. Результаты лабораторной работы вы узнаете не сразу, обычно по истечении 2-3х недель. Если вы успешно сдал три письменных экзамена и выполнили квалификационную лабораторную работу на проходной балл, то вы становитесь Microsoft Certified Master. Так вы оказываетесь в одном шаге от наивысшей сертификации Microsoft – Microsoft Certified Architect Technology Series. Этот последний шаг – это участие в Review Board…
 


[1] http://www.microsoft.com/presspass/press/1999/Sept99/W2Kpr.mspx
2月1日

ISA 2004, 2006 Registry keys - Tips and Tricks

Я решил собрать в этом посте все известные мне ключи реестра для настройки ISA 2004/2006, которые могут оказаться весьма полезными при конфигурировании ISA и решении различных проблем с ней. А так же некоторые рекомендации по взаимодействию с другими firewall-ами, установленными между ISA и сетью Интернет.

Рассмотрим наиболее типичную конфигурацию подключения к сети Интернет, которую я привел ниже на рисунке:

image

Итак, в такой ситуации следует сразу же сконфигурировать ISA 2004/2006 используя шаблон Back Firewall. Не стоит этим принебрегать. Второе, что я советую сделать - это изменить Network Rule между сетями External и Internal с NAT на Routing. Связано это с тем, что трансляция сетевых адресов (NAT) на ISA имеет определенные ограничения, которые отсутствуют у некоторых других firewall-ов. Например Cisco PIX или Juniper. Сразу замечу, что использование ISA как back firewall имеет свои преимущества, т.к. ISA 2004/2006 обеспечивает гораздо более эффективные средства публикации внутренних сервисов (таких как Exchange, OCS, SharePoint и т.п.), а также средства Windows Integrated Authentication для Web-Proxy Client и Firewall Client, позволяющие настраивать правила фильтрации для конкретных пользователей AD.

Тепрь я постараюсь описать известные мне ключи реестра для настройки ISA 2004/2006, настройка которых выолняется только с использованием редактора реестра regedit и недоступна через GUI интерфейс или конфигурацию XML.

таблица с важными ключами реестра для ISA 2004/2006.

 

Ключ Описание/ссылка

NonPassiveFTPTransfer

Нельзя установить через COM интерфейс управления ISA.
Форсирует использование для ISA Web-Clients пассивного режима FTP вместо используемого по умолчанию активного. Эта опция очень полезна в случае, когда front firewall не пропускает активные FTP соединения. (FTP error 500: Illegal port command). Для Cisco PIX например можно разрешить активные FTP соединения командой "fuxup protocol ftp 21".

Подробное описание дано в статье "Troubleshooting Outbound FTP Access in ISA Server".

SkipAuthenticationForRoutingInformation

Позволяет при включенной опции Always Authenticate выполнять анонимные запросы к конфигурации WPAD. Описано в статье MSDN и статье KB885683. Обратите внимание, что для Enterprise Edition версии ISA 2004/2006 требуется настраивать данный параметр скриптом через COM интерфейс. Это описано в статье "Troubleshooting Firewall Clients in ISA Server".

ProxyVmemAlloc1pSize

Влияет на количество одновременных SSL-сессий. Описано в статье KB842438.

ProxyVmemAlloc3pSize

Влияет на количество доступных одновременно запросов на проксирование. Описано в статье KB842438.

AllowAskBasicAuthOverNonSecureConnection

Управляет обязательным требованием использовать или нет SSL при доступе с автроризацией к веб-сайтам.
Описано в статье KB912122.

А вообще все подробности по администрированию и настройке ISA 2004/2006 в том числе и не доступные из GUI описаны в ISA Server 2004/2006 SDK по ссылке: http://msdn2.microsoft.com/en-us/library/ms828058.aspx

Эта ссылка на условия поиска, с помощью которого можно посмотреть все параметры и настройки ISA 2004/2006, которые нельзя установить из GUI интерфейса.

10月25日

Очередной обзор свежих Downloads от Microsoft.

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

Итак начнем по-порядку:

Вышел MUI (Multilingual User Interface) для Internet Explorer 7.0. Доступны версии для Windows XP SP2, Windows Server 2003 SP1/SP2, для Windows Server 2003 IA64 SP1/SP2, Windows Server 2003 x64. Дополнительную информацию по MUI/LIP, а так же продуктам Microsoft, для которых выпускаются отдельные локализационные пакеты можно посмотреть здесь.

Вышла обновленная версия клиента SMS 2003 SP3 исправляющий ряд досадных ошибок в работе SMS-клиента. Обновление доступно как в формате MSI, так и MSP.

Вышла CTP-версия (Community Technology Preview) драйвера для работы PHP 5 c Microsoft SQL Server 2005. Поскольку я весьма симпатизирую PHP как языку разработки динамического Web-контента эта новость не может не радовать. Сам правда пока не пользовался этим интерфейсом.

Наконец-то вышел Exchange 2007 Management Pack для System Center Operations Manager 2007. Уж очень долго пришлось ждать. Жаль в нем нет пока диаграмм. Кроме того, пока не очень хорошо с документацией по тонкой настройке этого MP. Я поставил его в Production на следующий день после его выхода - 2е недели, полет нормальный. Только имейте ввиду, что этот MP добаляет много правил мониторинга и что бы у вас не кончилось место в оперативной безе данных мониторинга следует увеличить ее размер на SQL-сервере.

Вышли Virtual Machine Additions for Linux для Virtual Server 2005 R2 SP1. Они обеспечивают следующий функционал: синхронизация времени guest и host машин, драйверы клавиатуры, дисплея и SCSI контроллера. Доступны версии для x32 и x64. Список поддерживаемых guest-операционных систем: Red Hat Enterprise Linux 2.1 (update 7); Red Hat Enterprise Linux 3.0 (update 8); Red Hat Enterprise Linux 4.0 (update 4); Red Hat Enterprise Linux 5.0; SuSE Linux Enterprise Server 9.0; SuSE Linux Enterprise Server 10.0; Red Hat Linux 9.0; SuSE Linux 9.3; SuSE Linux 10.0; SuSE Linux 10.1; SuSE Linux 10.2. Рекомендую ставить их только при подключении виртуальных дисков через виртуальный SCSI адаптер, правда для этого потребуется самая свежая версия Virtual Server 2005 R2 SP1, а на предыдущих версиях сервера эти VM Additions корректно работать не будут.

Microsoft обнародовала предварительную спецификацию на Hypervisor Viridian - главный слой micro-kernalized виртуализации в Windows Server 2008. В основном это документ важен для партнеров, но это означает, что под платформу Windows Virtualization (Viridian) будут активно разрабатываться сторонние решения. Учитывая ее перспективность хочется надеяться что в ближайшем будущем мы увидим целую серию разработок сторонних компаний в этой области. Замечу так же, что Windows Virtualization поддерживается Windows Server 2008 CORE.

Недавно в разное время вышел комплект обновленной MBSA 2.1 beta2 (Microsoft base Line Security Analyzer). Доступны версии под x32 и под x64, а так же MBSA Visio 2007 Connector. Этот комплект утилит позволит довольно просто и удобно просканировать компьютерную сеть на базе ОС Windows на предмет основных известных уязвимостей, даст рекомендации по их устранению, а так же позволит создать наглядный отчет о результатах работы в Visio.

Обновилась версия Virtual Earth 3D Beta . Забавная вещица, правда по России еще векторные карты весьма посредственные. Но прогресс идет давольно быстро.

10月9日

Технология TCP/IP Dead Gateway Detection - причина "странной" маршрутизации.

Раз уж мы начали обсуждать стек TCP/IP и его реализацию в Microsoft Windows Server 2003, то я хотел бы этот ряд продолжить описанием еще одной очень полезной технологии TCP/IP Dead Gateway Detection. Это технология довольно старая, описанная в RFC 816, и поддерживается Microsoft начиная еще с версии Windows 95. Однако, как показывает практика мало кто понимает как она работает и соответственно мало кто умеет ее корректно применять на практике.

Суть алгоритма очень проста. Известно, что после передачи по протоколу TCP определенной порции данных (или истечения определенного таймаута) хост-получатель отправляет хосту-отправителю подтверждение (ACK) о получении этой порции данных. Хост отправитель ожидает переодического получения таких подтверждений, прежде чем отправить следующую порцию данных. В случае если такое подтверждение не получено, хост-тправитель попопытается отправить эту порцию данных еще раз. И так хост-отправитель будет делать несколько раз, после чего сочтет TCP-соединение разоравнным и закроет соответствующий сокет. Число попыток такой передачи задается в реестре Windows в параметре TcpMaxDataRetransmissions. По умолчанию это значение принимается равным 5-и. Все описанное ранее верно, если настроен всего один шлюз по умолчанию. В том случае если в таблице маршрутизации указано несколько шлюзов по умолчанию (Default Gateways), то передача даных будет работать несколько иначе.

Если при передаче данных нет подтверждения (ACK) от хоста-получателя, то как и раньше выполняется попытка повторной передачи данных. Однако, если по истечении более половины попыток (в нашем случае это 3-и попытки) передача все же оказалась неудачной, то в КЕШ-записи (Route Cached Entry - RCE) маршрута к этому хосту-получателю изменятется адрес шлюза на следующий по списку адрес шлюза по умолчанию и процедура повторяется заново. Если все перечисленные в таблице маршрутизации шюзы по умолчанию опробованы и подтверждения от хоста-получателя все же нет, то TCP-соединение разрывается.

Если более 25% от всех TCP соединений в записях RCE уже использут следующий шлюз по умолчанию, то все остальные TCP-соединений тоже переводятся на новый шлюз по умолчанию, а так же делается отметка в таблице маршрутизации, что основным шлюзом по умолчанию теперь является новый хост.

Следует заметить, что работа данного алгоритма возможна ТОЛЬКО при следующих условиях:

  1. В настройках TCP/IP указано более одного шлюза по умолчанию.
  2. Через неработающий шлюз по умолчанию уже установлены TCP соединения или устанавливаются TCP-соединения с внешними хостами.
  3. Через альтернативные шлюзы по умолчанию возможна маршрутизация до хоста-назначения.

Очевидно, что переключение с одного шлюза по умолчанию на другой не возможно без TCP соединений. Например выполнение команды PING не приведет к переключению шлюзов, т.к. PING использует ICMP протокол.

В Windows Server 2003 и в Windows XP данный алгоритм по умолчанию включен. Есть два параметра реестра в разделе HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 

DWORD DeadGWDetectDefault

DWORD Interfaces\{int-guid}\EnableDeadGWDetect

отвечающие за работу этого алгоритма. Первый из них (DeadGWDetectDefault) позволяет включить или выключить алгоритм на всех интерфейсах сразу, а второй (EnableDeadGWDetect), позволяет контролировать работу алгоритма на уровне каждого интерфейса по отдельности.

Для того, что бы узнать о многих других особенностях работы стека TCP/IP и его скрытых настройках скачайте документ Microsoft Windows Server 2003 TCP/IP Implementation Details.

Что в SID-е тебе моем?!

Тема SID-а разжёвана в сети уже многократно, но почему-то к ней приходится возвращаться с удручающей постоянностью, когда выясняется, что многие инженеры и администраторы ОС Microsoft Windows не понимают некоторых весьма важных вещей в отношении использования SID-ов и то как он применяется в системе Windows.

SID (Security IDentifier) состоит из нескольких частей (он может быть переменной длины). В начале идет "версия" SID-а, потом Генеральная область Authority - т.е. ссылка на ту систему-источник, которая отвечает за его выпуск. Версия сейчас в системах Windows всегда одна: 1, чаще всего Генеральная Authority 5 (Windows System) или 1 или 3. Однако с выходом Microsoft Exchange 2007 появилась новая Генеральная Authority - 9 (Exchange 2007). Потом в SID-е следуют один или несколько идентификаторов Sub Authority. И, в завершении, в конце может идти так называемый RID - Relative IDentificator - т.е. локальный для данного Sub Authority номер субъекта безопасности (например, учетной записи пользователя).

Таким образом, SID учетной записи обычно выглядит так: S-1-5-21-1721254763-462695806-1538882281-2605462.

В данном примере номер версии показан красным цветом, идентификатор Генеральной Области Authority показан желтым цветом, идентификаторы Sub Authority показаны зеленым цветом, а RID показан коричневым цветом.

Это примерно как структура ИНН - сначала код региона, потом код налогового органа выдавшего ИНН, а уже потом относительный номер налогоплательщика в данном налоговом органе.

Дополнительную информацию о SID-ах можно почерпнуть тут
http://msdn2.microsoft.com/en-us/library/aa379597.aspx и соседние по содержанию темы. Следует так же отметить, что существует целая серия так называемых Well Known SID-ов (хорошо известных SID-ов). К таким SID-ам относятся SID-ы групп: Everyone, Authenticated Users, SELF, BUILTIN\Administrators, BUILTIN\Guests и другие. Достаточно полный список можно посмотреть тут: http://support.microsoft.com/kb/243330.

Так вот, в отношении SID-компьютера стоит помнить два основных факта:

1.     Компьютерный SID - это внутренний SID системы Windows, который представляет собой идентификатор Sub Autority для ВСЕХ локальных на данном компьютере субъектов безопасности. Он создается при инсталляции операционной системы Windows. На его основе путем добавления RID генерируются ВСЕ SID-ы локальных пользователей и групп для данного компьютера с ОС Windows. Если он поменяется - ВСЕ локальные субъекты безопасности (пользователи и группы) потеряют пава доступа, поскольку в ACL права даются именно по SID-ам. И этот SID никакого отношения к членству в домене не имеет.

2.     Домен тоже имеет свой Domain SID, который представляет собой область Sub Autority ВСЕГО домена. Когда вы включаете станцию/сервер или даже контроллер домена в базе данных домена (AD NTDS) создается объект типа компьютер. Этот объект выведен из класса Security Principal (субъект безопасности), так же как и класс User или Group. Это значит, что такой объект может быть участником системы безопасности Windows и получать права доступа на другие объекты и ресурсы. Именно поэтому у класса Computer (впрочем, как и у класса User) есть атрибут objectSID. Собственно этот атрибут обязательный для всех Security Principals в домене и без него они не могут существовать. Для генерации SID-ов компьютеров, пользователей и групп берется доменный SID (Domain SID) и к нему пристыковывается первый свободный RID в домене. За выделение всем Security Principals в домене уникальных SID-ов отвечает контроллер, несущий роль FSMO RID Master.

Итак, когда рабочая станция логинется в домен в ее собственном системном Access Token-е будут храниться ДВА SIDа - один SID ее доменной учетной записи компьютера, а другой локальный ее собственный SID. Билет Kerberos TGT, который при логоне получает рабочая станция, будет при этом содержать ТОЛЬКО ее Доменный SID.

Когда вы переносите станцию из домена в домен вы в принципе не можете скопировать SID из старого домена в атрибут objectSID в новом домене - это будет противоречить всей идеологии безопасности. Поэтому для объекта учетной записи компьютера в новом домене будет сгенерирован новый SID, который будет состоять из Domain SID нового домена и какого-то доступного в настоящий момент в новом домене RID-а.

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

В AD есть специальный атрибут sIDHistory - в который администратор домена при миграции может поместить старые SID-ы субъектов безопасности для того, что бы сохранить их доступ к тем ресурсам, где такой доступ им был назначен по их старому SID-у. При входе в систему пользователя у которого заполнен атрибут sIDHistory все SID-ы из этого атрибута так же попадают в Access Token этого пользователя. С применением технологии SID History работают утилиты: movetree и ADMT всех версий.

Утилиты NewSID и Sysprep меняют не только SID компьютера, но и соответственно SID-ы всех локальных компьютерных учетных записей и групп, а также проходят по всем ACL на всех доступных им объектах безопасности для того, что бы обновить информацию о выданных правах с учетом смены SIDов всех локальных учетных записей и групп. Именно поэтому версия sysprep обновляется с выходом каждого Service Pack и на самом деле не подходит от одной версии ОС Windows к другой.

Теперь, когда вы понимаете логику процесса, нужно сказать, что весьма важно, чтобы изменение SID-а компьютера утилитами SysPrep или NewSID происходило как можно ближе к моменту инсталляции системы (пока не сделано много особенных прав доступа, не заведено много пользователей и т.п.). Это связано с тем, что при установке на компьютер какого-то дополнительного ПО могут появиться ресурсы илли другие объекты безопасности, о существовании которых не подозревает ваша версия NewSID или SysPrep. И при смене SIDа ACL на этих объектах безопасности не будут обновлены, как следствие будут нарушены права доступа и работоспособность дополнительного ПО может быть потеряна.

На самом деле при работе в домене ничего страшного в том, что локальные SID-ы компьютеров совпадают, вроде бы нет, однако есть ряд особенностей работы системы аутентификации Windows, при которых даже в доменной среде можно будет получить доступ от одной такой клонированной машины к другой в обход настроенных прав доступа.

Именно поэтому надо при клонировании дисков SID компьютеров МЕНЯТЬ ВСЕГДА. Политика Microsoft в отношении установки систем путем дуплицирования диска.

Что же касается доступа по SID-у компьютера - предоставить доступ по учетной записи компьютера (ее SID-у) можно только в доменной среде на основании аккаунта компьютера в AD и соответственно SID-а из AD, где как я говорил он гарантированно уникальный (при условии что у вас не падал и не восстанавливался из BackUp-а некорректным способом RID Master вместе с AD).

Дырочка в безопасности при совпадении SID-ов компьютеров может быть в доступе предоставленном локальным пользователям на разных компьютерах. Вот об этой "дырочке" и пишет Марк Русинович в своей статье.

10月8日

Path MTU Discovery или еще одна причина проблем с сетевым взаимодействием.

Раз уж я поднял проблему сетевого взаимодействия, то приведу еще один пример из моей практики, а так же поделюсь некоторыми рекомендациями связанными с особенностью работы стека TCP/IP в Microsoft Windows Server 2003.

Впервые я столкнулся с этой проблемой, когда стал массово устанавливать Windows Server 2003 Service Pack 1 на серверы. Проблема обычно выражалась в том, что хосты с Win2k3SP1 отделенные от других хостов, маршрутизаторами или сегментами сетей использующими не Ethernet среду передачи начали взаимодействовать друг с другом очень не стабильно. В скором времени выяснилось, что виной тому исправление безопасности MS05-019, которое интегрированно в SP1 как KB893066. К сожалению в коде этого исправления была допущена ошибка в алгоритме Path MTU Discovery (это описано в статье KB898060). Сам алгоритм PMTU Discovery подробно описан в RFC 1191. Кроме того, в RFC 2923 дано описание того, как даже корректная работа этого алгоритма может приводить к проблемам в сетевом взаимодействии.

Для начала два слова, что такое MTU - Maximum Transmission Unit. Как вы поняли из расшифровки аббревиатуры - это максимальная длина пакета IP, которая может быть передана через конкретный тип канала. Для сетей Ethernet MTU равен 1500. Для других протоколов значения MTU можно посмотреть в различных RFC или в статье MS KB140375.

Причиной сбоев алгоритма PMTU Discovery зачастую являются так называемые Black Hole Router-ы (KB159211). Что это такое - все просто, в соответствии с рекомендациями по применению протокола ICMP хостами и роутерами, в случае если при маршрутизации пакета IP он (пакет) не помещается в размер установленного MTU промежуточного участка трассы, пограничный роутер должен его фрагментировать (разбить его на несколько более мелких пакетов IP, отметив в специальном поле их заголовка очередность последующей сборки). Однако в заголовке пакета IP есть специальный флаг - don't fragment (DF). Если этот флаг установлен никто не имеет права фрагментировать этот пакет. Если пакет по таблице маршрутизации надо передать в сеть, у которой MTU меньше размера этого пакета, а сам пакет отмечен флагом DF, то роутер не может выполнить такое задание, и обязан отбросить (удалить) такой "странный" пакет. При этом роутер может послать специальное ICMP оповещение тому хосту, IP-адрес которого указан в поле отпрвителя (Source Address) исходного пакета с флагом DF. Однако, как вы заметили, роутер вовсе не обязан отправлять это ICMP сообщение хосту-отправителю. В таком случае хост-отправитель не будет знать, о том, что его пакет пропал и не был доставлен до адресата.

Может показаться, что это безвыходная ситуация, однако если вспомнить, что при установлении TCP/IP соединения хосты обмениваются очень короткими пакетами SYN->, SYNACK<-, ACK-> длина которых настолько мала, что практически всегда меньше MTU большинства типов каналов связи, то проблема MTU проявиться уже при передаче данных в рамках открытого TCP-соединения и будет выявлена стандартным механизмом TCP. Загвоздка только в том, что данные через такой канал все равно не удастся передать.

Для решения подобных проблем был изобретен алгортм Path MTU Discovery, который если не вдаваться в детали работает очень просто: сначала хост посылает ICMP пакет получателю с максимально возможным MTU для своего сетевого интерфейса (например 1500). Если вместо ответа от хоста-адресата от промежуточного маршрутизатора пришло специальное ICMP сообщение Packet Too Big, то размер посылаемого пакета уменьшается и процедура повторяется, до тех пор, пока пакет не пройдет по всей трассе до конечного получателя.

Так что алгоритм весьма полезный, например он помогает в работе с NLB (WLBS) кластерами, как это описано в статье MS KB229064. Для NLB кластеров важно, что бы TCP пакеты приходили на общий NLB-адрес нефрагментированными, иначе высока вероятность (при стандартных настройках NLB), что разные фрагменты пакета попадут на разные узлы кластера NLB и вообще не будут обработаны.

В этой статье MS KB дано описание того, как можно эффективно настроить стек TCP/IP Windows Server 2003 для ситуации, когда на пути от хоста к хосту меняется MTU трассы и может быть даже меньше 576 байт: http://support.microsoft.com/kb/900926

Дополнительно в этой статье даются некоторые рекомендации по так называемой процедуре Hardening-а (усиления безопасности) для стека TCP/IP в реализации Microsoft Windows Server 2003: http://support.microsoft.com/kb/324270

Наконец в Windows Server 2003 SP2, Windows Vista и Windows Server 2008 работа алгоритма PMTU Discovery была немного изменена. Эти изменения описаны в статье MS KB925280.

Возможные сетевые проблемы после установки Windows Server 2003 SP2

Я за последнее время довольно часто сталкивался или мне сообщали об этом коллеги и знакомые админы, что после инсталляции Service Pack 2 у них появлялись необъяснимые проблемы с сетевыми подключениями. Часто это выражалось в невозможности провести репликацию между контроллерами домена, задержках в работе сетевых подключений, нестабильной работе ISA 2004/2006 при авторизации пользователей и в массивах NLB.

Во многи случаях оказалось, что причиной является включенное в SP2 и активируемое по умолчанию обновление Scalable Networking Pack, описанное в статье KB912222. Более того оказалось, что само по себе обновление зачастую безвредно, проблема появляется в несовместимости функций заложенных в него и сетевых драйверов от поставщиков серверного оборудования. Очень часто обновление драйверов до последних версий решало проблемы, но не всегда. Поэтому привжу официльную рекомендацию статьи KB936594, о том как отключить функции данного обновления.

Для этого надо открыть раздел реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

найти ключи типа DWORD EnableRSS, EnableTCPA и EnableTCPChimney и установить их значение в 0.

Не забудте перезагрузить компьютер...

UPDATE: 31 января 2008 года вышла официальная статья про ошибку в SNP, приводящую к этим результатам. Вот ссылка: On a Windows Server 2003-based computer that has a TCP Chimney Offload network adapter, the TCP data stream may be corrupted when the network adapter indicates an MDL chain whose starting MDL has a nonzero offset.

UPDATE2: 21 июня 2008 года была завершена еще одна важная статья в базе знаний Microsoft касающаяся SNP. Вот ссылка: Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008.

Как починить ошибки в стеке TCP/IP на Windows XP SP2 и Windows Server 2003 SP1

Для начала приведу основные симптомы сбоя в стеке TCP/IP, которые обычно требуют восстановления стека приведенными ниже способами.

Так если вы видите следующие сообщения об ошибках:

Message 1:
An error occurred while renewing interface 'Internet': An operation was attempted on something that is not a socket.

Message 2:
An error occurred while renewing interface Local Area Connection: the requested service provider could not be loaded or initialized.

При запуске Интернет Эксплорер:

The page cannot be displayed

When you use your computer, you may receive the following error message:

Initialization function INITHELPERDLL in IPMONTR.DLL failed to start with error code 10107

Так же вы можете не получать DHCP адрес и не получать адрес APIPA (из диапазона 169.254.x.x или пакеты могут отправляться в сеть, но не приниматься из сети, а при попытке выполненить команду ipconfig /renew вы можете получить следующие сообщения:

Message 1:
An error occurred while renewing interface local area connection: an operation was attempted on something that is not a socket. Unable to contact driver Error code 2.

Message 2:
The operation failed since no adapter is in the state permissible for this operation.

Message 3:
The attempted operation is not supported for the type of object referenced.

В оснастке Device Manager, при выборе опции Show Hidden Devices, устройство TCP/IP Protocol Driver отображается выключенным в разделе Non-Plug and Play drivers, а так же вы получаете ошибку 24.

При попытке создать PPP-соединение вы можете получить ошибку:
Error 720: No PPP Control Protocols Configured.

Итак, если вы столкнулись с подобными ошибками, высока вероятность того, что у вас поврежден стек протоколов TCP/IP или его настройки, следовательно необходимо сбросить его в "чистые" настройки.
 
Для начала есть способ который позволяет мягко сбросить текущее состояние библиотеки WinSock в начальные "чистые" настройки. Делается это командой netsh winsock reset.

Если первый способ не помог, то дальше надо сбросить конфигурацию интерфейсов IP. Делается это командой netsh int ip reset c:\resetlog.txt

Если и это не помогло, полностью переустановить стек TCP/IP можно так:

  1. Удалите раздел реестра командой REG DELETE HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Winsock
  2. Удалите раздел реестра командой REG DELETE HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Winsock2
  3. Перезагрузите компьютер
  4. Откройте папку %winroot%\inf
  5. В ней найтите файл nettcpip.inf, сделайте его резервную копию и после откройте его в текстовом редакторе (например Notepad).
  6. Найдите в нем строки:
    [MS_TCPIP.PrimaryInstall]
    ; TCPIP has properties to display
    Characteristics = 0xA0 ; NCF_HAS_UI | NCF_NOT_USER_REMOVABLE
  7. Исправить их на:
    [MS_TCPIP.PrimaryInstall]
    ; TCPIP has properties to display
    Characteristics = 0x80 ; NCF_HAS_UI
  8. Сохранить изменения в файле nettcpip.inf
  9. Открыть Network Connections и щелкнув правой кнопкой мыши по свойству нужного нам сетевого подключения выбрать Install->Protocol->Add. Далее выбрать "have disk" и указать путь %winroot%\inf
  10. Выбрать TCP/IP из списка. После этого вы опять попадете в окно свойств сетевого подключения, но для TCP/IP теперь кнопка Uninstall будет активна.
  11. Выберите в списке This connection uses the following items протокол TCP/IP и нажмите кнопку Uninstall.
  12. Перезагрузите компьютер
  13. Установить протокол TCP/IP аналогично шагам 9-12.

Статьи KB по данной теме:
http://support.microsoft.com/kb/325356
http://support.microsoft.com/kb/317518
http://support.microsoft.com/kb/299357

10月6日

Несколько новостей с корпоративного сайта

Первая новость: вышел IEAK 7 RTM.
Вторая новость: Get ready - DPM 2007 is coming!!! Уже есть внутренний Release Candidate, соответственно в публичном доступе обновились документы по проектированию, развертыванию и настройке DPM 2007.
Вот ссылки:
 

Кроме того, 1 октября появились новые и обновились некоторые Management Packs под System Center OpsMgr 2007. Вот выборка из MS Downloads.