Устранение проблем MCA, часть 1. Определение компьютеров с проблемами MCA

В этой статье описывается, как собирать и анализировать данные, чтобы определить, может ли у вас проблема, которую можно устранить с помощью MaxConcurrentApi записи реестра. Эта проблема также называется проблемой MCA. Этот процесс помогает определить, какие компьютеры в инфраструктуре влияют на эту проблему.

Область применения: Windows Server 2012 и более поздних версий, Windows 8 и более поздних версий

Итоги

MaxConcurrentApi Технически определяет количество потоков lsass.exe на защищенный канал, доступный службе Netlogon. Это значение задается в реестре каждого сервера. Вы не должны изменить его, если только вы не сделали следующее:

• Идентифицированные определенные серверы, которые показывают доказательства проблемы MCA
• Вычисляется определенное MaxConcurrentApi значение для каждого затронутого сервера.

Если изменить значение без выполнения этих правил, возможно, проблема не устранена. На самом деле, вы можете вызвать другие проблемы.

В этой статье описывается, как определить серверы, которые необходимо изменить с помощью следующего процесса:

1. Определите собираемые данные.
2. Определение компьютеров, на которых требуется собирать данные
3. Определите, имеет ли ваша инфраструктура проблему MCA.
4. Определите определенные серверы, которые могут воспользоваться настроенным MaxConcurrentApi значением.

Полезные типы данных

В следующей таблице перечислены типы данных, которые необходимо использовать для методов, описанных в этой статье.

Тип данных	Исходный код	Наиболее полезно для
Сообщения об ошибках Дополнительные сведения о журналах и сообщениях об ошибках Netlogon	Журналы netlogon	Определение проблемы MCA
Сообщения о подключении к серверу	Журналы netlogon	Определение того, какие контроллеры домена участвуют в транзакциях проверки подлинности
События Дополнительные сведения о событиях	Журнал событий системы Журналы netlogon	Определение проблемы MCA Определение возможных причин задержек проверки подлинности
Счетчики производительности Дополнительные сведения о счетчиках производительности Netlogon	Системный монитор Журналы netlogon Системный журнал событий	Определение проблемы MCA Настройка значений MCA
Сведения о транзакциях между серверами, включая взаимодействие контроллера домена Запуск и остановка трассировок сети	netsh Сетевой монитор	Определение того, какие контроллеры домена участвуют в транзакциях проверки подлинности Определение возможных причин задержек проверки подлинности
Пользовательские отчеты	Пользователи	Указывая, что может возникнуть проблема MCA

Примечание.

Этот список данных и источников данных не является исчерпывающим. Другие типы данных и источники данных, такие как трассировка событий windows (ETW) и журнал событий NTLM Operations, выходят за рамки этой статьи.

Запуск и остановка трассировок сети

Для сбора сетевых трассировок можно использовать средство оболочки собственной сети Windows (netsh ). Чтобы начать трассировку, откройте окно командной строки на затронутом сервере и введите следующую команду:

netsh trace start capture=yes tracefile=c:\temp\<Filename>.etl

Примечание.

В этой команде <имя файла> представляет имя файла, в который хранятся данные трассировки.

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

netsh trace stop

После остановки трассировки netsh создает ETL и CAB-файлы в указанном расположении. Для просмотра файлов можно использовать сетевой монитор или анализатор сообщений (нерекомендуемый, недоступный для скачивания).

Дополнительные сведения о счетчиках производительности Netlogon

Счетчики производительности Netlogon предоставляют наиболее точные данные для настройки MaxConcurrentApi значения.

Примечание.

• Объект статистики системы безопасности в Монитор производительности предоставляет несколько счетчиков, связанных с проверкой подлинности. Однако они не предоставляют данные, к которым можно напрямую применяться MaxConcurrentApi.
• Другие счетчики производительности, такие как счетчики ЦП и сети, не отражают сведения о производительности, которые относятся к MaxConcurrentApi.

В следующей таблице описаны наиболее релевантные счетчики. (В Монитор производительности эти счетчики принадлежат объекту Netlogon.) Сценарий "Продуктовый магазин" является более повторной версией технического объяснения.

