Максим Ефремов. Блог.

О работе…

Maxim Efremov — Tue, 31 Aug 2010 14:20:43 +0000

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

Как стать участником MCP-клуба

Maxim Efremov — Tue, 24 Aug 2010 19:02:54 +0000

Итак, вы узнали о существовании MCP-клубов и эта идея вам понравилась, так как же можно вступить в клуб?

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

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

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

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

Приоритет распознавания имен в протоколе TCP/IP от Microsoft

Maxim Efremov — Tue, 13 Jul 2010 13:47:58 +0000

В очередной раз столкнувшись с распознаванием имен на клиентских машинах, решил, наконец, собрать все данные в этот пост. По специфике нашей работы приходится много работать с крупными заказчиками, служба каталогов которых основана на Active Directory. AD с свою очередь использует для преобразования IP-адресов в человекочитаемые имена систему DNS (Domain Name System) и все бы ничего, но операционные системы семейства Windows используют кроме DNS ещё несколько способов распознавания имен.

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

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

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

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

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

Метод определения	Описание
Local host name/Локальное имя	Сравнивается локальное имя компьютера (аналогично выводу утилиты hostname) с запрашиваемым именем.
Hosts file/ Файл Hosts	Локальный текстовый файл в формате аналогичном формату UNIX /etc/hosts. Этот файл содержит соответствие имен IP-адресам. В ОС Windows, вопреки распространенному заблуждению, этот файл не просматривается системой. Его содержимое полностью помещается в кэш DNS расопознователя (DNS Resolver Cache).
DNS Server	Сервер, который содержит базу данных соответствия имен адресам. Может запросить другой сервер, если нужной записи нет.

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

Метод определения	Описание
DNS Client Resolver Cache/Кэш DNS распознавателя.	Таблица в оперативной памяти, которая содержит записи из файла Hosts и ранее полученные успешные и неуспешные(!) попытки разрешения имен через DNS Server.
NetBIOS Name Cache /Кэш NetBIOS	Имена, полученные путем разрешения методом NetBIOS. Содержит только IPv4 адреса.
NetBIOS name server (NBNS)	Сервер, который разрешает имена согласно RFC 1001 и 1002. Реализация Microsoft носит имя Windows Internet Name Service (WINS). Содержит только IPv4 адреса.
Local Broadcast/ Широковещательный запрос	До 3х широковещательных запросов на определение имени NetBIOS в подсеть, к которой присоединен клиент.
Lmhosts file/Файл Lmhosts	Локальный текстовый файл, который содержит соответствия NetBIOS имен IPv4 адресам.

Итак, алгоритм, по которому 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-сервер. И это тот момент, когда вы можете получить в ответ на запрос ОС один адрес, а в ответ на запрос браузера другой. За разъяснение этого механизма спасибо уже упомянутому выше Артему Синицыну.

Семинар Techdays в Самаре

Maxim Efremov — Tue, 23 Mar 2010 18:26:18 +0000

Наконец-то и мы дождались оффлайн мероприятия TechDays в Самаре! Регистрация открыта, всем велкам.

Ваш покорный слуга читает доклад «Как обеспечить работоспособность унаследованных приложений под Windows 7?»

Статья в журнале PCWeek

Maxim Efremov — Thu, 21 Jan 2010 11:06:54 +0000

Новшества Windows Server 2008 R2
В отличие от Windows 7, которая доступна как в 32-, так и в 64-разрядном исполнении, Windows Server 2008 R2 является …

Открыть материал

Получение динамического адреса на почту

Maxim Efremov — Tue, 08 Dec 2009 11:17:27 +0000

