Главная System Center, Без рубрики, Новое Проблемы при синхронизации SUP ConfigMgr 2007 \ 2012 с серверами Windows Update
  • Проблемы при синхронизации SUP ConfigMgr 2007 \ 2012 с серверами Windows Update

    6220_Давно я не брал шашку в руки не писал статьи. Надеюсь что я исправлю это досадное недоразумение. По крайней мере идей для статей у меня очень много и почти все они посвящены грядущему выходу Configuration Manager 2012, ну а сегодня я хотел бы рассказать об одной редкой проблеме с которой я столкнулся несколько раз при подготовке своих виртуальных лаб с SCCM. Собственно сама проблема плавающая и мне не до конца понятны причины ее появления, благо что встречается она очень редко.

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

    И так, мои условия возникновения проблемы звучат так (у вас они могут быть абсолютно другими!):

    • используется ConfigMgr 2007 или ConfigMgr 2012
    • сервер с SUP SCCM имеет два сетевых подключения: одно в во внутреннюю сеть стенда, второе в Интернет (вашу основную сеть)
    • вы используете FQDN server name в свойствах сайта SCCM
    • вы используете прокси-сервер для синхронизации SUP\WSUS

    и при этом у вас не работает синхронизация SUP SCCM с серверами Windows Update в Интернете. Синхронизация  отдельного WSUS на этом же сервере при этом проходит без проблем. Дополнительная сложность состоит в том, что я выступаю в роли обычного пользователя для моих корпоративных серверов, поэтому не могу ничего поправить ни на корпоративном прокси-сервере, ни на сервере DNS.

    В логах вы можете наблюдать следующую ошибку:

    Wsyncmgr.log:

    Sync failed: WSUS server not configured. Source: CWSyncMgr::DoSync SMS_WSUS_SYNC_MANAGER Status message 6703: SMS_WSUS_SYNC_MANAGER SMS WSUS Synchronization failed. Message: WSUS server not configured. Source: CWSyncMgr::DoSync. The operating system reported error 2147500037: Unspecified error

    WCM.log:

    System.Net.WebException: The request failed with HTTP status 502: Proxy Error ( The host was not found. ).~~ at Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer(Object[] args)~~ at Microsoft.UpdateServices.Administration.AdminProxy.GetUpdateServer(String serverName, Boolean useSecureConnection, Int32 portNumber)~~ at Microsoft.SystemsManagementServer.WSUS.WSUSServer.ConnectToWSUSServer(String ServerName, Boolean UseSSL, Int32 PortNumber) Remote configuration failed on WSUS Server.

    Естественно что все настройки роли SUP вы производите правильно.

    Кроме того, при попытке обращения по адресу http://FQDN-SUP-Server-SCCM/ApiRemoting30/ (например http://cm12-cas.itband.local/ApiRemoting30/) или просто при попытке обращения к http://FQDN-SUP-Server-SCCM/ вы вместо стандартного приветствия IIS (или ошибки HTTP 403.14 для варианта обращения к ApiRemoting30) получаете сообщение от своего сервера о том что заданный хост не найден:

    Error Code 11001: Host not found
    Background: This error indicates that the gateway could not find the IP address of the website you are trying to access. This is usually due to a DNS-related error.
    Date: 3/20/2012 7:42:36 PM [GMT]
    Server: red-prxy-28.redmond.corp.microsoft.com
    Source: DNS error

    Пока я склонен винить в этой проблеме связку прокси-сервер, SUP SCCM и для моего тестового домена. Но полной уверенность в этом у меня нет, поэтому если вы столкнулись с такой же проблемой попробуйте следующие действия (все они применяются на сервере SUP SCCM):

    1. Добавьте в файл HOSTS строку вида 127.0.0.1 FQDN вашего сервера
    2. Перезагрузите сервер и попробуйте произвести синхронизацию с Windows Update

    Если первый вариант не сработал, то мы можем попробовать изменить настройки Internet Explorer. Маленькая тонкость состоит в том, что эти настройки необходимо проводить для учетной записи SYSTEM, поэтому нам нужен Internet Explorer запущенный из под пользователя SYSTEM. Для этого я использовал утилиту psexec.exe. Запускаем командную строку (cmd.exe или powershell.exe) с повышенными привилегиями и выполняем следующую команду: psexec.exe –s –i cmd.exe –c в появившемся окне с помощью команды whoami убеждаемся что действительно работаем с пользователем SYSTEM и запускаем Interner Explorer: C:\Program Files (x86)\Internet Explorer\iexplore.exe

      1. В первую очередь проверяем доступен ли наш IIS по полному имени. Мы должны получить ту же ошибку Host not found что и раньше. При этом обращение по короткому имени (

    http://cm12-cas/

      ) будет отображать нормальную заставку IIS

    1. Добавляем FQDN-адрес вашего сервера в зону Local Intranet в настройках Internet Explorer и проверяем доступность http://cm12-cas.itband.local/ если заставка IIS отображается, то можем пробовать синхронизацию SUP с серверами в Интернет – все должно работать.
    2. Если шаг 2 нам не помог, тогда пробуем изменять настройки прокси-севера в Internet Explorer, в частности добавляем адрес http://cm12-cas.itband.local/ к исключениям для прокси-сервера, так как это показано на рисунке
    3. После этого пробуем перезагрузить сервер и проверить работ синхронизации.

    SUP SCCM IE Proxy Settings

     

    Надеюсь что вы не столкнетесь с данной проблемой, а если столкнетесь то сможете ее успешно решить воспользовавшись данной инструкцией Улыбка

    Алексей Тараненко

