none
Некорректное преобразование имени MS Office Web Apps (OWAps) сервера при публикации SharePoint 2013 Server RRS feed

  • Вопрос

  • Есть ферма SharePoint 2013, коллекция сайтов с нее опубликована наружу через TMG.

    Развернут MS Office Web Apps (OWAps) сервер, пристегнут к ферме с SharePoint, опубликован наружу (пока для теста через HTTP).

    Пристегнут путем:

    New-OfficeWebAppsFarm -InternalURL "http://owaps.Acompany.local" - ExternalURL "http://owaps.Acompany.com" -AllowHttp -EditingEnabled
    New-SPWOPIBinding -ServerName "http://owaps.Acompany.local" -AllowHTTP

    Изнутри все документы видятся и редактируются через браузер прекрасно.

    Снаруже же получаем ошибку преобразования имен, SharePoint неправильно отдает url. Формирует неправильную ссылку именно SharePoint, проверял сниффером на TMG и на самой ферме.

    Пример.

    Внутреннее имя фермы: http://intranet.Acompany.local
    Внутреннее имя OWAps: http://owaps.Acompany.local
    Внешнее имя сайта портала: https://intranet.Acompany.com
    При попытке открытия снаружи документов видно, что браузер пытается открыть внутреннюю ссылку, т.е. идет на http://owaps.Acompany.local вместо http://owaps.Acompany.com

    Вопрос. Как побороть? Документации по OWAps - мизер...


    • Изменено Allan Stark 8 декабря 2014 г. 10:27
    8 декабря 2014 г. 10:26

