none
Skype for Business взаимодействие между трастовыми доменами в разных лесах RRS feed

  • Вопрос

  • Доброго времени суток.

    Имеется 2 леса, между доменами которых установлены 2-сторонние доверительные отношения.

    В первом установлен односерверный S4B standard, и прописан тарстовый домен в качестве дополнительного поддерживаемого сип-домена.

    Во втором установлен 2-серверный пул переднего плана Энтерпрайз эдишн.

    В нем домен первого леса так же прописан в качестве дополнительного поддерживаемого сип-домена.

    Добавил в клиенте в первом домене пользователя из второго в качестве пользователя не из моей организации.

    Пользователь добавился с неопределенным статусом, подхватил даже доменный аватар, но сообщения не уходят.

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

    в логах:


    ms-diagnostics: 1003;reason="User does not exist";destination="trusteduser@dom.org.ru";source="SKYPESRV01.maindom.ru"


    • Изменено Mr. Snipfold 26 октября 2018 г. 12:15
    26 октября 2018 г. 11:14

Ответы

Все ответы

  • Вам нужно добавить запись доверенного приложения

    Здесь описана нужная Вам конфигурация 

    26 октября 2018 г. 12:34
  • Добавил все по инструкции, но не работает, как проверить на каком этапе отбивает?

    29 октября 2018 г. 12:32
  • При добавлении сервера из другого леса вышло предупреждение:

    PS C:\Users\Admin> New-CsTrustedApplicationPool -Identity skypedom2.dom2.ru
    -Registrar fepool-ee.dom1.org1.ru -site "Site:ORG1S4B" -requiresreplicati
    on:$false
    ПРЕДУПРЕЖДЕНИЕ: Компьютер skypedom2.dom2.ru из публикуемой топологии не найден в
     Active Directory. Это приведет к ошибкам во время процедуры Enable-CsTopology,
     так как с ее стороны осуществляется попытка подготовить записи Active
    Directory для компьютеров топологии. В случае публикации этой топологии
    потребуется повторный запуск Enable-CsTopology, как только недостающие
    компьютеры будут присоединены к домену.

    Компьютер не найден
    Следующие компьютеры из публикуемой топологии не были найдены в Active
    Directory. Это приведет к ошибкам во время процедуры Enable-CsTopology, так как
     она пытается подготовить записи Active Directory для компьютеров топологии. В
    случае публикации этой топологии потребуется повторный запуск
    Enable-CsTopology, как только недостающие компьютеры будут присоединены к
    домену:

    Это нормально?

    30 октября 2018 г. 6:14
  • Сертификаты на Фронты добавили друг друга? В доверенные.
    30 октября 2018 г. 7:02
  • Да, добавил Root-ca первого в доверенные корневые на сервере пула переднего плана второго и наоборот.

    А каким тестом проверить правильность сертификатов ?\

    30 октября 2018 г. 19:17
  • Пройдитесь еще раз по этому сценарию и проверьте правильно ли Вы все указали.
    31 октября 2018 г. 7:26
  • Да, правильно, но не работает.

    Я сейча пробую через Edge организовать связь, эджи стартовали нормально и даже идет попытка связаться но опять что-то мешает, ошибка:

    ms-diagnostics: 1047;reason="Failed to complete TLS negotiation with a federated peer server";fqdn="dom2edge.dom2.org.ru:5061";ip-address="xxx.xxx.xx.xxx";peer-type="FederatedPartner";winsock-code="10054";winsock-info="The peer forced closure of the connection";source="dom1edge.dom1.mainorg.ru"

    31 октября 2018 г. 14:07
  • Похоже что то с сертификатами не так "Failed to complete TLS negotiation with a federated peer server"

    Проверьте рутовые сертификаты на обоих серверах, что бы все были на своих местах.

    31 октября 2018 г. 14:12
  • С сертификатами разобрался, заработало, только в одну сторону и на одно сообщение, после второго сообщения выбивает ошибку как будто абонент не в сети.

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

    В логах:

    ms-diagnostics: 1033;reason="Previous hop server component did not report diagnostic information";Domain="dom1.org.ru";PeerServer="10.123.123.32";source="SKYPEDOM2.dom2.ru"

    Где 10.123.123.32 - адрес шлюза Avaya aura

    Вопрос - как организовать маршрутизацию, чтобы не нарушить работу шлюза и обеспечить доступность клиентов с первого домена?




    • Изменено Mr. Snipfold 2 ноября 2018 г. 6:16
    2 ноября 2018 г. 6:13
  • Переименовать этот шлюз проблематично? 

    В моем случае мы для ВКС делали разные MatchUri 

    Пример

    Я имею ввиду, для Lync сервера домен .dom2.ru а для ВКС - VCS.dom2.ru
    2 ноября 2018 г. 7:26
  • Спасибо за информацию, попробуем.Временно убрал маршрут до шлюза AVAYA, заработало, но только на одно сообщение, второе сообщение недоставлятся.

    Может быть если используются эджи убрать все статические маршруты?

    Еще вопрос, а можно ли будет использовать созданные для трастовых доменов эджи в дальнейшем  для доступа к скайпу через интернет, создав дополнительный виртуальный сетевой интерфейс в dmz зоне?

    Или для интернета лучше создать отдельный эдж?


    • Изменено Mr. Snipfold 3 ноября 2018 г. 14:05
    3 ноября 2018 г. 13:21
  • Если организации доступны по локальной сети между собой, то должно работать статическими маршрутами без Edge. Но в Вашем случае у ВКС должен домен немного отличатся.

    Edge сервер пробрасывает 3 службы, соответственно 3 внешних интерфейса и один внутренний, или можно эти три службы "подцепить" на один внешний интерфейс но по разным портам. 

    Для корректной работы, Вам нужен выделенный Edge, для внешнего доступа пользователей, публикуйте через реверс прокси (WAP к примеру).

    5 ноября 2018 г. 7:11
  • Да, организации доступны между собой по сети, но почему-то через доверенное приложение не удалось законнектить.

    По эджам, сейчас попробовал с одного эджа запустить веб-страницу другого, в итоге получил:

    https://edge01.dom1.org1.ru  (по внутренней сети)  так же как и по внешней https://sip.dom1.org1.ru

    Ответ:

    Не удается отобразить эту страницу

    Включите TLS 1.0, TLS 1.1 и TLS 1.2 в дополнительных параметрах и повторите попытку подключения к https://sip.dom1.org1.ru . Если ошибка повторяется, возможно, этот сайт использует неподдерживаемый протокол или комплект шифров, например RC4 (ссылка на статью со сведениями), который не считается безопасным. Обратитесь к администратору сайта.

    Это нормально или что-то не то с сертификатами, вроде все сертификаты прописаны, ошибок нет.


    • Изменено Mr. Snipfold 6 ноября 2018 г. 10:38
    6 ноября 2018 г. 10:15
  • На Edge не должна открываться страница. TLS не отключали через реестр? 
    6 ноября 2018 г. 10:43
  • Нет.

    Тогда как устранить ошибку доступа 2-го эджа на первый:

    ms-diagnostics: 1047;reason="Failed to complete TLS negotiation with a federated peer server";fqdn="edge1.dom1.org1.ru:5061";ip-address="10.123.123.68";peer-type="FederatedPartner";winsock-code="10054";winsock-info="The peer forced closure of the connection";source="edge02"

    PS

    10.123.123.68 - это внутренний адрес второго эджа (я развернул эджи во внутренней сети с двумя смежными адресами на одной сетевой карте, внешний адрес 10.123.123.69) может в этом проблема?

    Федеративный тест проходит без проблем с обеих сторон:

    PS C:\Users\Admin> Test-CsFederatedPartner -Domain dom1.org1.ru -TargetFqdn
     edge02.dom2.org2.ru
    ПОДРОБНО: Начато чтение порта прокси-сервера доступа из топологии.
    ПОДРОБНО: Чтение порта прокси-сервера доступа "5061" из топологии успешно
    завершено.
    ПОДРОБНО: Начато чтение сертификата.
    ПОДРОБНО: Чтение сертификата успешно завершено.
    ПОДРОБНО: Выполняется поиск сертификата с именем издателя = "CN=ROOTCA2, DC=dom2,
    DC=org2, DC=ru" и серийным номером = "xxxxxxxx00000000001e".
    ПОДРОБНО: Успешно найден сертификат с соответствующим именем издателя и
    серийным номером.
    ПОДРОБНО: Экземпляр рабочего процесса "............"
    запущен.
    ПОДРОБНО: Выполненная командная строка: "Test-CsFederatedPartner -Domain
    dom1.org1.ru -TargetFqdn edge02.dom2.org2.ru".


    Target Fqdn   : edge02.dom2.org2.ru
    Result        : Success
    Latency       : 00:00:00
    Error Message :
    Diagnosis     :

    ПОДРОБНО: Начат рабочий процесс
    "Microsoft.Rtc.SyntheticTransactions.Workflows.STFederatedPartnerWorkflow".
    Рабочий поток
    "Microsoft.Rtc.SyntheticTransactions.Workflows.STFederatedPartnerWorkflow"
    завершен за "0,022967" с.
    Успешно выполнен рабочий процесс
    "Microsoft.Rtc.SyntheticTransactions.Workflows.STFederatedPartnerWorkflow".
    Начато действие "Options".
    Действие "Options" выполнено за "1,8183546" с.
    ПОДРОБНО: Экземпляр рабочего процесса с ИД
    "............." завершен.
    ПОДРОБНО: Время выполнения рабочего процесса (с): 3,5359872.


    • Изменено Mr. Snipfold 6 ноября 2018 г. 11:30
    6 ноября 2018 г. 11:05
  • Похоже на фаерволы. Между эджами проверьте что бы все порты были открыты. 

    Когда устанавливается соединение, вступает в работу STUN и TURN протоколы которые ищут альтернативные пути. В случае прямой доступности, клиенты свяжутся между собой и будут общаться без посредников (если точка-точка). В Вашем случае, соединение идет через Edge сервера (они выступают посредниками).

    Перепроверьте порты между Edge серверами и от клиента к Edge серверам (и на оборот).


    Возможно по этой причине у Вас не заработал вариант с доверенным приложением.
    6 ноября 2018 г. 11:53
  • по портам 5061, 443 и 4443 телнет проходит без проблем, а какие еще порты проверить?

    И не понятно, почему первое сообщение проходит нормально, а второе отбивает, это получается первым сообщением идет через эджи а потом напрямую?


    • Изменено Mr. Snipfold 6 ноября 2018 г. 12:47
    6 ноября 2018 г. 12:45

  • Для корректной работы, Вам нужен выделенный Edge, для внешнего доступа пользователей, публикуйте через реверс прокси (WAP к примеру).

    А можно просто отдельный Edge, который одним VLAN-ом будет крутиться в DMZ зоне, другим в корпоративной сети, для чего нужен реверс-прокси, для дополнительной безопасности?

    6 ноября 2018 г. 12:54
  • По портам Вы найдете информацию здесь

    По поводу двух пулов Edge server. Не уверен что такая конфигурация заработает, через него вы публикуете службы. Здесь нужно кейс открывать в MS.

    Реверс-прокси нужен для публикации к ресурсам, доступа клиентов и веб конференций, ну и дополнительная безопасность.

    6 ноября 2018 г. 13:14
  • ОК, возможно придется 2 организации пускать через внешний эдж.

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

    Вопрос важный, потому как сейчас формируем задачу для связистов, нужно ли открывать все порты от клиента до федеративного эджа или соседнего фронта, либо открыть им порты только до своих фронтов?

    а еще клиент взаимодействует с Exchange и AD, нужно ли ему ходить на соседний AD и exchange?


    • Изменено Mr. Snipfold 6 ноября 2018 г. 14:13
    6 ноября 2018 г. 14:12
  • Начну с последнего.

    Доступ к Exchange и AD не нужен, если через федерацию а не доверенное приложение.

    Только от клиента к своему edge server и наоборот и только между edge серверами двух организаций.

    Если между клиентами нет прямого доступа, то они используют edge сервер как посредник. Даже внутри организации, если между клиентскими подсетями не будет доступа а через edge будет то клиенты будут друг с другом работать через edge сервер.

    6 ноября 2018 г. 14:43
  • Не нашел я причину того что между федеративными клиентами уходит только первое сообщение, может это из-за того что на каждом эдже одна сетевая с двумя адресами, получается внутренний и внешний адрес в одной подсети.

    Попробую на эджевых виртуалках добавить по сетевому интерфейсу, и соединить эти интерфейсы по всем портам, может проблема разрешится?

    7 ноября 2018 г. 14:02
  • Как у Вас Edge сервера сейчас сконфигурированы? У них по одному сетевому интерфейсу?

    У Вас должен быть как минимум 1 внутренний интерфейс и 1 наружу. Тот который наружу объединит в себе 3 роли, AV, SIP и Webconf. 

    Но опять же, я не рекомендую использовать эджи что бы связать 2 организации доступные между собой по сети. Лучше добить доверенное приложение. Создать приложения и маршруты, проверить открытые порты между пользовательскими подсетями (ссылка выше) и серверами Front End, проверить установку и корректное расположение сертификатов противоположных организаций.

    7 ноября 2018 г. 14:36
  • Ок, эджи пока уберу из федератвных доменов, оставлю для внешнего доступа.

    По доверенному приложению, может в маршрутизации использовать не TLSRoute а TCPRoute по аналогии со шлюзом AVAYA Scopia Video Gateway ?

    И не global а Identity : Service:Registrar:skypeodom1.org1.ru ???


    Скрипт сейчас выглядит так:

    New-CsTrustedApplicationPool -Identity skypedom2.org2.ru -Registrar region1-fepool-ee.dom1.org1.ru -site "Site:org1S4B" -requiresreplication:$false
    new-cstrustedapplication -identity skypedom2.org2.ru/skypedom2 -port 5061
    Enable-CSTopology

    $Route1=New-CsStaticRoute -TLSRoute -Destination "skypedom2.org2.ru" -MatchUri "dom2.org2.ru" –Port 5061 -UseDefaultCertificate $true
    Set-CsStaticRoutingConfiguration -Identity global -Route @{Add=$Route1}

    Выполняется с предупреждением:

     PS C:\Users\Admin> New-CsTrustedApplicationPool -Identity skypedom1.org2.ru
    -Registrar region1-fepool-ee.dom2.org1.ru -site "Site:org1S4B" -requiresreplicati
    on:$false
    ПРЕДУПРЕЖДЕНИЕ: Компьютер skypedom1.org2.ru из публикуемой топологии не найден в
     Active Directory. Это приведет к ошибкам во время процедуры Enable-CsTopology,
     так как с ее стороны осуществляется попытка подготовить записи Active
    Directory для компьютеров топологии. В случае публикации этой топологии
    потребуется повторный запуск Enable-CsTopology, как только недостающие
    компьютеры будут присоединены к домену.
    
    Компьютер не найден
    Следующие компьютеры из публикуемой топологии не были найдены в Active
    Directory. Это приведет к ошибкам во время процедуры Enable-CsTopology, так как
     она пытается подготовить записи Active Directory для компьютеров топологии. В
    случае публикации этой топологии потребуется повторный запуск
    Enable-CsTopology, как только недостающие компьютеры будут присоединены к
    домену:
    
    skypedom1.org2.ru
    [Y] Да - Y  [A] Да для всех - A  [N] Нет - N  [L] Нет для всех - L
    [S] Приостановить - S[?] Справка (значением по умолчанию является "Y"): Y
    ПРЕДУПРЕЖДЕНИЕ: Для выполнения операции необходимы следующие изменения.
    Все еще необходимо запустить Enable-CsTopology, чтобы все изменения вступили в
    силу.
    
    
    Identity             : 1-ExternalServer-7
    Registrar            : Registrar:region1-fepool-ee.dom2.org1.ru
    FileStore            :
    ThrottleAsServer     : True
    TreatAsAuthenticated : True
    OutboundOnly         : False
    RequiresReplication  : False
    AudioPortStart       :
    AudioPortCount       : 0
    AppSharingPortStart  :
    AppSharingPortCount  : 0
    VideoPortStart       :
    VideoPortCount       : 0
    Applications         : {}
    DependentServiceList : {}
    ServiceId            : 1-ExternalServer-7
    SiteId               : Site:org1S4B
    PoolFqdn             : skypedom1.org2.ru
    Version              : 7
    Role                 : TrustedApplicationPool
    
    
    
    PS C:\Users\Admin> new-cstrustedapplication -identity skypedom1.org2.ru/skyp
    edom1 -port 5061
    ПРЕДУПРЕЖДЕНИЕ: Для выполнения операции необходимы следующие изменения.
    Все еще необходимо запустить Enable-CsTopology, чтобы все изменения вступили в
    силу.
    
    
    Identity                   : skypedom1.org2.ru/urn:application:skypedom1
    ComputerGruus              : {skypedom1.org2.ru sip:skypedom1.org2.ru@dom2.org1
                                 .ru;gruu;opaque=srvr:skypedom1:NfQKKUkxu1SmFwuw7yH
                                 szgAA}
    ServiceGruu                : sip:skypedom1.org2.ru@dom2.org1.ru;gruu;opaque=sr
                                 vr:skypedom1:NfQKKUkxu1SmFwuw7yHszgAA
    Protocol                   : Mtls
    ApplicationId              : urn:application:skypedom1
    TrustedApplicationPoolFqdn : skypedom1.org2.ru
    Port                       : 5061
    LegacyApplicationName      : skypedom1
    
    


    • Изменено Mr. Snipfold 8 ноября 2018 г. 6:32
    8 ноября 2018 г. 6:30
  • Последние редакции ВКС Cisco (CMS,VCS), полностью отказались от не шифрованных соединений.

    Обратите внимание еще раз на статью:

    Нужно обеспечить распознавание имен (не только компьютеров и серверов: не забывайте про SIP домены!) – подружить DNS

    8 ноября 2018 г. 7:05
  • Распознавание имен без проблем, DNS-зоны проброшены, ертификаты прописаны, маршруты тоже, порты все открыты, что еще ему надо????

    Via: SIP/2.0/TLS 192.168.228.10:50122;ms-received-port=50122;ms-received-cid=19FC00

    ms-diagnostics: 1047;reason="Failed to complete TLS negotiation with a federated peer server";fqdn="skypedom2.org2.ru:5061";ip-address="192.168.200.21";peer-type="FederatedPartner";winsock-code="10054";winsock-info="The peer forced closure of the connection";source="skyedge.dom1.org1.ru"

    Server: RTC/6.0

    Content-Length: 0

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

    8 ноября 2018 г. 7:18
  • Доверенные приложения создали? Покажите пожалуйста вывод Get-CsTrustedApplicationPool

    Маршруты создали? Покажите Get-CsStaticRoutingConfiguration

    Попытка обращения на Edge идет когда Front End не может найти у себя информацию про искомый sip домен, он считает что это федеративный пользователь и отправляет соединение на Edge

    Имена которые Вы указали, нормально резолвятся между серверами и клиентами доменов?

    8 ноября 2018 г. 7:32
  • PS C:\Users\Admin> Get-CsTrustedApplicationPool
    
    ПОДРОБНО: Сопоставление с шаблоном подстановочного знака:
    "Microsoft.Rtc.Management.Xds.XdsGlobalRelativeIdentityFilter"
    ПОДРОБНО: Сопоставление с шаблоном подстановочного знака:
    "Microsoft.Rtc.Management.Xds.XdsGlobalRelativeIdentityFilter"
    
    
    Identity             : TrustedApplicationPool:iviewpool.dom1.org1.ru
    Registrar            : Registrar:region1-fepool-ee.dom1.org1.ru
    FileStore            :
    ThrottleAsServer     : True
    TreatAsAuthenticated : True
    OutboundOnly         : False
    RequiresReplication  : False
    AudioPortStart       :
    AudioPortCount       : 0
    AppSharingPortStart  :
    AppSharingPortCount  : 0
    VideoPortStart       :
    VideoPortCount       : 0
    Applications         : {urn:application:trustedserver}
    DependentServiceList : {}
    ServiceId            : 1-ExternalServer-6
    SiteId               : Site:ORG1S4B
    PoolFqdn             : iviewpool.dom1.org1.ru
    Version              : 7
    Role                 : TrustedApplicationPool
    
    Identity             : TrustedApplicationPool:skypedom2.org2.ru
    Registrar            : Registrar:region1-fepool-ee.dom1.org1.ru
    FileStore            :
    ThrottleAsServer     : True
    TreatAsAuthenticated : True
    OutboundOnly         : False
    RequiresReplication  : False
    AudioPortStart       :
    AudioPortCount       : 0
    AppSharingPortStart  :
    AppSharingPortCount  : 0
    VideoPortStart       :
    VideoPortCount       : 0
    Applications         : {urn:application:skypedom2}
    DependentServiceList : {}
    ServiceId            : 1-ExternalServer-7
    SiteId               : Site:ORG1S4B
    PoolFqdn             : skypedom2.org2.ru
    Version              : 7
    Role                 : TrustedApplicationPool
    
    
    
    PS C:\Users\Admin>
    
    
    PS C:\Users\Admin>
    PS C:\Users\Admin> Get-CsStaticRoutingConfiguration
    ПОДРОБНО: Сопоставление с шаблоном подстановочного знака:
    "System.Management.Automation.WildcardPattern"
    ПОДРОБНО: Сопоставление с шаблоном подстановочного знака:
    "System.Management.Automation.WildcardPattern"
    
    
    Identity : Global
    Route    : {MatchUri=dom2.org2.ru;MatchOnlyPhoneUri=False;Enabled=True;ReplaceHo
               stInRequestUri=False}
    
    ПОДРОБНО: Сопоставление с шаблоном подстановочного знака:
    "System.Management.Automation.WildcardPattern"
    Identity : Service:Registrar:region1-fepool-ee.dom1.org1.ru
    Route    : {MatchUri=avaya.org1.ru;MatchOnlyPhoneUri=False;Enabled=True;Replace
               HostInRequestUri=False}
    
    
    
    PS C:\Users\Admin>

    Имена резолвятся нормально.

    PS C:\Users\Admin> (Get-CsStaticRoutingConfiguration).Route
    
    ПОДРОБНО: Сопоставление с шаблоном подстановочного знака:
    "System.Management.Automation.WildcardPattern"
    ПОДРОБНО: Сопоставление с шаблоном подстановочного знака:
    "System.Management.Automation.WildcardPattern"
    ПОДРОБНО: Сопоставление с шаблоном подстановочного знака:
    "System.Management.Automation.WildcardPattern"
    
    
    Transport               : TransportChoice=Certificate=Microsoft.Rtc.Management.
                              WritableConfig.Settings.SipProxy.UseDefaultCert;Fqdn=
                              skypedom2.org2.ru;Port=5061
    MatchUri                : dom2.org2.ru
    MatchOnlyPhoneUri       : False
    Enabled                 : True
    ReplaceHostInRequestUri : False
    Element                 : <Route xmlns="urn:schema:Microsoft.Rtc.Management.Set
                              tings.SipProxy.2008" MatchUri="dom2.org2.ru" MatchOnly
                              PhoneUri="false" Enabled="true" ReplaceHostInRequestU
                              ri="false">
                                <Transport Port="5061">
                                  <TLS Fqdn="skypedom2.org2.ru">
                                    <UseDefaultCert />
                                  </TLS>
                                </Transport>
                              </Route>
    
    Transport               : TransportChoice=IPAddress=10.123.123.32;Port=5060
    MatchUri                : avaya.org1.ru
    MatchOnlyPhoneUri       : False
    Enabled                 : True
    ReplaceHostInRequestUri : False
    Element                 : <Route xmlns="urn:schema:Microsoft.Rtc.Management.Set
                              tings.SipProxy.2008" MatchUri="avaya.org1.ru" MatchOn
                              lyPhoneUri="false" Enabled="true" ReplaceHostInReques
                              tUri="false">
                                <Transport Port="5060">
                                  <TCP IPAddress="10.123.123.32" />
                                </Transport>
                              </Route>
    
    
    
    PS C:\Users\Admin>
    

    • Изменено Mr. Snipfold 8 ноября 2018 г. 8:39
    8 ноября 2018 г. 8:34
  • Что в логах клиента происходит когда Вы пытаетесь написать контрагенту из другого домена?
    8 ноября 2018 г. 10:42
  • 11/08/2018|14:09:55.821 1090:5D4 INFO  :: End of Data Received -192.168.221.121:5061 (To Local Address: 192.168.208.111:56359) 834 bytes
    11/08/2018|14:09:55.821 1090:5D4 TRACE :: CSIPMessageCollator::AsyncProcessSipMsg - [0x0CBC7988]
    11/08/2018|14:09:55.821 1090:5D4 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x0CBC7988]
    11/08/2018|14:09:55.821 1090:5D4 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x0CD79E08]
    11/08/2018|14:09:55.821 1090:5D4 TRACE :: SECURE_SOCKET: decrypting buffer size: 245 (first 8):
    11/08/2018|14:09:55.821 1090:5D4 TRACE :: 	17 03 03 00 F0 4A B0 29  :....рJ°)
    11/08/2018|14:09:55.821 1090:5D4 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x0CD1A380]
    11/08/2018|14:09:55.821 1090:5D4 TRACE :: CSIPCompression::DecompressRecvBuffer decompression, BytesProcessed = 175, cbDataDeCompressed = 837, psDecompressedData = 1D0E4408 
    11/08/2018|14:09:55.821 1090:5D4 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x0CAB78D8]
    11/08/2018|14:09:55.821 1090:5D4 INFO  :: Data Received -192.168.221.121:5061 (To Local Address: 192.168.208.111:56359) 837 bytes:
    11/08/2018|14:09:55.821 1090:5D4 INFO  :: SIP/2.0 404 Not Found
    Authentication-Info: TLS-DSK qop="auth", opaque="635A6903", srand="FA2ED995", snum="72", rspauth="2dd11e86d1f6211c3b178a50f198d651614eb2038541902aae650a0c6be1a1770591713da7232a2ecffa5374eae09f60", targetname="SKYPEDOM2.org2.ru", realm="SIP Communications Service", version=4
    From: "Admin"<sip:Adminov@dom2.org2.ru>;tag=83ebb004f0;epid=d1aebccd68
    To: <sip:Adminovya@dom1.org1.ru>;tag=BCD35D057819961D4DDD4F5F2EA46986
    Call-ID: 72c08cae977e428192fd58f2d1dcab2c
    CSeq: 1 SUBSCRIBE
    Via: SIP/2.0/TLS 192.168.208.111:56359;ms-received-port=56359;ms-received-cid=456700
    ms-diagnostics: 1008;reason="Unable to resolve DNS SRV record";domain="dom1.org1.ru";dns-srv-result="NegativeResult";dns-source="InternalCache";source="org2skyedge"
    Server: RTC/6.0
    Content-Length: 0
    
    
    11/08/2018|14:09:55.821 1090:5D4 INFO  :: End of Data Received -192.168.221.121:5061 (To Local Address: 192.168.208.111:56359) 837 bytes
    11/08/2018|14:09:55.821 1090:5D4 TRACE :: CSIPMessageCollator::AsyncProcessSipMsg - [0x0CBC7988]
    11/08/2018|14:09:55.821 1090:5D4 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x0CBC7988]
    11/08/2018|14:09:55.821 1090:5D4 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x0CD79E08]
    11/08/2018|14:09:55.821 1090:5D4 TRACE :: verified buffer: <TLS-DSK><B04EC0BD><71><SIP Communications Service><SKYPEDOM2.org2.ru><f1191f6336b14d4b9b4d477cc4b10f75><1><INVITE><sip:Adminov@dom2.org2.ru><6b3732f29d><sip:Adminovya@dom1.org1.ru><BCD35D057819961D4DDD4F5F2EA46986><><><><404>-length-228. signature:278426334a154f83356679cad7bfddf072295d3181a3362defb798fcf71dad5d347beb3109a5ffe248ceae6bd84407ba
    11/08/2018|14:09:55.821 1090:5D4 INFO  :: Trxn corr-id (216DA048), SIP msg corr-id (6b4c8dd9)
    11/08/2018|14:09:55.821 1090:5D4 TRACE :: AddTag 0CD6B788-<sip:Adminovya@dom1.org1.ru>;tag=BCD35D057819961D4DDD4F5F2EA46986, local=sip:Adminov@dom2.org2.ru
    11/08/2018|14:09:55.821 1090:5D4 INFO  :: Sending Packet - 192.168.221.121:5061 (From Local Address: 192.168.208.111:56359) 655 bytes:
    11/08/2018|14:09:55.821 1090:5D4 INFO  :: ACK sip:Adminovya@dom1.org1.ru SIP/2.0
    Via: SIP/2.0/TLS 192.168.208.111:56359
    Max-Forwards: 70
    From: <sip:Adminov@dom2.org2.ru>;tag=6b3732f29d;epid=d1aebccd68
    To: <sip:Adminovya@dom1.org1.ru>;tag=BCD35D057819961D4DDD4F5F2EA46986
    Call-ID: f1191f6336b14d4b9b4d477cc4b10f75
    CSeq: 1 ACK
    User-Agent: UCCAPI/16.0.4756.1000 OC/16.0.4756.1000 (Skype for Business)
    Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="635A6903", targetname="SKYPEDOM2.org2.ru", crand="95a2e177", cnum="66", response="59adacfc95da55779e3192dd6e4e193dbba36bba0581b233bef0e5aa39e0424ae54f4882cf4336556987212a9439a5ad"
    
    

    8 ноября 2018 г. 11:18

  • "Unable to resolve DNS SRV record";domain="dom1.org1.ru"
    Судя по всему он у Вас продолжает идти через Edge. С этого ПК резолвится Front End другой организации?
    8 ноября 2018 г. 11:50
  • Да, причем работает раундробин на имя пула по очереди резолвятся адреса 3-х серверов пула.

    8 ноября 2018 г. 12:05
  • Сейчас нашел ошибку в эджах, там на внешку шло то же самое имя что и на внутрянку, сейчас добавил по виртуальному сетевому интерфейсу на каждый эдж и связисты связывают вланы между организациями, внутренние адреса эджей убрали с акцесс-листов.

    8 ноября 2018 г. 12:07
  • Если с Edge серверами, то лучше делайте по архитектуре. Выставляйте 2 организации наружу и пусть они через внешку общаются.
    8 ноября 2018 г. 12:38
  • Заработало как надо!!!!

    С эджами.

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

    8 ноября 2018 г. 12:52
  • Если с Edge серверами, то лучше делайте по архитектуре. Выставляйте 2 организации наружу и пусть они через внешку общаются.

    А со вторым эджем не получится? в федерации же явно прописано, от какого домена на какой эдж ходить.

    В принципе можно на одном эдже цисками трафик между организациями не пускать наружу, это со связистами решим.

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

    На сколько я знаю, такая возможность у MS есть, но только с клиентами, вошедшими в скайп через учетную запись Microsoft.

    Тогда федерация будет через сайты Microsoft и соответственно трафик будет идти через сервера MS

    Вопрос - на сколько безопасно такое общение в плане конфиденциальности.

    И последнее, на последних версиях ios возникли трудности подключения iphone к S4B через VPN непосредственно к фронту.

    Вопрос - такая схема подключения с доменным сертификатом ONLY, купленных нет, будет работоспособна, есть ли подробные инструкции по подключению яблочных устройств к скайпу?  С андроидом всё ОК, проблем не было.

    8 ноября 2018 г. 19:04
  • Начну с последнего.

    Яблокам нужны честные сертификаты, у нас тоже с ними были проблемы. Поэтому тут не подскажу. У меня они подключаются через реверс-прокси с честно купленным Комодовским сертификатом.

    По поводу обычного скайпа, мы сделали такую федерацию, она работает. Но как всегда есть "Но". У МС Скайпа генерится какой то чудо идентификатор, который нигде не указан в учетной записи, поэтому проще искать с обычного Скайпа корпоративных пользователей по sip имени и добавлять их к себе. После этого они должны добавить друг друга в контакты к себе и тогда только можно нормально будет переписываться.

    Еще один подводный камень с которым я столкнулся, Вам нужно будет зарегистрировать свой sip домен на сайте https://pic.lync.com

    Причем на сайте лучше в первую очередь зарегистрироваться.

    9 ноября 2018 г. 7:00
  • У нас в организации 1 сейчас развернут ARR для того чтобы мобильные клиенты ходили на почтовый сервер Exchange

    Вопрос - можно ли этот вебреверспрокси задействовать для скайпа фо бизнес?

    Если да, то где можно найти примерчик подключения, настраивал его не я, мне нужна информация.

    Его подключать непосредственно к фронту или к эджу?

    9 ноября 2018 г. 17:38
  • Проброс делается на Front End сервер, на них Вы должны указать имя для внешнего подключения. 

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

    По поводу ARR не подскажу, нужно искать на просторах Интернета и на офф сайтах.

    12 ноября 2018 г. 7:07
  • А имя для внешнего подключения может совпадать и именем внутреннего?

    Уже имеется в наличии купленный сертификат, на весь домен dom1.ru, я его установил на вебпрокси в персональные и в настройках IIS назначил на него 443 + добавил в доверенные корневые доменный центр авторизации и USERTrust

    Этого достаточно или нужно сертифицировать отдельно lyncdiscover.org1.dom1.ru, meet.org1.dom1.ru dialin.org1.dom1.ru итд?

    И какие записи  прописывать в ДНС интернет зоне ?

    Запись A -  IP внешней ноги веб прокси -  skype4b.org1.dom1.ru

    Запись A -  IP внешней ноги веб прокси -  skype02.org1.dom1.ru

    Запись A -  IP внешней ноги веб прокси -  skype03.org1.dom1.ru

    Запись A -  IP внешней ноги веб прокси -  region1-fepool-ee.org1.dom1.ru

    Тоесть все записи пула и трех его фронтов должны указывать на веб-прокси, верно?

    И запись SRV

    Домен: org1.dom1.ru

    Служба: _sipinternal

    Протокол: _tcp

    0

    0

    Порт: 5061

    Узел этой службы: region1-fepool-ee.org1.dom1.ru

    Верно?

    19 ноября 2018 г. 19:44
  • На реверс-прокси:
    webapp.domain.com (если есть такая роль)
    lwa.domain.com
    lyncdiscover.domain.com

    На edge сервера (эти имена должны присутствовать в сертификате, WildeCard не подходит):

    sip.domain.com

    av.domain.com

    webconf.domain.com

    Если все через один интерфейс то только имя sip.domain.com

    Имя записи

    Приоритет

    Вес

    Порт

    Значение

    _sip._tls

    0

    0

    443

    sip.domain.com

    _sipfederationtls._tcp

    0

    0

    5061

    sip.domain.com


    21 ноября 2018 г. 14:37
  • Веб-прокси вроде заработал, когда ввожу в интернете https://lyncdiscover.dom1.ru

    В ответ прилетает xml следующего содержания:

    XML-файлом не связана ни одна таблица стилей. Ниже показано дерево элементов.
          <resource rel="root" href="https://region1-fepool-ee.org1.dom1.ru/Autodiscover/AutodiscoverService.svc/root?originalDomain=dom1.ru"><link rel="user" href="https://region1-fepool-ee.org1.dom1.ru/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=dom1.ru"/><link rel="xframe" href="https://region1-fepool-ee.org1.dom1.ru/Autodiscover/XFrame/XFrame.html"/></resource>

    А вот когда ввожу https://meet.dom1.ru в ответ прилетает:

    Ошибка сервера

    <fieldset>

    403 - запрещено. Доступ запрещен.

    Предоставленные учетные данные не дают права на просмотр этого каталога или страницы.

    </fieldset>

    В чем может быть проблема?

    Меня смущает то что линкдискавер возвращает внутреннее доменное имя пула переднего плана, причем внутренний домен называется org1.dom1.ru а внешний dom1.ru, причем получается домен 2 порядка является корневым в лесу, может в этом проблема, хотя вебпрокси правильно пробросил, если линкдискавер ответил.

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

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

    21 ноября 2018 г. 19:33
  • Вы в конфигурации топологии должны били прописать имя для внешнего подключения. 

    Мобильные клиенты подключаются через edge по SRV записи, потому что из за своей простоты они не знают автодискаверов и им нужно явно отдать куда, по какому протоколу и порту нужно подключатся.

    Роль реверс-прокси это подключения внешних клиентов и доступ к веб ресурсам, таких как WebApp

    Весь остальной трафик, медийный и протоколы подключения STUN/TURN идут через edge сервера. В том числе мобильные клиенты (повторюсь) потому что с autodiscover они не работают.

    22 ноября 2018 г. 7:21
  • Ясно.

    Iphone подключился через ARR но только в режиме сообщений, звук, видео и презентации не работают.

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

    PS

    Сейчас дал задание сетевикам на открытие портов на эдж в диапазоне 50000-60000

    И сразу возникли вопросы у службы безопасности, а зачем так много портов открывать?

    Вопрос - диапазон медиапортов как-то настраивается или мобильные клиенты автоматически выбирают из заданного по умолчанию диапазона?


    • Изменено Mr. Snipfold 22 ноября 2018 г. 8:31
    22 ноября 2018 г. 8:11
  • И еще момент, при автонастройке мобильных устройств я ввожу sip-адрес, который содержит домен второго  уровня (IvanovIP@org1.dom1.ru)  а во внешней сети у провайдера задействован домен 1-го уровня (dom1.ru) и автонастройщик будет искать lyncdiscovery.org1.dom1.ru, он  берет из адреса домен второго уровня и попытается к нему обратиться, найти в нем SRV-запись, по крайней мере я такое наблюдал на ноуте с виндовым S4B.

    Как разрешить такую ситуацию?

    22 ноября 2018 г. 10:37
  • На мобильных используйте S4B для подключения к Lync Server

    Выбирается любой свободный порт из диапазона для медийного трафика, в связи с этим и диапазон большой.

    50 000 по 50 003 должны быть открыты и по TCP для удаленного управления (разшарить рабочий стол).

    По последнему вопросу.

    У Вас SIP не соответствует почтовому адресу?

    Наверное здесь Ваш вопрос: Google

    22 ноября 2018 г. 12:05
  • Добавил домен 1 уровня в качестве дополнительного, перевыпустил сертификаты на всех 3-х серверах фронтпула, прописал в DNS внутренней зоны, сделал алиасы на домен 2 уровня на dialin meet и autodiscovery, meet один раз сработал, потом снова ошибки 403 и 404

    Как всё-таки сделать проброс, может в ARR сделать подстановки чтобы принимало из интернета dom1.ru а выдавало во внутреннюю сеть org1.dom1.ru ?

    А может раундробин виноват:У меня в DNS dialin.org1.dom1.ru meet.org1.dom1.ru lyncdiscover.org1.dom1.ru и lyncdiscoverinternal.org1.dom1.ru ссылаются на все 3 фронта.

    Как вообще правильно прописывать dns внешние и внутренние если разные домены?


    • Изменено Mr. Snipfold 22 ноября 2018 г. 14:30
    22 ноября 2018 г. 14:14
  • В построителе топологий, указать внешний домен в внешних веб службах.

    В настройках пула переднего плана.

    22 ноября 2018 г. 15:26
  • во внешних службах назначается внешнее доменное имя пула переднего плана.

    Я имею ввиду когда клиенту по почте приходит ссылка

    https://meet.org1.dom1.ru/admin/NBV5DL24?sl=1

    то перейдя по ней в браузере возникает ошибка, потому как домен 2 уровня во внешке не существует.

    Как временное решение я прописал в хостах

    <внешний айпи ARR> meet.org1.dom1.ru
    <внешний айпи ARR> dialin.org1.dom1.ru

    в этом случае ругнулось на сертификат, но пропустило на присоединение к собранию, правда только чат.

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

    Хотя сертификат вилдкард, на *.dom1.ru, должен принимать поддомен *.org.dom1.ru но по факту не принимает.

    22 ноября 2018 г. 21:16
  • PS

    А есть ли у S4B что-то тип OWA Exchange-вого (LWA???) ?

    И аналог виртуальных каталогов.

    В экченже командой

    Set-OwaVirtualDirectory -Identity "Contoso\owa (default Web site)" -ExternalUrl "https://consto.com/owa"

    Я задаю внешний адрес веб-приложения.

    Есть ли что-нибудь подобное в Skype for Business?

    22 ноября 2018 г. 21:36
  • Еще один момент.

    Когда конфигурировал 2-ой эдж то выдало предупреждения что федерация возможно только с одним, я оставил федерацию для первого эджа, который связывает трастовые домены, а второй стал основным маршрутом пула.

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

    Тогда придется еще один пул переднего плана поднимать и на него второй эдж линковать?

    Или можно как-нибудь маршрутами через команды PowerShell разрулить.

    Может нужно пул Директор поднимать?

    23 ноября 2018 г. 8:02
  • PS

    А для чего на эдже нужно разделять адреса на sip av и webconf ?

    В топологии допускается всё в одном на имя sip, если я так пропишу, проблем не будет?

    23 ноября 2018 г. 8:45
  • Можно на один sip по разным портам. Разделяют по "лучшей практике".

    По поводу эджей и фронтов я Вам писал выше. Сделайте по человечески, пустите 2 организации через федерацию, пусть через Интернет общаются между собой и остальным миром.

    23 ноября 2018 г. 9:12
  • Ок, сделаю, пока настраиваю эдж на внешке, порты телнетятся, но при входе с ноута (Win 8) (внешний сервер - sip.dom1.ru) пишет Ошибка проверки сертификата с сервера, в чем может быть проблема, какие сертификаты проверить, если на iphone ввожу в качестве внешнего сервера sip.dom1.ru просто отбивает, в логах клиента (windows)  идет попытка  коннекта на реверспрокси по порту 5061 и отбивает, может на реверспрокси открыть 5061?

    23 ноября 2018 г. 11:14
  • Упс ...  забыл NAT прописать, скорее всего из-за него проблемы.

    23 ноября 2018 г. 12:03
  • Заработало!!!!  С 2-мя эджами.

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

    Вопрос - а для чего нужен на эдже 444-ый, для презентаций?

    23 ноября 2018 г. 20:28
  • Ps

    Не нашел  в мобильном приложении сохраняемого чата, эта функция недоступна или я что-то не доставил?

    И когда приложение свернуто (iphone) невозможно дозвониться, только после запуска приложения всплывает сообщение о пропущенных звонках/беседах, можно ли настроить чтобы как в обычном скайпе, звонок активировал приложение?

    • Изменено Mr. Snipfold 26 ноября 2018 г. 6:11
    26 ноября 2018 г. 5:45
  • а на ноуте виндовом, почему-то не коннектится из интернета, пробовал указывать в качестве серверов и эдж и реверсвебпрокси, когда указываю эдж - ошибка сертификата, когда реверспрокси -ошибка "Мы столкнулись с проблемой при подключении к серверу", он пытается войти на прокси по порту 5061, который закрыт.

    26 ноября 2018 г. 6:22
  • Мобильные клиенты не дают абсолютно всего функционала. Для реверс прокси (подключения клиентов) можно использовать wildcard, или смотрите что бы все имена были в Вашем San Сертификате. Перепроверьте повторно все необходимые порты.
    26 ноября 2018 г. 6:58
  • Показ рабочего стола работает, а вот показ презентации и доска рисования -нет.

    Получается с мобильного только видео, звук и сообщения.

    26 ноября 2018 г. 8:14
  • С ноутбука через интернет-веб удалось подключиться к собранию, через плагин, здесь интерактивная доска работает, а презентация отбивается, сначала пишет соединение с сервером успешно, далее идет загрузка и в конце отбой - некоторые функции общего доступа недоступны из-за проблем подключения к серверу.

    Вопрос - я так понимаю идет коннект к Office online server, какие порты должны быть открыты от EDGE до OOS, или может OOS нужно пробрасывать дополнительно?

    26 ноября 2018 г. 8:54
  • пробросил OOS, заработала презентация с ноута.

    Кстати, сменил у тестовой учетной записи sip-адрес с sip:test@org1.dom1.ru на внешний sip:test@dom1.ru и сразу сработал autodiscovery, тоесть то что прописал в SRV записи во внешнем DNS

    Вопрос - а можно ли иметь две sip-записи у одного пользователя типа sip:user@org1.dom1.ru и sip:user@dom1.ru ?

    27 ноября 2018 г. 11:26
  • На сколько я знаю, то нет. У четной записи может быть один sip. Коллеги меня поправят если я не прав.
    27 ноября 2018 г. 13:40
  • PS

    Клиент Skype for Business (от офиса 2016) на ноутбуке, который в интернете запустился используя EDGE только тогда, когда я прописал в доверенные корневые доменный ROOT-CA сертификат.

    Без него ругалась - ошибка получения сертификата с сервера.

    Интересно, на маках тоже прописывать доменный сертификат?

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


    • Изменено Mr. Snipfold 27 ноября 2018 г. 13:53
    27 ноября 2018 г. 13:48
  • Вы судя по всему не правильно edge сервера настроили. На внешнем интерфейсе Вы указали внешний сертификат SAN?
    27 ноября 2018 г. 15:25
  • Да, по умолчанию, нужно вилкард ?, так я его добавил в оснастке сертификатов в персональные, рядом с установленными в установщике скайпа, когда на веб-форму захожу https://sip.dom1.ru на сертификат не ругается.

    Что-то еще нужно настроить?

    28 ноября 2018 г. 6:17
  • Вы когда настраиваете сертификаты на edge сервере, указываете на внешний интерфейс/интерфейсы какой сертификат? На edge сервера нельзя ставить *.domain.com только именованный, пример sip.domain.com

    WildCard можно использовать на реверс-прокси для подключения пользователей.

    28 ноября 2018 г. 7:05
  • Ясно, тоесть нужно заказывать руцентру  отдельный сертификат на sip.dom1.ru av.dom1.ru и webconf.dom1.ru

    Хорошо, спасибо за информацию

    28 ноября 2018 г. 7:14
  • Всё работает нормально, кроме одного.

    Когда пользователь из трастового домена (org2.dom2.ru) присоединяется к конференции по ссылке, сгенерированной в 1-ом домене (org1.dom1.ru) то звук и видео передается нормально а при показе презентации или доски рисования выдает ошибку:

    И при подключении пользователь из трастового домена ожидает подтверждения.

    Скайпы трастовых доменов объединены федерацией через Эджи.

    В чем может быть проблема?

    В логах:

    ms-diagnostics: 2019;reason="Report error service is not available";source="SKYPEORG2.dom2.ru"

    4 декабря 2018 г. 5:31
  • Если подключаться к собранию через Web App гостем (т.к. учетные данные из другого домена не принимаются) то всё ОК

    Вопрос, это действительно ошибка DNS или может в функционале Skype For Business не предусмотрен показ содержимого для федеративной организации?



    • Изменено Mr. Snipfold 4 декабря 2018 г. 5:46
    4 декабря 2018 г. 5:44
  • Презентации идут через сервер OFFICE WEB APPS. Проверяйте его доступность с проблемного АРМ, порты, DNS.
    4 декабря 2018 г. 7:01
  • OOS доступен, дело не в нем, такая же ошибка возникает при показе доски для рисования, а демонстрация экрана проходит нормально.


    4 декабря 2018 г. 7:53
  • PS может быть дело во 2-ом эдже?

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

    Вопрос  - конфигурация с одним эджем не создаст проблем с нагрузкой?

    4 декабря 2018 г. 8:24
  • Убрал второй эдж для связи между организациями, назначил для федерации один единственный и всё вернулось в прежнее состояние :(  Односторонняя связь, с первого домена пользователи второго видны, обратно нет, придется возвращать обратно второй эдж.

    4 декабря 2018 г. 9:10
  • Проблема с Эджем.

    Подключился вместо фронта на эдж org1 клиентом от Office 2016  и опять блокирует  содержимое.

    Вопрос - где искать проблему - от эджа до фронтов или до эджа???

    Вероятно какие-то порты зарыты.

    Самое интересное Эдж org2 таких проблем не имеет, если подключиться к нему напрямую то конференция и доска рисования открываются без проблем.

    Как такое может быть?

    • Изменено Mr. Snipfold 4 декабря 2018 г. 10:25
    4 декабря 2018 г. 10:14
  • Между пользователями одного домена все нормально проходит?
    4 декабря 2018 г. 10:19
  • Да, всё ок, даже если один с мобильного через интернет, второй со стационарного с фронта, презентация видна и на стационарном и на мобильном.

    Проблема именно между организациями, причем удалось выяснить что она со стороны эджа 1-ой организации.

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


    • Изменено Mr. Snipfold 4 декабря 2018 г. 11:29
    4 декабря 2018 г. 11:28
  • Я Вам кидал набор портов с их описанием, где то выше. 

    Для того что бы остальным пользователям technet было проще и быстрей находить ответы на свои вопросы (проблемы), по каждому нужно создавать отдельную тему а не описывать все в одной. Так же, возможно где то ранее уже обсуждались некоторые вопросы которые Вас интересуют, воспользуйтесь поиском.

    Воспользуйтесь ссылками приведенными ранее. Там есть ответы.

    4 декабря 2018 г. 12:34
  • Ok, с этим разобрался, по теме взаимодействия трастовых доменов через эджи.

    Сейчас работает корректно с одной стороны, тоесь в организации №2 С одним пулом стандарт и одним эджем я создаю веб-ссылку meet.org2.dom2.ru/... и перехожу по ней в организации №1, в которой энтерпрайз и два эджа, всё нормально, в организации 1 я попадаю в комнату ожидания и после допуска во 2-ой организации вижу видео/презентацию/доску рисования.

    Далее в организации 1 создаю ссылку на презентацию meet.org1.dom1.ru/... и перехожу по ней в организации 2, так же во второй организации попадаю в комнату ожидания и после допуска 1-ой вижу картинку и показ рабочего стола, но стоит только в 1-ой запустить презентацию или доску рисования - ошибка DNS 141

    Вопрос - в какой организации неправильно настроен DNS?

    Я так понял идет запрос webconf.???.???.ru  по порту 443, но с какого  эджа?

    5 декабря 2018 г. 10:35
  • Да, порт 443. Webconf идет подключение к конференции (комнате) которая создается на Front End Server.

    Где у Вас рольWeb APPS? возможно нет доступа с компьютера к серверу с этой ролью и стоит проверить что бы между Edge Server 1-й организации и Web APPS Server этой же организации был доступ.

    Проверяйте и порты и как DNS резолвится.

    5 декабря 2018 г. 11:00
  • Заработало!!!!!

    В ДНС прописал webconf.dom1.ru  алиас на webconf.org1.dom1.ru на внешний адрес второго эджа который в ДМЗ и пробросил с этого адреса портв 444 443 и 5061 на всю сеть обеих организаций.

    5 декабря 2018 г. 14:07
  • Отлично!

    Советую все это задокументировать, потому что в таком "костыле" самому потом будет сложно разобраться :)

    6 декабря 2018 г. 7:01
  • Ок.

    Вот еще такой момент, на некоторых рабочих станциях в домене 2 во время показа презентации домена1 выходит такая ошибка:

    ServerFQDN="webconf.dom1.ru";ServerPort="444";ConnectionMethod="DataProxy";ServerIPAddress="10.28.147.168:444";ClientIPAddress="192.168.11.111:59342";ConnectionType="Wired";ProbeFailure="Server probe completed but did not succeed";InitializationFailedInfo="Exception while probing server: placeware::InvalidCertificateException: InitializeSecurityContext returned SEC_E_UNTRUSTED_ROOT (lync\client\application\conversations\psom\kernel\sslsocket.cpp: placeware::SslSocket::connectInternal(), 555)"</diagHeader><progressReports/></error></reportError>

     

    Это проблема сети (порты) или проблема сертификатов, или может быть какие обновления не установлены?

    И когда мобильный клиент домена1 вызывает стационарного клиента домена 2 то видеозвонок не проходит, может 2 эджа в такой конфигурации не позволяют этого сделать?

    8 декабря 2018 г. 9:05
  • PS

    На проблемной рабочей станции обнаружил что идет запрос к доменному центру авторизации по порту 80

    Для чего клиенту линка нужен такой запрос?

    До запроса веб-ссылки с сервера oos дело не доходит.

    Еще обнаружил что на проблемных станциях не телнетится порт 809 OOS сервера, уже дал задание сетевикам на открытие порта.



    • Изменено Mr. Snipfold 9 декабря 2018 г. 21:11
    9 декабря 2018 г. 18:30
  • Спасибо, порты открыли все между фронтами.

    Я кажется нашел причину, на сервере OOS домена1 в IIS сертификат выпущен от имени доменного центра авторизации домена1 и когда на него заходят пользователи с домена 2 то естественно они не проходят.

    Я уже добавил доменный ROOT-CA от домена 2 в доверенные корневые но нужно в IIS как-то обозначить что на него будут ходить по SSL из домена 2.

    Вопрос - как это реализовать?

    10 декабря 2018 г. 14:17
  • Никак Вы это не реализуете. Там может быть только один сертификат. Они будут подключатся по открытому ключу того домена, к которому относится сервер (которых хранит закрытый ключ). Главное что бы Root и корневой сертификаты были добавлены в доверенные, для возможности его проверить.
    10 декабря 2018 г. 15:12
  • Мобильные клиенты не дают абсолютно всего функционала. Для реверс прокси (подключения клиентов) можно использовать wildcard, или смотрите что бы все имена были в Вашем San Сертификате. Перепроверьте повторно все необходимые порты.

    Настроил EDGE, всё работает нормально.

    Решили купить у GlobalSign сертификат для эджа с именем sip.dom.ru и доп SAN именами sip.dom.ru webconf.dom.ru av.dom.ru  и dom.ru

    Заказали на недельное тестирование.

    Сначала для выпущенного сертификата сгенерировал Private Key (без него эдж не импортирует сертификат)

    Затем после успешного импорта назначил на внешку.

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

    В чем может быть проблема ???

    15 февраля 2019 г. 19:36
  • Привет.

    Request/Renewing Skype for Business Server 2015 Certificates

    Test-CsAVEdgeConnectivity


    MCITP, MCSE. Regards, Oleg

    15 февраля 2019 г. 22:05
    Модератор
  • Привет.

    Request/Renewing Skype for Business Server 2015 Certificates

    Test-CsAVEdgeConnectivity


    MCITP, MCSE. Regards, Oleg

    Это штатно для сертификатов, выданных доменным ЦА.

    Меня интересует установка купленных EV сертфикатов (от GlobalSign)

    17 февраля 2019 г. 7:36
  • Уже разобрался, сертификаты ставятся вручную + обязательно подписать сервером

    22 февраля 2019 г. 19:46