none
Проблема при звонках с клиентов подключаемых к EDGE серверу Lync 2010 RRS feed

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

  • Доброго дня!

    Настроил edge за NAT согласно супер видео Stanky и Илгиза, наблюдаются следующие проблемы, клиенты подключаются без проблем и могут легко переписываться друг с другом. При звонке на Lync сначала идут 3 коротких гудка, потом начинает идти звонок, человек поднимает трубку и появляется статус "Идёт подключение..." потом вываливается ошибка

    И что самое отвратительное, что при звонках внутри организации наблюдаются те же короткие гудки прежде чем телефон начнёт звонить... Может совпадение, но клиенты не могут звонить в мир. До появления Edge всё работало отлично.

    Подскажите куда смотреть, есть подозрение, что все звонки Lync Front End решил заруливать через Edge.

    Спасибо

    7 марта 2012 г. 13:53

Все ответы

  • В топологии ни чего не напутали? Имя Edge'а внутри сети разрешается? Сам Edge имена других серверов разрешает? Какой адрес прописан у Edge'а для NAT? Edge в DMZ или в рабочей сети?
    7 марта 2012 г. 13:58
    Модератор
  • Вроде ничего не напутал... Имя внутри сети lync-edge.domain.ua разрешается (или имеется ввиду внешнее его имя).  Прописан ip соответствующий адресу av.domain.ua. Не совсем понял вопрос про DMZ и рабочую сеть..
    7 марта 2012 г. 14:16
  • Прописан внешний IP-адрес?

    Ну Edge у вас в какую-то выделенную сеть подключен или точно так же, как любой другой сервер?

    Edge введён в домен? Сколько у него сетевых интерфейсов? Сколько и какие адреса на них прописаны? Какие Default Gateway'и указаны?

    Внутренний IP-адрес самого TMG? Сколько на нём внешних IP-адресов?

    7 марта 2012 г. 14:33
    Модератор
  • У моего edge одна сетевая карта и один шлюз, на сетевую карту я назначил 4 ip внутренней сети, один самого egde и по одному для ролей sip, conf, av. И в DNS у провайдера прописал соответствие адресам sip.mydomain.ua (не локального, а того что виден из мира) к белым адресам

    На роутере прописал внешние sip, conf, av к белым адресам и пробросил их напрямую к сетевым адресам внутри сети. Нужно ли и четвёртый напрямую выпускать в мир?!

    У меня стоит не TMG а Cisco RV 120W. На нём 4 белых ip


    • Изменено vshihov 7 марта 2012 г. 16:20
    7 марта 2012 г. 15:15
  • А у вас точно весь трафик, приходящий на внешний адрес 125 перенаправляется на внутренний 43 и весь исходящний с 43 идёт через 125?

    7 марта 2012 г. 22:18
    Модератор
  • В общем, судя по моему анализу, именно в этом у вас и проблема. Во всяком случае, внешний IP-адрес, назначенный для Media-трафика, по 443-му порту не отвечает.

    А ещё у вас в сертификатах неправильные ссылки (AIA и CDP) прописаны - отсутствует ".com" ;) .

    7 марта 2012 г. 22:43
    Модератор
  • Подправил, теперь адрес отвечает по порту 443 порту... но ситуация не особенно изменилась :( В момент соединения вываливается вся та же ошибка...

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

    Опубликовать центр сертификации при помощи Reverse Proxy получится?! У меня нет пока желания настраивать TMG

    И ещё не работает синхронизация с Exchange и не подтягивается адресная книга, я так полагаю, что это всё из-за одного и того же :(

    Спасибо за оказываемую помощь..




    • Изменено vshihov 8 марта 2012 г. 14:16
    8 марта 2012 г. 9:53
  • В целях уменьшения площади допущения ошибки, для начала, предлагаю все службы повесить на один адрес.

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

    А что именно вы понимаете под "Reverse Proxy"? Это же не название продукта, а просто "технология" ;) .

    Это всё происходит при внешнем доступе? Самая вероятная причина - ошибка в публикации Web-служб.

    8 марта 2012 г. 23:07
    Модератор
  • Т.е. все службы EDGE перенести на один адрес и разнести по портам? Существующие надо перестроить на внешний домен?

    Под Revers Proxy я имел ввиду ваше вдео при публикации служб для Lync Mobility, можно ли таким образом настроить выдачу сертификатов? Если я куплю сертификаты, то все же следует поправить ссылки (AIA и CDP)?

    Да все ошибки происходят именно при внешнем доступе, при использовании Lync внутри организации проблем не наблюдается...

    Как можно проверить корректную информацию по публикации веб-служб. У меня Lync client находит EDGE сервер в автоматическом режиме, ему не yадо указывть edge-lync:443...

    Спасибо, что помогаете...

    9 марта 2012 г. 14:03
  • Да - на один с разнесением по портам.

    Не понял про "перестроить на внешний домен".

    Да, с помощью Reverse Proxy на базе IIS'а можно публиковать всё что угодно - я им и обычные сайты и Remote Desktop Gateway и Lync и Exchange с полным набором возможностей публикую :) . Вот, только, вы говорите про "выдачу сертификатов" - путаете наверно ;) ?

    Ссылки - это построение цепочки и скачивание CRL'ей. Если вы планируете использовать свой внутренний PKI (пусть и только внутри), то работоспособность ссылок, прописанных в сертификатах нужно обеспечить.

    Например, с помощью этого и этого.

    9 марта 2012 г. 14:30
    Модератор
  • Testing the SSL certificate to make sure it's valid.
      The SSL certificate failed one or more certificate validation checks.
      
     Этапы проверки
      
     ExRCA is attempting to obtain the SSL certificate from remote server xxxxx.com.ua on port 443.
      ExRCA wasn't able to obtain the remote SSL certificate.
      
     Дополнительные сведения
      The SSL certificate failed validation for an unknown reason

     
    Certificate trust is being validated.

      Certificate trust validation failed.
      
     Этапы проверки
      
     ExRCA is attempting to build certificate chains for certificate CN=mail.xxxx.com.ua, OU=, O=, L=Kiev, S=Kiev, C=UA.
      A certificate chain couldn't be constructed for the certificate.
      
     Дополнительные сведения
      The certificate chain couldn't be built. You may be missing required intermediate certificates.

    Анализатором ExRCA проверяется узел autodiscover.xxxxx.com.ua для перенаправления HTTP в службу автообнаружения.
      Анализатору ExRCA не удалось получить ответ о перенаправлении HTTP для службы автообнаружения.
      
     Дополнительные сведения
      Получен запрещенный ответ HTTP 403. Этот ответ отправлен Unknown. Текст ответа: You do not have permission to view this directory or page.

    Попытка найти SRV-запись record _autodiscover._tcp.xxxxx.com.ua в службе DNS. - Эту запись следует делать в локальном DNS и ей как я полагаю необходимо указать белый ip, тот же что и отвечает за службу OWA?

      Запись SRV автообнаружения не найдена в службе DNS.

    Проблем полно :( и очевидно что проблема в сертификатах и в неверно настроеном IIS :(((

    10 марта 2012 г. 13:15
  • Так тут же говорится про недоверие сертификату. Оно и не удивительно - у вас же внутренний сертификат, а не публичный ;) . Там в тестах (правда не во всех) есть соответствующая галка, отменяющая проверку сертификата.

    SRV-запись нужно делать во внешней зоне - это же проверка внешних подключений ;) Указывать должна на CAS-сервер. Ну и во внутренней, на самом деле, её тоже нужно делать, что б Lync находил EWS.

    11 марта 2012 г. 7:53
    Модератор
  • Если поставить галку про Ignore Trust SSL то выдаёт ошибку

    Subscription for provisioning data did not return a valid MRAS URI.

    Где это можно подправить?!

    Спасибо

    Но всё дело в том, Lync то он находит чудесно, и писать друг другу можно, но вот только нельзя позвонить и пообщаться, а так хочется :)

    11 марта 2012 г. 9:21
  • Данное сообщение, обычно, означает, что Edge не может найти пул - с DNS'ом точно всё в порядке?

    Вы переделали схему на использование одного IP-адреса?

    11 марта 2012 г. 9:50
    Модератор
  • DNS работает нормально, все именя резолвит...

    Все передалал..

    11 марта 2012 г. 10:53
  • В таком случае, зупускайте сбор логов на Edge'е, запускайте тест и смотрите в чём проблема...

    P. S. 445-й порт используется службой файлового доступа (SMB), поэтому, в таком виде оно у вас работать не будет ;) .

    11 марта 2012 г. 11:23
    Модератор
  • Всё поменял, проблема не изменилась :(

    ( 000000000825EAB8 ) Exit FALSE: mail.domain.ua is not an IP Address

    Единственная подозрительная запись :(

    Запись sip.domain.com.ua откликается по всем портам которые указаны в Topology Builder, но всё равно не получается совершить звонок с внешнего клиента...

    John I need help :)))))

    • Изменено vshihov 11 марта 2012 г. 13:01
    11 марта 2012 г. 12:43
  • Какой тест вы запускали?
    11 марта 2012 г. 12:51
    Модератор
  • Или речь идёт о тех двух сайтах для тестирования удалённого подключения?!

    11 марта 2012 г. 13:55
  • О "тех двух сайтах" :) .

    11 марта 2012 г. 14:18
    Модератор
  • Ошибка всё та же :(

    Subscription for provisioning data did not return a valid MRAS URI

    11 марта 2012 г. 16:49
  • Ну так а тест-то который ;) ?

    Что при его выполнении в логах Edge'а есть подозрительного?

    11 марта 2012 г. 19:26
    Модератор
  • Прости, вот этот тест... Microsoft Lync Server Remote Connectivity Test with AutoDiscover

    в логах на Lync FE единственно подозрительное это

    Exit: XML node does not exist - S_OK.

    ни одна из строк не выделенна жёлтым либо красным цветом :(

    На Lync Edge есть такое

    $$begin_record
    LogType: connection
    Severity: error
    Text: The connection was closed before TLS negotiation completed. Did the remote peer accept our certificate?
    Local-IP: 10.0.0.41:5061
    Peer-IP: 207.46.14.56:55648
    Connection-ID: 0x4700
    Transport: TLS
    $$end_record

    ( 00000000035E2FD8 ) Denied: the connection was closed before negotiation completed.

    ( 00000000036C4FA0 ) isOutbound[0x00000000(false)] transport[SIP_TRANSPORT_TLS] peerAddr[207.046.014.056:55646] edgeType[EDGE_TYPE_EXTERNAL]

    ( 0000000003621520 ) Exit - not enough data, async receive posted. Result S_FALSE

    ( 00000000036C6F70 ) Exit - TCP CompleteRecv failed. Result 10101(WSAEDISCON)

     

    Предыдущая ошибка в логах наблюдалась при попытке звонка с Lync клиента подключённого к EDGE


    • Изменено vshihov 11 марта 2012 г. 21:22
    11 марта 2012 г. 21:06
  • Такое чувство, что у вас проблема в сертификатах ;) . Для начала, обеспечьте правильное функционирование скачивания цепочки и CRL'ей, которое уже обсуждали и перевыпустите все сертификаты для Lync-серверов...

    12 марта 2012 г. 6:34
    Модератор
  • В настройках центра сертификации AIA и CDP настроены на внтуренний домен, отличный от внешнего. Всё сделано по вашему с Илгизом видео. Через DFS, я не публивал ca.domain.ua в мир, так как у меня нету TMG, может ли быть проблема в этом?!

    Скините пожалуйста статью где прочесть про "правильное функционирование скачивания цепочки и CRL'ей"?

    Спасибо


    И ещё любопытный факт, я не могу серверу Edge подсунуть внешний сертификат от сторонего CA, хотя импорт проходит успешно и сертификат есть в папке Personal сервера, при assign появляются 3 сертификата моего CA, а четвёртого сторонего нету :( 
    • Изменено vshihov 12 марта 2012 г. 10:43
    12 марта 2012 г. 9:38
  • Ну а что вам мешает-то настроить их на использование внешнего домена?

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

    Самое качественно и полное описание по работе PKI на Русском языке, которое я знаю, находится на блоге моего хорошего товарища Вадима Поданса.

    Либо, сам сертификат получен не совсем корректный, либо установлен неправильно. У него точно закрытый ключ есть?

    12 марта 2012 г. 14:39
    Модератор
  • Я получил его с сайта c разширением cer, но к нему требуется вводить пароль... Он не pfx :(

    12 марта 2012 г. 19:28
  • Если он у вас с расширением CER, то на машине, предварительно, должна быть сгенерирована криптопара, которая связывается с данным сертификатом при установке. Как, вообще, вы этот сертификат запрашивали? Как устанавливали?

    О каком пароле вы говорите?

    12 марта 2012 г. 20:09
    Модератор
  • Я запрашивал этот сертификат на сайте startssl, предворительно сгенерировал запрос на сертифика в настройке EDGE. При генерации запросили пароль и я его ввёл, далее было написано сохранить текст в файл cer, что я собственно и сделал. При импорте если не ставить галку в поле

    "Certificate file contains certificates's private key", выводить такое окно

    Если ввети пароль, то статус меняется на True

    Но этот сертификат всё равно нигде не отображается :(

    13 марта 2012 г. 11:12
  • Нашёл на форуме запись о таком решении моей пробелемы

    Bernd,
    Have you created the public SRV record for your SIP domain?

    It should be _sip._tls.domain.com pointing to your edge servers public name (i.e. sip.domain.com) on port 443. Without that record things will not connect.

    Мне надо в моём локальном DNS прописать это, или у провайдера?! У провайдера Я не могу создавать записи типа SRV :(

    13 марта 2012 г. 13:53
  • Вы, лучше, покажите как именно выполнялся запрос сертификата и где именно требовалось ввести пароль при его генерации ;) .

    13 марта 2012 г. 17:13
    Модератор
  • Так-то это ни разу не решение вашей проблемы. К слову говоря, в нашем "кино-романе" я говорил про эту запись ;) .

    Да и отвечающий несколько лукавит - если данная запись отсутствует, то Lync будет выполнять вход через A-запись "sip.domain.ru"...

    А, вообще, хоть это и ни коим образом к проблеме не относится - если в современном мире провайдер не позволяет создавать SRV-записи, переносите свою зону к другому ;) .

    13 марта 2012 г. 17:18
    Модератор
  • В какой из серий?! :)

    С созданием записей разобрались, они странно создаются.. Но всё успешно создано! У меня скорее всего линк клиенты находят сервер именно по А записи, но это уже другая песня... Сейчас покупаю сертификат, может он каким то образом поможет?!

    • Изменено vshihov 14 марта 2012 г. 14:35
    14 марта 2012 г. 14:34
  • Вы думаете, я их наизусть помню :) ? Скорее всего, в этой, а может и в самой первой - принцип-то поиска сервера что внутри, что снаружи, один и тот же.

    Всё может, но я бы на это особо не рассчитывал.

    14 марта 2012 г. 14:42
    Модератор
  • Доверяю Вам всецело, но надо попробовать. Чтобы знать наверняка :)
    14 марта 2012 г. 15:19
  • Так я, ведь, не отговариваю ;) .

    14 марта 2012 г. 15:21
    Модератор
  • У меня появилась дополнительная информация касательно, того почему не работает голос ;)

    Когда подключается ВПН, то можно звонить.. Отключаешь нельзя :)

    Скорее всего это связано с тем, что в CRL указан путь к серверу внутри домена, а не к внешнему, попробую через reverse proxy опубликовать http с путями к сертификатам, попутно изменив пути в AIA и CDP и отпишу о результате, ваше видео для публикации Lync Mobility должно подойти..

    Спасибо

    19 марта 2012 г. 10:08
  • А я думаю, что когда вы поднимаете VPN, то Edge просто не используется и звонки идут напрямую ;) .
    19 марта 2012 г. 10:12
    Модератор
  • Но как же понять тогда что ему мешает :(
    19 марта 2012 г. 10:28
  • Логи-трафик-логи :) !
    19 марта 2012 г. 18:33
    Модератор
  • Проверил опытным путём, при подключении ВПН звонок идёт нормально, как только отключаю VPN звонок обрывается, получается, что где то указано внутреннее имя FrontEnd сервера, т.е. подключение происходит через EDGE а вот дальше ничего не проходит :(
    20 марта 2012 г. 10:04
  • А причём тут Front-End? Я же вам сказал, что при поднятом VPN'е, у вас звонки просто идут "напрямую" ;) .
    20 марта 2012 г. 16:20
    Модератор
  • Попробовал опять на 3 разных IP для EDGE ну не хочет соединяться :( Это может быть связано с тем, что когда я например захожу на dialin.xxxxx.com.ua он меня перебрасывает на srv-lync.xxxx.ua? Почему то он подсовывает внутреннее имя сервера :( Так как он пытается подключится к внутреннему имени сервера, которое естественно не доступно из мира :(
    • Изменено vshihov 21 марта 2012 г. 14:40
    21 марта 2012 г. 14:27
  • Нет, Edge и Web-сервисы - это разные вещи ;) . Видимо, вы пробросили порты не на внешний сайт (8080 и 4443), а на внутренний (80 и 443).
    21 марта 2012 г. 18:25
    Модератор
  • Именно на внешний я посмотрел в топологии, что это имя lync.xxxxx.com.ua и телнетом пробую подключится по портам 8080 и 4443 они чудесно проваливаются внутрь. :(((

    Ещё вчера собрал логи с клиента линк который не соединяет и показывает данную ошибку, выбрал их... Есть парочка интересных моментов, о которых я думал, почему он звонит при подключённом VPN

    <O_TRC><ADR>0x00000000</ADR>Failed to parse uri: sip:tel:4444444;phone-context=syntegra_location_profile hr=80EE0012</O_TRC>

    <O_TRC><ADR>0x00359848</ADR>Condition failed with S_FALSE</O_TRC>

    <O_TRC><ADR>0x0035EF68</ADR>DetermineWebServiceUrl failed. Ignore the error. hr=80f10031</O_TRC>

    <O_TRC><ADR>0x0496DA00</ADR>MEX resolution failed for https://srv-lync.xxxxx.ua/WebTicket/WebTicketService.svc, hr=0x80f10045</O_TRC>

    <O_TRC><ADR>0x00352B38</ADR>Calendar capabilties are not available because Autodiscover has not completed yet HRESULT failed=HRESULT=80EE0058</O_TRC>

    <O_TRC><ADR>0x00326708</ADR>Failed to resolve the server name to IP address. status=0861A688, hr=80f10045</O_TRC>

    <O_TRC><ADR>0x00000000</ADR>WebServices::CMetaDataModel::GetMetaDataDescription[751] - ASSERTION FAILURE: Metadata resolution failed!. hr=0x80f10045</O_TRC>

    <O_TRC><ADR>0x00326708</ADR>Failed to send a dummy request: hr=0x80072f0d, url=https://xxxxx.com.ua/autodiscover/autodiscover.xml</O_TRC>

    Мне кажется, что не верно опубликовал web службы :( Их лучше опубликовывать через настройки reverse proxy или пробросом портов?!

    22 марта 2012 г. 9:14
  • Так снаружи-то этот сайт должен быть доступен не по 8080 и 4443, а по стандартным 80 и 443 ;) . То есть, если вы делаете проброс портов, то он должен выглядеть так: lync-ws.domain.com:443 -> lync.domain.local:4443.

    22 марта 2012 г. 9:44
    Модератор
  • Это мы говорим о Lync Mobility?! У меня внешнее имя FE lync.xxxxx.com.ua а имя lync-ws.xxxxx.com.ua зарезервировано для Mobility там же настроен и Reverse Proxy
    22 марта 2012 г. 10:12
  • Лично я говорю о Web-сервисах ;) . Mobility работает на тех же Web-сервисах, что и всё остальное. Вы хотите сказать, что вы под него какое-то специальное имя выделили?

    22 марта 2012 г. 10:15
    Модератор
  • Да :) Я выделил имя lync-ws.xxxx.com.ua для мобилити, ip IIS exchange. Где я поднял reverse proxy, который отрабатывает корректно. Т.е. если я захожу на lyncdiscover.xxxxx.com.ua он предлогает скачать файлик. Но клиент с майфуна не хочет коннектится :( Это могут быть звенья одной цепи?! Мобильный клиент пишет, что сервер не найден :) Корневой сертификат на телефон я скачал....
    22 марта 2012 г. 10:23
  • А для чего вы это сделали? И как именно сделали?
    22 марта 2012 г. 10:25
    Модератор
  • Реверс прокси был поднят по вашему с Илгизом видео для публикации веб-служб мобилити в мир, разнёс по разным серверам для того, чтобы не убивать работающую owa exchange, потому как в реверс прокси применяется другой сертификат и служба owa после этой замены падала.

    Можно ли проверить работает ли проброс портов, я настроил проброс с приходящего 80 на 8080, но ситуация кардинально не изменилась :(

    • Изменено vshihov 22 марта 2012 г. 10:28
    22 марта 2012 г. 10:27
  • Вы всё смешали в одну кучу ;) . Нет у Mobility каких-то своих отдельных Web-служб - они одни "на все случаи жизни".

    Reverse Proxy мы подняли на Exchange'е по одной простой причине - там был IIS. В том контексте, что я показывал, IIS = TMG.

    22 марта 2012 г. 10:32
    Модератор
  • У меня в голове примерно такая же ситуация :( Полная каша и только только начинаю всё немного раскладывать по полочкам.. Т.е. мне надо реверс прокси поднять на IIS Lync FE или же для публикации можно использовать уже настроенный?

    И к серверу IIS надо будет прикручивать сертификаты содержищие имена sip.xxxx.com.ua lync-ws.xxxx.com.ua meet.xxxx.com.ua?


    • Изменено vshihov 22 марта 2012 г. 10:37
    22 марта 2012 г. 10:34
  • Опять 25 :( ...

    Reverse Proxy - это тот компонент, который позволяет через интернет обратиться ко внутренним Web-сервисам, находящимся внутри сети ;) . Ну поднимите вы этот Reverse Proxy на IIS'е Front-End'а, а дальше что? Как к нему через интернет обращаться-то будут?

    Если же вы подключили Front-End напрямую в интернет, то и не нужно городить Reverse Proxy - достаточно изменить Binding внешнего сайта, чтоб он принимал подключения только по внешнему IP-адресу и стандартным портам 80 и 443.

    Про поддерживаемость и нерекомендуемость второго сценария я не говорю.

    22 марта 2012 г. 10:40
    Модератор
  • Сорри за недопонимание :(

    Публиковать FE в мир это не совсем верно, надо же всё делать по правилам как минимум безопасности. Reverse Proxy это аналог TMG только многим легче и его докупать не следует.

    Остаётся единственно верный сценарий публикации web-служб через RP. Я кончно понимаю, что задолбал уже тебя в дым :(

    Но мой мозг не совсем включаем :( Какие web сервисы надо публиковать?! Надо прописать в DNS имя lync.xxxxx.com.ua = whiteip который и будет пробрасывать порты, сейчас у меня указано там имя lync-wz.xxxxxx.com.ua и lyncdiscover.xxxxx.com.ua которые ссылаются на FE. Т.е. если файл скачивается, то проброс настроен верно, теперь надо по такому же принципу настроить проброс имени lync.xxxxx.com.ua, которое указано в Topology Builder.

    Я верным путём мыслю или вообще мимо кассы?!

    22 марта 2012 г. 10:53
  • У Front-End'а на IIS'е два сайта - Internal и External. Публиковать нужно External. Во внешнем DNS'е нужно прописать имя "lyncdiscover" и то, что указано в топологии (External web services). Эти записи должны ссылаться на внешний IP-адрес. С этого IP-адреса по портам 80 и 443 должен быть сделан пропрос на Reverse Proxy по этим же портам, либо по портам 8080 и 4443 на сам Front-End.

    Так понятно?

    22 марта 2012 г. 11:07
    Модератор
  • Более чем, читаю http://www.buldakov.ru/?p=1912 супер подробно описано, попробую опубликовать... Поправь меня если я чего то не верно скажу.

    У меня уже опубликован lyncdiscover который имеет внешний и который отвечает на запросы из мира и пробрасывает все запросы на Lync FE. Надо добавить имя lync.xxxxxx.com.ua чтобы оно ссылалось на тот же ip и добавить парочку правил в RP для того чтобы запросы приходящие на lync.xxxx.com.ua перенаправлялись на Lync FE. Проброс портов следует осуществить средствами GW или RP данную красоту умеет?


    MS сказали, что эта проблема 99% в неверно настроенном EDGE и такое случается, что не верно работает STUM. Но все порты же проброщены :(
    • Изменено vshihov 22 марта 2012 г. 12:59
    22 марта 2012 г. 12:28
  • Я выступал в качестве редактора и рецензора :) .

    А зачем добавлять ещё правила, тем более, парочку? Не проще ли добавить только одно это имя в уже существующее правило?

    RP - это "умный проброс портов" ;) . Если он напрямую подключен в интернет, то никаких пробросов не нужно, если он внутри сети, то порты 80 и 443 нужно пробросить до него самого.

    22 марта 2012 г. 12:33
    Модератор
  • Необходимо добавить правило, что все приходящие на lync.xxxx.com.ua пробрасывать на ServerFarm?
     Ура Ура .... публикация служб прошла успешно и уже можно зайти на внешние адреса meet и dialin

    Оcталось подружить мобилити и понять ну чего же не хочет звонить.. пошёл читать и смотреть видео о публикации EDGE за NAT... Хотя я пробросил все порты, и разнёс по разным IP роли EDGE...


    • Изменено vshihov 22 марта 2012 г. 14:50
    22 марта 2012 г. 13:23
  • Либо отдельное правило, либо просто добавить это имя в уже существующее. Отдельное правило для каждого имени - не рационально.
    22 марта 2012 г. 15:42
    Модератор
  • Начал звонить, но только 4 секунды :)))))) У меня вообще нет идей почему он так себя поскудно ведёт :(
    23 марта 2012 г. 13:33
  • Антивирусы на клиентах есть?
    23 марта 2012 г. 16:34
    Модератор
  • Уважаемый пользователь!
    В вашей теме отсутствует активность в течение последних 5 дней. При отсутствии каких-либо действий в течение 2 последующих дней, тема будет переведена в разряд обсуждений. Вы можете возобновить дискуссию, просто оставив сообщение в данной теме.

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

    3 апреля 2012 г. 9:50