none
DCOM was unable to communicate with the computer (несуществующий сервер) using any of the configured protocols. RRS feed

  • Вопрос

  • Доброго всем!

    В логах на DC регулярная ошибка DCOM was unable to communicate with the computer (несуществующий сервер) using any of the configured protocols.

    Недавно проводил чистку AD с помощью ntdsutil, руководствуясь статьей Delete Failed DCs from Active Directory. Все прошло успешно, "мертвые души" были удалены, DNS почищен, в AD Sites and Services только живые сервера. Проверял через ntdsutil - комадна list servers in site выводит имена только существующих серверов. Тем не менее, эта ошибка не исчезает.

    Где еще поискать записи, относящиеся к давно несуществующим серверам?

    Спасибо.


    Я отказался от сигарет!

    8 августа 2013 г. 4:32

Ответы

  • Добрый день. 

    DHCP были совмещены с контроллерами домена? Если да, были ли они деавторизованы перед удалением?

    Вы уверены что реплика, после отчистки метаданных прошла?

    Данные о авторизованных серверах DHCP хранятся разделе конфигурации леса. Если сервер был перед удалением де-авторизован корректно, то запись о нём автоматически уберается из данного CN. P.S. CN=DhcpRoot не трогаем.


    http://cheryatnikov.blogspot.com/


    9 августа 2013 г. 12:56
  • Перед тем, как отработать по RPC или каким либо другим способом, консоль MMC управления DHCP в разделе Manage Authorized Servers получает список авторизованных серверов из соответствующего раздела Конфигурации, иначе она не узнает куда подключаться (если DHCP не установлен локально).

    Данный раздел хранит данные о всех авторизованных сейчас или ранее DHCP. Если сервер не был де-авторизован и был выведен из эксплуатации, либо реплика не прошла - данные зависнут в разделе конфигурации того сервера, на котором вносились изменения

    Пример ниже, я на демо-стенде убрал запись о DHCP.

    Мой ответ касается второго вопроса про DHCP.


    http://cheryatnikov.blogspot.com/





    10 августа 2013 г. 6:40
  • Это к несуществующим серверам пытается обратиться какая-то программа (например, в моей практике это был корпоративный Symantec Antivirus). Ни репликация AD, ни управление DHCP и другими службами DCOM не использует - там используется напрямую RPC.


    Слава России!

    9 августа 2013 г. 20:00
  • В принципе да, если это выглядит, как на скриншотах ниже.

    Обычно контроллер домена регистрирует несколько видов сервисных записей в DNS, включая ту, которую вы привели.

    Естественно ID будет разный у Вас и у меня;


    http://cheryatnikov.blogspot.com/



    • Изменено Vitalishe 21 августа 2013 г. 6:40 дополнение;
    • Помечено в качестве ответа Alexander.V 21 августа 2013 г. 7:02
    21 августа 2013 г. 6:28
  • http://www.techdiving.pro/2013/04/active-directory-domain-services-total_16.html - там описано:) коротко, как поправить через ADSI Edit

    http://cheryatnikov.blogspot.com/


    • Изменено Vitalishe 21 августа 2013 г. 7:09
    • Помечено в качестве ответа Alexander.V 21 августа 2013 г. 8:56
    21 августа 2013 г. 7:08

