none
S4B Edge публикация сервисов RRS feed

  • Вопрос

  • Доброго времени Уважаемые коллеги.

    Есть пару вопросов касаемо публикации внутренней инфраструктуры S4B. Есть развернутая внутренняя инфраструктура Skype fo Business Serevr 2015 (S4B) с одним FE Standard сервером. Возникла необходимость использовать Lync Basic клиентов на ПК пользователей находящихся во внешней сети, а так же использование мобильных клиентов (смартфоны и т.д).

    Вопрос 1: По рекомендациям MS для роли EDGE требуется два сетевых интерфейса , один NIC смотрит либо в сеть периметра, другой во внутреннюю сеть на FE S4B. А как быть если у меня нет периметра да и все ограничивается одной подсетью, а на границе с инетом стоит микротик с одним белым ip-адресом. Могу ли я назначить два NIC и одной подсети, только указав NIC для внешнего- смотрящего на микротик - как бы что бы трафик натился на него, шлюз по умолчанию. А на внутреннем NIC указать внутренний DNS без шлюза ?

    Вопрос 2: Если я хочу использовать на первоначальном этапе только переписку клиентов в мессенджере S4B за пределами своей сети на ПК пользователей в инете и важно!!- на мобильных устройствах, повторяю- только для переписки, что бы клиент Lync Basic работал - достаточно ли мне одного лишь сервера EDGE, либо для мобильных клиентов нужен еще и Web Application Proxy ? Нужна только переписка - как чат, как аська, не видео не аудио не нужно!! Просто тут инфраструктура виртуальная на Hyper-V и каждая лишняя виртуалка - это лицензия, так как хосты не Datacenter...

    Заранее благодарен!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 31 июля 2017 г. 10:28
    31 июля 2017 г. 10:22

