Непрерывно проверяйте возможность соединения LDAP к Контроллерам домена (Проверка Heartbeat LDAP)
работа над разработкой сценария, который работает через задачу расписания; целая цель его состоит в том, чтобы предназначаться для немногих контроллеров домена, и непрерывно (в течение каждых 2 секунд) делают запрос ldap, предназначающийся, что конкретный DC и выводит вывод к csv, находят. По существу я делаю ниже шагов.
$root = [ADSI]"LDAP://CN=$TargetDCName,OU=Domain Controllers,DC=Fabricom,DC=com"
$search = [adsisearcher]$root
$Search.Filter = "(&(objectClass=computer))"
$Search.SearchScope = "base"
$Obj = $Search.Findone()
$Obj = $Obj.Path
$DateFormatted = Get-Date -uformat "%Y-%m-%d_%I-%M-%S-%p"
$Data = $DateFormatted + "," + $TargetDCName+ "," + "$Obj"
Add-Content -Path $Path -Value $Data
Теперь я получаю немного сомнений; 1.) Делает то, что я делаю выше, имеют смысл как проверку возможности соединения LDAP, так как я запрашиваю DC с помощью того же DC в качестве КОРНЯ/ОСНОВЫ. (Вышеупомянутый код подтверждают, что возможность соединения LDAP существует к тому конкретному DC из какого-либо приложения, которое правильно настроено?)
2.) Этот вопрос расценивает powershell, как получить журналы ошибок LDAP в powershell? Я хочу протестировать его против не существующий или DC, который закрывается, какое событие журнала я должен ожидать и как получить его.
3.) То же как вопрос 2, если DC имеет проблемы репликации, действительно ли он производит возможность соединения LDAP? какие журналы должны быть получены и как? Ниже некоторые ошибки репликации, какое-либо из этих событий вызывает проблему к возможности соединения LDAP?
**-> (1256) удаленная система не доступна. Для получения информации о сетевом поиске и устранении неисправностей см. Windows Help.-> (1722) сервер RPC недоступен.-> (8206) служба каталогов занята.-> (8438) служба каталогов слишком занята для завершения операции репликации в это время. **
4.) Как Определить Задержку запроса LDAP? Начиная с этого сценария выполнения самостоятельно, там способ определить, во сколько взял, или измерьте его задержку?
сообщите мне, запрашивается ли больше информации.
Имеет смысл то, что я делаю выше, так как проверка LDAP-соединения
Выполняя ее каждые 2 секунды, вы перестараетесь. Это слишком. Если вы собираетесь это сделать, подумайте о том, чтобы удлинить интервал до проверки только раз в 5 минут или около того. LDAP серверы не настолько склонны к сбоям, чтобы вы могли проверять их каждые 2 секунды.
Подтверждает ли приведенный выше код, что LDAP соединение существует с этим конкретным DC из любого приложения, которое правильно сконфигурировано?)
Да, он будет проверять LDAP соединение. Это не единственный способ, и он может быть, а может и не быть лучшим, но это один способ.
Я также скептически отношусь к тому, как вы выводите в CSV на каждой итерации скрипта (каждые 2 секунды!) и просто перезаписываете одно и то же CSV на каждой итерации. Если бы вы вместо этого посылали вывод, скажем, в базу данных SQL и добавляли строку каждый раз, когда запускался ваш скрипт, у вас было бы гораздо больше контекстных данных. Например, вы могли бы запросить БД и увидеть, что у вас был 30-минутный перерыв с 10:00 до 10:30, а затем у вас был 5-минутный перерыв с 11:45 до 11:50 7 июля и т.д.
Этот вопрос касается powershell, как получить журналы ошибок LDAP в powershell? Я хочу протестировать его на несуществующем или выключенном контроллере, какое журнальное событие я должен ожидать и как его захватить.
Вам нужно создать свой собственный журнал событий. Powershell не записывает автоматически каждую ошибку и исключение без вашей просьбы. Подумайте об использовании Start-Transcript для записи сеансов Powershell в файл. Или вы можете использовать команду New-Event для создания собственных сообщений в журнале регистрации событий. Используйте блоки Try/Catch, чтобы легко перехватывать исключения. Можно также использовать переменную $Error в своих сценариях, чтобы увидеть последнюю ошибку.
То же самое, что и вопрос 2, если в DC возникают проблемы с репликацией, какие журналы нужно перехватывать и как?
Это не подходящий способ проверки на наличие проблем с репликацией на контроллере домена. Для мониторинга состояния репликации следует использовать repadmin.exe /showreps, журнал регистрации событий службы каталогов и т.д.
Edit: Для решения проблемы с репликацией
RPC ошибки не приравниваются к ошибкам репликации Active Directory. Доступность сервера RPC - это отдельная проблема... хотя основная причина проблем с доступностью сервера RPC, безусловно, может также способствовать возникновению проблем с репликацией по стечению обстоятельств. Потребуется больше поиска и устранения неисправностей.
Как определить задержку LDAP запроса? Поскольку этот сценарий работает сам по себе, есть ли способ определить, сколько времени он занял, или измерить его задержку?
С точки зрения клиента, команда Measure-Command хорошо подходит для того, чтобы сказать вам, сколько времени что-то заняло. Или вы можете использовать базовый объект System.Diagnostics.Stopwatch .NET. Он довольно точный.
С точки зрения сервера, Вы захотите посмотреть Performance Monitor. (Perfmon) Посмотрите на объекты 'Directory Services' и NTDS perfmon - там есть различные счетчики производительности, связанные с количеством чтений каталогов в секунду, их средним временем, длиной очереди и т.д. Счётчики Perfmon хороши для общего состояния , но сервер, скорее всего, не будет отслеживать задержку каждого отдельного LDAP запроса. Если вас интересует это измерение, вы, вероятно, захотите взять его у клиента.
.