Привет, коллеги. В этом посте я хотел бы поведать о недавнем событии, произошедшем в жизни Самарского МСР-клуба, а именно встрече 1 октября.

Необычной эта встреча была по двум причинам. Во-первых, встреча клуба проходила утром в субботу, а во-вторых с докладом выступал широкоизвестный и глубокоуважаемый Михаил Черномордиков. Вопреки моим опасениям, пришло довольно много голодных умов, желающих больше узнать о Windows Phone 7 Mango. А узнать можно было многое. На протяжении почти двух часов 15 пришедших участников мучали Мишу вопросами.

За это время можно было узнать об особенностях работы WP7 в России и о головокружительных возможностях заработать на этой платформе. Вне всяких сомнений, если бы Михаил не спешил на #404fest, то его бы так и не выпустили из офиса Майкрософт, т.к. желание узнать о WP7 все никак не иссякало. И даже на 10 минутном кофе-брейке, вопросы все продолжались и продолжались.

Михаилу удалось немного ослабить натиск технических специалистов обещанием ещё раз посетить Самару когда-нибудь.

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

Отдельное спасибо хотелось бы выразить Оксане Костиной-Паничевой за организацию визита Миши на Самарскую встречу. Оксана, спасибо тебе большое от всех IT Pro и Developers Самары =).

Microsoft Operations Framework. Беглый взгляд from Maxim Efremov on Vimeo.

В прошедшее время я очень редко писал в блог. Да, что уж прибедняться – вообще практически не писал. 2011 год с самого начала был для меня очень напряженным. Частично это было связано с большим количеством оффлайн активностей, частично с тем, что я все меньше занимаюсь техническими вещами в целом и Configuration Manager в частности. Но самой большой причиной стал факт плавного и планомерного перехода из технической области в организационную. Как следствие это привело к тому, что писать на глуботехнические темы стало сложно. По основному роду деятельности все чаще приходилось объяснять, не «как» внедрять, а «зачем». Такой переход не мог не отразиться на генерируемом мной контенте, что в свою очередь не ускользнуло от зорких глаз координаторов MVP программы в России и привело к смене технической экспертизы MVP на Management Infrastructure. В текущем году, я обещаю приложить все усилия, чтобы наполнить мой блог интересным и регулярным контентом.

Пользуясь случаем, также хочу поздравить новоиспеченных Самарских MVP Егора Старцева и Илгиза Мамышева. Ура!

С небольшим запозданием решил написать отчет о предпоследней встрече I&D Community в в этом году.

Утро 25 ноября 2010 года для меня началось в 5 часов со звонка Александра Станкевича, известившего о том, что он ждет меня на автовокзале. Александр проделал долгий путь из Ижевска для того, чтобы послушать доклад, который в этот день на собрании сообщества читал Андрей Мишечкин. В последние пару лет, каждый раз, когда речь заходила о скриптах в Windows, у всех в голове появлялся логотип PowerShell, однако Андрей показал, что это не так.

Александр, соблюдая все меры безопасности, осматривает нашу серверную.

Традиционное начало: плюшки и кофе.

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

Спор о том, нужны ли антивирусы в компании.

Андрей торжественно начинает.

Один из завсегдатаев клуба с интересом вникает в доклад.

Ни секунды перерыва в помощи комьюнити.

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

По просьбам коллег, выложил презентацию сюда.

Народ начал потихоньку собираться с 18-00, в этот раз Егор Старцев должен был рассказать о System Center Data Protection Manager 2010, а конкретно о Disaster Recovery!
Первые пришедшие решили перед заседанием размять мозги партией в шахматы. Айтишники склонились над доской в постановочном кадре для телефона.

Затем количество участников стало расти – голодные айтишники приходили с работы и за чашкой чая или кофе с пирожками и плюшками обсуждали последние новости.

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

Новоиспеченный MVP:VM одобрил начало выступления

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

Коллеги погрузились в доклад с вниманием.

Для большей наглядности были задействованы аналоговые инструменты.

Речь заходит о резервном копировании кластеров SQL и Илгиз очень радуется, получив ответ на свой вопрос.

Самая напряженная часть демонстрации – запланированная катастрофа (симуляция падения первичного DPM-сервера).

Некоторые коллеги, заранее зная, что все будет хорошо, все же начали переживать.

По залу прошла волна ностальгии о продуктах для резервного копирования 90-х годов, ленточных магнитофонов и флоппи-дисков.

Все данные в сохранности!

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

Я сердечно благодарю Егора за доклад…