Как-то раз, в блоге у Сергея Полякова я увидел рубрику Coding for fun. Поэтому, ту нехитрую работу, которую я проделал можно охарактеризовать как Administering for fun and profit. Начну сначала: в славном городе Самара широкополосный интернет (для домашнего использования) появился не так давно и сразу начал активно развиваться. На настоящий момент доразвивался он до того, что безлимитный тариф со скорость 5Мбит стал вполне доступным. И все бы хорошо, но провайдер ни при каких условиях не согласен выделять статические интернет IP-адреса пользователям безлимитного тарифа. В силу того, что большую часть жизни я провожу на работе меня это не сильно напрягало, а вот моя вторая половинка, подловив меня на фразой «Кто в доме айтишник?» заставила задуматься о следующей проблеме: ей необходим доступ к домашнему компьютеру через интернет. Ситуацию значительно осложняло то, что домашний компьютер находится за роутером, который в свою очередь выходит в интернет через pppoe соединение. План был придуман сразу, а вот реализация затянулась…
Первым делом пришлось повозиться с роутером. Настоящий айтишник всегда готов к масштабированию своей домашней сети, поэтому роутер является также и DHCP-сервером. Вкратце настройка роутера свелась к нескольких шагам:
1) Настройка DHCP резервации для домашнего компьютера по его MAC-адресу
2) Настройка встроенного firewall’a для проброса необходимых портов.
Хочу отдельно отметить, что после того, как я поделился своими скоромными успехами в работе с встроенным firewall’ом мне пришлось выслушать очень длительную лекцию от Артема Синицына о различии в пробросе портов и публикации служб. Чтобы не приводить ее здесь целиком – резюмирую главное: проброс портов является серьезной потенциальной уязвимостью в вашей домашней машине. Прежде чем решиться на такой шаг – тщательно продумайте все аспекты безопасности.
Далее началась самая интересная для меня часть. При каждом переподключении к провайдеру, мой и без того нестатичный внешний IP-адрес менялся. Задача заключалась в том, чтобы всегда знать, какой IP-адрес в данный момент имеет роутер. Быстренько пробежав по интернет, я не нашел ничего, что бы на 100% подходило как решение моей задачи, поэтому было решено изобрести колесо и проделать некоторую работу по автоматизации оповещения. Хотелось чтобы рабочая станция автоматически узнавала внешний IP адрес и если бы он изменился, то присылала новый адрес на электронную почту или смс-сообщением. Честно сказать, первую часть задачи я уже решал в пору своей грасноглазой юности, для этого была использована кросс-платформенная утилита wget, которая и ныне доступна всем желающим. Источником внешнего адреса послужил ресурс whatismyip.com, который без лишней скромности отвечает на вопрос в собственном названии. Выполнив команду
wget -qO- www.whatismyip.com/automation/n09230945.asp получаем наш внешний адрес в чистом, текстовом виде. Заранее озаботимся о Command-Line SMTP клиенте. Я использую bmail.
Ну, а дальше в ход вступает старая школа, поскольку я так и не выучил PowerShell пришлось в очередной раз обратиться к старым добрым batch-скриптам:
C:\ip\wget -qO- www.whatismyip.com/automation/n09230945.asp > c:\ip\possible.txt SET /P IP= < c:\ip\possible.txt find "%IP%" "c:\ip\current.txt" > nul &if errorlevel 1 goto changed goto end :changed type c:\ip\possible.txt > c:\ip\current.txt c:\ip\bmail -s smtp.email.serv -t to@email.serv -f from@email.serv -h -a "home ip" -m c:\ip\current.txt -c :end
Этот скрипт при первом запуске создаст 2 текстовых файла: possible.txt, который будет содержать адрес, полученный из сети Интернет. И current.txt в котором будет содержаться текущий (или прошлый в зависимости от того сменился ли он) IP-адрес. При каждом последующем запуске, скрипт записывает IP адрес в файл possible.txt и сверяет его с файлом current.txt. Если файлы сходятся (IP-адрес не изменился), то не происходит ничего, а если файлы не сходятся (IP-адрес изменился), то в файл current.txt записывается его обновленное значение и этот файл отправляется на электронную почту. Последним шагом мы добавляем полученный скрипт в планировщик заданий Windows и выставляем запуск каждые N минут/часов/дней. Я проверяю адрес каждый час, но можно это делать как чаще, так и реже.
Хочу заметить, что я создал папку в корне диска C:\ с названием IP. Я это сделал для того, чтобы в скрипте использовать статические пути к командам и файлам, если вы будете использовать другой путь, то не забудьте сменить его в командном файле.

Я на платформе 2010

Maxim Efremov — Thu, 12 Nov 2009 07:27:12 +0000

Коллеги, всем привет. Я участвую в мероприятии Платформа 2010 в качестве эксперта. Если вы хотите со мной пообщаться – ищите меня в зоне «Спроси эксперта»

К нам едет Руслан Карманов

Maxim Efremov — Thu, 22 Oct 2009 06:55:31 +0000

Коллеги, привет. У меня есть отличная новость: к нам в Самарский МСР-клуб приезжает Руслан Карманов. Он прочитает доклад: «Планирование Public Key Infrastructure на предприятии«.
Заседание клуба состоится 30 октября в 19:00. Всех коллег, кто сможет добраться до Самары, приглашаю в офис Microsoft по адресу г. Самара ул. Лесная, 23.
Ссылка на регистрацию должна появится на http://microsoft.com/rus/events буквально на днях.