Счетчик производительности	Техническое объяснение	Сценарий продуктового магазина
Держатели Семафора	Количество потоков, содержащих семафор. Это число может быть любым значением до текущего настроенного значения MaxConcurrentApi.	Количество людей, которые в настоящее время проверяются на кассовых кассах.
Семафор Официанты	Количество потоков, ожидающих получения семафора.	Количество людей, которые ждут в очереди, чтобы проверить.
Время ожидания Семафора	Общее количество времени ожидания потока во время ожидания семафора, измеряемого в течение времени существования безопасного канала (или с момента запуска системы).	Общее количество людей, которые отказываются от линии выхода, потому что они закончились. (Если строка была быстрее или были дополнительные строки, это может не произойти.)
Среднее время удержания Семафора	Среднее время (измеряется в секундах), которое семафор проводится в течение последнего образца.	Среднее время, которое требуется каждому человеку, чтобы пройти через линию и проверить.
Семафор получает	Общее количество попыток получения семафора за время существования безопасного канала (или с момента запуска системы).	Общее количество пользователей, которые успешно извлечены.

Дополнительные сведения о событиях

В следующей таблице перечислены события, связанные с проблемами MCA. Эти события можно найти с помощью Просмотр событий или файлов журнала Netlogon, чтобы получить краткие сведения о том, может ли компьютер иметь проблему С MCA.

Источник событий и идентификатор	Описание события	Связанные счетчики производительности
Netlogon 5816	Netlogon завершился сбоем запроса проверки подлинности имени пользователя учетной записи <в полное> доменное имя> домена <домена. Время ожидания запроса истекло до его отправки на контроллер домена непосредственно доверенное полное> доменное имя контроллера <домена в домене <напрямую доверенное доменное имя>. Это первый сбой. Если проблема продолжается, консолидированные события будут регистрироваться по каждой <частоте журнала событий в минутах> .	Время ожидания Semaphore имеет ненулевое значение. Запросы проверки подлинности завершаются ошибкой.
Netlogon 5817	Netlogon завершился сбоем дополнительных <> запросов на проверку подлинности в последней< частоте журнала событий в минутах.> Время ожидания запросов истекло до их отправки на контроллер домена непосредственно доверенное полное> доменное имя контроллера <домена в домене <напрямую доверенное доменное имя>.	Время ожидания Semaphore имеет ненулевое значение. Запросы проверки подлинности завершаются ошибкой.
Netlogon 5818	Netlogon занял более чем <пороговое значение> предупреждения секунд для запроса проверки подлинности имени пользователя учетной записи <в><< полное доменное доменное имя> домена домена через контроллер домена напрямую доверенное полное> доменное имя контроллера домена в домене< напрямую доверенное доменное имя.> Это первое предупреждение. Если проблема сохраняется, повторяющееся событие будет регистрироваться каждую <частоту журнала событий в минутах> .	Semaphore Waiters имеет ненулевое значение. Запросы проверки подлинности замедляются.
Netlogon 5819	Netlogon занял более чем <пороговое значение> предупреждения в секундах для< подсчета> запросов проверки подлинности через контроллер домена напрямую доверенное полное> доменное имя контроллера <домена в домене< напрямую доверенное доменное имя> в последней< частоте журнала событий в минутах>.	Semaphore Waiters имеет ненулевое значение. Запросы проверки подлинности замедляются.

Примечание.

Идентификатор события Kerberos 7 может указывать на проблему MCA. Событие содержит следующее описание:

Подсистема Kerberos обнаружила сбой проверки PAC. Это означает, что PAC из клиента в области имел PAC, который не проверял или не был изменен. Обратитесь к администратору системы.

Однако ситуации, отличные от проблемы MCA, также могут активировать это событие.

Сведения об изменении частоты ведения журнала и порогового значения предупреждений идентификаторов событий 5816–5819 см. в новых записях журнала событий, отслеживающих задержки и сбои проверки подлинности NTLM в Windows Server 2008 R2.

