none
"Сообщения голосовой почты отсутствуют" в Lync 2010 RRS feed

  • Вопрос

  • После интеграции Lync + Exchange UM голосовая почта работает, но есть один нюанс: в клиенте Lync не отображается голосовая почта (http://img580.imageshack.us/i/lyncexchange.png/). Знаю что она должна отображаться.
    1) SIP FQDN = Active Disrectory FQDN и не равен Exchange SMTP FQDN доменам.
    2) в Exchange GW "1:1" включено "Разрешить индикатор Message Waiting"
    3) Версия Lync - 4.0.7577.0 версия х64 рус, Версия Lync Server - так же 4.0.7577.0. Версия Exchange 2010 SP1 (Build 218.15), Outlook 2010 x64 Rus (14.0.4760.1000)
    В какую сторону "копать" ?



Ответы

  • ВСЕ !!! РЕШИЛ САМ (к сожалению).

    Как я несколькими постами выше ссылался на руководство по решению проблемы:
    http://social.technet.microsoft.com/Forums/en-US/ocsvoice/thread/283db822-7156-438b-bd2f-0f00f74d00b2/#bb213fe9-72fe-48da-86f4-eb4d03084e2e

    рекомендуют поправить настройки ASP.NET, но у меня *.svc настройки присутствуют (и затирать их рекомендуемыми на форуме я не решаюсь - не хотелось бы все сломать. Тем более что эти настройки я не понимаю):
     <add name="AutodiscoverDiscoveryHandler"
         path="*.svc"
         verb="GET"
         type="Microsoft.Exchange.Autodiscover.WCF.AutodiscoverDiscoveryHttpHandler, Microsoft.Exchange.Autodiscover, Version=14.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
         preCondition="integratedMode,runtimeVersionv2.0" />


    Просто я побоялся влазить в настройку того, чего не понимаю. А оказалось, что это было решением.
    Для таких как я расписываю решение:

    1) заходим в консоль IIS на сервере CAS Exchange

    2) выбираем папку Autodiscover

    3) заходим в настройки Handler Mapping

    4) добавляем handler  Имя:svc-Integrated, путь:*.svc, тип:System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

    5) делаем iisreset

    После этого перегружаем свой Lync 2010 и практически сразу получаем рабочий Lync с голосовой почтой и списком звонков !!!

    PS:
    Вот здесь https://support.arvixe.com/index.php?/Knowledgebase/Article/View/152/0/how-to-fix-wcf-svc-file-gives-a-404-error рекомендуют добавлять 2 handler-а на сервера где стоит .NET v4.0.

    Я счастлив !


    • Помечено в качестве ответа R. Dmitriy 29 января 2012 г. 6:40
    • Изменено R. Dmitriy 30 января 2012 г. 3:44
    • Снята пометка об ответе R. Dmitriy 30 января 2012 г. 3:45
    • Помечено в качестве ответа R. Dmitriy 30 января 2012 г. 3:45
    29 января 2012 г. 6:40