Это реклама Руслана Карманова и МСР-клубов.

Установка SCCM SP1 на Windows Server 2003 без проблем

Maxim Efremov — Wed, 16 Sep 2009 04:22:25 +0000

B ожидании Service Pack 2 для System Center Configuration Manager 2007, можно в очередной раз развернуть его в тестовой среде (а может и в промышленной). Наверняка все, кто хоть раз сам устанавливал SCCM на Windows Server 2003 замечал нужную и полезную вещь – Prerequisite Checker. Запустив его перед установкой SCCM можно заранее узнать, насколько ваш сервер подходит для установки. Что более приятно, если сервер не соответствует необходимым требованиям – вы получите сообщение об этом. Сообщение будет либо предупреждением, после которого можно продолжить установку, либо ошибкой, которую нельзя игнорировать. И, конечно же, аналогично предупреждениям, есть два типа администраторов: те, кто игнорирует все предупреждения, и те, кто обязан добиться идеальных условий. Для второго типа администраторов и предназначен этот пост.

При установке SCCM SP1 на Windows Server 2003 в Prerequisite Checker’e вы непременно увидите такую картину:

MMC updates for Configuration Manager (Software Updates) .

Сообщение говорит о необходимости заплатки для MMC, если вы используете Software Updates.

Пройдя по ссылке, указанной в комментарии вы попадаете на сайт Microsoft, где можно заказать(!) указанную заплатку на почту. Если вы нажмете на ссылку с выбором версии ОС, то вас ждет следующий сюрприз:

Я долго осмысливал представленное мне явление. На август 2009 года ещё не существовало SP3 для Windows Server 2003, однако заплатка для него доступна очень давно. По некоторым косвенным признаком можно предположить, что SP3 в названии заплатки это ее собственная версия. В любом случае, если вы используете Windows Server 2003 SP2 English – то вам нужен выделенный на картинке апдейт. Поэтому выбираете его, вводите свой e-mail и capcha код. И почти сразу же вам в ящик приходит письмо со ссылкой на заплатку и паролем к ее архиву. Пароль архива на сайте периодически меняется, так что советую сразу скачать и распаковать его.

После установке обновления Prerequsite Checker покажет нам… ту же ошибку.

Если заглянуть в log-файл, c:\configmgrprereq.log, то мы увидим следующее сообщение:

<08-27-2009 08:23:18> Failed to connect to registry for KB940848 with 203.

<08-27-2009 08:23:18> SCCM; MMC updates for Configuration Manager (Software Updates); Warning; This software update addresses several MMC errors that may occur when running the Configuration Manager console. This update should be applied if any of the following occur: Configuration Manager console stops responding when the host computer is low on available memory, context menu errors on console home pages, or inconsistent display after drag-and-drop operations do not succeed. More information about this update is available at: http://go.microsoft.com/fwlink/?LinkId=98349.

Итак, failed to connect to registry, а это значит в диагностику вступает regmon от sysinternals.

Запускаем Regmon и указываем в фильтре setup.exe, затем анализируем наш вывод:

В результате анализа мы видим, что установщик sccm не смог найти информацию о kb940848 в реестре. Открываем regedit и проходим по указанному пути. И действительно в HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ нет ветки, которая называется KB940848, но зато есть ветка, которая называется KB940848-v3. Это и есть нужная нам информация о заплатке. Т.о. заплатка уже установлена, но Prerequisite Checker ищет информацию в другом месте. Если создать пустую ветку HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\KB940848, то при проверке в Regmon’е мы увидим, что не хватает ключа в этой ветке с названием DisplayName, поэтому экспортируем ветку HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ KB940848-v3 (нажимаем правой кнопкой и выбираем Export). Сохраняем в файл на видное место. Открываем полученный файл и редактируем 3ю строку, а именно меняем:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\KB940848-v3]

На

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\KB940848]

Сохраняем и запускаем наш файл, соглашаемся на вопрос о добавлении информации в реестр.

Теперь опять запускаем Prerequisite Checker и …

Проходим все тесты на ура. Именно такая картина и радует меня при установке любого продукта.

На всякий случай выкладываю готовый reg-файл сюда, но не стоит добавлять информацию из него, если у вас не установлена сама заплатка

Что нового в групповых политиках Windows Server 2008 R2

Maxim Efremov — Fri, 28 Aug 2009 13:05:09 +0000

Привет, коллеги.

Если вас, также как и меня, интересует этот вопрос, то можно ознакомиться с моим очередным докладом на techdays.ru. Как обычно – обратная связь цениться очень высоко.