Ответы

  • Вкратце - проблема была таки в связке OWAps и SharePoint.

    OWAps просто не умеет трансформировать свои ссылки, за него это делает SharePoint, для которого привязку к SPWOPI в случае работы на две и более сред необходимо указывать только как external (что собственно и описано в документации), но непосредственно создавать привязку (New-SPWOPIBinding) нужно ПОСЛЕ настройки зоны (Set-SPWOPIZone).

    Топология:

    На OWAps сервере:
    1. Вносим в файл hosts IP сервера webapp.company.com или создаем в доменном DNS зону webapp.company.com
    2. Импортируем в локальное хранилище сертификатов нужный сертификат, сертификат должен быть pfx формата.
    3. На сервере IIS добавляем в bind к сайту HTTP80 альтернативное имя :
    https://webapp.company.com:443
    4. Выполняем создание новой OWAps фермы:
    New-OfficeWebAppsFarm -InternalUrl "http://webapp.company.local" -ExternalUrl "https://webapp.company.com" -CertificateName
     "wild.company.com" -EditingEnabled -AllowHTTP

    На SharePoint сервере:
    1. Вносим в файл hosts IP сервера
    webapp.company.com или создаем в доменном DNS зону webapp.company.com
    2. Проверяем SPWOPI зону:
    Get-SPWOPIZone
    в случае, отличном от “external-https” - правим:
    Set-SPWOPIZone -zone "external-https"
    3. Делаем привязку к серверу OWAps (привязка исп. текущее значение SPWOPIZone):
    New-SPWOPIBinding -ServerName webapp.company.local -AllowHTTP

    На TMG сервере:
    1. Вносим в файл hosts IP сервера
    webapp.company.com или создаем в доменном DNS зону webapp.company.com
    2. Создаем два правила публикации: одно для самого сервера SharePoint 2013 и второе - для OWAps, правила публикации типовые,
     для SharePoint. В свойствах web-listener-а указываем принудительную переадрессацию HTTP на HTTPS и обязательно включаем SSO, чтобы при переходе к OWAps-у заново не открывалась страница HTML Form аутентификации.

    Замечания.

    1. С внесением в hosts на самом деле можно не заморачиваться и сделать более красиво - путем добавления зоны webapp.company.com в DNS серверы домена и созданием в ней соотв. "A" записи - способ более правильный и элегантный (по факту так и сделал).

    2. В моем случае схема развертывания на самом деле на порядок сложнее из-за наличия нескольких external trusted доменов, подключенных site-to-site, потому требуются некоторые дополнительные аналогичные телодвижения в DNS серверах этих доменов для нахождения OWAps сервера.

    3. В моем случае все осложняет наличие единственного wild сертификата - по каким-то причинам, даже если в нем в хранилище конкретного сервера внести Friendly name - все равно при попытке бинда в правиле публикации TMG выкидывет ошибку несоответствия имен (сертификат есть в хранилищах обоих серверов), но с самого сервера TMG следующий диагностический URL прекрасно открывается: https://webapp.company.com/hosting/dicovery. Разворачивать локальный CA или заморачиваться с самоподписными сертификатами не захотел, потому проблему решил "малой кровью" - путем принудительной переадресации HTTP на HTTPS. В любом случае сниффер показывает, что непосредственно сами документы OWAps отдает по HTTPS, по HTTP идут команды взаимодействия с интерфейсом, например при редактировании.

    Скудная справка в TechNet по интеграции OWAps и SharePoint явно писалась для сценария, когда все локальные домены "названы правильно", типа officeN.company.com (на эту тему интересно почитать "прозрение" г-на Рудя:http://itband.ru/2012/05/name/ ), но у многих в наличии архитектуры доменов, взращенных еще с начала 2000-х (в духе "что-то там".local), потому странно что в справке описан только один сценарий и лишь мимоходом упомянуто, что с  сингл-нэйм доменами ничего работать не будет (собственно все и так давно знают что такие домены не работоспособны).

    Если будут вопросы - пишите в личку, постараюсь ответить.

    • Предложено в качестве ответа Kaplin VladimirModerator 10 декабря 2014 г. 8:53
    • Помечено в качестве ответа Allan Stark 10 декабря 2014 г. 9:02
    • Изменено Allan Stark 10 декабря 2014 г. 10:00
    10 декабря 2014 г. 8:47

Все ответы

  • добрый день

    AllowHTTP - Указывает, может ли командлет использовать протокол HTTP для обнаружения поддерживаемых приложением WOPI функций. Если задано значение True, сведения об обнаружении из приложения WOPI будут отправлены через незащищенное соединение.

    получается, что HTTPs работать не будет.

    подробнее:

    New-SPWOPIBinding

    Настройка Office Web Apps для SharePoint 2013


    8 декабря 2014 г. 11:55
    Модератор
  • Не в этом проблема.

    Можно вернуть обратно Set-SPWOPIZone -zone "internal-https" и заморочиться самоподписными сертификатами или выдать из локального центра сертификатов - проблема остается на месте.

    Нужно как-то объяснить SharePoint-у, что если он отдает ссылку на обращение к OWAps-у наружу через AAM, то надо это делать правильно...

    На TMG настроен SSO, обращение к OWAps-у напрямую, только по правильному имени, например http://owaps.company.com/letterhead/%D0%AE%D0%BD%D0%B8%D... - прекрасно отображает документ.

    Т.е. проблема именно в SharePoint-е, при исп. AAM он не транслирует правильно URL к вызову OWAps.

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



    • Изменено Allan Stark 8 декабря 2014 г. 15:51
    8 декабря 2014 г. 15:49
  • посмотрите, возможно уже видели

    Configuring Office Web Apps in SharePoint 2013

    8 декабря 2014 г. 19:29
    Модератор
  • Да, это просто вольный пересказ справки... В итоге поборол проблему. Вечером попробую набросать подробный мануал и выложить сюда. Там много чего интересного будет :)
    9 декабря 2014 г. 12:26
  • У самого только HTTP 

    будем ждать.

    9 декабря 2014 г. 14:32
    Модератор
  • Вкратце - проблема была таки в связке OWAps и SharePoint.

    OWAps просто не умеет трансформировать свои ссылки, за него это делает SharePoint, для которого привязку к SPWOPI в случае работы на две и более сред необходимо указывать только как external (что собственно и описано в документации), но непосредственно создавать привязку (New-SPWOPIBinding) нужно ПОСЛЕ настройки зоны (Set-SPWOPIZone).

    Топология:

    На OWAps сервере:
    1. Вносим в файл hosts IP сервера webapp.company.com или создаем в доменном DNS зону webapp.company.com
    2. Импортируем в локальное хранилище сертификатов нужный сертификат, сертификат должен быть pfx формата.
    3. На сервере IIS добавляем в bind к сайту HTTP80 альтернативное имя :
    https://webapp.company.com:443
    4. Выполняем создание новой OWAps фермы:
    New-OfficeWebAppsFarm -InternalUrl "http://webapp.company.local" -ExternalUrl "https://webapp.company.com" -CertificateName
     "wild.company.com" -EditingEnabled -AllowHTTP

    На SharePoint сервере:
    1. Вносим в файл hosts IP сервера
    webapp.company.com или создаем в доменном DNS зону webapp.company.com
    2. Проверяем SPWOPI зону:
    Get-SPWOPIZone
    в случае, отличном от “external-https” - правим:
    Set-SPWOPIZone -zone "external-https"
    3. Делаем привязку к серверу OWAps (привязка исп. текущее значение SPWOPIZone):
    New-SPWOPIBinding -ServerName webapp.company.local -AllowHTTP

    На TMG сервере:
    1. Вносим в файл hosts IP сервера
    webapp.company.com или создаем в доменном DNS зону webapp.company.com
    2. Создаем два правила публикации: одно для самого сервера SharePoint 2013 и второе - для OWAps, правила публикации типовые,
     для SharePoint. В свойствах web-listener-а указываем принудительную переадрессацию HTTP на HTTPS и обязательно включаем SSO, чтобы при переходе к OWAps-у заново не открывалась страница HTML Form аутентификации.

    Замечания.

    1. С внесением в hosts на самом деле можно не заморачиваться и сделать более красиво - путем добавления зоны webapp.company.com в DNS серверы домена и созданием в ней соотв. "A" записи - способ более правильный и элегантный (по факту так и сделал).

    2. В моем случае схема развертывания на самом деле на порядок сложнее из-за наличия нескольких external trusted доменов, подключенных site-to-site, потому требуются некоторые дополнительные аналогичные телодвижения в DNS серверах этих доменов для нахождения OWAps сервера.

    3. В моем случае все осложняет наличие единственного wild сертификата - по каким-то причинам, даже если в нем в хранилище конкретного сервера внести Friendly name - все равно при попытке бинда в правиле публикации TMG выкидывет ошибку несоответствия имен (сертификат есть в хранилищах обоих серверов), но с самого сервера TMG следующий диагностический URL прекрасно открывается: https://webapp.company.com/hosting/dicovery. Разворачивать локальный CA или заморачиваться с самоподписными сертификатами не захотел, потому проблему решил "малой кровью" - путем принудительной переадресации HTTP на HTTPS. В любом случае сниффер показывает, что непосредственно сами документы OWAps отдает по HTTPS, по HTTP идут команды взаимодействия с интерфейсом, например при редактировании.

    Скудная справка в TechNet по интеграции OWAps и SharePoint явно писалась для сценария, когда все локальные домены "названы правильно", типа officeN.company.com (на эту тему интересно почитать "прозрение" г-на Рудя:http://itband.ru/2012/05/name/ ), но у многих в наличии архитектуры доменов, взращенных еще с начала 2000-х (в духе "что-то там".local), потому странно что в справке описан только один сценарий и лишь мимоходом упомянуто, что с  сингл-нэйм доменами ничего работать не будет (собственно все и так давно знают что такие домены не работоспособны).

    Если будут вопросы - пишите в личку, постараюсь ответить.

    • Предложено в качестве ответа Kaplin VladimirModerator 10 декабря 2014 г. 8:53
    • Помечено в качестве ответа Allan Stark 10 декабря 2014 г. 9:02
    • Изменено Allan Stark 10 декабря 2014 г. 10:00
    10 декабря 2014 г. 8:47
  • Allan Stark, спасибо за подробный мануал, который Вы написали! Он может пригодится многим участникам форума!

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

    10 декабря 2014 г. 9:41
    Модератор
  • Привел в нормальный вид пост с алгоритмом (т.к. копировал из нашей базы знаний, а местный движок очень любит калечить форматирование).
    10 декабря 2014 г. 9:57