… и вручаю почетную грамоту.

В очередной раз хочу пригласить всех желающих вступить в сообщество разработчиков и IT-профессионалов в Самаре. Присоединяйтесь к нам на https://www.technicalcommunity.com и получайте оповещения о грядущих встречах!

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

Во-вторых, нужно зайти на портал https://www.technicalcommunity.com/ . Портал до Сентября 2010 доступен только на английском языке, но уже в Сентябре будет полная локализация на русский. К слову, портал построен на базе Sharepoint Server и по заверению авторов полностью работоспособен в браузерах IE7 и IE8, полная поддержка FireFox и Chrome будут позже. На главной странице нажимаем кнопку “Sign In” и авторизуемся при помощи имеющийся учетной записи LiveID. После авторизации выбираем в верхнем меню “MY DASHBOARD”. На следующем этапе нужно будет заполнить персональный профиль.

Представленные поля не вызывают никаких вопросов, последний пункт позволяет установить по каким вопросам вас можно беспокоить с портала. На следующей странице заполняем информацию о профессиональной деятельности. На последней странице нажимаем кнопку “Join a Group” и выбираем нужный нам МСР-клуб.

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

Коллега и друг Артем Синицын когда-то рассказывал мне замысловатую фразу, по первым буквам которой можно узнать точный порядок распознавания имен. Однако хотелось изучить весь процесс более детально. Итак: при использовании рабочей станции или сервера под управлением Windows XP/Windows Server 2003 и новее мы имеем два сценария распознавания имен:

1. Пользователь или система использует распознавание имен в Windows Sockets приложениях. Это подавляющее большинство случаев. При этом необходимо указать либо имя, которое будет разрешаться в адрес, либо сразу указать сам адрес.

2. Пользователь или система указывает адрес в NetBIOS приложениях. Это менее распространенный, устаревающий вариант, однако и такое иногда встречается. В этом случае необходимо указать только NetBIOS имя, которое будет разрешаться.

Сам процесс разрешения имени можно разделить на два этапа в основе которые лежат различные методы разрешения имен.

Стандартные методы:

Методы характерные для Windows:

Итак, алгоритм, по которому Windows определяет имена узлов. Если в настройках ОС не указан DNS или WINS серверы, то соответствующий шаг пропускается. Ниже представлен полный алгоритм разрешения имен при сценарии Windows Sockets, который завершается на любом шаге, когда получен IP-адрес. Используются DNS и NetBIOS over TCP/IP.

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

2. Если локальное и запрашиваемое имя различаются, то просматривается содержимое кэша DNS распознавателя (DNS Client Resolver Cache). В котором, как мы знаем все содержимое файла Hosts. На этом шаге нужно обязательно учитывать, что неудачные попытки разрешить имя DNS сервером тоже кэшируются. Просмотреть кэш можно командой ipconfig /displaydns, а сбросить ipconfig /flushdns .

3. Если в кэше не найдено записи Windows отправляет запрос на настроенный DNS сервер. Описание механизма разрешения имен сервером DNS выходит за рамки данного поста.

4. Если запрашиваемое имя “плоское” (например server5), то Windows переводит его в формат NetBIOS и пытается найти соответствие в локальном NetBIOS кэше. Если имя запрашивается в формате FQDN или имеет длину более 16 символов, то методы NetBIOS не применяются.

5. Если имя не найдено в кэше NetBIOS, то оно запрашивается на настроенном сервере WINS.

6. Если на сервер WINS нет соответствующей записи, то Windows посылает не более 3х широковещательных запросов в подсеть, к которой присоединена. Если узел с таким именем есть в этой подсети – он ответит на запрос.

7. Если предыдущий запрос не принес результатов Windows ищет в локальном файле Lmhosts.

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

Для изменения порядка методов распознавания имен необходимо внести изменения в реестр Windows.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ServiceProvider

Вы увидите 4 нужных параметра:

LocalPriority, HostsPriority, DnsPriority, NetbtPriority названия их говорят сами за себя. Меняя их значения можно поменять и порядок методов распознавания имен.

Для более подробно в разделе TCP/IP Fundamentals for Windows

P.S. Отдельным моментов в разрешении имен является использование приложения, у которого настроен proxy-сервер. В этом случае запросы на разрешение имен этого приложения будет обрабатывать proxy-сервер. И это тот момент, когда вы можете получить в ответ на запрос ОС один адрес, а в ответ на запрос браузера другой. За разъяснение этого механизма спасибо уже упомянутому выше Артему Синицыну.