работа над созданием скрипта, который запускается по расписанию; вся его цель - настроить таргетинг на несколько контроллеров домена и непрерывно (каждые 2 секунды) выполнять запрос ldap, ориентированный на этот конкретный DC, и выгружать вывод в csv find. По сути, я делаю следующие шаги.
$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, что и ROOT / Base. (Подтверждает ли приведенный выше код, что LDAP-соединение существует с этим конкретным DC из любого приложения, которое правильно настроен?)
2.) Этот вопрос касается PowerShell, как получить журналы ошибок LDAP в PowerShell? Я хочу протестировать его на несуществующем или выключенном контроллере домена, какое событие журнала мне следует ожидать и как его зафиксировать.
3.) То же, что и в вопросе 2, если DC имеет проблемы с репликацией, влияет ли это на подключение LDAP? какие журналы нужно записывать и как? Ниже приведены некоторые из ошибок репликации. Вызывает ли какое-либо из этих событий проблемы с подключением LDAP?
** -> (1256) Удаленная система недоступна. Для получения информации об устранении неполадок в сети см. Справку Windows. -> (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, если у контроллера домена возникают проблемы с репликацией, какие журналы следует записывать и как?
Это не подходящий способ тестирования проблем репликации на контроллере домена. Вы должны использовать repadmin.exe /showreps, журнал событий службы каталогов и т. д. для отслеживания работоспособности репликации.
Редактировать: Чтобы ответить на ваше обновление,
Ошибки RPC не приравниваются к ошибкам репликации Active Directory. Доступность RPC-сервера - это отдельная проблема ... хотя основная причина проблем с доступностью RPC-сервера, безусловно, также может способствовать случайным проблемам репликации. Потребуется больше устранения неполадок.
Как определить задержку запроса LDAP? Поскольку этот скрипт работает сам по себе, есть ли способ определить, сколько времени он занял, или измерить задержку?
С точки зрения клиента, Measure-Command командлет хорошо показывает, сколько времени что-то заняло. Или вы можете использовать базовый объект .NET System.Diagnostics.Stopwatch. Это довольно точно.
С точки зрения сервера, вы могли бы наблюдать за монитором производительности. (Perfmon) Посмотрите на объекты «Службы каталогов» и NTDS perfmon - у них есть различные счетчики производительности, связанные с тем, сколько операций чтения каталога выполняется в секунду, а также их среднее время, длину очереди и т. Д. Счетчики Perfmon хороши для в общем и целом работоспособность, но сервер, вероятно, не будет отслеживать задержку каждого отдельного запроса LDAP. Если вы заинтересованы в этом измерении, вы, вероятно, захотите снять его у клиента.