Дополнительные сведения о журналах и сообщениях об ошибках Netlogon

Если ведение журнала Netlogon включено на сервере, служба Netlogon создает Netlogon.log и Netlogon.bak файлы. Дополнительные сведения см. в разделе "Включение ведения журнала отладки" для службы Netlogon. Сообщения об ошибках и события можно использовать для выявления проблем MCA при их возникновении, чтобы определить, какие контроллеры домена отвечают на запросы проверки подлинности, а также для выявления тенденций в времени возникновения проблем.

Текстовый редактор можно использовать для просмотра файлов журналов. Если доступны Netlogon.bak файлы, просмотрите эти файлы в дополнение к файлам Netlogon.log. При истечении времени ожидания запроса проверки подлинности из-за проблемы MCA отображается шаблон записей журнала, похожих на следующий фрагмент:

06/03 14:16:58 [LOGON] SamLogon: Network logon of <Domain>\User1 from WORKSTATION1 Entered  
06/03 14:17:43 [CRITICAL] <Domain>: NlAllocateClientApi timed out: 0 258  
06/03 14:17:43 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.  
06/03 14:17:43 [LOGON] SamLogon: Network logon of <Domain>\User1 from WORKSTATION1 Returns 0xC000005E  

Первая строка фрагмента записывает запрос проверки подлинности. Вторая строка создается через 45 секунд и документирует время ожидания.

Примечание.

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

Две сообщения об ошибках следуют строке времени ожидания:

• Не удается выделить слот API клиента. Это сообщение является диагностикой проблемы MCA.
• Вход в сеть... Возвращает 0xC000005E. Это сообщение всегда сопровождает предыдущее сообщение. Однако другие проблемы также могут генерировать это сообщение, поэтому он не считается диагностическим.

При возникновении проблемы MCA журнал Netlogon может также записывать события Netlogon (идентификатор события 5816-5819).

Записи журнала, похожие на следующий пример, помогают отслеживать пути, которые запросы проверки подлинности выполняются в системах:

12/25 01:39:03 [PERF] NlSetServerClientSession: Not changing connection (000000000A10FA48): "\\DC01.FAKEDOMAIN.LOCAL"

Где начать поиск проблемы

Аналогично любому узкому месту, среда ( в частности топология домена и сетевая инфраструктура) влияет на то, как сама проблема MCA проявляется. Проблема, возникающая на одном сервере, может вызвать связанные проблемы на других серверах. Наиболее вероятные серверы, имеющие проблемы С MCA, являются контроллерами домена и серверами приложений (интерфейсными или внутренними серверами). Проблемы MCA редки на рабочих станциях.

Примечание.

Если вы знаете пользователя и рабочую станцию, состоящую из проблем с проверкой подлинности, вы также можете просмотреть подробные журналы Netlogon с рабочей станции. Эти журналы могут дать представление о проблеме. Тем не менее, они вряд ли раскрывают первопричину проблемы.

Определение потенциальных путей проверки подлинности и точек chokepoint

Путь проверки подлинности — это путь от одного сервера к следующему, который следует запросу проверки подлинности на основе Netlogon. В целях этого обсуждения сервер приложений сначала получает запрос. Запрос отправляется на контроллер домена, который завершает проверку подлинности и возвращает ответ на сервер приложений. Однако это очень упрощенное представление. Сведения о процессе зависят от инфраструктуры и топологии домена, среди прочего. Этот процесс важен, так как для выявления проблемы MCA необходимо проанализировать данные с каждого сервера приложений и контроллера домена, которые могут обрабатывать запрос проверки подлинности.

Внимание

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

Когда сервер приложений должен пройти проверку подлинности пользователя, сервер приложений сначала пытается связаться с ближайшим контроллером домена (то есть в том же логическом сайте Active Directory). Если на одном сайте нет контроллера домена, сервер приложений отправляет запрос проверки подлинности любому контроллеру домена, доступному в локальном домене. Если пользователь не является членом домена, контроллер домена должен передать запрос. Система использует несколько критериев для определения того, где выполняется следующий запрос:

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

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

