Ошибка 4113 MSExchange ADAccess появлялась всего пару раз в течение последних суток и заставила обратить на себя внимание из-за уж очень страшного описания. Какой-то закономерности её проявления выявить не удалось, а потом интересно было разобраться откуда она взялась, к тому же заглавные буквы AD явно намекали на связь с Active Directory.
Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики – Exchange 2013 — Установка, настройка, администрирование.
Устранение ошибки 4113 MSExchange ADAccess
Для начала небольшая диагностическая информация. Полный текст ошибки выглядел следующим образом:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
Процесс powershell.exe (PID=8880). Компонент: Microsoft.Exchange.Data.Directory.ConfigurationSettingsADNotificationException: Ошибка при запуске операции AD. ---> Microsoft.Exchange.Data.Directory.ADTopologyUnexpectedException: Непредвиденная ошибка при вызове службы топологии Active Directory Microsoft Exchange на сервере "TopologyClientTcpEndpoint (localhost)". Сведения об ошибке: Отказано в доступе.. ---> System.ServiceModel.Security.SecurityAccessDeniedException: Отказано в доступе. Server stack trace: в System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter) в System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc) в System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) в System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) в System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message) Exception rethrown at [0]: в System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) в System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) в Microsoft.Exchange.Data.Directory.TopologyDiscovery.ITopologyClient.GetServersForRole(String partitionFqdn, List`1 currentlyUsedServers, ADServerRole role, Int32 serversRequested, Boolean forestWideAffinityRequested) в Microsoft.Exchange.Data.Directory.ServiceTopologyProvider.<>c__DisplayClass10.<InternalServiceProviderGetServersForRole>b__f(IPooledServiceProxy`1 proxy) в Microsoft.Exchange.Net.ServiceProxyPool`1.TryCallServiceWithRetry(Action`1 action, String debugMessage, WCFConnectionStateTuple proxyToUse, Int32 numberOfRetries, Boolean doNotReturnProxyOnSuccess, Exception& exception) --- Конец трассировки внутреннего стека исключений --- в Microsoft.Exchange.Data.Directory.ServiceTopologyProvider.GetConfigDCInfo(String partitionFqdn, Boolean throwOnFailure) в Microsoft.Exchange.Data.Directory.TopologyProvider.PopulateConfigNamingContexts(String partitionFqdn) в Microsoft.Exchange.Data.Directory.TopologyProvider.GetConfigurationNamingContext(String partitionFqdn) в Microsoft.Exchange.Data.Directory.SystemConfiguration.ADSystemConfigurationSession.GetRootOrgContainer(String partitionFqdn, String domainController, NetworkCredential credential) в Microsoft.Exchange.Data.Directory.SystemConfiguration.ConfigurationSettings.ADConfigDriver.<>c__DisplayClass2.<LoadSettings>b__0() в Microsoft.Exchange.Data.Directory.ADNotificationAdapter.RunADOperation(ADOperation adOperation, Int32 retryCount) в Microsoft.Exchange.Data.Directory.ADNotificationAdapter.TryRunADOperation(ADOperation adOperation, Int32 retryCount) --- Конец трассировки внутреннего стека исключений ---. Не удается загрузить параметры приложения. Исключение: "%4" |
Скриншот:
На официальных ресурсах 1 причину возникновения проблемы описали как установка обновления (CU) без предварительного выполнения команды /PrepareAD. Это был явно не мой случай, поскольку обновления я не ставил в последние полгода точно и ошибка ранее не появлялась.
Причина 2 проблемы оказалась банальной до смешного – оболочка Exchange Management Shell была запущена без прав администратора.
После принудительного запуска с правами админа (правой кнопкой на ярлыке – запустить с правами администратора) ошибка в журнале событий появляться перестала. Тем не менее все равно странно, что она вообще имела место быть, ведь по умолчанию EMS и так запускается с правами админа.
Notes:
