none
Пингуется не тот контролер домена RRS feed

  • Вопрос

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

    В сети есть 4 домен контролера (один домен, один сайт, один лес)

    1-ый - PDC - находится локально в офисе;

    2 -ой - DC - тоже локально в офисе;

    3, 4- ый - DC - в другой стране 

    Находясь локально в офисе, некоторые компы при попытке пинговать домен - пингуют домен контролер, который находится в другой стране.

    В чем может быть проблема и как сделать так чтобы все компы в сети пинговали тот КД, который ближе всего?

    15 марта 2018 г. 17:02

Ответы

Все ответы

  • для того что бы у машин была возможность узнать кто из кд ближе всего существуют сайты, так как он у вас один, то и причин нет отказывать себе в удовольствии попинговать КД в другой стране

    Коль не секрет зачем кд выносить в другую страну?


    The opinion expressed by me is not an official position of Microsoft

    15 марта 2018 г. 17:37
    Модератор
  • Так как в другой стране есть сервера, которые должны быть в домене и которые должны обращаться к АД.

    Как сделать так, чтобы компы офиса обращались только к локальному КД? В ДНС указаны именно те КД, которые нужны

     
    15 марта 2018 г. 18:20
  • Так как в другой стране есть сервера, которые должны быть в домене и которые должны обращаться к АД.

    Как сделать так, чтобы компы офиса обращались только к локальному КД? В ДНС указаны именно те КД, которые нужны


    после первого абзаца что-то прояснилось, а вот после второго все опять запуталось.

    У вас в днс по идее должны быть все контроллеры иначе половина их функционала начнет работать ректально.

    Или вы про настройку клиентов? если да то их (клиентов) задача - из списка серверов выбрать первый живой и далее разрезолвить имя. При этом на само имя клиент никак не влияет


    The opinion expressed by me is not an official position of Microsoft

    15 марта 2018 г. 19:38
    Модератор
  • Да. я говорил о клиентах! Клиенты знают только о своих локальных ДК, которые доступны 100%, но некоторые компьютеры все равно пытаются стучать на ДК вне офиса
    15 марта 2018 г. 19:43
  • Да. я говорил о клиентах! Клиенты знают только о своих локальных ДК, которые доступны 100%, но некоторые компьютеры все равно пытаются стучать на ДК вне офиса
    При этом возникает проблема, что некоторые компьютеры тянут групповые политики минут 30 при загрузке системы. В чем собственно и проблема
    15 марта 2018 г. 19:46
  • Да. я говорил о клиентах! Клиенты знают только о своих локальных ДК, которые доступны 100%, но некоторые компьютеры все равно пытаются стучать на ДК вне офиса

    При этом возникает проблема, что некоторые компьютеры тянут групповые политики минут 30 при загрузке системы. В чем собственно и проблема
    делайте два сайта. локальный и в другой стране
    15 марта 2018 г. 20:27
    Модератор
  • Да. я говорил о клиентах! Клиенты знают только о своих локальных ДК, которые доступны 100%, но некоторые компьютеры все равно пытаются стучать на ДК вне офиса
    с чего вы это взяли? они (клиенты) знают о рабочем днс а он (днс сервер) знает о всех кд. а дальше колесо фартуны и кто какой кд выберет с тем и работает

    The opinion expressed by me is not an official position of Microsoft

    15 марта 2018 г. 21:03
    Модератор
  • делайте два сайта. локальный и в другой стране

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

    https://technet.microsoft.com/en-us/library/cc960556.aspx

    https://technet.microsoft.com/en-us/library/cc960559.aspx

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/creating-a-site-design

    16 марта 2018 г. 5:19
  • 1. Если я выставлю приориоритет и вес ДК в ДНС, то смогу ли обойти данную проблему или клиенты всеравно будут ломиться на рандомный КД?

    2. Если я фаерволом обрежу доступ офисным компам к КД что за бугром, возможно это решит проблему? 

    16 марта 2018 г. 8:55
  • Виталий, ваши действия могут привезти только к дополнительным проблемам в Active Directory, которые проявятся в самый неподходящий момент.

    Чем вас не устраивают сайты?

     
    16 марта 2018 г. 9:09
  • Согласен. Буду делать сайты. Посмотрим что с этого получится
    16 марта 2018 г. 9:10
  • Настроил три сайта. Проблема осталась. Компы всерано пингуют не локальный КД 
    • Изменено Vitaliy_88 19 марта 2018 г. 15:21
    19 марта 2018 г. 15:21
  • посмотрите вывод команды, в каком сервере был "зарегистрирован" компьютер?:

    systeminfo | find "Logon Server:"

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

    19 марта 2018 г. 15:37
    Модератор
  • посмотрите вывод команды, в каком сервере был "зарегистрирован" компьютер?:

    systeminfo | find "Logon Server:"

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

    Никаких данных данная команда не выводит
    19 марта 2018 г. 15:56
  • Вы как то так настраивали? Сети в разные в сайтах?

    The opinion expressed by me is not an official position of Microsoft

    19 марта 2018 г. 16:22
    Модератор
  • Вы как то так настраивали? Сети в разные в сайтах?

    The opinion expressed by me is not an official position of Microsoft

    Именно так! 

    Комманда >nltest /server:ххх.yyy.local /dsgetsite выдает правильный сайт с КД, но при пинге этого КД получаю IP заграничного КД

    19 марта 2018 г. 16:27
  • Никаких данных данная команда не выводит

    А Вы на доменной машине ее выполняли?

    Цель- посмотреть в каком сайте ПК, можно вот так еще:

    nltest /DsGetSite

    И пример тоже неплохо бы увидеть, что именно Вы делаете?

    Пингуете полное имя домена? Ну так у Вас несколько КД и внезапно еще и DNS Round Robin работает, и по карусели их крутит. Пинг- это сетевая утилита диагностики, а не панацея на все случаи жизни.

    Перестаньте проверять пингом доменные имена раз и навсегда. Для этого есть nslookup.

    19 марта 2018 г. 16:28
  • Никаких данных данная команда не выводит

    А Вы на доменной машине ее выполняли?

    Цель- посмотреть в каком сайте ПК, можно вот так еще:

    nltest /DsGetSite

    И пример тоже неплохо бы увидеть, что именно Вы делаете?

    Пингуете полное имя домена? Ну так у Вас несколько КД и внезапно еще и DNS Round Robin работает, и по карусели их крутит. Пинг- это сетевая утилита диагностики, а не панацея на все случаи жизни.

    Перестаньте проверять пингом доменные имена раз и навсегда. Для этого есть nslookup.

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

    19 марта 2018 г. 16:35
  • Странно! Сначало IP одного КД, через 5 минут - другого и еще через 5 - третьего, и так по кругу))))
    19 марта 2018 г. 16:39
  • Ничего удивительного нет, поскольку работают механизмы Netmask Ordering и RR. О нем можно самостоятельно поискать и почитать информацию.

    Ключевое- ПК находится в локальном сайте, стягивает политики с локального кд. Задача решена, проблемы никакой нет, самое время изучить механизмы высокой доступности Active Directory и DNS.

    19 марта 2018 г. 16:40
  • посмотрите вывод команды, в каком сервере был "зарегистрирован" компьютер?:

    systeminfo | find "Logon Server:"


    Никаких данных данная команда не выводит

    а просто systeminfo?

    DNS Round Robin работает, и по карусели их крутит.
    у меня не крутит
    19 марта 2018 г. 16:40
    Модератор
  • Странно! Сначало IP одного КД, через 5 минут - другого и еще через 5 - третьего, и так по кругу))))

    Это называется DNS Round Robin, кстати если прочитать последнюю статью то в комментариях таки даже есть ссылка на пояснения.

    Вы выполните команду nslookup fqdnдомена и также будете смотреть, как IP адреса перемешиваются.

    Повторю. Пинг оставьте для сетевиков и выявления проблемы на сетевом уровне (выключен пк закрыт ли файерволл или нет). Это не утилита проверки разрешения имен.

    Садитесь читать документацию лучше уже.

    19 марта 2018 г. 16:45
  • посмотрите вывод команды, в каком сервере был "зарегистрирован" компьютер?:

    systeminfo | find "Logon Server:"


    Никаких данных данная команда не выводит

    а просто systeminfo?

    DNS Round Robin работает, и по карусели их крутит.

    у меня не крутит

    systeminfo Logon Server вывод правильный КД 

    Что в таком случае делать с DNS Round Robin?

    19 марта 2018 г. 16:45
  • Что значит не крутит? Первый раз первый кд будет в списке, второй/третий.Нный рар они поменяются местами. Ничего делать не надо, надо читать ссылки в треде.
    19 марта 2018 г. 16:47
  • Что значит не крутит?
    а то и значит. У меня два КД в одном сайте, расстояние между КД сотни км, между ними S2S VPN. При пинге (пингую просто так, не для никакой не проверки) домен и по полному имени, и по короткому - всегда возвращается один и тот же IP. RR включен по умолчанию.
    19 марта 2018 г. 16:51
    Модератор
  • nslookup fqdn выводит правильный IP
    19 марта 2018 г. 16:56
  • А если несколько раз выполнить команду nslookup fqdn, будет крутить IP адреса?

    (я сейчас ТС спрашиваю, и до этого тоже его спрашивал), а не Вас, Anahaym


    19 марта 2018 г. 16:58
  • Да, крути IP по кругу
    19 марта 2018 г. 17:04
  • Я так понял решение по этой ссылке?

    https://blogs.technet.microsoft.com/askpfeplat/2013/02/18/how-netmask-ordering-feature-in-dns-affects-the-resultant-queries/


    • Изменено Vitaliy_88 19 марта 2018 г. 17:08
    19 марта 2018 г. 17:06
  • Хорошо, прошу занести этот факт в протокол.

    Именно это я и спрашивал, когда подал реплику 

    Что значит не крутит?
    И именно этот механизм я описывал, когда говорил о

    Ну так у Вас несколько КД и внезапно еще и DNS Round Robin работает, и по карусели их крутит.

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

    И какую утилиту для диагностики доменных имен использовать не нужно.

    19 марта 2018 г. 17:09
  • Решение чего?

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

    (заметьте, Вы только сайты переопределили, как Вам и посоветовали). И это явно говорит клиентам- сначала поговори со своими контроллерами, а уж если они недоступны иди к другим. И только.

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

    19 марта 2018 г. 17:14
  • Да, на домменом! Команда выдает правильный сайт, там где один локальный КД. Пингую просто домменое имя и возвращает айпи заграничного КД.

    А с какой целью вы пингуете доменное имя?

    Только не говорите, что для диагностики поиска контроллеров домена: клиенты Windows в реальности ищут контроллер домена не по записи A с именем домена, а другим способом (по записям SRV, как именно - ссылки были выше) .Контроллер домена регистрирует доменное имя только для поддержки сторонних (и устаревших) клиентов LDAP, которые не умеют искать сервер LDAP для домена через записи SRV. Если таких клиентов у вас нет, то запись A с именем домена вообще не нужна, и можно даже отключить её регистрацию контроллерами домена (через групповую политику).

    PS Для диагностики поиска контроллеров домена используйте утилиту nltest.

    PPS Для других коллег. nslookup для диагностики нужно использовать осторожно - иногда (при включенной NRPT, например) правильные результаты даёт именно ping, а не nslookup. А для полноценной диагностики разрешения имён следует, начиная c Win8/2012, использовать Resolve-DnsName в powershell.


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

    19 марта 2018 г. 18:18
  • А если несколько раз выполнить команду nslookup fqdn, будет крутить IP адреса?

    я прошу прощения, мне nslookup mydomain.com выдаёт мне IP адреса ВСЕХ контроллеров домена ))))
    У Вас не так?
    Я понимаю, что Вы спрашиваете ТС. Вы утверждаете, что RR будет "крутить". Тогда почему у меня он не крутит? настрйоки домена - стандартные, по умолчанию (a RR там включен по умочланию).

    M.V.V. _ да дело тут наверное не в тесте, просто ТС решил зачем-то пингануть домен и увидел, что адрес то возращается "не тот", и задался вопросом - почему не тот?

    П.с.: с выходом на работу )

    19 марта 2018 г. 18:31
    Модератор
  • Да, на домменом! Команда выдает правильный сайт, там где один локальный КД. Пингую просто домменое имя и возвращает айпи заграничного КД.

    А с какой целью вы пингуете доменное имя?

    Только не говорите, что для диагностики поиска контроллеров домена: клиенты Windows в реальности ищут контроллер домена не по записи A с именем домена, а другим способом (по записям SRV, как именно - ссылки были выше) .Контроллер домена регистрирует доменное имя только для поддержки сторонних (и устаревших) клиентов LDAP, которые не умеют искать сервер LDAP для домена через записи SRV. Если таких клиентов у вас нет, то запись A с именем домена вообще не нужна, и можно даже отключить её регистрацию контроллерами домена (через групповую политику).

    PS Для диагностики поиска контроллеров домена используйте утилиту nltest.

    PPS Для других коллег. nslookup для диагностики нужно использовать осторожно - иногда (при включенной NRPT, например) правильные результаты даёт именно ping, а не nslookup. А для полноценной диагностики разрешения имён следует, начиная c Win8/2012, использовать Resolve-DnsName в powershell.


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

    Команда nltest возвращает правильный сайт. В чем тогда может быть причина, что при логине нового пользователя компьютер загружается минут 20-30? 
    19 марта 2018 г. 18:44
  • Контроллер домена регистрирует доменное имя только для поддержки сторонних (и устаревших) клиентов LDAP, которые не умеют искать сервер LDAP для домена через записи SRV.

    Все так, но клиенты такие почти сгинули- 98я винда не умела жевать SRV записи, а линуксы уже давно научились. Уже архивные знания получаются, к сожалению.

    PPS Для других коллег. nslookup для диагностики нужно использовать осторожно - иногда (при включенной NRPT, например) правильные результаты даёт именно ping, а не nslookup. А для полноценной диагностики разрешения имён следует, начиная c Win8/2012, использовать Resolve-DnsName в Powershell.

    Да, я видел как-то недавно тред, где Вова Озеров озадачивался настройкой DNS и как раз оттоптались на этом- на разнице работы командлета и нслукапа. Я предположу, что Nslookup все ту же старую добрую апишнку дергает, которую никто не обновлял со времен NT, а вот пинг регулярно обновляется, и получает новые ключи. Ну и поддержку протоколов соответственно. Но это хорошо бы с нетмоном сесть и посмотреть глазами, а настроенной среды с NRPT сейчас нет.

    я прошу прощения, мне nslookup mydomain.comвыдаёт мне IP адреса ВСЕХконтроллеров домена ))))
    У Вас не так?
    Я понимаю, что Вы спрашиваете ТС. Вы утверждаете, что RR будет "крутить". Тогда почему у меня он не крутит? настрйоки домена - стандартные, по умолчанию (a RR там включен по умочланию).

    У меня (и не только)  не так: не важно же, что спрашиваем fqdn домена с 50ю кд или веб ферму из 10 узлов - DNS отдаст нам пачку А записей и заботливо перемешает их в ответе. Почему не крутит - кто nslookup или ping? Первый должен, он же пачку IP получает, второй- не должен, ибо адрес один в ответ уходит. 

    Можно здесь вообще вспомнить страшную тайну, что nslookup не работает с кэшем и всегда отправляет живой запрос на первый DNS, прописанный на сетевом адаптере, а ping прекрасно работает с hosts файлом и сразу "видит" внесенную в файл запись и работает с ней. Но это лирика, и отсылка к картинке в разделе технета "how dns name resolution works".

    Команда nltest возвращает правильный сайт. В чем тогда может быть причина, что при логине нового пользователя компьютер загружается минут 20-30? 

    Вы провели несколько тестов, и после нарезки сайтов и привязки подсетей ничего не изменилось?

    Если Вы наблюдаете проблему, из описания которой следует что новый пользователь, ни разу не логинившийся на ПК загружает и применяет настройки очень долго, то начать можно с очевидного- журнала event viewer- windows logs- application - windows - Group policies.

    В нем будет видно название политик, сайт и прочая потребная для понимания информация.

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

    19 марта 2018 г. 19:16
  • Контроллер домена регистрирует доменное имя только для поддержки сторонних (и устаревших) клиентов LDAP, которые не умеют искать сервер LDAP для домена через записи SRV.

    Все так, но клиенты такие почти сгинули- 98я винда не умела жевать SRV записи, а линуксы уже давно научились. Уже архивные знания получаются, к сожалению.

    PPS Для других коллег. nslookup для диагностики нужно использовать осторожно - иногда (при включенной NRPT, например) правильные результаты даёт именно ping, а не nslookup. А для полноценной диагностики разрешения имён следует, начиная c Win8/2012, использовать Resolve-DnsName в Powershell.

    Да, я видел как-то недавно тред, где Вова Озеров озадачивался настройкой DNS и как раз оттоптались на этом- на разнице работы командлета и нслукапа. Я предположу, что Nslookup все ту же старую добрую апишнку дергает, которую никто не обновлял со времен NT, а вот пинг регулярно обновляется, и получает новые ключи. Ну и поддержку протоколов соответственно. Но это хорошо бы с нетмоном сесть и посмотреть глазами, а настроенной среды с NRPT сейчас нет.

    я прошу прощения, мне nslookup mydomain.comвыдаёт мне IP адреса ВСЕХконтроллеров домена ))))
    У Вас не так?
    Я понимаю, что Вы спрашиваете ТС. Вы утверждаете, что RR будет "крутить". Тогда почему у меня он не крутит? настрйоки домена - стандартные, по умолчанию (a RR там включен по умочланию).

    У меня (и не только)  не так: не важно же, что спрашиваем fqdn домена с 50ю кд или веб ферму из 10 узлов - DNS отдаст нам пачку А записей и заботливо перемешает их в ответе. Почему не крутит - кто nslookup или ping? Первый должен, он же пачку IP получает, второй- не должен, ибо адрес один в ответ уходит. 

    Можно здесь вообще вспомнить страшную тайну, что nslookup не работает с кэшем и всегда отправляет живой запрос на первый DNS, прописанный на сетевом адаптере, а ping прекрасно работает с hosts файлом и сразу "видит" внесенную в файл запись и работает с ней. Но это лирика, и отсылка к картинке в разделе технета "how dns name resolution works".

    Команда nltest возвращает правильный сайт. В чем тогда может быть причина, что при логине нового пользователя компьютер загружается минут 20-30? 

    Вы провели несколько тестов, и после нарезки сайтов и привязки подсетей ничего не изменилось?

    Если Вы наблюдаете проблему, из описания которой следует что новый пользователь, ни разу не логинившийся на ПК загружает и применяет настройки очень долго, то начать можно с очевидного- журнала event viewer- windows logs- application - windows - Group policies.

    В нем будет видно название политик, сайт и прочая потребная для понимания информация.

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

    Первая проблема это логин новых пользователей. Вторая - не всегда синхронизируется время. Третья - gpupdate выполняется минут 30. Четвертая - не возможно доменного пользователя сделать локальным админом, так как компьютер не подтягивает доменную учетку (думает минут 10 потом выдает ошибку RPC не доступен) и т.д. На 70 % компьютеров все работает отлично, а вот на некоторых такая беда. Все ДК работают отлично, никаких проблем не обнаружил. Заметил что проблема происходит, только на ПК, которые пингуют заграничный ДК

    Лог

    The processing of Group Policy failed. Windows could not resolve the computer name. This could be caused by one of more of the following: 
    a) Name Resolution failure on the current domain controller. 
    b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).

    • Изменено Vitaliy_88 19 марта 2018 г. 19:50
    19 марта 2018 г. 19:32
  • Первая проблема это логин новых пользователей. Вторая - не всегда синхронизируется время. Третья - gpupdate выполняется минут 30. Четвертая - не возможно доменного пользователя сделать локальным админом, так как компьютер не подтягивает доменную учетку (думает минут 10 потом выдает ошибку RPC не доступен) и т.д. На 70 % компьютеров все работает отлично, а вот на некоторых такая беда. Все ДК работают отлично, никаких проблем не обнаружил. Заметил что проблема происходит, только на ПК, которые пингуют заграничный ДК

    Лог

    The processing of Group Policy failed. Windows could not resolve the computer name. This could be caused by one of more of the following: 
    a) Name Resolution failure on the current domain controller. 
    b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).

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

    ipconfig /all

    и с контроллера домена:

    dcdiag
    dcdiag /test:dns
    также расскажите, как у вас соединён главный офис с заграничным.
    19 марта 2018 г. 20:18
    Модератор
  • Первая проблема это логин новых пользователей. Вторая - не всегда синхронизируется время. Третья - gpupdate выполняется минут 30. Четвертая - не возможно доменного пользователя сделать локальным админом, так как компьютер не подтягивает доменную учетку (думает минут 10 потом выдает ошибку RPC не доступен) и т.д. На 70 % компьютеров все работает отлично, а вот на некоторых такая беда. Все ДК работают отлично, никаких проблем не обнаружил. Заметил что проблема происходит, только на ПК, которые пингуют заграничный ДК

    Лог

    The processing of Group Policy failed. Windows could not resolve the computer name. This could be caused by one of more of the following: 
    a) Name Resolution failure on the current domain controller. 
    b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).

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

    ipconfig /all

    и с контроллера домена:

    dcdiag
    dcdiag /test:dns
    также расскажите, как у вас соединён главный офис с заграничным.

    20 марта 2018 г. 9:54
  • 1) порядок ДНС на контроллерах домена:
     1 - сам на себя (172.16.10.5)
     2 - на любой другой КД (172.16.10.15)
     3 - петля
    2) покажите вывод с контроллера домена:

    get-ADReplicationSubnet -Filter *

    3) с клиента покажите:

    tracert 172.16.10.5

    пожалуйста, не используйте скрины командной строки. Скопируйте вывод и вставьте как код:

    • Помечено в качестве ответа Vitaliy_88 21 марта 2018 г. 19:33
    20 марта 2018 г. 10:05
    Модератор
  • C:\Windows\System32>tracert 172.16.10.5
    
    Tracing route to corp.local [172.16.10.5]
    over a maximum of 30 hops:
    
      1    <1 ms    <1 ms    <1 ms  172.16.14.1
      2    <1 ms    <1 ms     1 ms  corp.local [172.16.10.5]
     
    PS C:\windows\system32> get-ADReplicationSubnet -Filter *
    
    
    DistinguishedName : CN=172.16.9.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC= corp,DC=local
    Location          :
    Name              : 172.16.9.0/24
    ObjectClass       : subnet
    ObjectGUID        : 994ba1f7-4af6-4b27-9511-40e6930c7d50
    Site              : CN=Frankfurt,CN=Sites,CN=Configuration,DC= corp,DC=local
    
    DistinguishedName : CN=172.16.10.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC= corp,DC=local
    Location          :
    Name              : 172.16.10.0/24
    ObjectClass       : subnet
    ObjectGUID        : 9a45b706-4479-409c-bf76-13d90bc905a6
    Site              : CN=Kiev,CN=Sites,CN=Configuration,DC= corp,DC=local
    
    DistinguishedName : CN=172.16.22.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC= corp,DC=local
    Location          :
    Name              : 172.16.22.0/24
    ObjectClass       : subnet
    ObjectGUID        : 66aaf05f-8423-4d5f-9f83-4ef2c129e1fb
    Site              : CN=Frankfurt-Dev,CN=Sites,CN=Configuration,DC= corp,DC=local
    
    DistinguishedName : CN=172.16.8.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC= corp,DC=local
    Location          :
    Name              : 172.16.8.0/24
    ObjectClass       : subnet
    ObjectGUID        : e4290860-38f9-4b4f-bbbf-a8e78e0a7273
    Site              :
    
    DistinguishedName : CN=172.16.5.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC= corp,DC=local
    Location          :
    Name              : 172.16.5.0/24
    ObjectClass       : subnet
    ObjectGUID        : a372cb52-38f2-4a8d-84b5-5859266b2585
    Site              : CN=Kiev,CN=Sites,CN=Configuration,DC= corp,DC=local
    
    DistinguishedName : CN=172.16.4.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC= corp,DC=local
    Location          :
    Name              : 172.16.4.0/24
    ObjectClass       : subnet
    ObjectGUID        : 6e4760a7-2b09-4c9f-aa3d-c259194105cb
    Site              : CN=Kiev,CN=Sites,CN=Configuration,DC= corp,DC=local
    
    DistinguishedName : CN=172.16.1.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC= corp,DC=local
    Location          :
    Name              : 172.16.1.0/24
    ObjectClass       : subnet
    ObjectGUID        : 57d0f69f-0b82-4321-bdd0-22dbe5ddec2c
    Site              : CN=Kiev,CN=Sites,CN=Configuration,DC= corp,DC=local
    
    DistinguishedName : CN=172.16.2.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC= corp,DC=local
    Location          :
    Name              : 172.16.2.0/24
    ObjectClass       : subnet
    ObjectGUID        : eba1e59e-82e5-4577-a824-9eb503bfe1ef
    Site              : CN=Kiev,CN=Sites,CN=Configuration,DC= corp,DC=local
    
    DistinguishedName : CN=172.16.6.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC= corp,DC=local
    Location          :
    Name              : 172.16.6.0/24
    ObjectClass       : subnet
    ObjectGUID        : 59f582b2-8149-4960-ac14-07bd7b70f5d1
    Site              : CN=Kiev,CN=Sites,CN=Configuration,DC= corp,DC=local
    
    DistinguishedName : CN=192.168.10.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC= corp,DC=local
    Location          :
    Name              : 192.168.10.0/24
    ObjectClass       : subnet
    ObjectGUID        : eeede831-32d8-4edd-a349-da548339fd80
    Site              : CN=Kiev,CN=Sites,CN=Configuration,DC= corp,DC=local
    
    DistinguishedName : CN=172.16.14.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC= corp,DC=local
    Location          :
    Name              : 172.16.14.0/24
    ObjectClass       : subnet
    ObjectGUID        : c9f84117-614c-4fbd-bf48-95a1885301de
    Site              : CN=Kiev,CN=Sites,CN=Configuration,DC= corp,DC=local
    
    DistinguishedName : CN=172.16.7.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC= corp,DC=local
    Location          :
    Name              : 172.16.7.0/24
    ObjectClass       : subnet
    ObjectGUID        : 310ec459-8caa-441f-91e3-f76a7a52e602
    Site              : CN=Kiev,CN=Sites,CN=Configuration,DC= corp,DC=local
    
    DistinguishedName : CN=172.16.3.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC=corp,DC=local
    Location          :
    Name              : 172.16.3.0/24
    ObjectClass       : subnet
    ObjectGUID        : 68192fe8-f535-4902-947b-3ec58eb5df12
    Site              : CN=Kiev,CN=Sites,CN=Configuration,DC= corp,DC=local
    
    DistinguishedName : CN=172.16.20.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC= corp,DC=local
    Location          :
    Name              : 172.16.20.0/24
    ObjectClass       : subnet
    ObjectGUID        : 1a29dfee-f95d-4007-8a3f-264244522ebf
    Site              : CN=Kiev,CN=Sites,CN=Configuration,DC= corp,DC=local
    
    DistinguishedName : CN=172.16.13.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC= corp,DC=local
    Location          :
    Name              : 172.16.13.0/24
    ObjectClass       : subnet
    ObjectGUID        : eee3e5f8-b097-41ce-a9d0-9ac2860b2b84
    Site              : CN=Kiev,CN=Sites,CN=Configuration,DC= corp,DC=local
                               

    20 марта 2018 г. 10:39