Внимание

При использовании службы домен Active Directory (AD DS), интегрированной с DNS, топология сайта AD DS может упростить или усложнить путь проверки подлинности. Записи DNS для контроллеров домена содержат сведения о сайте. Поэтому, когда контроллер домена запрашивает DNS для поиска контроллера домена в целевом домене, он может фактически отправлять два DNS-запроса следующим образом:

• Первый запрос запрашивает список контроллеров домена, принадлежащих тому же сайту AD DS в целевом домене.
• Если первый запрос завершается ошибкой, контроллер домена снова запрашивает список всех контроллеров домена, которые находятся в целевом домене.

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

Дополнительные сведения о том, как Windows направляет запросы проверки подлинности при использовании имен сайтов в нескольких лесах, см. в разделе "Указатель домена" в пределах доверия леса.

Дополнительные сведения о интегрированных с Active Directory DNS см. в разделе "Обзор принципов DNS".

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

Примеры того, как определить пути проверки подлинности и потенциальные точки chokepoint

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

Пример 1. Топология одного леса

Рассмотрим следующую топологию.

Веб-сервер в доменных службах B пользователей из домена C и использует проверку подлинности NTLM. Домен B и домен C находятся в одном лесу. Домен A — это корневой домен леса.

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

1. Веб-сервер получает запрос проверки подлинности, а затем отправляет его на контроллер домена "поблизости" (контроллер домена в том же логическом сайте в домене веб-сервера).

   Если на том же сайте нет контроллера домена, веб-сервер повторно отправляет запрос любому контроллеру домена в домене B.

2. Контроллер домена B домена определяет, что пользователь не входит в домен B и передает запрос проверки подлинности в корневой каталог леса (домен А).

   Опять же, контроллер домена B сначала пытается отправить запрос на контроллер домена на том же сайте, и если это не работает, он отправляет запрос любому доступному контроллеру домена в домене A.

3. Контроллер домена A определяет, что пользователь не принадлежит домену A, но принадлежит домену C в том же лесу. Он отправляет запрос на домен C (контроллер домена одного сайта или любой контроллер домена в домене).

4. Контроллер домена C домена проверяет подлинность пользователя, а затем отправляет ответ проверки подлинности.

5. Чтобы завершить процесс проверки подлинности, ответ перемещается обратно по той же цепочке на веб-сервер в домене B.

В зависимости от топологии сайта следующие серверы являются потенциальными точками чоха.

Сегмент пути	Отправка и получение серверов на одном сайте	Отправка и получение серверов на разных сайтах
1	Веб-сервер Контроллеры домена B домена на сайте	Веб-сервер Все контроллеры домена B
2	Контроллеры домена В домене на сайте	Все контроллеры домена A
3	Контроллеры домена C домена на сайте	Все контроллеры домена C домена

Пример 2. Простая топология двух лесов

Рассмотрим следующую топологию:

Домен A — это корневой домен леса A, а домен D — корневой домен леса B. Домены А и B имеют доверие к лесу.

Домены B и C относятся к лесу A, а домены E и F принадлежат лесу B. Веб-сервер в домене B использует проверку подлинности NTLM для обслуживания пользователей домена E.

Веб-сервер в доменных службах B пользователи из домена E и используют проверку подлинности NTLM. Домен B — это дочерний домен домена A (корень леса) с доменом A, в котором хранится доверие леса с доменом D, который содержит домен E (дочерний домен, содержащий учетные записи пользователей).

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

1. Веб-сервер получает запрос проверки подлинности, а затем отправляет его на контроллер домена "поблизости" (контроллер домена в том же логическом сайте в домене веб-сервера).

   Если на том же сайте нет контроллера домена, веб-сервер повторно отправляет запрос любому контроллеру домена в домене B.

2. Контроллер домена B определяет, что пользователь не входит в домен B. Он передает запрос проверки подлинности в корневой каталог леса (домен А).

   Снова контроллер домена B сначала пытается отправить запрос контроллеру домена на том же сайте. Если это не работает, контроллер домена B отправляет запрос на любой доступный контроллер домена в доменЕ A.