Комментарии

  1. Гы-гы у меня тоже все стенды itband, правда itband.ru

  2. кто-нить бы лучше чиркнул opsmgr 2012 шустрее работает 2007 r2 ? или уже забить на этих индусов и сразу пробовать другое…

  3. Ну как только но будет RTM и GA я думаю статьи будут появляться. Тем более чтобы понять, что он работает быстрее на реальных инфраструктурах нужно какое-то время 🙂

  4. да хотя бы последний RC, в предыдущих версиях уже по ним все было понятно 🙂

  5. Привет!
    А не может быть эта ошибка навеяна тем, что у Вас на сервере SUP SCCM’а два сетевых соединения и на каждом из них по-умолчанию в настройках TCP стоит галка “Register this connection’s addresses in DNS”. Соответственно в копроративном DNS две записи для сервера. И когда при резолвинге DNS, SCCM получает IP не из внутренней сети, мы получаем проблему.

  6. Возможно, но это не объясняет почему WSUS работает, а SUP нет 🙁

  7. Любое шаманство всегда связано с незнанием, либо прямого продукта/технологий, либо косвенных. От незнания приходится придумывать небылицы, пробовать все подряд, плясать с бубном. Здесь проблема вряд ли с SCCM, скорее всего проблема с сетевыми компонентами, их настройкой и конфигурацией. Почему проблем нет с WSUS, а с SCCM есть? Все же, SCCM продукт с большим числом компонентов, уровней, сложным взаимодействием между компонентами и уровнями. WSUS же в этом отношении намного проще. Почему бы вам не сообщить конфигурацию испытуемого, а также конфигурацию окружения. Я уверен, что вам помогут.

  8. дополнительно: думаю, что вывода
    netstat -aon
    ipconfig /all
    и
    tasklist
    будет достаточно 🙂

  9. К сожалению как я уже отмечал: “Дополнительная сложность состоит в том, что я выступаю в роли обычного пользователя для моих корпоративных серверов, поэтому не могу ничего поправить ни на корпоративном прокси-сервере, ни на сервере DNS”, равно как и посмотреть какие-либо настройки серверов.
    но вы правы, наверное стоило это назвать workaround’ом 🙂

  10. >>> Дополнительная сложность состоит в том, что я выступаю в роли обычного пользователя для моих корпоративных серверов, поэтому не могу ничего поправить ни на корпоративном прокси-сервере, ни на сервере DNS.

    Выполнить перечисленные команды, которые ничего не изменяют, вы можете. Тем более в hosts вы сделали изменения, значит и менять конфигурацию на сервере также можете. Задача же – определить проблему, а не небылицы людям рассказывать. Workaround нужен, когда проблема определена, определена ее причина, а вот исправления проблемы нет, есть только обходной путь, который в неполной мере (а если бы был в полной, то это исправление) решает созданные неудобства. В данном случае мы наблюдаем простое шаманство, пляски с бубном и нежелание разобраться и понять причины. Толк от этого нулевой. Читателям что думать то? Значит, читатель, должен, не зная причин, не зная окружения и условий, просто выполнять непонятные действия? НеАйс!

  11. Вы мне вначале расскажите пожалуйста, что вы собираетесь в выводе команд увидеть? Особенно в списке процессов?

  12. binding процессов. решение такого рода проблем необходимо начинать именно с этих команд. первая показывает соединения и binding, вторая показывает ip-адреса :). ну а третья позволяет узнать процессы, которые можно соотнести к первой команде.

  13. @12, а вы вообще знаете,где автор статьи работает?

  14. Знает, местные троли прекрасно знают, кто и где работает 🙂

  15. прекрасно знаю, но это не показатель.

  16. в двойне должно быть стыдно за такой непрофессиональный подход.

  17. Угу тут все после комментов анонимов слезами обливаются от стыда. Свали не раздражай.

  18. Черт побери, я такой знатный срач пропустил… По теме – недавно буквально была такая фигня, но подзабыл уже в чем дело, какой-то из нагугленных форумов навёл на правильную идею. Если не ошибаюсь, грабли были связаны с сертификатами, у меня native-mode, но тут проблема не в этом видимо. Хотя еще что-то с настройками IIS-узла для WSUS кажется делал. Жаль что забыл что именно 🙂

  19. Мне не стыдно. Я в отличии от, под своими словами подписываюсь своим именем.
    Поскольку у меня нет 100% уверенности в том что я знаю причину возникновения этой проблемы, я не выдаю желаемое за действительно и честно об этом говорю. То что виновата по моему мнению связка DNS-Proxy-SCCM (с включенным FQDN) я говорил в самом начале статьи. Если у меня будет четкая уверенность в том что я знаю причину – будет обновление в статье.

  20. Алексей обычно Ваши статьи вызывали интерес, но данная скорее для “галочки”, читая её я всетаки не смог наити какойто практичкский интерес в ней.

  21. И это хорошо что не нашли практического интереса. Это статья о том как побеждать довольно редкую и весьма не очевидную проблему. Поэтому я действительно рад, что статья для вас бесполезна 🙂 Это значит что вас такая проблема миновала.

    Ну а насчет интересных статей – время System Center 2012. Я думаю что скоро нас ждет много интересных статей о Configuration Manager 2012 и от меня и от других авторов.

  22. Лёша, у меня такая же проблема была, ты знаешь.
    Сегодня перенёс виртуалку в рабочую среду, соответственно, надобность во втором сетевом интерфейсе, который смотрит в мир, отпала. Удалил его, удалил все настройки IE – синхронизация работает.

  23. Столкнулись с похожей проблемой на рабочих станциях при настройке Windows Intune через proxy. Сначала выяснили, что открыты порты и адреса в firewall. Однако, на прокси попытки обратиться к сайтам даже не фиксировались. На Win7 помогла проверка netsh winhttp show proxy. Установка правильных параметров проблему решила.