none
переезд клиентов с 2010 на 2013 RRS feed

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

  • В организации развернут Exchnage 2010. Была поставлена задача обновить инфраструктуру до Exchnage 2013 в режиме DAG. Развернул. Начал тестовую работу по отладке + проверки работы. Был куплен wild сертификат * В организации остался в работе Echange 2010 (назовем его exch2010) + два сервера 2013 (exch2013). 
    Клиентские базы переброшены на новый сервер exch2013.

    На клиентах которые внутри домена все встало отлично , все работает. Но есть проблемы с клиентами регионалами в чем суть проблемы.

    1. Клиенты подключаются к сети через технологию VPN (UAG) 

    2. связь между серверами и клиентом не чем не фильтруется

    3. ЭТО ВАЖНО Клиентская машина не входит в домен. 

    4. Использует Outlook 2010 (все обновления актуальные (за этим следит UAG)) 

    ... 
    Клиентов подключаем через Exchnage (настройки outlook)
    В настройках в вкладке подключения указываю прокси сервер и проверку подлинности NTLM (на сервере она выставлена именно эта) 

    Имя резолится и клиент находи авторизацию...(для меня не понятно почему в качетве сервера он подставляет старый сервер exch2010, а не новый) подставляет пользователя. Но при открытии outlook 

    не удается запустить приложение MIcrosoft outlook. Невозможно открыть окно Outlook. Невозможно открыть набор папок. Сервер Microsfot Exchnage Outlook недоступен. Либо имеются проблемы с сетью, либо сервер Exchnage отключен на время обслуживания.
    

    Мне бы понять, чего делать тут или хотя бы намекните какие логи и где поглядеть , чтобы хоть как-то нащупать пути к решению.  

    19 января 2015 г. 7:31

Все ответы

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

    Логи поглядеть и нащупать, в чем проблема можно тут:

    aka.ms/rca

    "...(для меня не понятно почему в качетве сервера он подставляет старый сервер exch2010, а не новый)"

    А ящик-то при этом где клиентский, на 2010 все-таки остается? Тогда вполне логично, что 2013 сервер смотрит, где расположен ящик и перенаправляет Ваш запрос.

    Проверьте по чеклисту, что среда развернута правильно.

    19 января 2015 г. 7:49
  • Добрый день.

    во что у вас резолвится autodiscover.domain.name с недоменных компов?


    Blog - Smtp25.ru
    Полезные ссылки - Links

    19 января 2015 г. 7:55
    Отвечающий
  • Спасибо за быстрый ответ.
    Ящик текущего пользователя находятся на новых 2013 серверах. 

    По чеклисту - пробегаюсь ... 
    19 января 2015 г. 7:55
  • autodiscover.domain.name 
    резолится новый 2013 сервер
    19 января 2015 г. 8:08
  • Доброго дня,

    Это проблема с сертификатами, похоже, так как соединение не устанавливается...

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

    еще некоторые клиенты не могут в сертификате перебирать имена и имя кластера приходится задавать вручную через CertPrincipalName - msstd

    19 января 2015 г. 8:34
  • Доброго дня,

    Это проблема с сертификатами, похоже, так как соединение не устанавливается...

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

    еще некоторые клиенты не могут в сертификате перебирать имена и имя кластера приходится задавать вручную через CertPrincipalName - msstd

    ОЧень похоже на правду ...
    у нас домена contoso.local | почта contoso.ru 
    сертификат установлен на contoso.local 
    ТОгда вопрос , как установить его корректно. Меня смущает вот что ...
    Так как клиенты в домене у нас не имеют выхода в интернет как они отреагируют на сертификат ?
    В плане того, что к центру сертификата у них нет доступа по интернету... он будет определять его как поддельный?! 

    19 января 2015 г. 8:56
  • У Вас Wild сертификат на какие имена выпущен? *.contoso.ru?

    1. В DNS создайте еще зону contoso.ru и пропишите туда IP адреса Exchange...

    Я не работал с Wind сертификатами, я покупал SAN, у меня получилось:

    autodiscovery.externaldomain.ru

    exch.extertaldomain.ru и exch.internaldomain.ru (exch.* имя DAG кластера) и т.д.

    2.В ECP Сертификаты - проверить, что сертификаты действительные... В IIS привязку сертификата к 443 и 444 портам и т.д.

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

    Заходите https://dagcluster/ecp и смотрите сертификат (горит ли красным), если все норм, пробуете еще раз запустить outlook...

    19 января 2015 г. 9:46
  • или для начала для тестов отключить шифрование:

    Set-RpcClientAccess и -EncryptionRequired $False

    Set-MailboxServer и -MapiEncryptionRequired:$False

    посмотрите справку, не помню команды...

    еще советую включить MAPI, проблем с ним как-то меньше...

    19 января 2015 г. 9:49
  • Поскольку у вас внутреннее имя домена отличается от публичного имени SMTP домена, то для доступа внутренних пользователей логичнее было бы использовать SAN сертификат, выпущенный вашим корпоративным CA. Вы, кстати, не написали, каким образом у вас осуществляется балансировка клиентских подключений к Exchange. По опыту внедрений могу сказать, что в принципе существует возможность использования коммерческого wildcard сертификата для внутреннего доступа (при условии, что на клиентах установлены ОС Vista и выше. Для XP эта возможность не подходит. Как раз из за трудностях в распознавании имен сертификатов.

    Сколько примерно у вас клиентов, пытающихся подключиться через VPN, с машин, не входящих в домен? Если число невелико, то рекомендую все-таки импортировать на них сертификат вашего внутреннего центра сертификации и использовать для внутреннего доступа SAN сертификат, выпущенный вашим же центром. Самоподписные сертификаты Exchange использовать не рекомендуется, поскольку для клиентов они будут недоверенными, в результате чего значительно вырастают административные затраты на эксплуатацию почтовой системы.

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


    Do not multiply entities beyond what is necessary

    19 января 2015 г. 11:48
  • Спасибо за ответ, Дмитрий.

    У нас стоит DAG (имя) + DNS RR  записи согласно статьям от MS. Тут я не вижу проблем в работе. 
    Клиенты все у нас windows 7 или windows 8. Outlook в 90% 2010 , остаток 2013. 
    Клиентов достаточно много -порядка 1000. 

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

    21 января 2015 г. 6:24
  • поищите что-то вроде "публикация Exchange 2013". Если количество внешних пользователей относительно невелико, вполне успешно можно использовать для публикации IIS Arr. Как вариант, использовать аппаратный/виртуальный балансировщик для выполнения функций балансировки серверов клиентского доступа и организации доступа внешних пользователей. В общем решений много. Можно так же использовать TMG, если у вас имеется лицензия на него (несмотря на то, что продукт уже не выпускается, свои функции он выполняет довольно успешно).

    Do not multiply entities beyond what is necessary

    21 января 2015 г. 6:35
  • Да у нас стоит TMG 2010. 
    Сертификат не могу вкорячил в TMG он отлично там стоит ... 
    21 января 2015 г. 7:29