3. Контроллер домена A определяет, что пользователь не принадлежит домену A, и что домен пользователя не находится в лесу A. Он перенаправит запрос проверки подлинности по лесу в домен D (контроллер домена одного сайта или любой контроллер домена в домене).

4. Контроллер домена D определяет, что пользователь не принадлежит домену D, но принадлежит домену E в том же лесу. Он отправляет запрос на домен E (контроллер домена одного сайта или любой контроллер домена в домене).

5. Контроллер домена E проверяет подлинность пользователя, а затем отправляет ответ проверки подлинности.

6. Чтобы завершить процесс проверки подлинности, ответ перемещается обратно по той же цепочке на веб-сервер в домене B.

В зависимости от топологии сайта следующие серверы являются потенциальными точками чоха:

Сегмент пути	Отправка и получение серверов на одном сайте	Отправка и получение серверов на разных сайтах
1	Веб-сервер Контроллеры домена B домена на сайте	Веб-сервер Все контроллеры домена B
2	Контроллеры домена В домене на сайте	Все контроллеры домена A
3	Контроллеры домена D домена на сайте	Все контроллеры домена D
4	Контроллеры домена E на сайте	Все контроллеры домена E

Пример 3. Топология внутреннего или внешнего леса

Рассмотрим следующую топологию.

Домен A и домен D имеют внешнее доверие. Веб-сервер в домене A пользователи из домена D и используют проверку подлинности NTLM.

Примечание.

Это тот же метод, который применяется к ярлыкам доверия.

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

1. Веб-сервер получает запрос проверки подлинности, а затем отправляет его на контроллер домена "поблизости" (контроллер домена в том же логическом сайте в домене веб-сервера). Если на том же сайте нет контроллера домена, веб-сервер повторно отправляет запрос любому контроллеру домена в домене A.

2. Контроллер домена A определяет, что пользователь не принадлежит домену A. Он перенаправит запрос проверки подлинности по внешнему доверию домену D (контроллер домена одного сайта или любой контроллер домена в домене).

3. Контроллер домена D проверяет подлинность пользователя, а затем отправляет ответ проверки подлинности.

4. Чтобы завершить процесс проверки подлинности, ответ перемещается обратно по той же цепочке на веб-сервер в домене A.

В зависимости от топологии сайта следующие серверы являются потенциальными точками чоха.

Сегмент пути	Отправка и получение серверов на одном сайте	Отправка и получение серверов на разных сайтах
1	Веб-сервер Контроллеры домена В домене на сайте	Веб-сервер Все контроллеры домена A
2	Контроллеры домена E на сайте	Все контроллеры домена E

Краткий справочник: потенциальные точки чоха в разных сценариях

В этой таблице рассматриваются возможные точки чоха в более обобщенной области в качестве рекомендаций по поиску. При просмотре таблицы следует помнить, что в конфигурациях внешнего или внутреннего сервера серверы интерфейсных и внутренних приложений являются потенциальными точками останова. Аналогичным образом необходимо собирать данные обо всех членах групп серверов с балансировкой нагрузки.

Сценарии с одним лесом