Все ответы

  • Что-то мне подсказывает, что вы и есть автор вопроса :) .

    Во-первых - в чём смысл делать SIP-домен отличным от почтового?

    Во-вторых - уверен, что у вас проблема с EWS. В "Сведения о конфигурации" что у вас в "Сведения о EWS" написано?

    23 января 2012 г. 9:41
    Модератор
  • :) блин действительно - как бы сосредотачиваешься на сути, на автора и не смотришь - так и до дискуссии "сам с сабой" не долго дойти.

    1) просто почтовый домен отличается от домена Active Directory. В отличии от нескольких SRV записей для на внешнем домене domain.com в поддомене ads.domain.com, вариант с двумя зонами (внешней и внутренней) значительно усложняется.

     

    2) внешнее имя lync.domain.com, которое с помощью Cisco NAT DNS inspection преобразуется из внешнего IP во внутренний IP для клиентов во внутренней сети. Т.е. ping lync.domain.com пингует внутренний адрес

    порты 80/443 и 8080/4443 соответственно.

    А как дальше проверить ?

    23 января 2012 г. 11:08
  • 1. Честно говоря, не понял, что вы хотели сказать :) . А, вообще, я сторонник единого адреса ;) . И имя вашего AD-домена вообще ни на что не влияет.

    2. Опять же не понял для чего вы это написали. Для начала, давайте определимся - у вас проблема внутри сети или снаружи?

    23 января 2012 г. 21:46
    Модератор
  • 1)  http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml если вам это поможет.
    Очень хороший механизм, особенно если в сети компании множество сайтов, внутри которых еще и несколько DMZ.
    Без этого механизма бы домен contoso.com пришлось бы создавать 1 для Internet и по 1 DNS серверу в каждой изолированной подсети (для внутренней, для DMZ, для  удаленных офисов). Работы бы по обновлению всех этих DNS прибавилось. А так - в одном месте поравил и все работает.

    2) Может я тогда не понял вопроса ? Что вкладывали в вопрос "В "Сведения о конфигурации" что у вас в "Сведения о EWS" написано?"

    Проблема внутри. наружу ничего не опубликовано (чего публиковать, если еще не работает). Благодаря Cisco DNS Doctoring обращаясь на External Web site по имени lync.domain.com клиент попадает именно на сервер External Web Site внутри сети по внутреннему IP.

    Может кого-то наведет на мысль еще один ньюанс - При траблешутинге голосовой маршрутизации наткнулся на попытку Exchange зарегистрироваться на Lync, но ему не удалось :

    Message-Type: request
    Start-Line: SUBSCRIBE sip:MSExchangeUM@SRV-EXUM1.ads.domain.com SIP/2.0
    From: <sip:MSExchangeUM@SRV-EXUM1.ads.domain.com:5066;transport=Tls;ms-opaque=9c9df052b0b94892>;epid=3C2D29EE7A;tag=dc57a06c9c
    To: <sip:MSExchangeUM@SRV-EXUM1.ads.domain.com>
    CSeq: 56 SUBSCRIBE
    Call-ID: 61e1f29a5ab24522b16f1845663ec9fa
    MAX-FORWARDS: 70
    VIA: SIP/2.0/TLS 10.1.2.22:47097;branch=z9hG4bKa3189bef
    CONTACT: <sip:SRV-EXUM1.ads.domain.com:5066;transport=Tls;ms-opaque=9c9df052b0b94892>;automata;text;audio;video;image
    CONTENT-LENGTH: 472
    EVENT: vnd-microsoft-provisioning-v2
    EXPIRES: 0
    SUPPORTED: ms-dialog-route-set-update
    SUPPORTED: com.microsoft.autoextend
    SUPPORTED: ms-piggyback-first-notify
    SUPPORTED: ms-benotify
    USER-AGENT: RTCC/3.5.0.0 MSExchangeUM/14.01.0355.002
    CONTENT-TYPE: application/vnd-microsoft-roaming-provisioning-v2+xml

    Direction: outgoing;source="local"
    Peer: SRV-EXUM1.ads.domain.com:47097
    Message-Type: response
    Start-Line: SIP/2.0 404 Not Found
    From: <sip:MSExchangeUM@SRV-EXUM1.ads.domain.com:5066;transport=Tls;ms-opaque=9c9df052b0b94892>;epid=3C2D29EE7A;tag=dc57a06c9c
    To: <sip:MSExchangeUM@SRV-EXUM1.ads.domain.com>;tag=EF26FB60282F0ADCF7C5150998E110E1
    CSeq: 56 SUBSCRIBE
    Call-ID: 61e1f29a5ab24522b16f1845663ec9fa
    Via: SIP/2.0/TLS 10.1.2.22:47097;branch=z9hG4bKa3189bef;ms-received-port=47097;ms-received-cid=7B00
    ms-diagnostics: 1003;reason="User does not exist";TargetUri="MSExchangeUM@SRV-exum1.ads.domain.com";source="SRV-LC01.ads.domain.com"
    Server: RTC/4.0
    Content-Length: 0
    Message-Body: –


    Может в этом дело ? За что это имя MSExchangeUM отвечает ?


    • Изменено R. Dmitriy 24 января 2012 г. 11:51
    24 января 2012 г. 11:50
  • 1. Ну и какое отношение это имеет к тому, что у вас AD, почтовый и SIP домены разные? Что мешает-то делать SIP-адреса равными почтовым?

    2. Нажимаем и удерживаем Ctrl -> правый клик по значку Lync'а -> Сведения о конфигурации -> ...

    А чего ради вы внутренних клиентов перенаправляете на сайт, предназначенный для внешних?

    3. Ну, видимо, вы создавали автоответчик, вот и видите его эхо. По данному вопросу лучше создайте отдельную тему.

    24 января 2012 г. 22:04
    Модератор
  • Судя по статье http://support.microsoft.com/kb/2436962/en-us пишется что при отличии адреса sip от e-mail возникают трудности.
    Пришлось всю топологию и DNS сервера переделывать.

    Судя по "Сведения о конфигурации"
    1) Служба EXUM выключена
    2) Службы EWS не развернуты
    Тогда как тогда вообще сейчас работает и Автосекретарь и голосовая почта ? А они работают !
    "Проверка автоконфигурации электронной почты" на Outlook проходит успешно, Web сайт EWS/Exchange.asmx и EWS/UM2007Legacy.asmx тоже отвечают сервисами SOAP успешно. Так что сам Exchange правильно настроен.

    В общем собрал я данные в один архивчик - https://rapidshare.com/files/4237378808/lync.zip
    В нем Сведения о конфигурации, публичный сертификат сервера, и файл топологии.
    адреса в топологии соответствуют действующим DNS в Internet, только из-вне все закрыто (за исключением номера дозвона и почты).

    PS: домены сменил, а проблема осталась (только куча сопутствующих проблем вылезло - теперь разбираюсь с каждой в отельности): например, автосекретарь Exchange теперь при дозвоне на внутренний номер абонента звонит на URI AD домена (старый SIP ID), естейственно его не находит и отвечает "вызов не может быть переведен".





    • Изменено R. Dmitriy 25 января 2012 г. 9:33
    25 января 2012 г. 7:01
  • 2. Что и требовалось доказать ;) !

    Они работают у вас на Exchange'е с Outlook'ом, а Lync, в отличии от Outlook'а, не такой умный и не умеет находить Exchange через AD - ему нужна запись в DNS'е. Лично я предпочитаю создавать не A-запись "autodiscover.domain.com", а SRV-запись "_autodiscover._tcp.domain.com", которая указывает на CAS/массив, через который клиент получает все необходимые данные об Exchange'е.

    Команда "Get-ClientAccessServer | fl AutodiscoverServiceInternalUri" что у вас выдаёт?

    25 января 2012 г. 10:37
    Модератор
  • Так это и сделано еще во времена "царя гороха"
    dig.exe @10.1.72.3 _autodiscover._tcp.domain.com SRV
    
    ; <<>> DiG 9.3.2 <<>> @10.1.72.3 _autodiscover._tcp.domain.com SRV
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 578
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; QUESTION SECTION:
    ;_autodiscover._tcp.domain.com. IN SRV
    
    ;; ANSWER SECTION:
    _autodiscover._tcp.domain.com. 14400 IN SRV 0 100 443 mail.domain.com.
    
    ;; ADDITIONAL SECTION:
    mail.domain.com.        10827   IN      A       10.1.2.5
    
    ;; Query time: 271 msec
    ;; SERVER: 10.1.72.3#53(10.1.72.3)
    ;; WHEN: Wed Jan 25 17:00:20 2012
    ;; MSG SIZE  rcvd: 105
    

    Get-ClientAccessServer | fl AutodiscoverServiceInternalUri

    AutoDiscoverServiceInternalUri : https://pl-ata-ex01.<ad-domain>/Autodiscover/Autodiscover.xml

    AutoDiscoverServiceInternalUri : https://pl-ata-ex02.<ad-domain>/Autodiscover/Autodiscover.xml


    PS: Я же сказал - "в топологии соответствуют действующим DNS в Internet". т.к. в архиве реальные адреса. Просто не хочу чтобы при поиске google по имени компании начала высвечиваться наша переписка.

    PS2: IP 10.1.2.5 - это как раз результат Cisco DNS doctoring (на самом DNS стоит реальный IP)

    • Изменено R. Dmitriy 25 января 2012 г. 11:10
    25 января 2012 г. 11:08
  • А Outlook у вас EWS находит вовсе не по "mail.domain.com", а через "pl-ata-ex01.<ad-domain>" и "pl-ata-ex02.<ad-domain>" ;) .

    И вы бы лучше простенький лог с самого клиента скидывали, чем такие портянки, следующей последовательностью команд:

    nslookup

    set type=srv

    _autodiscover._tcp.domain.com

    25 января 2012 г. 11:14
    Модератор
  • Я же не знаю ваших предпочтений:

    _autodiscover._tcp.<e-mail domain>    SRV service location:
              priority       = 0
              weight         = 100
              port           = 443
              svr hostname   = mail.<e-mail domain>

    Кстати, этот сервис успешно работает давно (например для удаленных пользователей Outlook Exchange proxy over HTTP).
    Что касается Outlook, то возможно этот механизм не работает  каждый раз. Если сервер CAS доступен, то автодисковери не запускается.

    Как бы то ни было _autodiscover._tcp в DNS есть.
    25 января 2012 г. 11:48
  • Я вам про Фому, а вы мне про Ерёму.

    Про запись в DNS'е я всё понял ещё с первого раза ;) .

    Не надо мешать в одну кучу внешних и внутренних пользователей - это разные вещи.

    Outlook внутри сети выполняет Autodiscover через AD и совершенно не смотрит на то, что происходит в DNS'е.

    Она есть, но указывает-то на совершенно другое имя ;) ! Опять же, у вас сейчас адреса в Lync'е и Exchange'е совпадают?

    25 января 2012 г. 11:53
    Модератор
  • сейчас e-mail domain = SIP domain .  Правда на Exchange 3 почтовых домена (некоторые ящики имеют по 2-3 e-mail), поэтому равенство только по primary e-mail domain. Все проблемы с переходом на другие домены решил (сейчас работает то, что раньше работало, предмет обсуждения не работает).

    Я тут снифером просмотрел куда ломится Lync при подключении.

    Получается так:
    1) поиск по _sipinternaltls._tcp (находит)
    2) поиск по _sip.tls (находит)
    3) поиск по host в SRV записях SIP. (находит)
    4) поиск по внутреннему URL сервера (находит).

    Происходит общение с Lync по порту HTTPS

    5) поиск по <email domain> (это Web сайт, т.ч. подключиться не удается)
    6) поиск по autodiscover.<email domain> (не находит)
    7) поиск по_autodiscover._tcp.<email.domain> (находит)
    8) поиск по host в SRV записях autodiscover._tcp (находит)

    Происходит общение с Exchange по порту HTTPS

    9) поиск по autodiscover.<host в SRV записях autodiscover._tcp> (НЕ ПОНЯЛ, ПОЧЕМУ ???)
    10) поиск по внутреннему имени CAS сервера.
    после 10 шага на Lync гаснет галочка(внизу справа) о ошибке подключения к Exchange.



    • Изменено R. Dmitriy 25 января 2012 г. 12:54
    25 января 2012 г. 12:11
  • Равенство должно быть не просто по доменам, а по адресам.

    Вы запись-то в DNS'е измените, чтоб имя соответствовало тому, что прописано в AD?

    25 января 2012 г. 12:40
    Модератор
  • про какую запись DNS вы говорите? если про e-mail (внешний) домен то публиковать в нем записи AD по меньшей мере не логично по соображениям безопасности ! А если бы AD домен у меня был вроде domain.local - где бы я нашел домен первого уровня local ?

    Я тут разбирался с autodiscovery - нашел баг в настройке

    [PS] C:\Windows\system32>get-autodiscovervirtualdirectory

    Name                                    Server                                  InternalUrl
    ----                                    ------                                  -----------
    Autodiscover (Default Web Site)         SRV-EX01
    Autodiscover (Default Web Site)         SRV-EX02


    Решил исправить по аналогии с командой
    Get-AutodiscoverVirtualDirectory -server exch2010fe1  | Set-AutodiscoverVirtualDirectory -ExternalUrl 'https://webmail.example.com/Autodiscover/Autodiscover.xml' -InternalUrl 'https://webmail.example.com/Autodiscover/Autodiscover.xml'

    все равно не сработало

    • Изменено R. Dmitriy 25 января 2012 г. 16:08
    25 января 2012 г. 15:32
  • Чё-то мы с вами совершенно на разных языках говорим...

    Допустим, у вас почтовый адрес "User@domain.ru" и такой же в Lync'е. Так вот, Lync будет отправлять DNS-запрос на имя "_autodiscover._tcp.domain.ru" и внутри сети логично получить тот же адрес, который использует для своей настройки Outlook. Как мы выяснили ранее, у вас это "pl-ata-ex01.<ad-domain>" и "pl-ata-ex02.<ad-domain>". К чему тут имя вашего AD-домена я не улавливаю.

    Как ваш DNS организован я понятия не имею ;) . Но внешняя зона меня абсолютно не интересует, раз уж мы говорим про внутренних клиентов.

    Вы понимаете разницу в логике работы Lync'а и Outlook'а? То, что вы исправили - это SCP, находящаяся в AD, которую использует ТОЛЬКО Outlook для своей настройки. Lync не умеет считывать SCP из AD и поэтому требует запись в DNS'е.

    У вас сейчас внутри сети Autodiscover работает? Outlook сам настраивается?

    26 января 2012 г. 9:04
    Модератор
  • ДА, для каждого юзера почтовый адрес (primary) = sip адресу Lync.
    так же ДА, _autodiscover._tcp.domain.ru указывает на сервер CAS Exchange 2010, в моем случае на PL-ATA-EX01(только по имени mail.<e-mail-domain>). по адресу https://mail.<e-mail-domain>/owa/ можно зайти на OWA Exchange (как изнутри так и снаружи, по одному имени). Я это и сказал несколькими постами выше.

     

    26 января 2012 г. 9:29
  • Вот вы сейчас ответили на мои утверждения и ни на один вопрос ;) .

    OWA меня абсолютно не интересует ;) .

    Я, конечно, понимаю, что мы на разных языках говорим, но не настолько же :) ! Где это и что вы такое сказали "несколькими постами выше"? Специально перечитал - ни чего не увидел.

    26 января 2012 г. 10:03
    Модератор
  • Autodiscover судя по "Сведенья о конфигурации" Lync не работает - в конфигурации даже не пахнет теми записями, что стоят в DNS для почты и полей _autodiscover. Однако, как то Lync к почте подключается, т.к. алерт "Отсутствует соединение с Exchange пропадает.

    Outlook сам настраивается (как в прочем и до установки Lync Server)

    26 января 2012 г. 10:21
  • отсутствие алерта "Отсутствует соединение с Exchange" не показатель, что линк как то начал с эксченджем взаимодействовать.
    26 января 2012 г. 11:48
  • Каких ещё "полей _autodiscover"?

    А делает он это очень просто - через Outlook ;) ! Если внимательно посмотрите на те же сведения о конфигурации, то обнаружите там "Состояние MAPI: ОК"...

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

    26 января 2012 г. 11:57
    Модератор
  • Почему я игнорирую вопросы? Если пищу лишнее так это что бы дать больше информации.
    я отвечал на все ваши вопросы:

    Каких ещё "полей _autodiscover"?             -              в зоне DNS e-mail/SIP домена. записи (_autodiscover._tcp.<sip-domain>)
    У вас сейчас внутри сети Autodiscover работает? Outlook сам настраивается?  -   Autodiscover судя по "Сведенья о конфигурации" Lync не работает. Outlook сам настраивается
    у вас сейчас адреса в Lync'е и Exchange'е совпадают? - ДА, для каждого юзера почтовый адрес (primary) = sip адресу Lync.
    Команда "Get-ClientAccessServer | fl AutodiscoverServiceInternalUri" что у вас выдаёт?  -
    Get-ClientAccessServer | fl AutodiscoverServiceInternalUri
    AutoDiscoverServiceInternalUri : https://pl-ata-ex01.<ad-domain>/Autodiscover/Autodiscover.xml
    AutoDiscoverServiceInternalUri : https://pl-ata-ex02.<ad-domain>/Autodiscover/Autodiscover.xml

    какие вопросы я проигнорировал ? предлагаю чат - skype:rogozinskiy
    26 января 2012 г. 12:30
  • Уже гораздо лучше ;) !

    Давайте так - ради теста, без преперательств, измените имя сервера в записи "_autodiscover._tcp.<sip-domain>", чтоб компьютер с Lync'ом получал не "mail.<e-mail domain>", а то же, что прописано в AD - "pl-ata-ex01.<ad-domain>"...

    Кстати, вы говорили, что у вас была ошибка в настройках и вы её исправили. Что там за ошибка-то была? Отсутствие ExternalURL? У вас в AD сейчас уже другие имена прописаны или как?

    26 января 2012 г. 12:43
    Модератор
  • Ошибка была в отсутствии URL autodiscovery:

    [PS] C:\Windows\system32>get-autodiscovervirtualdirectory

    Name                                    Server                                  InternalUrl
    ----                                    ------                                  -----------
    Autodiscover (Default Web Site)         SRV-EX01
    Autodiscover (Default Web Site)         SRV-EX02

    Но это было в консоли Exchange и для Outlook и без этого работало, а вы сказали эти настройки касаются только Outlook.

    поменял DNS как сказали (+ еще DNS запись autodiscover.<sip-domain> изменил) - результат тот же. Я снифером промониторил подключение как при mail.<e-mail domain> так и при pl-ata-ex01.<ad-domain>. Поведение Lync в точности идентичное, обращение к тем же IP адресам и портам.
    После получения записи autodiscover.<domain> Lync сначала обращается по HTTPS к CAS, потом по HTTP (на HTTP идет возврат ошибки 403, так как каталог требует HTTPS). Потом получает запись _autodiscover._tcp.<sip-domain>. Опять же обращается HTTPS.
    Без запуска Outlook Lync пишет MAPI недоступен.
    26 января 2012 г. 13:34
  • Очень странно. А вы можете посмотреть в логах IIS'а на CAS'е о чём клиент с ним разговаривал? Может, вы как-то накрутили параметры аутентификации или ещё чего, что Lync не может подключиться к EWS?
    26 января 2012 г. 13:42
    Модератор
  • А по поводу "Get-AutodiscoverVirtualDirectory" - это вовсе не ошибка, а штатное положение дел и эти данные уже на уровне метаданных IIS'а находятся, а не в AD ;) .
    26 января 2012 г. 13:54
    Модератор
  • Похоже что Lync не посылает на Exchange логин/пароль !!! А Outlook посылает :

    Lync:
    2012-01-26 13:57:44 10.1.2.5 GET /autodiscover/autodiscover.xml - 443 - 10.1.3.65 OC/4.0.7577.4051+(Microsoft+Lync+2010) 401 0 0 6874
    2012-01-26 13:57:44 10.1.2.5 GET /autodiscover/autodiscover.xml - 443 - 10.1.3.65 OC/4.0.7577.4051+(Microsoft+Lync+2010) 401 0 0 15
    2012-01-26 13:57:44 10.1.2.5 POST /autodiscover/autodiscover.svc - 443 - 10.1.3.65 OC/4.0.7577.4051+(Microsoft+Lync+2010) 405 0 1 218
    2012-01-26 13:57:44 10.1.2.5 GET /autodiscover/autodiscover.xml - 80 - 10.1.3.65 OC/4.0.7577.4051+(Microsoft+Lync+2010) 403 4 5 218

    OutLook:
    2012-01-26 14:00:54 10.1.2.5 POST /autodiscover/autodiscover.xml - 443 AD-DOMAIN\dmitriy 10.1.3.65 Microsoft+Office/14.0+(Windows+NT+6.1;+Microsoft+Outlook+14.0.6112;+Pro) 200 0 64 31
    2012-01-26 14:00:54 10.1.2.5 GET /autodiscover/autodiscover.xml - 80 - 10.1.2.9 Microsoft+Office/14.0+(Windows+NT+6.1;+Microsoft+Outlook+14.0.6112;+Pro) 403 4 5 218

    401 ошибка - неавторизован, 403 - запрет доступа по HTTP, 405 - Method Not Allowed


    Может конечно Kerberous SPN добавить для сервера ...

    • Изменено R. Dmitriy 26 января 2012 г. 14:24
    26 января 2012 г. 14:07
  • А какой SPN вы хотите прописать? Если обращение идёт по имени самого CAS-сервера, то "HTTP/pl-ata-ex01" и "HTTP/pl-ata-ex01.<ad-domain>" там уже есть.

    Если через браузер открыть "https://pl-ata-ex01.<ad-domain>/autodiscover/autodiscover.xml", пароль запрашивается? После ввода XML-содержимое отображается?

    26 января 2012 г. 14:50
    Модератор
  • SPN для mail.sip-domain.com Его там нет. Но так как IE открывает (сейчас) без  пароля, то и Lync по идее должен делать тоже.

    Я уже по рекомендациям http://www.confusedamused.com/notebook/lync-claims-ews-not-deployed/ добавил сайт в Local Intranet Zone.
    IE стал заходить не спрашивая пароля, по всем возможным именам https://CAS/autodiscover/autodiscover.xml (где CAS и AD и SIP имена подставлял). А Lync все равно отваливается по 401 ошибке. Судя по логам сервера этому URL обращение идет по POST, поэтому сервер отвечает браузеру XML c ответом "Invalid Request".



    Здесь http://social.technet.microsoft.com/Forums/en-US/ocsvoice/thread/283db822-7156-438b-bd2f-0f00f74d00b2/#bb213fe9-72fe-48da-86f4-eb4d03084e2e

    рекомендуют поправить настройки ASP.NET, но у меня *.svc настройки присутствуют (и затирать их рекомендуемыми на форуме я не решаюсь - не хотелось бы все сломать. Тем более что эти настройки я не понимаю):
     <add name="AutodiscoverDiscoveryHandler"
         path="*.svc"
         verb="GET"
         type="Microsoft.Exchange.Autodiscover.WCF.AutodiscoverDiscoveryHttpHandler, Microsoft.Exchange.Autodiscover, Version=14.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
         preCondition="integratedMode,runtimeVersionv2.0" />
     

    • Изменено R. Dmitriy 26 января 2012 г. 15:52
    26 января 2012 г. 15:13
  • Сегодня попробовал подключиться на IPad - подключился, но проблема осталась та же: При подключении к серверу Exchange выдается 401 ошибка, а законектится с паролем он даже не пытается.

    2012-01-27 07:49:42 10.1.2.5 GET /autodiscover/autodiscover.xml - 443 - 10.1.3.140 Lync%202010/1.0+CFNetwork/485.13.9+Darwin/11.0.0 401 0 0 15
    2012-01-27 07:49:42 10.1.2.5 POST /autodiscover/autodiscover.svc - 443 - 10.1.3.140 Microsoft+Lync+iPhone/M2 405 0 1 15
    2012-01-27 07:49:42 10.1.2.5 GET /autodiscover/autodiscover.xml - 80 - 10.1.3.140 Lync%202010/1.0+CFNetwork/485.13.9+Darwin/11.0.0 403 4 5 0
    2012-01-27 07:49:42 10.1.2.5 GET /autodiscover/autodiscover.xml - 443 - 10.1.3.140 Lync%202010/1.0+CFNetwork/485.13.9+Darwin/11.0.0 401 0 0 0
    2012-01-27 07:49:42 10.1.2.5 POST /autodiscover/autodiscover.svc - 443 - 10.1.3.140 Microsoft+Lync+iPhone/M2 405 0 1 15

    А ведь у Ipad нет Local Intranet Zone, Зато в Exchange и с IPad и c IPhone автодисковери работает на ура(зашел и сразу определил почтовый сервер к которому конектиться по логину и имени e-mail).
    Я бы еще понял, если бы все клиенты отрубались по 401 ошибке - так ведь Outlook нормально автодисковерится. Уж не проверяет ли Exchange какой клиент к нему долбится ? и в зависимости от этого пускает либо отвергает ????
    • Изменено R. Dmitriy 27 января 2012 г. 11:36
    27 января 2012 г. 10:51
  • В IE ручками выполните https://ваш-кас-сервер/autodiscover/autodiscover.xml Какой результат?


    Сазонов Илья http://isazonov.wordpress.com/
    27 января 2012 г. 13:22
    Модератор
  • Я же сказал двумя постами выше:
    IE стал заходить не спрашивая пароля, по всем возможным именам https://CAS/autodiscover/autodiscover.xml (где CAS и AD и SIP имена подставлял). А Lync все равно отваливается по 401 ошибке. Судя по логам сервера этому URL обращение идет по POST, поэтому сервер отвечает браузеру XML c ответом "Invalid Request".
    27 января 2012 г. 14:27
  • На самом деле, даже без этого SPN'а всё будет отрабатывать по NTLM'у, так что это можете пока не рассматривать.

    Если оно есть, то не надо трогать ;) .

    27 января 2012 г. 18:38
    Модератор
  • У меня общение Lync 'а с Exchange'ем выглядит вот так:

    2012-01-27 22:01:37 192.168.1.4 GET /autodiscover/autodiscover.xml - 443 - 192.168.1.11 OC/4.0.7577.0+(Microsoft+Lync+2010) 401 0 0 7416
    2012-01-27 22:01:37 192.168.1.4 POST /autodiscover/autodiscover.svc - 443 - 192.168.1.11 OC/4.0.7577.0+(Microsoft+Lync+2010) 401 0 0 166
    2012-01-27 22:01:43 192.168.1.4 POST /autodiscover/autodiscover.svc - 443 DOMAIN\User 192.168.1.11 OC/4.0.7577.0+(Microsoft+Lync+2010) 200 0 0 5838
    2012-01-27 22:01:45 192.168.1.4 POST /EWS/Exchange.asmx - 443 - 192.168.1.11 OC/4.0.7577.0+(Microsoft+Lync+2010) 401 0 0 2091

    27 января 2012 г. 18:39
    Модератор
  • В общем, я провёл небольшое исследование и выявил три основные момента, которые могут выливаться в неработоспособность.

    У вас клиент сертификату на CAS'е доверяет? Какие имена в сертификате присутствуют?

    Какой результат выводится на команду "Get-WebServicesVirtualDirectory | fl *URL"?

    27 января 2012 г. 18:42
    Модератор
  • 1) При обращении к серверу через IE никаких алертов про "недоверие" или "недействительный сертификат" или "неправильное имя" нет. при просмотре сертификата выдает "Этот сертификат действителен."
    Так что сертификату доверие есть. После добавления сайтов в Local Intranet Zone - заходит без ввода пароля (с текущими индентификационными данными)

    2)В сертификате стоит CN=mail.<email-domain1>
    В альтернативных именах сертификата:
    DNS-имя=pl-ata-ex01.<ad-domain>
    DNS-имя=mail.<email-domain1>
    DNS-имя=mail.<email-domain2>
    DNS-имя=autodiscover.<email-domain1>
    DNS-имя=autodiscover.<email-domain2>
    DNS-имя=autodiscover.<ad-domain>
    DNS-имя=PL-ATA-EX01


    PS: Если бы сертификаты были бы недействительны, то и Outlook обращаться отказался бы !


    3)
    InternalNLBBypassUrl : https://pl-ata-ex01.<ad-domain>/ews/exchange.asmx
    InternalUrl          : https://pl-ata-ex01.<ad-domain>/EWS/Exchange.asmx
    ExternalUrl          : https://mail.<email-domain1>/ews/exchange.asmx

    InternalNLBBypassUrl : https://pl-ata-ex02.<ad-domain>/ews/exchange.asmx
    InternalUrl          : https://pl-ata-ex02.<ad-domain>/EWS/Exchange.asmx
    ExternalUrl          : https://mail.<email-domain1>/ews/exchange.asmx


    В статье http://technet.microsoft.com/ru-ru/library/dd351057.aspx "You must use a public certificate if you are using Unified Messaging with Office Communications Server".  Я что-то не пойму этой тонкости ? это имеет значение в моем случае ?





    • Изменено R. Dmitriy 29 января 2012 г. 5:40
    29 января 2012 г. 3:44
  • ВСЕ !!! РЕШИЛ САМ (к сожалению).

    Как я несколькими постами выше ссылался на руководство по решению проблемы:
    http://social.technet.microsoft.com/Forums/en-US/ocsvoice/thread/283db822-7156-438b-bd2f-0f00f74d00b2/#bb213fe9-72fe-48da-86f4-eb4d03084e2e

    рекомендуют поправить настройки ASP.NET, но у меня *.svc настройки присутствуют (и затирать их рекомендуемыми на форуме я не решаюсь - не хотелось бы все сломать. Тем более что эти настройки я не понимаю):
     <add name="AutodiscoverDiscoveryHandler"
         path="*.svc"
         verb="GET"
         type="Microsoft.Exchange.Autodiscover.WCF.AutodiscoverDiscoveryHttpHandler, Microsoft.Exchange.Autodiscover, Version=14.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
         preCondition="integratedMode,runtimeVersionv2.0" />


    Просто я побоялся влазить в настройку того, чего не понимаю. А оказалось, что это было решением.
    Для таких как я расписываю решение:

    1) заходим в консоль IIS на сервере CAS Exchange

    2) выбираем папку Autodiscover

    3) заходим в настройки Handler Mapping

    4) добавляем handler  Имя:svc-Integrated, путь:*.svc, тип:System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

    5) делаем iisreset

    После этого перегружаем свой Lync 2010 и практически сразу получаем рабочий Lync с голосовой почтой и списком звонков !!!

    PS:
    Вот здесь https://support.arvixe.com/index.php?/Knowledgebase/Article/View/152/0/how-to-fix-wcf-svc-file-gives-a-404-error рекомендуют добавлять 2 handler-а на сервера где стоит .NET v4.0.

    Я счастлив !


    • Помечено в качестве ответа R. Dmitriy 29 января 2012 г. 6:40
    • Изменено R. Dmitriy 30 января 2012 г. 3:44
    • Снята пометка об ответе R. Dmitriy 30 января 2012 г. 3:45
    • Помечено в качестве ответа R. Dmitriy 30 января 2012 г. 3:45
    29 января 2012 г. 6:40
  • Поздравляю :) !

    Тогда, возникает резонный вопрос - откуда у вас взялось значение "Microsoft.Exchange.Autodiscover.WCF.AutodiscoverDiscoveryHttpHandler"? Как и откуда вы разворачивали свои CAS'ы? Какие обновления на них стоят? На обоих серверах прописано "неправильное" значение?

    29 января 2012 г. 6:48
    Модератор
  • ХЗ! Почему так получилось. я тоже лоханулся - сейчас посмотрел, на втором CAS этот handler стоял правильно(я на первый CAS НЕ ЗАМЕНЯЛ, а ДОБАВИЛ handler и это правильно).
    Одназначно, то что я в такую "глубину" никогда не залазил, чтобы самостоятельно какие-то значения убирать.
    Подозреваю, что с одним из Exchange update и последующим Rollup от Microsoft осталась эта бага, ведь не случайно Rollup Microsoft выпускал. просто CAS1 живет уже давно, а CAS2 - полгода, поэтому видимо CAS1 "застал" проблемный update, а CAS2 нет.
    Например Rollup3-v3, Rollup4-v2 - значит эти Rollup были и 1 и 2-й версии, которые забраковали, но которые я по простоте душевной ставил.

    у меня по информации 70 обновлений, ломы их все сюда постить.
    По Exchange 2010 на CAS1 стоят
    Update Rollup 6
    Update Rollup 5
    Update Rollup 4-v2
    Update Rollup 3-v3
    Update Rollup 2

    А на CAS2 поменьше :
    Update Rollup 6
    Update Rollup 5
    Update Rollup 4-v2

    • Изменено R. Dmitriy 29 января 2012 г. 7:13
    29 января 2012 г. 7:00
  • Понятно.

    P. S. И на будущее - не изменяйте так радикально свои ответы. В первоначальном сообщении, где вы упомянули о решении, им даже и не пахло - была лишь первая часть сообщения про SPN и ссылка на рекомендации. Когда приходит уведомление о новом сообщении в теме, в нём содержится только оригинал сообщения, а все изменения остаются незамечанными, если специально всю тему не перечитывать - так что этот момент я просто "проморгал" :) .

    29 января 2012 г. 7:15
    Модератор
  • А вот тут, кстати, наврал - в AD эти ссылки хранятся.

    29 января 2012 г. 7:20
    Модератор
  • Это получается я исправил на CAS1, и исправление автоматически сделалось и на CAS2 ? и я смотрел потом на CAS2 уже после того как все исправилось ?

    PS: Кстати, этот баг мог возникнуть и при установке одного из .NET фиксов, т.к. он затрагивает ASP.NET.
    • Изменено R. Dmitriy 30 января 2012 г. 3:39
    30 января 2012 г. 3:33
  • Нет, то что вы сделали - чисто лакальные настройки.

    30 января 2012 г. 5:25
    Модератор
  • Спасибо, была таже проблема, помогло!
    13 марта 2012 г. 18:06