Все ответы

  • Сегодня нашел еще следы давно умерших контроллеров. В оснастке DHCP, по правому клику выбрал "Manage Authorized Servers" и увидел список из пяти серверов. Из которых реально существует только два.

    Можно как-то вычистить AD от этих мертвецов? Жить конечно не мешают, но раздражают :)


    Я отказался от сигарет!

    9 августа 2013 г. 5:29
  • Добрый день. 

    DHCP были совмещены с контроллерами домена? Если да, были ли они деавторизованы перед удалением?

    Вы уверены что реплика, после отчистки метаданных прошла?

    Данные о авторизованных серверах DHCP хранятся разделе конфигурации леса. Если сервер был перед удалением де-авторизован корректно, то запись о нём автоматически уберается из данного CN. P.S. CN=DhcpRoot не трогаем.


    http://cheryatnikov.blogspot.com/


    9 августа 2013 г. 12:56
  • Это к несуществующим серверам пытается обратиться какая-то программа (например, в моей практике это был корпоративный Symantec Antivirus). Ни репликация AD, ни управление DHCP и другими службами DCOM не использует - там используется напрямую RPC.


    Слава России!

    9 августа 2013 г. 20:00
  • Перед тем, как отработать по RPC или каким либо другим способом, консоль MMC управления DHCP в разделе Manage Authorized Servers получает список авторизованных серверов из соответствующего раздела Конфигурации, иначе она не узнает куда подключаться (если DHCP не установлен локально).

    Данный раздел хранит данные о всех авторизованных сейчас или ранее DHCP. Если сервер не был де-авторизован и был выведен из эксплуатации, либо реплика не прошла - данные зависнут в разделе конфигурации того сервера, на котором вносились изменения

    Пример ниже, я на демо-стенде убрал запись о DHCP.

    Мой ответ касается второго вопроса про DHCP.


    http://cheryatnikov.blogspot.com/





    10 августа 2013 г. 6:40
  • Всем доброго!
    Сорри, что долго не отвечал. Не было возможности.

    >DHCP были совмещены с контроллерами домена?
    Скорее всего да. Но не могу утверждать.
    >Если да, были ли они деавторизованы перед удалением?
    Насчет этого сильно сомневаюсь. Вряд-ли выполнялась деавторизация.

    >Вы уверены что реплика, после отчистки метаданных прошла?
    Да. Проверял записи в DNS на живых контроллерах и выполнял netdom query fsmo на контроллерах. В результатах указан правильный Roles Master.

    Однако, сейчас попытался понизить один из трех контроллеров, который "живет" на VMWare workstation и в самом начале выполнения dcpromo получил сообщение об ошибке:

    The operation failed because:
    Active Directory Domain Services could not transfer the remaining data in directory partition
    DC=ForestDnsZones,DC=FBC,DC=offices to Active Directory Domain Controller \\FBC-DC7.FBC.offices
    "The directory service is missing mandatory configuration information, and unable to determine the ownership of floating single-master operation roles."

    Хотя при выполнении netdom query fsmo на нем выводится, что хозяином всех операций является FBC-DC1.

    Можно конечно, передать все роли обратно на этот DC7 и попробовать запустить снова dcpromo, но что все же интересно, почему контроллер "зная" кто хозяин, пытается обратиться к другому серверу?

    Как правильно поступить в данной ситуации?



    Я отказался от сигарет!


    • Изменено Alexander.V 14 августа 2013 г. 5:21
    14 августа 2013 г. 5:20
  • http://www.techdiving.pro/2013/04/active-directory-domain-services-total_16.html - посмотрите вот тут:) Думаю поможет

    http://cheryatnikov.blogspot.com/


    • Изменено Vitalishe 14 августа 2013 г. 6:16
    14 августа 2013 г. 6:16
  • Спасибо, почитал, полезно. Но, к своему стыду вынужден признать, что я не знаю, как подключиться из ADSI edit к контексту именования домена или леса, чтобы найти там объект CN=Infrastructure, дабы посмотреть его атрибуты. ps У меня один лес и один домен.


    Я отказался от сигарет!

    Да, и спасибо Вам и M.V.V.  за ответы по DHCP. В консоли DHCP в Manage Authorized Servers и в указанном разделе ADSI я нашел те сервера, которые давно не существуют!

    • Изменено Alexander.V 21 августа 2013 г. 5:23 Уточнение
    21 августа 2013 г. 5:14
  • Ничего страшного, не каждый день администраторам приходиться выполнять подобные задачи.

    Всё достаточно просто в Вашем случае:

    1. Открываем оснастку ADSI

    2. Правой кнопкой жмём на ADSI Edit в левой части MMC

    3. Выбираем Connect to и в строке Select Type or Distinguished Name or Naming Context пишем DC=ForestDNSZones,DC=CONTOSO,DC=COM (где contoso.com - имя вашего домена)

    4. Ищем объект CN=Infrastructure - Вас интересуют свойства этого объекта (отмеченно красной стрелкой, см. пример ниже)

    5. Далее, предварительно сняв резервную копию, действуем по инструкции в моей статье, либо тут http://support.microsoft.com/kb/949257,

    6. Аналогичные действия выполняем для раздела DomainDNSZones


    http://cheryatnikov.blogspot.com/

    21 августа 2013 г. 5:29
  • Спасибо!

    У меня там (в атрибутах CN=Infrastrucrure, fSMORoleOwner) жуть какая-то. :)

    CN=NTDS Settings\0ADEL:3a74efb5-7ee2-4ddc-afe1-1768a9a1d445,CN=FBC-XDC\0ADEL:7bcdd342-1cdf-419d-bf67-81cc42d4388c,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=FBC,DC=offices

    Сервер FBC-XDC действительно когда-то существовал. Как мне рассказали, у него материнка умерла, а новую не купили. Купили сразу новый сервер. Ладно, это не суть. Просто мне казалось, что я почистил упоминания об этом сервере, когда выполнял действия из статьи, указанной в первом сообщении этого топика.

    И еще вопрос... В консоли DNS-Forward Lookup Zones\fbc.offices\_msdcs\domains есть объект, у которого вместо имени нашего домена абракадабра вида "8c11eef-8v82-54f1-......длинная запись" Это нормально?


    Я отказался от сигарет!

    21 августа 2013 г. 6:03
  • В принципе да, если это выглядит, как на скриншотах ниже.

    Обычно контроллер домена регистрирует несколько видов сервисных записей в DNS, включая ту, которую вы привели.

    Естественно ID будет разный у Вас и у меня;


    http://cheryatnikov.blogspot.com/



    • Изменено Vitalishe 21 августа 2013 г. 6:40 дополнение;
    • Помечено в качестве ответа Alexander.V 21 августа 2013 г. 7:02
    21 августа 2013 г. 6:28
  • 5. Далее, предварительно сняв резервную копию, действуем по инструкции в моей статье, либо тут http://support.microsoft.com/kb/949257,

    6. Аналогичные действия выполняем для раздела DomainDNSZones


    http://cheryatnikov.blogspot.com/

    А по какой Вашей статье?

    Я отказался от сигарет!

    21 августа 2013 г. 7:06
  • http://www.techdiving.pro/2013/04/active-directory-domain-services-total_16.html - там описано:) коротко, как поправить через ADSI Edit

    http://cheryatnikov.blogspot.com/


    • Изменено Vitalishe 21 августа 2013 г. 7:09
    • Помечено в качестве ответа Alexander.V 21 августа 2013 г. 8:56
    21 августа 2013 г. 7:08
  • Спасибо! Сорри, протупил. :) Статью видел, сделал все по ней. Смог понизить временный сервер на виртуалке до рядового. Даже успешно выполнил adprep/forestprep и adprep/domainprep для подготовки к переходу на Server2012, который скоро должны купить.

    Я отказался от сигарет!

    21 августа 2013 г. 8:56
  • Отлично, рад, что помогло.

    http://cheryatnikov.blogspot.com/

    21 августа 2013 г. 9:51
  • Гм....

    Благодаря ответам в этом топике мне удалось разобраться с записями в DHCP и в AD, но ошибка, из-за которой этот топик и создавался не исчезла. Сейчас еще раз внимательно посмотрю все записи в DNS.


    Я отказался от сигарет!

    22 августа 2013 г. 6:10
  • В каком логе ошибка?

    Посмотрите логи сервисов ADDS, DFS - есть ли там ошибки, возникающие в одно время или рядом с этим событием, есть ли там вообще ошибки?


    http://cheryatnikov.blogspot.com/

    22 августа 2013 г. 6:45
  • Ошибка в Event Viewer (Local)-Windows Logs-System. Больше ошибок нет, только Warning от тайм-сервиса.

    В DFS ошибок нет, в ADDS только Warning-и о долгом отсутствии бекапов и то, вчерашние.


    Я отказался от сигарет!

    22 августа 2013 г. 7:38
  • Я правильно понимаю, что вы просмотрели вот эти логи?

    Так же можно проверить конфигурацию сервисов смежных с AD в разделах Configuration, в контейнере System.

    Ещё указывается ли в ошибке служба или GUID пытающийся обратиться к удалённому серверу? Если да, то можно поискать по реестру, чтобы определиться, что именно инициирует подключение.

    Был ли установлен сторонний софт на КД?


    http://cheryatnikov.blogspot.com/

    22 августа 2013 г. 10:31
  • Нет, эти ошибки разделом выше, в Windows Logs\System. Присутствуют на каждом из двух контроллеров. В Details посмотрел GUID - {1b562e86-b7aa-4131-badc-b6f3a001407e}, выполнил по нему поиск в реестре. Поиск нашел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{1b562e86-b7aa-4131-badc-b6f3a001407e}

    Из стороннего софта - только консоль для управления АТС на одном из DC. Ошибка была до установки этого ПО.

    >Так же можно проверить конфигурацию сервисов смежных с AD в разделах Configuration, в >контейнере System.

    Это в ADSI Edit? Если да, то в каком контексте?


    Я отказался от сигарет!

    23 августа 2013 г. 5:05
  • А в приведённых на моём скриншотах журналах ADDS, DFS и т.д. ошибки есть?


    http://cheryatnikov.blogspot.com/

    23 августа 2013 г. 5:20
  • Ошибок нет, есть пара сегодняшних одинаковых Warning-ов в 9:12:

    В DS:

    • Active Directory Domain Services could not update the following object with changes received from the directory service at the following network address because Active Directory Domain Services was busy processing information.

    В DFS последняя ошибка от 21-го числа о том, что failed to contact domain controller, спустя 10 мин есть событие об успехе: The DFS Replication service successfully contacted domain controller


    Я отказался от сигарет!

    23 августа 2013 г. 7:59
  • В общем, идея следующая:

    1. Что-то пытается обратиться к удалённому сервису сервера, который был удалён;

    2. Происходит это регулярно (как регулярно? Ответ на этот вопрос важен)

    Т.е. где-то осталась настройка или параметр, который заставляет какой то сервис обращаться к несуществующему КД.

    Я не имею доступ к вашей системе, и не могу сам посмотреть.

    Ошибки лучше приводить в скринах, чтобы видеть доп. информацию, то, что вы написали ни о чём почти не говорит.

    Для начала попробуйте пойти старым методом:

    1. вычищаем и сохраняем все журналы (повторяю: все, которые мы обсуждали выше: System, Application,Ad, DFS etc.);

    2. перезагружаем КД;

    3. анализируем, что записывается в логи


    http://cheryatnikov.blogspot.com/

    23 августа 2013 г. 9:39
  • Ок, понял. Сделаю - отпишусь. Событие регулярное. Период 8 часов +1 или 2 сек

    Я отказался от сигарет!

    23 августа 2013 г. 9:48
  • Ну, что у Вас получилось?

    http://cheryatnikov.blogspot.com/

    2 сентября 2013 г. 5:35
  • Сорри, пока этим не занимался, не было времени. Как обещал, отпишусь чуть позже...

    Я отказался от сигарет!

    3 сентября 2013 г. 12:13