Примеры сценариев узких мест	Возможные точки чоха (где собирать данные)
Сервер приложений, отправляя учетные данные для пользователей в том же домене Сведения о сценарии: Пользователи в домене B Сервер приложений в домене B Контроллеры домена в домене B	Сервер приложений Контроллер домена из домена B (тот же логический и физический сайт) Контроллер домена из домена B (то же имя логического сайта; возможно, удаленный физический сайт) Контроллер домена из домена B (другое имя логического сайта)
Сервер приложений, отправляющий учетные данные для пользователей в другом доверенном домене (нетрансляционный внешний доверий ИЛИ транзитивное доверие с корнем леса)* Сведения о сценарии: Пользователи в домене A Сервер приложений в домене B Контроллеры домена в домене B Контроллеры домена в домене A	Сервер приложений Контроллер домена из домена B (тот же логический и физический сайт) Контроллер домена из домена B (тот же логический сайт, возможно, удаленный физический сайт) Контроллер домена из домена B (другой логический сайт) Контроллер домена из домена A (то же имя логического сайта) Контроллер домена из домена A (другое имя логического сайта)
Сервер приложений, отправляющий учетные данные для пользователей в другом дочернем домене (в одном лесу) Сведения о сценарии: Пользователи в домене C Сервер приложений в домене B Контроллеры домена в домене B Контроллеры домена в домене C Контроллеры домена в домене A (корень леса)	Сервер приложений Контроллер домена из домена B (тот же физический сайт) Контроллер домена из домена B (тот же логический сайт, возможно, удаленный физический сайт) Контроллер домена из домена B (другой логический сайт) Контроллер домена из домена A (то же имя логического сайта) Контроллер домена из домена A (другое имя логического сайта) Контроллер домена из домена C (то же имя логического сайта) Контроллер домена из домена C (другое имя логического сайта)

* Это сценарий, описанный в примере 2. Простая топология двух лесов.

Сценарии с несколькими лесами

Примеры сценариев узких мест	Возможные точки чоха (где собирать данные)
Сервер приложений в дочернем домене, отправляющий учетные данные для пользователей в корневом каталоге леса в другом лесу (по доверию к лесу) Сведения о сценарии: Пользователи в домене D Сервер приложений в домене B Контроллеры домена в домене B Контроллеры домена в домене A (корень леса) Контроллеры домена в домене D (корневой каталог доверенного леса)	Сервер приложений Контроллер домена из домена B (тот же физический сайт) Контроллер домена из домена B (тот же логический сайт, возможно, удаленный физический сайт) Контроллер домена из домена B (другой логический сайт) Контроллер домена из домена A (то же имя логического сайта) Контроллер домена из домена A (другое имя логического сайта) Контроллер домена из домена D (то же имя логического сайта) Контроллер домена из домена D (другое логическое имя сайта)
Сервер приложений в дочернем домене, отправляющий учетные данные для пользователей в дочернем домене другого леса (по доверию к лесу)* Сведения о сценарии: Пользователи в домене E Сервер приложений в домене B Контроллеры домена в домене B Контроллеры домена в домене A (корень леса) Контроллеры домена в домене D (корневой каталог доверенного леса) Контроллеры домена в домене E (дочерний домен доверенного леса)	Сервер приложений Контроллер домена из домена B (тот же физический сайт) Контроллер домена из домена B (тот же логический сайт, возможно, удаленный физический сайт) Контроллер домена из домена B (другой логический сайт) Контроллер домена из домена A (то же имя логического сайта) Контроллер домена из домена A (другое имя логического сайта) Контроллер домена из домена D (то же имя логического сайта) Контроллер домена из домена D (другое логическое имя сайта) Контроллер домена из домена E (то же имя логического сайта) Контроллер домена из домена E (другое имя логического сайта)
Немного более сложный сценарий... Конфигурация внешнего или внутреннего сервера приложений (например, Microsoft Exchange) в дочернем домене, который отправляет учетные данные для пользователей в дочернем домене другого леса (через доверие к лесу) Сведения о сценарии: Пользователи в домене E Сервер приложений в домене B Контроллеры домена в домене B Контроллеры домена в домене A (корень леса) Контроллеры домена в домене D (корневой каталог доверенного леса) Контроллеры домена в домене E (дочерний домен доверенного леса)	Внешний сервер приложений Сервер сервер внутренних приложений Контроллер домена из домена B (тот же физический сайт) Контроллер домена из домена B (тот же логический сайт, возможно, удаленный физический сайт) Контроллер домена из домена B (другой логический сайт) Контроллер домена из домена A (то же имя логического сайта) Контроллер домена из домена A (другое имя логического сайта) Контроллер домена из домена D (то же имя логического сайта) Контроллер домена из домена D (другое логическое имя сайта) Контроллер домена из домена E (то же имя логического сайта) Контроллер домена из домена E (другое имя логического сайта)

