none
Exhcange2010 проблема с EMC RRS feed

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

  • Добрый день. С недавних пор поялвилась проблема с подключением к Exchnge 2010.
    Sever 2008 sp2 + Echange 2010Sp2

    В IIS - PowerShell проверка подлинности стоит анонимная, перествлял как WinRM 2.0 так и компонент (Расширение IIS WinRm)

    Не удалось подключиться к http ://test.local.local/powershell с помощью проверки подлинности "Kerberos": Не удалось подключться к удаленному серверу . Сообщение о ошибке: Отказано в доступе. Дополнительные сведения см. в разделе справки......

    9 января 2013 г. 7:52

Все ответы

  • Добрый день.

    Расхождение во времени есть?


    Blog - Smtp25.ru

    9 января 2013 г. 8:00
    Отвечающий
  • Расхождения со временем нет, net time показывает что время синхронизировано с доменом.

    9 января 2013 г. 8:02
  • Что покажет команда:

    netsh winhttp show proxy


    Blog - Smtp25.ru

    9 января 2013 г. 8:10
    Отвечающий
  • C:\Users\Администратор>netsh winhttp show proxy

    Текущие параметры WinHTTP прокси.

        Прямой доступ (без прокси-сервера).

    9 января 2013 г. 8:11
  • Попробуйте запустить скрипт: Resolving WinRM errors and Exchange 2010 Management tools startup failures

    Blog - Smtp25.ru

    9 января 2013 г. 8:13
    Отвечающий
  • Welcome to the Exchange Management Troubleshooter!

    We recommend that you run the troubleshooter after making changes to
    IIS to ensure that connectivity to Exchange Powershell is unaffected.

    Checking IIS Service...

    Checking the Exchange Install Path variable...

    Checking the Powershell Virtual Directory...

    Checking the Powershell vdir SSL setting...

    Checking the Powershell vdir path setting...

    Testing for errors...

    ПОДРОБНО: Connecting to test.local.local


    [test.local.local] Не удалось подключиться к удаленному серверу. Сообщение об ошибке: Отказано в доступе. Дополнительные
        + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExcep
        + FullyQualifiedErrorId : PSSessionOpenFailed
    The Exchange Management Troubleshooter successfully completed connecting to:

    test.local.local

    Failed to connect to any Exchange Server in the current site.

    Problem found:

    Looking for error...

    Unknown Error

    After each error is resolved, close this window and re-run the tool to check for additional problems.

    9 января 2013 г. 8:30
  • Коллеги, еше кто нибудь может подсказать в чом может быть проблема?

    9 января 2013 г. 11:38
  • сервер виртуализирован?

    Blog - Smtp25.ru

    9 января 2013 г. 11:42
    Отвечающий
  • Нет. Под Exchange выделен полностью отдельный сервер так же на платформе server 2008 sp2.
    9 января 2013 г. 11:52
  • С точно такой же ошибкой я боролся недавно.
    Получил я её после переустановки IIS (когда боролся с другой проблемой).

    На этом\моём сервере стояли роли HUB, CAS, MBX.
    Переустановка роли CAS хоть и восстанавливала все каталоги Exchange в IIS, но проблему с PowerShell не решала.

    Проблему решил путём установки SP2 для Exchange Server 2010  (перед обновлением была установлена версия Exchange Server 2010 SP1).

    З.Ы.:
    Скрипт Resolving WinRM errors and Exchange 2010 Management tools startup failures тупо не работал, т.к. не мог подключиться к Exchange (Powershell)

    З.З.Ы.:
    Установка SP считаю решила проблему за счёт того, что Exchange при установке SP по сути был полностью переустановлен, в том числе и виртуальные каталоги Exchnage в IIS, и в том числе и каталог Powershell.

    Кто-нибудь предложит более простой\элегантный способ восстановления работоспособности?


    MCITP





    9 января 2013 г. 13:08
  • Данная проблема у меня появилась еще на exchange 2010 без каких либо сервис паков. Первое что пришло в голову это обновиться до Exchange 2010 sp2 так как при обновлении все компаненты переустанавливаются а именно идет удаление старой версии с последующей установкой Exchange 2010 sp2. Обновление прошло успешно, все службы стартанули, почта заработала, но EMC попрежнему не пускал в консоль управления Exchange2010.
    Еще после обновления был переустановлен IIS в связи с чем в модулях IIS-PowerShell пропал модуль kerbauth, при поиске проблемы пытался создать в ручную но в IIS собстенных модулей под названием kerbauth не было.
    После нескольких часов поиска по форумам была найдена статья по востановлению kerbauth путем редактирования файла C:\Windows\System32\inetsrv\config\applicationHost.config, и добавления в него информации о следующих глобальных модулях
    <globalModules>
                <add name="exppw" image="C:\Program Files\Microsoft\Exchange server\v14\ClientAccess\Owa\auth\exppw.dll" />
                <add name="kerbauth" image="C:\Program Files\\Microsoft\Exchange server\v14\bin\kerbauth.dll" />
                <add name="WSMan" image="%windir%\system32\wsmsvc.dll" />
    После этого добавил в модули IIS-PowerShell модуль kerbauth, Перегрузил сервер в логах ни чего подозрительного не обнаружено, с почтой все в норме но доступа к EMC по прежнему нет((

    9 января 2013 г. 16:22
  • Эти моменты проверяли?

    1. Remote PowerShell uses Kerberos to authenticate the user connecting. IIS implements this Kerberos authentication method via a native module. In IIS Manager, if you go to the PowerShell Virtual Directory and then look at the Modules, you should see Kerbauth listed as a Native Module, with the dll location pointing to C:\Program Files\Microsoft\Exchange Server\v14\Bin\kerbauth.dll. If the Kerbauth module shows up as a Managed module instead of Native, or if the Kerbauth module has been loaded on the Default Web Site level (instead of, or in addition to, the PowerShell virtual directory), you can experience this issue. To correct this, make sure that the Kerbauth module is not enabled on the Default Web Site, but is only enabled on the PowerShell virtual directory. The entry type of "Local" indicates that the Kerbauth module was enabled directly on this level, and not inherited from a parent.

    2. If the WSMan module entry is missing from the global modules section of the C:\Windows\System32\Inetsrv\config\ApplicationHost.config file, as follows:

    <globalModules>
               <add name="WSMan" image="C:\Windows\system32\wsmsvc.dll" />

    This will result in the WSMan module displaying as a Managed module on the PowerShell virtual directory.

    To correct this, make sure that the WSMan module has been registered (but not enabled) at the Server level, and has been enabled on the PowerShell virtual directory.


    Blog - Smtp25.ru

    9 января 2013 г. 16:29
    Отвечающий
  • Да проверил, модуль kerbauth тип собстенный-локальный WSMan аналогично.

    9 января 2013 г. 16:57
  • Попробуйте создать новую учетную запись, затем добавить ее в группу "Organization Management" и запустить консоль из-под нее.

    Blog - Smtp25.ru

    9 января 2013 г. 16:59
    Отвечающий
  • Почему бы просто не переустановить сервер и затем Exchange в режиме восстановления?

    Сазонов Илья http://isazonov.wordpress.com/

    10 января 2013 г. 2:35
    Модератор
  • А если просто удалить Exchange 2010 почистить ad и заново установить?

    10 января 2013 г. 3:51
  • Коллеги, при попытки подключения и создания сайта в exchange 2010 выскочила следующая ошибка.

    Не удалось подключиться к http:// test.local.local с помощью проверки подлинности "Kerberos": Не удалось подключиться к удаленному серверу. Сообщение об ошибке: WinRM не удается обработать запрос. При использовании проверки подлинности Kerberos возникла ошибка: Не найден сетевой путь. 
     Возможные причины:
      - Указаны неверные имя пользователя или пароль.
      - При отсутствии заданного метода проверки подлинности и имени пользователя используется проверка подлинности Kerberos.
      - Kerberos принимает имена пользователей домена, но не принимает имена локальных пользователей.
      - Имя участника-службы для имени и порта удаленного компьютера не существует.
      - Компьютер клиента и удаленный компьютер находятся в разных доменах, между которыми отсутствует доверительное отношение.
     После проверки указанных выше проблем попробуйте выполнить следующее:
      - Просмотрите в средстве "Просмотр событий" события, относящиеся к проверке подлинности.
     -Измените метод проверки подлинности, добавьте компьютер назначения к значениям параметра конфигурации TrustedHosts для WinRM либо воспользуйтесь транспортом HTTPS.
     Помните о том, что в списке TrustedHosts компьютеры могут находиться без проверки подлинности.
      Чтобы получить дополнительные сведения о настройке WinRM, выполните следующую команду: winrm help config. Дополнительные сведения см. в разделе справки, вызываемом командой about_Remote_Troubleshooting.

    10 января 2013 г. 10:13
  • Запускаете консоль с самого сервера?

    Причиной может быть (ключевая часть ошибки "Не найден сетевой путь"):

    1. firewall

    2. остановлен IIS (служба, сайт, application pool)

    3. маршрутизация в сети

    4. dns

    И лучше было бы новую ветку создать с вашим вопросом - так больше шансов получить ответ.


    Blog - Smtp25.ru

    10 января 2013 г. 10:26
    Отвечающий
  • Уважаемый пользователь!
    В вашей теме отсутствует активность в течение последних 5 дней. При отсутствии каких-либо действий в течение 2 последующих дней, тема будет переведена в разряд обсуждений. Вы можете возобновить дискуссию, просто оставив сообщение в данной теме.

    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий

    24 января 2013 г. 13:33
  • Тема переведена в разряд обсуждений по причине отсутствия активности

    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий

    5 февраля 2013 г. 12:05