Все ответы

  • 1. Теоретически должно работать. Но более красиво будет создать еще одну сеть и настроить ее как внешнюю. 

    2. Нужен сервер с ролью Reverse Proxy. А WAP - это вариант его реализации. Да, без него работать получится, но возникает столько много "НО", что гораздо лучше эту роль поднять. Например, через нее работает автообнаружение, шаринг презентаций, митинги с использованием браузера, телефония, мобильные клиенты, SfB Mac Os). Можно сделать все на Linux + Nginx, тогда платить за лицензию не надо, ресурсов потребуется минимум:

    http://www.lin.by/2015/11/reverse-proxy-lync-2013-sfb-nginx-1.html#more

    31 июля 2017 г. 11:28
  • Спасибо. А если не использвать WAP а опубликовать через микротик пробросом портов ? Ну я имею в виду если нужен только клиент на ПК и мобильный клиент- и только для переписки в первом варианте, не нужно никаких митингов и коференций. Либо разместить WAP на какой ни будь виртуалке совместно с каким ни будь сервисом ?

    Да и конечно три сервера для одно S4B - слишком жирно, даже Jabber и то не требует ничего этого. Хотя конечно неудобен с точки зрения прозрачной аутентификации -использовать УЗ из AD во вне..То есть использовать для авторизации виндовый логин и пароль! Spark Jabber уже есть и опубликован и работает на ПК внешний пользователей и на мобильных клиентах- НО использует локальную базу учетных записей, а хотелось бы интегрировать с AD, ну и конференции конечно Jabber не поддерживает ((



    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 31 июля 2017 г. 11:45
    31 июля 2017 г. 11:42
  • Нет, проброс портов != Reverse proxy. Чем вам вариант с Nginx не нравится? Бесплатно, все работает и не надо городить огород с совмещением роли WAP. Делается за минут 15, ну пусть без опыта уйдет часа 4, пока установите ОС и разберетесь (гугл все поможет).

    Для Jabber есть OpenFire - он отлично умеет работать с AD. И еще можно дать возможность пользователям Jabber писать пользователям Lync :)

    31 июля 2017 г. 11:52
  • А есть какой ни будь пример настройки с Для Jabber есть OpenFire , а то если этот вариант бесплатен, может зря городим S4B ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 31 июля 2017 г. 12:50
    31 июля 2017 г. 12:50
  • Да таких примеров навалом. Делается все через веб интерфейс. Бегло пролистал, вроде похоже на правду:

    http://antizlo.blogspot.com.by/2014/08/install-openfire-server-with-active-directory-authorization-on-centos-6.html

    ОС можно использовать Windows, суть не меняется.

    31 июля 2017 г. 12:57
  • Тестирование подключения выдает ошибку невозможности доступа к EDGE по порту 5061, хот япорт открыт, да и фаервол виндовый на время выключен. Через микротик сделан проброс на порты 5061 ,443, 444 на внутренний LAN интерфейс EDGE. На двух интерфейсах EDGE из одной сетки без периметра прописаны адреса для LAN с DNS без шлюха, для WAN без DNS со шлюзом.

    Что можно еще посмотреть ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    31 июля 2017 г. 18:13
  • Включите федерацию в топологии:

    31 июля 2017 г. 18:21
  • Все включено


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    31 июля 2017 г. 19:06
  • Вы этот тест не пройдете без валидного сертификата:

    1. Ваш сертификат просрочен

    2. В нем нет имени домена, которое указано на скриншотах

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

    1 августа 2017 г. 8:20
  • К слову о планировании EDGE-сервера. Да - его можно пускать через NAT, но там есть оговорки. Ознакомьтесь:

    https://technet.microsoft.com/ru-ru/library/mt346415.aspx#Anchor_0

    И в идеале для EDGE-сервера надо три белых IP-адреса. Можно использовать конечно и один (и это поддерживаемая конфигурация) - а службы вешать на альтернативные порты вместе 443-го. Но в этом случае мобильные пользователи будут сталкиваться с ситуацией, что не смогут зайти в S4B из зон бесплатного WI-FI, т.к там зачастую порезаны почти все порты кроме 80 и 443.

    PS: И не факт что сейчас проблема только в сертификате (test connectivity позволяет игнорировать этот момент) - вполне возможна некорректная настройка NAT для EDGE.


    1 августа 2017 г. 8:46
  • Вы этот тест не пройдете без валидного сертификата:

    1. Ваш сертификат просрочен

    2. В нем нет имени домена, которое указано на скриншотах

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

    Для целей тестирования у меня установлен внутренний корпоративный УЦ. На свой ПК в инете я импортировал только корневой сертификат УЦ, естественно в нем нет имени sip.itprofix.ru. Я так понимаю на ПК надо импортировать еще и сертификат выписанный для EDGE (там есть все необходимые SAN)?

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    1 августа 2017 г. 13:31
  • Сетевая конфигурация на сервере EDGE - сеть одна, нет периметра. Публикация на микротике идет на ip-адрес 10.47.0.138- LAN.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    1 августа 2017 г. 13:45
  • На ПК надо импотрировать Root CA, если он не в домене. 

    Чтобы проверить, что все прошло успешно, просто откройте в браузере (лучше всего в IE):

    https://sip.itprofix.ru

    Если Root CA установлен корректно, то ошибки сертификата не будет.

    1 августа 2017 г. 13:49
  • И похоже вы правы, что здесь было что-то не то:Где то навешан публичный серт похоже:


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    • Помечено в качестве ответа rеstless 1 августа 2017 г. 17:48
    • Снята пометка об ответе rеstless 28 августа 2017 г. 11:11
    1 августа 2017 г. 14:02
  • Ничего не понимаю, у меня вот так по примеру настроено.

    Куда должен ссылаться sip.itprofix.ru прямо на EDGУ на котором IIS нет, или на FE ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!



    • Изменено rеstless 1 августа 2017 г. 16:50
    1 августа 2017 г. 16:49
  • Смотрим на имена, порты и протоколы.

    Skype for Business 2015 Protocol Workloads Poster


    MCITP, MCSE. Regards, Oleg

    1 августа 2017 г. 18:24
    Модератор
  • Я смотрю, только не могу понять, где моя ошибка, из вне sipпо порту 5061, либо по 443 ? 

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    1 августа 2017 г. 18:42
  • Для вышестоящей картинки

    Имя sip.itprofix.ru должно ссылаться на IP Access Edge для 5061.

    Имя webconf.itprofix.ru должно ссылаться на IP  Web Conf Edge 443 ( это по BP или по православному)

    То что имя sip.itprofix.ru обращается по 443 для ряда других сервисов и протоколова, а не только для SIP/MTLS, это так инадо. :) Вы же не вручную создаете порты для Windwos Server.

    A для FW список портов вот тут Port summaries

    PS. Я бы импортировал root CA, sub CA и CRL последний. :)


    MCITP, MCSE. Regards, Oleg

    1 августа 2017 г. 18:59
    Модератор
  • Как-то так должно быть.

    Местоположение/тип/порт Полное доменное имя/DNS-запись IP-адрес/полное доменное имя Сопоставление/комментарии

    Внешний DNS/A

    sip.alekssh.com

    внешний IP

    Внешний интерфейс для пограничной службы доступа. Потребуется один интерфейс для каждого домена SIP с пользователями Skype для бизнеса.

    Внешний DNS/A

    webconf.alekssh.com

    внешний IP

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

    Внешний DNS/A

    av.alekssh.com

    внешний IP

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

    Внешние DNS/SRV/5061

    _sip._tls.alekssh.com

    sip.alekssh.com

    Внешний интерфейс для пограничной службы доступа. Эта SRV-запись требуется для внешней работы клиентов Skype для бизнеса Server 2015, Lync Server 2013 и Lync Server 2010. Потребуется одна запись для каждого домена с пользователями Skype для бизнеса.

    Внешние DNS/SRV/5061

    _sipfederationtls._tcp.alekssh.com

    alekssh.com

    Внешний интерфейс для пограничной службы доступа. Эта SRV-запись требуется для автоматического обнаружения DNS-записей федеративных партнеров, также называемых "Разрешенные домены SIP". Потребуется одна запись для каждого домена с пользователями Skype для бизнеса.

    По портам. Если вы используете один внешний IP-адрес, то как рекомендует Microsoft:

    Если установлен флажок Использовать единое полное доменное имя и IP-адрес , потребуется ввести единое внешнее полное доменное имя в поле Доступ SIP . Затем следует ввести разные номера портов для всех пограничных служб: это обеспечивает их независимое подключение. Рекомендуется назначить номер порта 5061 пограничной службе доступа по протоколу SIP , 444 – пограничной службе веб-конференций и 443 – пограничной службе видео-/голосовой связи . 

    Статья тут: https://technet.microsoft.com/ru-ru/library/dn933917.aspx?f=255&mspperror=-2147217396#Anchor_0

    И т.к. вы используете NAT - убедитесь, что в топологии это указано. Там нужно указать соответствующую опцию и прописать внутренние адреса служб EDGE и внешний публичный NAT. Судя по скриншотам - у вас так не сделано. Например:

    А дальше ниже там идёт указание публичного белого IP-адреса NAT.



    2 августа 2017 г. 4:07
  • Но это ещё пол дела. Вам нужно ещё опубликовать через обратный прокси веб-сервисы S4B. Там несколько доменных имен (которые вы заполняли в топологии) - которые так же надо будет добавить в сертификат. Инфы по этому вопросу достаточно. Хотя бы даже на том сайте, с которого вы брали инфу) 

    https://alekssh.com/2016/12/05/sfb-wap/

    Но будьте внимательны - все эти URL-адреса (meet, dialin, S4BWEB) и порты (например 4443) - могут отличаться от вашего случая. Всё зависит от того, что вы прописали в топологии.

    2 августа 2017 г. 4:36
  • Как-то так должно быть.

    Местоположение/тип/порт Полное доменное имя/DNS-запись IP-адрес/полное доменное имя Сопоставление/комментарии

    Внешний DNS/A

    sip.alekssh.com

    внешний IP

    Внешний интерфейс для пограничной службы доступа. Потребуется один интерфейс для каждого домена SIP с пользователями Skype для бизнеса.

    Внешний DNS/A

    webconf.alekssh.com

    внешний IP

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

    Внешний DNS/A

    av.alekssh.com

    внешний IP

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

    Внешние DNS/SRV/443

    _sip._tls.alekssh.com

    sip.alekssh.com

    Внешний интерфейс для пограничной службы доступа. Эта SRV-запись требуется для внешней работы клиентов Skype для бизнеса Server 2015, Lync Server 2013 и Lync Server 2010. Потребуется одна запись для каждого домена с пользователями Skype для бизнеса.

    Внешние DNS/SRV/5061

    _sipfederationtls._tcp.alekssh.com

    alekssh.com

    Внешний интерфейс для пограничной службы доступа. Эта SRV-запись требуется для автоматического обнаружения DNS-записей федеративных партнеров, также называемых "Разрешенные домены SIP". Потребуется одна запись для каждого домена с пользователями Skype для бизнеса.

    По портам. Если вы используете один внешний IP-адрес, то как рекомендует Microsoft:

    Если установлен флажок Использовать единое полное доменное имя и IP-адрес , потребуется ввести единое внешнее полное доменное имя в поле Доступ SIP . Затем следует ввести разные номера портов для всех пограничных служб: это обеспечивает их независимое подключение. Рекомендуется назначить номер порта 5061 пограничной службе доступа по протоколу SIP , 444 – пограничной службе веб-конференций и 443 – пограничной службе видео-/голосовой связи . 

    Статья тут: https://technet.microsoft.com/ru-ru/library/dn933917.aspx?f=255&mspperror=-2147217396#Anchor_0

    И т.к. вы используете NAT - убедитесь, что в топологии это указано. Там нужно указать соответствующую опцию и прописать внутренние адреса служб EDGE и внешний публичный NAT. Судя по скриншотам - у вас так не сделано. Например:

    А дальше ниже там идёт указание публичного белого IP-адреса NAT.


    У меня именно так и настроено, только вопрос, на микротике проброс портов делать на External IP, который я указал на EDGE , то есть 10.47.1.138 ? Internal у меня 10.47.0.138..

    А здесь Public NAT , это единственный публичный IP на микротике


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 2 августа 2017 г. 6:43
    2 августа 2017 г. 6:40
  • Но это ещё пол дела. Вам нужно ещё опубликовать через обратный прокси веб-сервисы S4B. Там несколько доменных имен (которые вы заполняли в топологии) - которые так же надо будет добавить в сертификат. Инфы по этому вопросу достаточно. Хотя бы даже на том сайте, с которого вы брали инфу) 

    https://alekssh.com/2016/12/05/sfb-wap/

    Но будьте внимательны - все эти URL-адреса (meet, dialin, S4BWEB) и порты (например 4443) - могут отличаться от вашего случая. Всё зависит от того, что вы прописали в топологии.

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

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    2 августа 2017 г. 6:41
  • По IP-адресам всё верно.

    А Reverse Proxy нужен по любому. Во первых через него отрабатывает autodiscover за пределами вашей организации. Во вторых для мобильных устройств не обойтись без обратного прокси:

    It's expected that the external Autodiscover requests will go through the reverse proxy you've configured for Skype for Business Server 2015. However, both the internal Mobility service URL and the external Mobility service URL are associated with the external Web Services FQDN. Therefore, regardless of whether a mobile device is internal or external to your network, the device always connects to the Skype for Business Server 2015 Mobility service externally, through your reverse proxy.

    Планирование мобильности

    2 августа 2017 г. 7:21
  • По IP-адресам всё верно.

    А Reverse Proxy нужен по любому. Во первых через него отрабатывает autodiscover за пределами вашей организации. Во вторых для мобильных устройств не обойтись без обратного прокси:

    It's expected that the external Autodiscover requests will go through the reverse proxy you've configured for Skype for Business Server 2015. However, both the internal Mobility service URL and the external Mobility service URL are associated with the external Web Services FQDN. Therefore, regardless of whether a mobile device is internal or external to your network, the device always connects to the Skype for Business Server 2015 Mobility service externally, through your reverse proxy.

    Планирование мобильности

    Да я все понимаю. Но для того что бы минимум использовать S4B клиент, мне достаточен пока только EDGE- сам факт подключения, потому на данном этапе получаю только вот это 

    А это лог подключения.

    


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 2 августа 2017 г. 7:30
    2 августа 2017 г. 7:27
  • Для вышестоящей картинки

    Имя sip.itprofix.ru должно ссылаться на IP Access Edge для 5061.

    Имя webconf.itprofix.ru должно ссылаться на IP  Web Conf Edge 443 ( это по BP или по православному)

    То что имя sip.itprofix.ru обращается по 443 для ряда других сервисов и протоколова, а не только для SIP/MTLS, это так инадо. :) Вы же не вручную создаете порты для Windwos Server.

    A для FW список портов вот тут Port summaries

    PS. Я бы импортировал root CA, sub CA и CRL последний. :)


    MCITP, MCSE. Regards, Oleg

    у меня списки отзыва не настроены на УЦ, к тому же нет подчиненного УЦ, все на одном Root + серт внутренний а не публичный- для целей тестирования , хотя бы одного удачного подключения с ПК не в домене!

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 2 августа 2017 г. 7:32
    2 августа 2017 г. 7:31
  • Да и еще момент, я здесь не использовал единое имя, хотя я так понял надо было бы- у меня же всего один белый ip.Или это не критично ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 2 августа 2017 г. 7:35
    2 августа 2017 г. 7:35
  • А сервер найти не может - потому что не отрабатывает автообнаружение наверное? - для которого нужен обратный прокси)
    В чем сложность ещё один сервис поднять? - вместо этого вы готовы вылавливать непредсказуемые глюки в работе системы? А потом гадать - то ли это мы что-то неправильно настроили, то ли для этого нужен Reverse Proxy. Как правильно в самом начале вам написали "Нужен сервер с ролью Reverse Proxy. А WAP - это вариант его реализации. Да, без него работать получится, но возникает столько много "НО", что гораздо лучше эту роль поднять. "
    2 августа 2017 г. 7:41

  • у меня списки отзыва не настроены на УЦ, к тому же нет подчиненного УЦ, все на одном Root + серт внутренний а не публичный- для целей тестирования , хотя бы одного удачного подключения с ПК не в домене!

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    Списки отзыва нужны.

    http://blog.schertz.name/2013/02/certificate-revocation-lync-2013/

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

    CRL и AIA в сертификатах советую настроить только на ссылку http - по которой можно будет зайти и внутри сети, и снаружи (а для этого опять же нужен обратный прокси =)) ). Никаких LDAP-ссылок и внутренних шар. 


    2 августа 2017 г. 7:51
  • А сервер найти не может - потому что не отрабатывает автообнаружение наверное? - для которого нужен обратный прокси)
    В чем сложность ещё один сервис поднять? - вместо этого вы готовы вылавливать непредсказуемые глюки в работе системы? А потом гадать - то ли это мы что-то неправильно настроили, то ли для этого нужен Reverse Proxy. Как правильно в самом начале вам написали "Нужен сервер с ролью Reverse Proxy. А WAP - это вариант его реализации. Да, без него работать получится, но возникает столько много "НО", что гораздо лучше эту роль поднять. "

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

    А вообще можно как то внутри сети проверить подключение через EDGE, просто судя по логам подключение проходит , имя sip.itprofix.ru разрешается во внешнем DNS а дальше затык.

    Это внешний DNS и я так понимаю необходимо добавить autodiscover ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    2 августа 2017 г. 7:52

  • у меня списки отзыва не настроены на УЦ, к тому же нет подчиненного УЦ, все на одном Root + серт внутренний а не публичный- для целей тестирования , хотя бы одного удачного подключения с ПК не в домене!

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    Списки отзыва нужны.

    http://blog.schertz.name/2013/02/certificate-revocation-lync-2013/

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

    CRL и AIA в сертификатах советую настроить только на ссылку http - по которой можно будет зайти и внутри сети, и снаружи (а для этого опять же нужен обратный прокси =)) ). Никаких LDAP-ссылок и внутренних шар. 


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

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    2 августа 2017 г. 7:54
  • Да, именно так и надо было делать. Вот как пример:

    https://blog.netnerds.net/2013/08/setup-a-fully-functional-lync-2013-lab-using-only-one-public-ip-address/

    https://www.google.by/search?client=safari&rls=en&q=lync+2013+edge+single+ip&ie=UTF-8&oe=UTF-8&gfe_rd=cr&ei=toGBWYDqJ9jDtAGu7q6ABA

    То есть использовать единое имя ? Получается топологию придется сносить и заново конфигурировать ?

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 2 августа 2017 г. 8:11
    2 августа 2017 г. 8:10
  • Внутри сети для тестов и траблшутинга можно использовать Lync Connectivity Analyzer. К сожалению Microsoft почему то решило похоронить эту утилитку и удалили её из загрузок (на замену этой утилите предлагают Microsoft Connectivity Analyzer Tool - но там более бедный функционал по отношению к Lync\S4B). Но вот например на этой страничке https://ucmart.uk/2017/07/04/copy-of-lync-connectivity-analyzer-download-link/ можно найти ссылку на старый добрый Lync Connectivity Analyzer. 
    2 августа 2017 г. 8:14

  • То есть использовать единое имя ? Получается топологию придется сносить и заново конфигурировать ?

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    Топологию можно просто поменять)
    2 августа 2017 г. 8:15
  • И вообще - если вам нужно было просто посмотреть как это будет работать. Если достаточно для демонстрации запустить S4B-клиент внутри вашей сети с компьютера который не в домене, то можно было и не публиковать в интернете S4B совсем - соответственно никаких NAT'ов. Всё максимально просто. Front-End сервер, EDGE-сервер с одним внутренним интерфейсом и тремя "внешними" (как и советует Microsoft) и в идеале WAP по аналогии как и EDGE. И подключать недоменную машинку из этой "внешней" подсети уже к этой песочнице.
    2 августа 2017 г. 8:48
  • И вообще - если вам нужно было просто посмотреть как это будет работать. Если достаточно для демонстрации запустить S4B-клиент внутри вашей сети с компьютера который не в домене, то можно было и не публиковать в интернете S4B совсем - соответственно никаких NAT'ов. Всё максимально просто. Front-End сервер, EDGE-сервер с одним внутренним интерфейсом и тремя "внешними" (как и советует Microsoft) и в идеале WAP по аналогии как и EDGE. И подключать недоменную машинку из этой "внешней" подсети уже к этой песочнице.
    Я бы рад, да у меня нет трех внешних белых IP, только один и как то поменять данную конфигурацию, пока не представляется возможным.

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    2 августа 2017 г. 9:40
  • Я же и пишу - можно просто развернуть было внутри сети песочницу - которая не будет смотреть наружу. Соответственно не нужны и белые IP-адреса. Но проверить работу можно будет только внутри сети - но этот вариант я так понимаю устраивает.
    2 августа 2017 г. 9:47
  • Я же и пишу - можно просто развернуть было внутри сети песочницу - которая не будет смотреть наружу. Соответственно не нужны и белые IP-адреса. Но проверить работу можно будет только внутри сети - но этот вариант я так понимаю устраивает.
    Песочница изнутри работает на ура. Другое дело именно изнутри проверить- подключение через EDGE!!! А как известно внутри сети EDGE нафиг не нужен. Если все работает изнутри, то встала необходимость обвязать внешних клиентов- для начала на ПК а потом и на мобильниках.

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    2 августа 2017 г. 12:14
  • Ну в общем после изменения конфигурации в топологии на единый FQDN без сепарэйта ip адресов, тест получает ся уже куда лучше, но теперь ругается на SSL сертификат, причем непонятно, зачем ему промежуточный, если у меня его нет на своем внутреннем корпоративном УЦ ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    2 августа 2017 г. 13:12
  • Может потому, что не может проверить его подлинность? ;)
    2 августа 2017 г. 13:32
  • Может потому, что не может проверить его подлинность? ;)

    Я же скопировал Root CA на свой ПК. Либо сам FE не может пройти проверку подлинности выданного сертификата на стороне внутреннего УЦ ? Я изменил топологию, но при этом переназначать сертификаты нет необходимости, так же как и повторно скачивать файл на EDGE.Топология обновляется автоматом через репликацию с EDGE.

    Что можно еще посмотреть ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    2 августа 2017 г. 13:43
  • Тут сам Connectivity Analyzer не доверяет сертификату. Вы же тестируете онлайн? Через https://testconnectivity.microsoft.com/? Когда начинаете тест - выберите галку "Ignore Trust for SSL"
    2 августа 2017 г. 13:59
  • Даже при галке игнорить SSL все равно:

    Но , а удаленное подключение клиента S4B так и идет с ошибкой.

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


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!



    • Изменено rеstless 2 августа 2017 г. 20:23
    2 августа 2017 г. 20:17
  • Странно , делаю маппинг портов на сам FE, клиент S4B из инета сразу предлагает принянть подключение и пароль запрашивает, но при воде пароля опять та же ошибка


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    2 августа 2017 г. 20:49
  • Для теста не нужно использовать учетную запись администратора (Я может параноик, но кто может быть уверен - куда попадут эти учетные данные, которые вы вводите =) )

    Расскажите какой тест вы делаете? Там их несколько. Покажите скрин с заполненными полями для теста. Покажите вывод команд powershell на FrontEnd и EDGE серверах:

    get-CsCertificate | fl Use, Subject, AlternativeNames, Thumbprint, NotAfter, Issuer

    Публиковать напрямую FrontEnd наружу не нужно! Я молчу про безопасность в этом случае. Вообще EDGE-сервер придумали не просто так. Приучайтесь делать презентационные стенды тоже правильно) На то это и песочница - чтоб разобраться со всеми тонкостями заранее, а не пилить потом боевой сервер.

    Вот тут например есть обсуждение "супер-идеи" публикации наружу Lync без EDGE. Ничего хорошего от такого решения не будет: НЕ ДЕЛАЙТЕ ТАК


    3 августа 2017 г. 2:15
  • Параметры учетных данных при теста обычного

    По сертификатам на FE

    На EDGE

    Получается когда я делаю маппинг портов через микротик на внутренний сервер EDGE то он не отдает имя sip.itprofix.ru,  внутри сети даже при проверке https://dcd-edge.itprofix.local страница пустая с ошибкой- даже без предупреждения сертификата.

    Вот пример правило публикации для порта EDGE 5061


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 3 августа 2017 г. 6:43
    3 августа 2017 г. 6:38
  • При чем если смотреть по логам подключения, то ка только в логе начинает фигурировать порт 5061, то сразу возникает ошибка клиента.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    3 августа 2017 г. 6:57
  • Вы используете в тесте автообнаружение "Use Autodiscover.." Оно у вас не отработает. Это по сути веб-сервис, который должен быть опубликован через обратный прокси. Вы пока что этого не сделали)

    Поэтому укажите свой сервер вручную "Manually specify server settings".

    Edge Server: sip.itprofix.ru

    Edge Port: 5061

    И я в команде powershell там опечатался - вместо subject написал Subkect. Исправьте пожалуйста и отправьте ещё раз вывод команд. Но в принципе вроде всё норм.

    3 августа 2017 г. 7:22
  • В ручную все норм, кроме

    Кому еще не доверяет- не пойму..


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    3 августа 2017 г. 7:30
  • Так возможно всё и норм. Попробуйте зацепиться с внешней системы через S4B-клиент. Настройки забивайте естественно вручную. И необходимо добавить корневой сертификат вашей организации в хранилище корневых центров сертфикации на этой удалённой машинке.

    А ещё лучше с этой машины запустить утилиту о которой я вам говорил (Lync Connectivity Analyzer).

    3 августа 2017 г. 7:35
  • Все действия выше- я проделывал именно с удаленно машины и сейчас это проделываю- но результат пока печален:

    Повторяю, внутри все работает на ура (в домене)


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    3 августа 2017 г. 7:51
  • Настройки сервера вручную указали в клиенте?

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

    3 августа 2017 г. 8:02
  • Внутренний сервер EDGE указывать в домене local ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    3 августа 2017 г. 8:07
  • Помоему можно только внешний оставить: sip.itprofix.ru:5061
    3 августа 2017 г. 8:16

  • Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    3 августа 2017 г. 9:06
  • Ай - проверил я эту утилиту. Она в первую очередь пытается залезть на autodiscover. Всё больше причин для вас - поднять нормальную схему с обратным прокси.
    3 августа 2017 г. 10:06
  • Именно, сделайте вы уже наконец как надо, или бросьте эту затею. Уже целая пачка сообщений с разбором "почему не работает та фигня, которую я делаю". 

    Ах да, документацию тоже стоит почитать чтобы понимать, что делаете и как это все должно работать. Тем более что ее навалом. Можете смело смотреть то, что относится к Lync 2013 - ее больше, чем для SfB, а разница в продуктах не сильно большая (на данном уровне так вообще нет никакой). 

    3 августа 2017 г. 10:12
  • И еще - раздобудьте нормальный сертификат. Из бесплатных можно попробовать StartSSL, если они еже живы. Вы все равно собираетесь использовать мобильные клиенты. Сертификат доменного СА на EDGE это боль с самого начала, как вы уже убедились.
    3 августа 2017 г. 10:15
  • Окей, как навояю отпишу, тему пока не закрываю.

    Спасибо.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    3 августа 2017 г. 10:53
  • И еще - раздобудьте нормальный сертификат. Из бесплатных можно попробовать StartSSL, если они еже живы. Вы все равно собираетесь использовать мобильные клиенты. Сертификат доменного СА на EDGE это боль с самого начала, как вы уже убедились.
    По поводу сертификата, так бесплатный только на один SAN дается, а мне их там пачку надо , потому что я так понял WildCard сертификат тут не катит ?

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    3 августа 2017 г. 10:54
  • 1. На StartSSL раньше можно было в сертификате указать несколько доменов

    2. Wildcard, в принципе, использовать можно. С ним не будут работать федерации и Push уведомления на мобильных клиентах (не факт, что это все вам надо).

    3 августа 2017 г. 11:02
  • Доброго дня!

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


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    6 августа 2017 г. 11:12
  • Зачем вы намешали в одном сертификате имена из разных служб? Тут у вас и пограничный сервер, и обратный прокси, и внутренние сервера намешаны. Читайте предварительно документацию. Например: планирование сертификации пограничного сервера

    Там перечислены необходимые поля для EDGE-сертификата. Обратите внимание на пункт "Имя субъекта". Что у вас в поле CN прописано в сертификате?

    Для внутреннего сервера и связи EDGE с внутренним сервером - проще использовать свой внутренний ЦС. Опять же - в документации есть предложение "Следует помнить, что внутренний сертификат использует запись SN и не использует записи SAN, поэтому вы можете не беспокоиться о SAN во внутреннем сертификате." Возможно в этом и кроется причина ваших проблем с внутренними клиентами. Читайте документацию перед тем, как что-либо делать. Это не тот продукт - где всё заработает само собой)

    7 августа 2017 г. 2:05
  • Доброго дня Александр, да вы правы, я немного не туда завернул. Все верно, соединение между FE и EDGE можно шифровать через сертифиаат выданный внутренним УЦ,  а на EDGE и WAP уже публичные назначить.

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    7 августа 2017 г. 10:53
  • если с WAP открываю страницу, все гуд, извне, так и не работает. 

    Такое ощущение что на EDGE трафик из вне вообще не идет


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 8 августа 2017 г. 13:00
    8 августа 2017 г. 12:35
  • В общем lyncDiscover и другие службы опубликованные через WAP работают штатно. а вот с EDGE как была проблема , так и осталась. Хотя telnet показывает что порт открыт. При тестах подключения  идет ругань на ssl.

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 8 августа 2017 г. 14:01
    8 августа 2017 г. 14:00
  • Покажите свои публикации через WAP.

    В вашем случае нужно было опубликовать записи lyncdiscover, dialin, meet, s4bweb.

    Я как минимум вижу, что у вас нет внешней DNS записи s4bweb.itprofix.ru. Она так же должна ссылаться на IP-адрес обратного прокси.

    Так же удалите внешнюю DNS-запись lyncdiscoverinternal. Эта запись для подключения из внутренней сети предприятия, и клиенты в первую очередь пытаются её резолвить. В вашем случае внешний клиент находит такую запись, пытается по ней подключиться к службе автообнаружения и терпит неудачу. Только после этого лезет уже на lyncdiscover. Страшного в этом нет ничего - но это не красиво, пораждает лишние запросы от клиентов и добавляет путаницы при траблшутинге)

    Ещё покажите конфигурацию Simple-URL'ов. Можно через топологию посмотреть, либо командой:

    (get-csSimpleUrlConfiguration).simpleUrl

    Так же покажите конфигурацию веб-служб. В топологии в настройках FE-сервера.

    https://technet.microsoft.com/en-us/library/gg520992(v=ocs.15).aspx


    9 августа 2017 г. 4:12
  • Ещё вопрос - вы WAP наружу как прокинули? Опять через NAT?)
    9 августа 2017 г. 4:25
  • WAP прокинут также как и EDGE двумя NIC из одной сетки, на внутреннем NIC прописан DNS , на другом шлюз- это и есть внешний NIC.

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 9 августа 2017 г. 6:50
    9 августа 2017 г. 6:49
  • И всё это дело публикуется через один единственный IP-адрес? Я никогда не располагал WAP за NAT'ом - могу чего-то не знать. Но у меня вопрос - как вы на вашем шлюзе NAT'ите трафик по 443 порту и на EDGE и на WAP? Выделите отдельный белый IP для WAP'а.

    Ну и по вопросам, которые выше писал - так же жду ответа))

    9 августа 2017 г. 7:57
  • И всё это дело публикуется через один единственный IP-адрес? Я никогда не располагал WAP за NAT'ом - могу чего-то не знать. Но у меня вопрос - как вы на вашем шлюзе NAT'ите трафик по 443 порту и на EDGE и на WAP? Выделите отдельный белый IP для WAP'а.

    Ну и по вопросам, которые выше писал - так же жду ответа))

    Ну вот получается у меня два правила для 443 порта. Ну нет у меня второго белого IP. Ну попробую выбить. Я так понял WAP надо как пограничный сервер выставить в инет получается  (с одной стороны белый адрес , второй локальный)-нет DMZ у нас так же ?

    По сервисам:

    Соответственно по записям во внешнем DNS . все SAN включая  lyncdiscover, dialin, meet, s4bweb. должны фигурировать в публичной сертификате так ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    9 августа 2017 г. 8:44
  • И еще вопрос: Да, есть возможность взять еще один белый IP, но WAN порт в микротике всего один и куда мне второй белый ip конфигурировать ?

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    9 августа 2017 г. 8:54
  • Забыли показать публикации на WAP.

    Да - имена lyncdiscover, dialin, meet, s4bweb должны быть в публичном сертификате. Этот сертификат используем в ReverseProxy. На FrontEnd-сервере мы спокойно можем использовать сертификаты, выданные внутренним ЦС. Но в нем конечно же тоже должны быть все необходимые имена (вышеперечисленные плюс внутренние имена).

    Вообще к планированию публичного сертификата надо будет подойти серьезно - в зависимости от потребностей возможно надо будет ещё добавлять имена. Например для использования PowePoint презентаций нужен будет опубликованный Office Web App Server - это ещё плюс одно имя в сертификате.

    На EDGE-сервере мы уже используем второй сертификат у которого CN=sip.domain.com, а в SAN прописаны в вашем случае sip.domain.com, av.domain.com, weconf.domain.com.

    Насчет NAT. Вообще WAP вполне может работать через NAT. Просто я не пробовал такой сценарий при публикации S4B. Может коллеги более опытные тут на форуме скажут своё слово.

    Два правила на 443 порт - в вашем случае скорее всего трафик всегда будет только по первому по приоритету правилу. Железка ж скорее всего не анализирует URL-заголовки. Так что выделяйте дополнительные белые IP-адреса. А лучше сразу пул - чтоб всё по уму было)) Новый белый IP-адрес можно будет повесить на маршрутизаторе - и NAT'ить с этого адреса трафик только на WAP. Но я бы начал с простого сценария - повесил белый IP-адрес непосредственно на WAP. Как протестируете - можно уже будет усложнять.

    9 августа 2017 г. 9:25
  • И еще вопрос: Да, есть возможность взять еще один белый IP, но WAN порт в микротике всего один и куда мне второй белый ip конфигурировать ?

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    Не знаю за Mikrotik - но многие маршрутизаторы умеют поднимать виртуальные интерфейсы. Думаю Mikrotik не исключение.
    9 августа 2017 г. 9:31
  • Спасибо Александр за содержательный ответ! Так сейчас по публикации WAP покажу и как проделаю схему с белыми IPотпишусь. Я еще заметил, что как только я правило для WAP поставил самое верхнее то автодискавер начал отрабатывать. Но вопрос остается пока голым- что мешает подключиться к EDGE - когда правило было только одно и отлуп был тогда, когда трафик доходил до порта 5061 по логам микротика. И telnet sip.itprofix.ru 5016 отрабатывает и порты открыты- может что-то внутри не так ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    9 августа 2017 г. 9:37
  • На мобильнике сертификат принимает, но а дальше невозможно подключиться к серверу:


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    9 августа 2017 г. 10:12
  • Да может быть всё что угодно)) Разберёмся.

    Покажите вывод информации по сертификату на FE-сервере. Нужен полный список SAN-имён и CN. Можно использовать get-csCertificate. Там должны присутствовать все имена, которые мы выше обсуждали, плюс внутреннее имя сервера. У меня есть подозрение, что вы могли s4bweb туда не добавить.

    Ещё важное замечание! - на внутренних серверах используйте сертификат в политиках применения которого добавлена проверка подлинности клиента. Обычно все по умолчанию используют шаблон сертификатов Web-Server. В нём включена только проверка подлинности сервера. Нам нужен шаблон в котором проверка подлинности и сервера и клиента.

    Почему это нужно - я не так давно столкнулся с одной проблемкой и причина была как раз в этом. Net Framework после одного из обновлений стал требовать дополнительную проверку сертификатов.

    Описано в этой статье. Там же и решение.

    Поэтому во избежании будущих проблем - делайте сразу сертификаты с нужными политиками.

    И репликация между FE и EDGE нормально ходит? Команда: Invoke-CsManagementStoreReplication

    9 августа 2017 г. 10:28
  • И кстати да, забыл же написать - сертификат от StartSSL у меня так же не доверенный. Их корневой сертификат не доверенный  в системе. Так что я думаю и testconnectivity будет постоянно на них ругаться. Так что толку от бесплатных сертификатов StartSSL видимо теперь совсем нет.

    Для тестов - добавьте их корневой сертификат к себе на удаленную машинку в хранилище корневых ЦС. И тестируйте с помощью утилиты Lync Connectivity Analyzer. В результатах выбирайте Detailed Information.

    9 августа 2017 г. 10:33
  • И ещё мысль - на серверах же тоже публичный SSL-сертификат не доверенный? Откройте его на сервере и проверьте. Добавьте Root-сертификат от StartSSL на серверах в хранилище корневых ЦС. (только в дальнейшем надо будет не забыть его удалить оттуда). Лиииибо - использовать пока для тестов свои сертификаты, т.к. StartSSL по свойствам стремится к ним))
    9 августа 2017 г. 10:38
  • Ну как у вас успехи?
    20 августа 2017 г. 3:59
  • Еще никак, белый IP есть, но не прокинули на сервер.

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    25 августа 2017 г. 9:49
  • Держите в курсе событий)) И уберите пометку с вашего поста, что проблема решенная. 
    28 августа 2017 г. 4:17
  • Прокинул на ВМ прямой белый ip. Теперь автодискавер зеленый Но на клиенте на ПК и мобильные клиенты так и не работают!! На мобиле сертификат принимает, но говорит что неможет проверить и ошибка подключения. В общем огород с белым айпи непомогает



    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!



    • Изменено rеstless 31 августа 2017 г. 11:48
    31 августа 2017 г. 10:48
  • Machine:DCD-WSUS01Join attempted at(UTC):8/31/2017 12:01:09 PMCorrelationId:3138611179User Agent:Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like GeckoAccept Header:text/htmlapplication/xhtml+xml*/*Incoming URL:https://meet.itprofix.ru/TelemetryId:93f1ae2b-58a2-4da7-9336-66ba574d20daError: Meeting URL format may be invalid



    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    31 августа 2017 г. 12:03
  • Страничка meet - не показатель.

    А вот на https://dialin.<sip-domain> я попробовал зайти - ругается, что не может попасть на https://s4bweb.<sip-domain>/Dialin/Conference.aspx

    У вас правильно опубликован через обратный прокси сайт S4BWeb? С нужным сертификатом и на внутренний s4bweb.<sip-domain>:4443?

    Проверьте DNS-записи внутри вашей организации. Должны быть все записи: dialin, meet, lyncdiscover, s4bweb - которые ссылаются на ваш FE-сервер.

    В топологии проверьте, что URL-имена введены верные. Так же URL для внешнего доступа в топологии у вас прописан как s4bweb.<sip-domain> и порт 4443?

    Так же - если вы меняли в какой-то момент в топологии простые URL-адреса, то необходимо было на FE-сервере запустить командлет enable-csComputer. Читайте тут:

    https://technet.microsoft.com/ru-ru/library/gg398287(v=ocs.15).aspx

    Заметил ещё ошибку у вас - вы используете один сертификат для ReverseProxy и Edge-сервера. Это ничего - но в сертификате у вас отсутствует имя: webconf.<sip-domain> 


    31 августа 2017 г. 13:53
  • Как раз не было записи в локальном DNS в зоне дополнительной itprofi.ru алиаса S4bweb CNAME ссылка на FE

    Я ее добавил и у меня линк клиент (который на ПК) в интернете, начал запрашивать учетные данные, да только как бы я их не вводил- ответ один и тот же. Конечно уже теплее, но это все равно нерабоатет.

     

    webconf.contoso.com я вообще не использую и во внешнем DNS ее то же не прописывал..


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!




    • Изменено rеstless 1 сентября 2017 г. 10:25
    31 августа 2017 г. 13:59
  • У вас скорее всего UPN пользователя не username@contoso.com, а что-нибудь вроде username@contoso.local

    В итоге адрес входа: username@<sip-domain>

    имя пользователя: <ваш_домен>\username

    ну и пароль))


    31 августа 2017 г. 14:13
  • да нет, все как бы нормально


    Причем странно, мой коллега даже с мобилы смог зайти, а я так же и не могу, через Wai-FI... что за волшебство ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 1 сентября 2017 г. 10:24
    31 августа 2017 г. 14:32
  • А покажите вывод: get-csUser cobion

    И насчет "webconf.<sip-domain> я вообще не использую и во внешнем DNS ее то же не прописывал.." Эта запись нужна - она ссылается на службу веб-конференций на пограничном сервере. И во внешнем DNS у вас такая запись имеется))


    Читайте технет - и куча вопросов и недопониманий сразу пропадёт)

    https://technet.microsoft.com/ru-ru/library/mt346415.aspx#Anchor_1


    31 августа 2017 г. 14:41
  • А покажите вывод: get-csUser cobion

    И насчет "webconf.contoso.com я вообще не использую и во внешнем DNS ее то же не прописывал.." Эта запись нужна - она ссылается на службу веб-конференций на пограничном сервере. И во внешнем DNS такая запись имеется))

    итайте технет - и куча вопросов и недопониманий сразу пропадёт)

    https://technet.microsoft.com/ru-ru/library/mt346415.aspx#Anchor_1

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

    вывод команды get-csuser

    а если всех get-csuser | ft


    Причем любого пользователя пробую- ровно такое же поведение! Запрашивает пароль и все равно не верен


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!




    • Изменено rеstless 1 сентября 2017 г. 10:24
    31 августа 2017 г. 14:52
  • я подправил посты)

    Покажи вывод тогда используя SAM account name:

    get-csuser username@contoso.com

    Нужен вывод всех полей.

    1 сентября 2017 г. 2:17
  • И посмотрите Event-логи на FE-сервере. Посмотрите Application - Lync Server логи. А так же Security логи сразу после неудачного логона.
    1 сентября 2017 г. 3:48
  • Доброго дня Александр! Я разобрался в чем было дело, по крайней мере на мобильном клиенте- надо было вводить Dmitriy.familia, ниже itprofix\cobion и пароль, сертификат ругнулся но проглотил- мобильный клиент работает, а вот на ПК выходит вот такая ошибка:

    И второе- как включить Push уведомления, а то в мобильном приложении пишет невключено - обратитесь к СА. И меня интересует главная фича- хранение истории, что бы все в одном окне как в джаббере...))


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 1 сентября 2017 г. 9:27
    1 сентября 2017 г. 9:15
  • Настроил Push уведомления, тестирую и получаю вот что:


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    1 сентября 2017 г. 15:20
  • Удалите во внешнем DNS SRV-запись: _sipinternaltls._tcp.<sipdomain>

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

    По истории - что вы конкретно хотите и подразумеваете "чтобы всё в одном окне"?

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

    Ну и гуглите. Надо самостоятельно учиться искать решения) Тем более инфы по типичным вопросам навалом. Удачи)

    Configure for Push notifications

    SKYPE4B MOBILITY PUSH NOTIFICATIONS

    1 сентября 2017 г. 15:20
  • И у меня есть большие предположения, что с вашим сертификатом PUSH может не заработать. Нужен всё-таки нормальный сертификат.
    1 сентября 2017 г. 15:23
  • После установки обновления , Push уедомления стали доступны на  мобильных клиентах, но если пишешь на мобильном устройстве , то на терминальном клиенте ничего нет и наоборот. С сертификатом я переустановлю на Edge что бы там фигурировал webconf.

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

    Не хотелось бы отказываться от данного продукта и переходить на связку Spark Jubber+OpenFire- для прозрачной аутентификации в AD.

     Заранее благодарен.

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    4 сентября 2017 г. 9:40
  • но если пишешь на мобильном устройстве , то на терминальном клиенте ничего нет и наоборот. 

    Я что то не понял этой фразы - расшифруйте)

    По поводу мобильного клиента сразу не скажу - надо будет потестировать. А то с мобилы редко использую S4B Client)

    Ну и по поводу истории. У вас имеется в организации Exchange-сервер? Если хотите общую сохраняемую историю - то необходима интеграция с Exchange. Без него - максимум только локальная история для каждого клиента (на мобильнике своя история, на компьютере своя и тд). Помоему так.



    4 сентября 2017 г. 10:27
  • но если пишешь на мобильном устройстве , то на терминальном клиенте ничего нет и наоборот. 

    Я что то не понял этой фразы - расшифруйте) - Расшифровываю-

    простой пример- на мобильном клиенте S4B я пишу абоненту некий текст, диалог был закончен. далее я захожу в сессию удаленного рабочего стола- где у меня стоит обычный клиент S4B, аутентифицируюь- и я должен увидеть тот же самый текст-который я набирал с мобильного клиента. Либо я залогинелся на S4B клиенте у себя на ноутбуке где ни будь в командировке и я так же должен увидеть всю историю переписки, которую только что вел с абонентом. И наоборот, если я общаюсь через стационарный S4B клиент с абонентом либо через терминал, то в любой момент открыв мобильное приложение я должен увидеть тот же зсамый текс, который только что вводил беседую с клиентом. Вообще так работает обычный скайп, либо тот же jubber.То есть я параллельно вижу свою переписку на ЛЮБОМ клиенте скайпа. Нам нужен именно такой функционал одно сообщение- все клиенты сразу его принимаюь под моим логином- push!

    Изначально цель всего этого базировалось на главном функционале, который бы позволял использовать одну учетной запись в AD при аутентификации где либо. Jubber c этим работать не умеет, но как недавно и выше пишут- что можно добиться SSO для того что бы войти а домен и с той же УЗ запускать клиента Spark Jubber использую некий механизм Open Fire. Работая при это с параллельными Push уведомлениями, сохранением историй и т.д. Если в S4B все это сложно реализуется, или вообще не реализуется, то смысл городить тогда весь этот огород.

    Exchange - конечно же нет, зачем он тут нужен, его не было и не будет!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!



    • Изменено rеstless 4 сентября 2017 г. 10:48
    4 сентября 2017 г. 10:45
  • Если в S4B все это сложно реализуется, или вообще не реализуется, то смысл городить тогда весь этот огород.

    Exchange - конечно же нет, зачем он тут нужен, его не было и не будет!

    Дополню мысль коллеги выше. Для архивации сообщений используется либо связка Exchnage+ Skype и тогда сообщения хранятся в почтовом ящике пользователя (логично, правда?) 

    Или

    отдельный экземпляр SQL сервера (чтобы хранить сообщения (логично, правда?) Немножко Вам надо повтыкать в архитектуру продукта чтобы понимать его лучше. А то с каждым постом хочется все больше, а знаний не прибавляется в таком же количестве.

    И позволю предложение оффтопа, уж простите старика- а на чем хостится почта сейчас?

    У провайдера за три копейки? Сколько ящиков?

    4 сентября 2017 г. 10:54
  • На яндексе. Этим занимается другой админ, если не изменяет память на PostFix, ящиков всего 5, более тут и не надо :-))

    Все логично! ;-) Поэтому остался один вариант- который нужен- мобильный клиент с одном окном при беседе и историей и параллельным push уведомлениями сразу на всех клиентов (мобильных, терминальных и на ПК). Начальный капитал говорит, что все отдельные экземпляры лицензирования- не потянуть. Затем придется все таки отказаться от даной милой затеи и переходить на бесплатные продукты со связкой J+OF.

    Но зато практикум хороший получился. Есть над чем работать.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!



    • Изменено rеstless 4 сентября 2017 г. 11:09
    4 сентября 2017 г. 11:08

  • Или

    отдельный экземпляр SQL сервера (чтобы хранить сообщения 

    Немного не так) - Архивация это не conversation history. При архивации наши сообщения хранятся в базе (либо S4B/Lync, либо Exchange) и при необходимости их можно выдернуть по запросу (какие-нибудь внутренние или судебные разбирательства).

    Начальный капитал говорит, что все отдельные экземпляры лицензирования- не потянуть

    Пожалуй надо было сразу с этого начать, что S4B-инфраструктура - далеко не бюджетное решение) И некоторые приятные плюшки вы получите только при интеграции с Exchange. 


    4 сентября 2017 г. 15:27
  • Ок, на данный момент хочу все таки закончить с одновременными push уведомлениями на все устройства и хотя бы читать историю не из куча разных окон, а из одного что в мобильном клиенте, что в клиенте S4B на ПК.

    Например вот такая каптильня на мобильном клиенте- вообще неудобный функционал:

    Ну и повторюсь- все что я в мобильном клиенте напишу- должно отображаться в таком же клиенте , но только у меня на ПК или ноуте, а сейчас то что я написал здесь, оно и остается здесь, окрывая свой клиент S4B на ноуте я не вижу своего предложения, которое писал в мобильном клиенте.((


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 4 сентября 2017 г. 16:34
    4 сентября 2017 г. 16:26
  • Про сертификаты

    На WAP

    Я так понимаю если здесь нет webconf- то и push уведомления из-за этого недоступны ?

    На EDGE:


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 4 сентября 2017 г. 16:57
    4 сентября 2017 г. 16:57
  • Давайте по порядку. 

    Мне кажется вы немного не понимаете терминологию "PUSH". Прочтите ещё раз

    Теперь о том как доходят сообщения при использовании нескольких устройств.

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

    Далее данная беседа сохранится в историю переписки. Ключевое слово БЕСЕДА. Поэтому когда вы смотрите историю - то видите именно историю по отдельным беседам. Это не единая общая история для конкретного контакта - а история отдельных бесед! Ну и  если нет Exchange-сервера, то история сохранится локально на клиенте. Если имеется Exchange и интеграция с ним - то сохранится на нём. Отсюда следующий вывод - без интеграции с Exchange вы не увидите на мобильном устройстве те сообщения которые написали с рабочего ПК. Ну и соответственно наоборот. Т.к. нет единого хранилища где хранится журнал бесед.

    Ну и по сертификату. На EDGE-сервере имеется такая служба как Web Conferencing Edge service. Данная запись в сертификате нужна для этой службы. К PUSH'у она не имеет никакого отношения. Её описание "The Web Conferencing Edge service enables external users to join meetings that are hosted on your internal Lync Server 2013 deployment."



    5 сентября 2017 г. 3:06
  • Александр, доброго дня!

    Хорошо, с push уведомлениями ясно. Но если нет Exchange, то что без вариантов совсем что ли ? Ника кне сохранить историю, или надо бэк-енд ставить SQL есть варианты кроме экса то ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    5 сентября 2017 г. 12:47
  • У кого день, а у кого вечер) Приветствую!

    Я не в курсе за другие варианты)) Как я уже писал - архивация на SQL-сервере это немного другое. Но может коллеги поправят или подтвердят))

    5 сентября 2017 г. 13:25