Предварительное расследование: Существует ли проблема MCA?

После того как вы определили потенциальные точки чоха в инфраструктуре, вы можете начать сбор и анализ данных. Первым приоритетом является определение того, существует ли проблема MCA. Позже вы сузите точно, какой сервер (или серверы) имеет проблему.

Внимание

Чтобы собрать данные, включите ведение журнала Netlogon для всех точек chokepoint, которые вы определили в предыдущем разделе. Если у вас есть множество потенциальных точек чоха, просмотрите как этот раздел, так и следующий раздел, сузьте область и определите тенденции.

Чтобы определить проблему MCA, необходимо собирать данные о производительности, пока серверы находятся под тяжелой нагрузкой. Тяжелая нагрузка возникает, когда серверы видят большинство клиентских запросов. Например, в сценарии сервера электронной почты лучшее время для сбора данных о производительности заключается в том, когда пользователи приходят на работу и проверяют свои сообщения электронной почты. Таким образом, необходимо убедиться, что все серверы в данном сценарии проверяют данные о производительности, пока они заняты обслуживанием тяжелых нагрузок.

Быстрая проверка: счетчики производительности и журналы событий

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

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

1. Нажмите кнопку "Пуск", введите regedit и выберите редактор реестра в результатах поиска.

2. Перейдите к следующему подразделу реестра:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\MaxConcurrentApi

3. MaxConcurrentApi Если ключ не существует, можно предположить, что компьютер использует значение по умолчанию дляMaxConcurrentApi. Значения по умолчанию приведены ниже:

   • Контроллеры домена и серверы-члены (Windows Server 2012 и более поздние версии): 10
   • Клиентские компьютеры и рабочие станции (Windows 8 и более поздние версии): 1

Примечание.

Клиентские компьютеры и рабочие станции редко используют значение, превышающее 1.

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

События	Значения счетчиков	Значение
Н/П	Владельцы Semaphore равны параметру MCA на локальном сервере.	Локальный сервер (или другой сервер на том же уровне цепочки проверки подлинности) может иметь проблему MCA.
5816 5817	Время ожидания Semaphore имеет ненулевое значение	Время ожидания проверки подлинности происходит. Локальный сервер может иметь проблему MCA.
5818 5819	Semaphore Waiters имеет ненулевое значение, которое продолжается в течение любого времени –и– Держатели Semaphore имеют значение, которое меньше параметра MCA на локальном сервере	Проблема MCA может существовать на другом сервере в цепочке проверки подлинности.

Быстрая проверка: файлы журнала Netlogon

Чтобы использовать файлы журнала Netlogon для выявления проблемы MCA, выполните поиск по файлам Can't allocate client API slot. Это можно сделать с помощью текстового редактора, например блокнота, скрипта или команд командной строки. Используйте поиск без учета регистра. Если эта строка отображается в файле журнала, возникла проблема С MCA.

Например, если вы сохранили netlogon.log и netlogon.bak в папке c:\temp, откройте окно командной строки и выполните следующие команды:

Find /I "Can't allocate client API slot" c:\temp\netlogon.log > c:\temp\MCA-detect-sample.txt
Find /I "Can't allocate client API slot" c:\temp\netlogon.bak >> c:\temp\MCA-detect-sample.txt

Если файлы журнала содержат строку, файл результатов MCA-detect-sample.txt содержит текст, похожий на следующий фрагмент:

---------- C:\temp\NETLOGON.LOG
[3]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[5]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[7]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[10]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[12]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[17]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[19]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.

Примечание.

В этом фрагменте <домен представляет домен> , который ответил на запрос проверки подлинности.

Если на определенном сервере нет совпадений, выполните поиск по файлам 0xC000005E. Этот код ошибки указывает, что время ожидания запроса проверки подлинности истекло. Это также может указывать на то, что один из других компьютеров, обрабатывающих запрос проверки подлинности, имеет ошибку MCA. Используйте эти сведения, чтобы определить, какие компьютеры следует изучить далее. Если вы работаете с большим количеством серверов, ознакомьтесь со следующим разделом, чтобы сузить область анализа.

