none
нет подключения к локальному серверу exchange с помощью ems, так же нет подключения с помощью powershell и web RRS feed

  • Общие обсуждения

  • пару слов о том, что имею:

    когда то в компании было два dc. был отдельно exchange 2010. позже убрали один из dc и после чего был потерян доступ к серверу exchange с помощью ems, powershell и web. При этом почта в компании работает.

    при подключении ошибка - не удалось подключиться к http://nameserv.local/powershell с помощью kerberos. отказано в доступе.

    EMTshooter указывает эту же ошибку.

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

    помогите восстановить подключение к exchange!))

    подскачите с чего нужно начать, чтоб сбрать больше инфы о текущем состоянии сервера и выяснить в чем дело?

    15 августа 2019 г. 10:47

Все ответы

  • Добрый день.
    Время корректно синхронизировано в домене между сервером Exchange и контроллерами домена?
    15 августа 2019 г. 10:49
  • Добрый день!

    время синхронизировано. ошибка все та же.

    подскажите , что еще можно проверить или настроить?

    • Изменено mezhi 15 августа 2019 г. 10:58
    15 августа 2019 г. 10:55
  • В сетевых настройках посмотрите какие DNS указаны.
    15 августа 2019 г. 10:58
  • если я правильно Вас понял, это в настройках сет адаптера -> протокол ip4 -> предпочитаемый DNS - установлен верный ip.

    В чем еще может быть дело?

    можете мне подсказать как проверить работостпособность трех вещей:

    1 - возможно проблемы изза отсутствия каких то прав доступа пользователя?

    2- возмодно чтото с сертификатом (-ми).?

    3- может чтото нужно проверить в IIS?

    когда проверял (изучал) IIS то обнаружил , что в виртупльном каталоге powershell сайта dafault web site не могу просмотреть модули (там я хочу просмотреть вкличены ли модули kerbauth и wsman). получаю ошибку, что в конф файле /exchangeserv/v14/clientaccess/pwershell/web.config ошибка в строке 30 и "ощибка:раздел конфигурации нельзя установить под приложением". ОК! в этом файле в 30 строке открывается тег <modules>. не понимаю в чем проблема! этот конф файл я не правил

    • Изменено mezhi 15 августа 2019 г. 11:25 дополнил
    15 августа 2019 г. 11:11
  • Добрый день!

    время синхронизировано. ошибка все та же.

    подскажите , что еще можно проверить или настроить?

    Прежде всего - журнал событий: включить, если не включен, аудит неудачных попыток входа в систему (делается через политику - локальную или групповую) и смотреть ошибку в журнале Безопасность; включить лог событий Kerberos (https://support.microsoft.com/en-us/help/262177/how-to-enable-kerberos-event-logging) и смотреть наличие ошибок Kerberos в журнале Системы.

    Далее - как убрали второй контроллер домена: штатно понизили до рядового сервера без каких либо происшествий или что-то было нештатное?

    PS И, на всякий случай, проверьте членство учетной записи, под которой входите, в группе 'Organization Management' (это одна из групп безопасности MS Exchange, соответствующих одноименным ролевым группам)


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


    • Изменено M.V.V. _ 15 августа 2019 г. 11:23
    15 августа 2019 г. 11:22

  • 1. логирование kerberos сделал (через реестр, как подсказали). я только не знаю в какой ветви просмотреть события связанные с kerberos(( Есть Журнал Windiws и Журнал приложений и служб. чтобы понять какой журнал за что отвечает я прочитал их описание. из описания я так и не понял где просматривать события связанные с kerberos? в каком журнале из двух? и еще, как спровоцировать Kerberos на создание события? достаточно ли для этого опять попробовать подключиться к локальному excahnge serv через ems или powershell?

    2. второй dc, как мне сказали, убоали штатно, без происшествий. 
    немного обьясню, что произошло: Было dc1 - ip 10.10.10.11, был dc2 - 10.10.10.12. Стало: dc1 - ip 10.10.10.12. Зачем так делолсь - не знаю)
    Изза этого Ваш вопрос навел меня на мысль: возможно ли , что службы , связяанные с exchange server, обращаются к несуществующему dc (dc2)? возможно я предполагаю бред, но не камняйтесь бросами)))

    3. доменный пользователь под которым я зашел на exchange (он же администратор) состоит в группе organization managment.

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

    спасибо за отклик



    • Изменено mezhi 15 августа 2019 г. 12:48
    15 августа 2019 г. 12:36
  • 1. Те журналы, которые я упомянул - они оба в ветке Журналы Windows

    2. Возможно, но в вашем случае - вряд ли, т.к. иначе бы были проблемы с работой почты. Контроллеры домена, которые видит Exchange, фиксируются в журнали событий Приложение (в той же ветке), в событии с источником MSExchangeDSAccess и ID события 2080, подробно оно описано в MS KB: https://support.microsoft.com/en-us/help/316300/event-id-2080-from-msexchangedsaccess


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

    15 августа 2019 г. 12:56

  • 1. да, точно. в журнале безопасность ошибок нет. в журнале система (по поводу kreberos) есть следующие ошибки:
    уровень                        источник                  код события                  категория задачи

    ошибка              SEcurity-Kreberos                     3                                 отсутствует        
    ошиька               windows remote management    10153                     отсутсвует          (их много)


    • Изменено mezhi 15 августа 2019 г. 14:45
    15 августа 2019 г. 13:41
  • Посмотрите ещё эти статьи:

    link1

    link2

    15 августа 2019 г. 14:27
  • и так!

    Благодаря Вам я знаю следующее:

    в журнале событий (подраздел система) регитсрируются следующие события (ошибки):

    1. (kerberos) 

    В сеансе входа в систему DOMAIN.LOCAL\exchangeserv$
    Код ошибки: 0x19 KDC_ERR_PREAUTH_REQUIRE
    Область сервера: DOMAIN.LOCAL
    Имя сервера: krbtgt/DOMAIN.LOCAL Имя целевого объекта: krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL

    так же есть еще одна :

    В сеансе входа в систему 
    Код ошибки: 0x19 KDC_ERR_BADOPTION
    Область сервера: DOMAIN.LOCAL
    Имя сервера: krbtgt/DOMAIN.LOCAL Имя целевого объекта: krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL

    2.(windows remote management) модулю IIS WSMan не удалось считать конфигурацию. Была получена ошибка - 2144108477:%%-2144108477. xml-файл конфигурации не действителен. Не найден xml-элемент "Plugin", который должен пристутствовать.
      Действие пользователя:
      Убедитесь, что файлы схемы и проверки присутствуют и действительны.

    подскажите, что нужно сделать в соостветствии с последней рекомендацией события windows remote management??



    • Изменено mezhi 15 августа 2019 г. 15:06
    15 августа 2019 г. 14:57
  • я кое что обнаружил у себя! в виртуальной директории IIS exchange в разделе Параметры SSL было установлено Не требовать ssl. Изменил на Требовать SSL (принимать).

    тепрь при одключении через ems к локальному exchange или через powershell возникает следующая ошибка :

    не удалось подключиться к http//server.domain.local/pwoershell с помощю проверки подлинности kerberos. сообщение об ошибке: клиент WinRM получил код состояния http 403 от удаленной службы WS-Management. 

    теперь в журнале слбытий возникает ошибка от security-Kerberos: KDC_ERR_S_PRINCIPAL_UNKNOWN

    таки дела))

    подскажите, что нужно сделать или исправить?
    напомню, все так же в IIS виртуального каталога powershell не могу получить доступ к модулям.


    15 августа 2019 г. 15:56
  • 1. По Kerberos: эти ошибки - шум. Они ожидаемы и их можно игнорировать.

    2. А вот второе - это, похоже на источник проблемы.

    В нормальной установке в каталоге приложения /Powershell в файле web.config (он имеет формат XML)должно быть примерно такое содержимое (внутри элемента <configuration>, у меня оно - почти в начале файла,  сразу после элемента <appSettings>, впрочем, оно может быть и ниже, главное - между <configuration> и </configuration>):

      <system.webServer>
        <system.management.wsmanagement.config>
          <PluginModules>
            <OperationsPlugins>
              <Plugin Name="PowerShellplugin" Filename="%windir%\system32\pwrshplugin.dll" SDKVersion="1" XmlRenderingType="text">
                <Resources>
                  <Resource ResourceUri="http://schemas.microsoft.com/powershell/Microsoft.Exchange" SupportsOptions="true">
                    <Capability Type="Shell" />
                  </Resource>
                </Resources>
                <InitializationParameters>
                  <Param Name="PSVersion" Value="2.0" />
                  <Param Name="ApplicationBase" Value="%ExchangeInstallPath%Bin" />
                  <Param Name="AssemblyName" Value="Microsoft.Exchange.Configuration.ObjectModel.dll" />
                  <Param Name="PSSessionConfigurationTypeName" Value="Microsoft.Exchange.Configuration.Authorization.ExchangeAuthorizationPlugin" />
                  <Param Name="PSMaximumReceivedObjectSizeMB" Value="75" />
                  <Param Name="PSMaximumReceivedDataSizePerCommandMB" Value="500" />
                </InitializationParameters>
              </Plugin>                   
            </OperationsPlugins>
            <AuthorizationPlugin Name="Microsoft.Exchange.AuthorizationPlugin" Filename="%ExchangeInstallPath%Bin\Microsoft.Exchange.AuthorizationPlugin.dll" SDKVersion="1" SupportsQuota="true" />
          </PluginModules>
          <OperationsConfiguration MaxOperationTimeoutSeconds="900" MaxShellIdleTimeoutMinutes="15"/>
        </system.management.wsmanagement.config>
        <modules>
          <add name="CertificateAuthModule" type="Microsoft.Exchange.Configuration.CertificateAuthentication.CertificateAuthenticationModule" />
          <add name="EMCVersionBlockerModule" type="Microsoft.Exchange.Configuration.RedirectionModule.EMCVersionBlockerModule" />
          <add name="kerbauth" />
          <add name="WSMan" />
          <add name="ErrorReportingModule" type="Microsoft.Exchange.Configuration.RedirectionModule.ErrorReportingModule" />
        </modules>
      </system.webServer>
    Проверьте, чего у вас там не хватает: похоже, ругается именно на тамошнее содержимое.


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


    • Изменено M.V.V. _ 15 августа 2019 г. 16:44
    15 августа 2019 г. 16:35
  • M.V.V. по поводу файла web.config ...

    так и есть - ругается. ругань я обнаруживаю при попытке просмотреть раздел "модули" в диспетчере служб IIS виртуального каталога pwoershell. В сообщени об ошибке (..его ругани) указано , что "раздел конфигурации нельзя установаить под приложением" и указывает на номер строки - 30 строка, в моем случае строка 30 указывает на открытие тега <modules>.

    как исправить эту проблему не знаю. если есть идеи - подскажите пожалуйста.

    16 августа 2019 г. 13:51
  • я кое что обнаружил у себя! в виртуальной директории IIS exchange в разделе Параметры SSL было установлено Не требовать ssl. Изменил на Требовать SSL (принимать).


    Снимите галку Требовать SSL обратно - она там не нужна.

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

    16 августа 2019 г. 14:01
  • Покажите начало файла web.config - например, до этой самой 30-й строки. Подозреваю, что там не закрыт элемент <appSettings>

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

    16 августа 2019 г. 14:03
  • теперь я отвечу на рекомендации , данные мне в другом разделе. обсуждение по ссылке https://social.technet.microsoft.com/Forums/ru-RU/53a091ea-8652-4d36-8062-712a58afb5ed/exchange-2010-107810911088108510721083?forum=exchange2010ru продолжаться тут.

    отвечаю на Oleg.Kovalenco:

    netdom query fsmo

    хозяин схемы                          DC1.mydomain.local
    хозяин именования доменов 
    DC1.mydomain.local
    PDC                                         
    DC1.mydomain.local
    Диспетчер пула RID                
    DC1.mydomain.local
    хозяин инфраструктуры         
    DC1.mydomain.local
    ком выполнена успешно.

    тут все гуд. в моем домене дейстительно есть DC1.mydomain.local и он единственный DC.

    потом почитав о том, что бывает аварийное завершение какого нибудь сервера DC ,без переноса ролей FSMO я проверил журнал событий на DC1 и нашел постоянную ошибку "ошибка репликации AD 1722. Сервер RPC не доступен". 

    Таким образом я решил для себя , что репликация не завершена и перенос ролей FSMO не завершен. Видимо когда то действительно был DC2 или скорее DC (именно DC появляется в ошибках связанных с топологией, репликацией, и dns)и его просто отключили.

    стал решать проблему согласно https://support.microsoft.com/ru-ru/help/2102154/active-directory-replication-error-1722-the-rpc-server-is-unavailable . дойдя до пункта 3 проверил следующее:

    > dcdiag /test:dns /v /e /d /c
    В разделе GLOBAL было обнаружно два сервера : DC1 и DC. DC.mydomain.local у меня в комапнии нет!!! 
    так же было указано, что DC.sdfdsf.local недоступен.

    зашел в AD на единственном моем DC - DС1.mydomain.local : корень -> AD пользовавтели и компьютеры -> mydomain.local -> Domain Controllers: тут я обнаружил две записи :DC1 и DC.

    при этом в колонке "тип контроллера домена" для DC(.mydomain.local) указано - "DC", я предполагаю - это Domain Controller.
    а в колонке "тип контроллера домена" для DC1(.mydomain.local) указано - "GC", я предполагаю - это Global Catalog.

    предполпгаю, что нужно совместить эти свойства для DC1, а DC - уничтожить.

    далее...

    если зайти в свойства каждого -> общие -> (внизу) параметры NTDS -> подключения то:
    (для свойств DC): источник репликации - DC1. Реплицировать в - DC1.
    (для свойств DC1): источник репликации - DC. Реплицировать в - DC.

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

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

    Из этого ВОПРОСЫ:

    1. могу ли я удалить запись "DC" в контейнере Doamins Controllers просто так (пр.к.м. - удалить)?
    2. как изменить записи для свойства "DC1" по пути : свойтсва DC1  -> общие -> (внизу) параметры NTDS -> подключения -> источник репликации?
                                         -> реплицировать в?

    отвечаю на рекомендациюM.V.V.:
    мйо Echange не имеет статической привязки к какомунибудь DC. Об этом говоит вывод команды powershell:

    >Get-exchangeServer -status |FL
                   ......

    StaticDomainControllers                          :    <>               (так и указано '<>')
    StaticGlobalCatalogs                               :    <>
    StaticConfigDomainController                 :            
    StaticExcludedConfigDomainControllers  :    <>
    CurrentDomainControllers                       :   <DC1.mydomain.local>
    CurrentGlobalCatalogs                            :   <DC1.mydomain.local>
    CurrentConfigDomainController               :  <DC1.mydomain.local>

                      ........

    при этом в остальных параметрах вывода этой команды сервер DC.mydomain.local нигде не фигурирует.

    как я вижу дальнейшее решение моей глобальной проблемы:

    -устраняю конфликт изза записи DC.mydomain.local
    -далее, возможно, это поможет дореплицироваться (изза существующей ошибки на DC1 - ошибка репликации 1722.недоступен сервер RPC) или вообще отменить репликацию
    -проверяю функционирование ролей FSMO на моем единственном DC1
    -далее, решить проблему с доступом к разделу "модули" виртуального каталога powershell
    -возможно это даст возможность получить доступ к Консоли управления Exchange (EMS), либо выдаст новую ошибку.

    помогите советом или поделитесь опытом.)))



    • Изменено mezhi 16 августа 2019 г. 15:30
    16 августа 2019 г. 15:16
  • Посмотрите ещё эти статьи:

    link1

    link2

    link2 - нет огрничения. тут все норм.

    link1 - побоялся это делать, так как сейчас хоть я и не имею доступа к EMS, но почта в компании работает. Боюсь, что если я удалю этот ключ реестра, то потеряю работающую почту.

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


    16 августа 2019 г. 16:15
  • Возможно у вас была потеря DC, без удаления остатков из DC1.

    Перед удалением и возможной чисткой, сделайте full бекап вашего доменного контроллера, и отдельно backup AD.

    AD Forest Recovery - Backing up a full server

    How to remove completely orphaned Domain Controller

    Clean up Active Directory Domain Controller server metadata

    Exchange у вас не привязан к контроллеру домена.

    В настройках сетевого интерфейса Exchange проверил настройки DNS, а вдруг там старый IP старого DNS.

    По проблеме с Kerberos. Делать в не бизнес время.

    1. В CMD от имени администратора

    netsh winhttp show proxy

    netsh winhttp reset proxy

    iisreset /noforce

    2 Exchange 2010: Unable to open Exchange Management Console – Initialization Failed

    iisreset /noforce


    MCITP, MCSE. Regards, Oleg

    16 августа 2019 г. 16:29
    Модератор
  • Многие симптомы говорят о том, что второй dc (DC) не был удален штатно, вопреки тому, что вам сказали. Поэтому, если он реально не функционирует, просто удалите его учетную запись из OU Domain Controllers - в современных версиях Windows Server этого достаточно, чтобы все ссылки в AD на этот DC были удалены корректно. После этого можно ещё проверить в DNS, не осталось ли следов от DC.

    PS После этого никакой репликации быть больше не должно, ошибок репликации - тоже. Может быть, и доступ к Powershell после этого починится, это надо проверить.


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

    16 августа 2019 г. 16:47
  • строка 30, на которую идет ругань начинаетрся с тега <modules>:

    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
      <appSettings>
        <add key="PSLanguageMode" value="RestrictedLanguage"/>
      </appSettings>
      <system.webServer>
        <system.management.wsmanagement.config>
          <PluginModules>
            <OperationsPlugins>
              <Plugin Name="PowerShellplugin" Filename="%windir%\system32\pwrshplugin.dll" SDKVersion="1" XmlRenderingType="text">
                <Resources>
                  <Resource ResourceUri="http://schemas.microsoft.com/powershell/Microsoft.Exchange" SupportsOptions="true">
                    <Capability Type="Shell" />
                  </Resource>
                </Resources>
                <InitializationParameters>
                  <Param Name="PSVersion" Value="2.0" />
                  <Param Name="ApplicationBase" Value="%ExchangeInstallPath%Bin" />
                  <Param Name="AssemblyName" Value="Microsoft.Exchange.Configuration.ObjectModel.dll" />
                  <Param Name="PSSessionConfigurationTypeName" Value="Microsoft.Exchange.Configuration.Authorization.ExchangeAuthorizationPlugin" />
                  <Param Name="PSMaximumReceivedObjectSizeMB" Value="75" />
                  <Param Name="PSMaximumReceivedDataSizePerCommandMB" Value="500" />
                </InitializationParameters>
              </Plugin>                   
            </OperationsPlugins>
            <AuthorizationPlugin Name="Microsoft.Exchange.AuthorizationPlugin" Filename="%ExchangeInstallPath%Bin\Microsoft.Exchange.AuthorizationPlugin.dll" SDKVersion="1" SupportsQuota="true" />
          </PluginModules>
          <OperationsConfiguration MaxOperationTimeoutSeconds="900" MaxShellIdleTimeoutMinutes="15"/>
        </system.management.wsmanagement.config>
        <modules> (на эут строку ругается)
          <add name="CertificateAuthModule" type="Microsoft.Exchange.Configuration.CertificateAuthentication.CertificateAuthenticationModule" />
          <add name="EMCVersionBlockerModule" type="Microsoft.Exchange.Configuration.RedirectionModule.EMCVersionBlockerModule" />
          <add name="kerbauth" />
          <add name="WSMan" />
          <add name="ErrorReportingModule" type="Microsoft.Exchange.Configuration.RedirectionModule.ErrorReportingModule" />
        </modules>

    в появляющемся сообщении говориться "раздел конфигурации нельзя установаить под приложением". строка - 30.

    напомню, это происходит в диспетчере iis в виртуальном каталоге powershell при попытке просмотреть раздел "модули".

    как вы думаете в чем может быть дело?

    19 августа 2019 г. 13:06
  • Текст ошибки "раздел конфигурации нельзя установить под приложением"  в переводе на язык оригинала (http://unlocalize.com/ru/70512_Configuration-section-not-allowed-to-be-set-below-application.html) означает, что в вышестоящем по иерархии файле конфигурации  заблокирована установка элемента (раздела)<modules> в файле конфигурации приложения.  Вышележащие файлы конфигураци - это файл C:\windows\system32\inetsrv\config\applicationHost.config и web.config в корне сайта Default Web Site (C:\inetpub/wwwroot по умолчанию)

    В чистой установке Exchange 2010 в корне  Default Web Site файла конфигурации быть не должно, а в applicationHost.config разрешение для изменения раздела <modules> в файлах web.config включено (кроме разрешения удалять ряд модулей) на глобальном уровне:

     <location path="" overrideMode="Allow">
       <system.webServer>
         ...
         <modules>
           <add name="HttpCacheModule" lockItem="true" />
           ...
         </modules>
       </system.webServer>

    и далее нигде в других элементах <location> не переопределяется.

    То есть, ошибка ваша говорит о том, что какой-то из вышележащих файлов конфигурации кем-то или чем-то переписан. Можете проверить это по приведенной выше информации.

    Если у вас действительно кем-то или чем-то перезаписан файл applicationHost.config, то что с этим делать на практике, я даже не знаю (в теории-то его, конечно, можно поправить вручную). Единственный надежный способ, известный мне - установка сервера Exchange в режиме восстановления (setup /mode:recoverserver) на другом сервере (или на этом же, но очищенном от существующей установки Exchange) с последующим восстановлением баз данных (для создания резервной копии баз данных можно даже просто скопировать содержимое файлы БД  (*.edb)после остановки Exchange Information Store, но там тоже есть тонкости). Менее надежный способ - взять applicationHost.config с чистой установки Exchange и сравнить его с тем, что у вас есть, а что не так - подправить.

    В связи с этим, есть пара вопросов по вашему Exchange:

    1. У вас именно Exchange 2010, а не SBS 2011?

    2. Стоят ли какие-либо ещё web-приложения на этом сервере?

    PS Документацию, как можно заблокировать элементы конфигурации на вышележащем уровне см. https://docs.microsoft.com/en-us/iis/get-started/planning-for-security/how-to-use-locking-in-iis-configuration

    PPS Есть кое-что, что я не понимаю. При удалении КД конфигурация IIS на Exchange сама поменяться никак не могла, так что оно либо как-то работало до этого (просто никто не интересовался как), либо кто-то что-то сделал с Exchange кроме удаления КД. Без знания истории того, что у вас там происходило, понять это невозможно.

    И, кстати, очистка AD от следов удаленного КД (о чем я писал раньше) - не помогла ли она решить проблему с подключением EMC/EMS к Exchange?


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


    • Изменено M.V.V. _ 19 августа 2019 г. 15:42
    19 августа 2019 г. 15:38
  • добрый день! 

    спсибо за ответы!!

    сегодня просмотрю вышележащие конфигурационные файлы и сверю их с дефолтными. спасибо.

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

    единственное, что я еще не проверил по Вашим рекомендациям, это команда iisreset /noforce...

    мне не понятны несколько вещей:

    1. не прекратиться ли функционирование почты (напомню, что у меня не работает лишь подключение к локальному серверу exchange через ems, а почта при этом раотает)изза рестрата службы iis?

    2. о рестарте на каком сервере вы вели речь: на exchange или на dc?

    благодарю за ответы и жду ваших рекомендаций

    20 августа 2019 г. 13:03
  • Смыла рестартовать IIS (естественно, на Exchange) до разбирательства с файлами его конфигурации я не вижу. А что до работы почты, то в Exch2010 и клиентах Outlook внутри локальной сети либо клиентах POP3/IMAP она слабо связана с IIS: только через автоконфигурацию, загрузку автономной адресной книги (OAB) и дополнительные функции Outlook (автоответы, календарная информация и т.д.)

    И уточните, я правильно понимаю, что:

    1. Доступ к управлению Exchange у вас после удаления мертвого DC не восстановился.

    2. Exchange у вас обычный (Standard или Enterprise)

    3. Никаких других программ, использующих IIS, у вас на сервере Exchange не установлено


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

    20 августа 2019 г. 13:27
  • 1, доступ к упрвлению exchange после удаления (и чистки метаданных) мертвого DC не появился  (не удалось подключиться с помощью проверки подлинности Kerberos. сообщение об ошибке:Отказано в доступе. Дополнитеьлные сведения см. всправке через командду about_troubleshooting)

    2. echange 2010 standart v.14.02.0247

    3.никакие программы службу IIS не используют. на этом сервере стоит только Kaspresky и Exchange.

    20 августа 2019 г. 15:28
  • Возможно эта статья вам подскажет.

    Нет в теме полной копии ошибки, что затрудняет идентификацию проблемы.

    Exchange 2010: Unable to open Exchange Management Console – Initialization Failed

    Перед удалением реестра не забудьте сделать бекап этой ветки.

    Примеры ошибок и их решения.

    Troubleshooting the Exchange Management Shell

    Exchange 2010 Management Console not opening – Initialization failed


    MCITP, MCSE. Regards, Oleg

    20 августа 2019 г. 16:23
    Модератор
  • после удаления парамера из реестра изменилась ошибка при попытке подкоючения к emc

    привожу пример из ems (в emc ошибка аналогичная)

    ПОДРОБНО: Подключение к exchangeserv.cstp.local
    [exchangeserv.cstp.local] Не удалось подключиться к удаленному серверу. Сообщение об ошибке: Клиенту WinRM не удается о
    бработать запрос. Невозможно определить тип содержимого ответа HTTP от компьютера назначения. Тип содержимого не являет
    ся допустимым или отсутствует. Дополнительные сведения см. в разделе справки, вызываемом командой about_Remote_Troubles
    hooting.
        + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExc
       eption
        + FullyQualifiedErrorId : PSSessionOpenFailed

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

    но от Вас я все так же жду помощи и рекомендаций.

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


    20 августа 2019 г. 17:05