Сузьте область и определите тенденции

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

Чтобы эффективно использовать MaxConcurrentApi , необходимо определить конкретные серверы для устранения рисков. В долгосрочной перспективе необходимо понять, почему эти конкретные серверы были перегружены. Используя эти сведения, вы можете улучшить топологию, чтобы она больше не нуждались MaxConcurrentApi в корректировках (описанная в части 3 этой серии).

Примечание.

Вы можете использовать такие приложения, как Блокнот или Microsoft Excel, для сортировки и поиска по файлам журнала.

Ищите такие тенденции, как показано ниже.

• Журналы netlogon включают сообщения о подключении, которые можно использовать для определения того, какие контроллеры домена участвуют в пути проверки подлинности. Такие записи журнала похожи на следующий фрагмент:

  12/25 01:39:03 [PERF] NlSetServerClientSession: Not changing connection (000000000A10FA48): "\\DC01.CONTOSO.LOCAL"
  

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

  Например, предположим, что в журналах сервера приложений находятся Can't allocate client API slot ошибки. Такие ошибки указывают на то, что сам сервер приложений имеет проблему MCA. Дважды проверьте все контроллеры домена, которые сервер приложений пытался связаться. Если сервер приложений является корнем проблемы, скорее всего, контроллеры домена никогда не получали запрос.

• Используйте метки времени в журналах Netlogon и сетевых трассировках (и потенциально счетчиках производительности), чтобы сравнить скорость каждого прыжка в пути проверки подлинности.

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

• Проверьте, какие пользователи затронуты, и когда они затронуты. Все затронутые пользователи из одного домена или леса? Влияет ли проблема только на определенных пользователей или всех пользователей? Имеет ли время дня разницу? Для отслеживания запросов для конкретных пользователей можно использовать записи журнала Netlogon, похожие на следующие фрагменты:

  [8]12/25 07:12:02 [LOGON] SamLogon: Network logon of CONTOSO\User1 from WIN7CLIENT1 Returns 0xC000005E
  

  [3905][29654]12/25 07:16:03 [LOGON] SamLogon: Network logon of CONTOSO\User1 from WIN7CLIENT1 Returns 0xC000005E
  

Пример. Используйте Монитор производительности для поиска проблемы MCA

В качестве примера в реальном мире рассмотрим файл Монитор производительности данных (BLG) с сервера приложений, на котором выполняется СЛУЖБА IIS и FTP, а также предоставляет функциональные возможности файлов и сервера печати. Файл данных запускается через несколько часов после появления проблемы. В этом примере предположим, что сервер, создающий эти данные, является единственным сервером, который находится в среде, которая подозревается в проблеме MCA.

В следующем представлении в Диспетчере производительности показан 110-секундный сегмент данных.

Истекает ли время ожидания запросов проверки подлинности?

Во-первых, используйте данные для счетчика времени ожидания Семафора, чтобы вычислить количество тайм-аутов семафора, которые происходят в течение этого интервала. Этот счетчик является накопительным. Таким образом, значение в начале длительности является минимальным, а значение в конце длительности — максимальное. Вычитание минимального количества времени ожидания из максимального числа тайм-аутов создает значение 22253 времени ожидания в течение этого интервала. Ожидаемое значение для этого счетчика равно нулю. Очевидно, что здесь существует проблема MCA.

Какой объем отложенных запросов?

Просмотрите данные для счетчика Семафор официантов в течение одного интервала. Этот счетчик отслеживает запросы, ожидающие, но еще не истекли. Эта информация может указывать на величину проблемы.

В этом случае во время этого интервала существуют до 2 157 "официантов".

Заключение

Наш пример сервера имеет значительную проблему времени ожидания проверки подлинности. Мы продолжим этот пример в части 2 этой серии, чтобы показать, как вычислить MaxConcurrentApi значение для этого сервера.

Следующие шаги

• Устранение проблем MCA, часть 2. Вычисление и изменение MCA на затронутых компьютерах