URL, используемые в адресах оповещения

Question

Недавно клиент хотел новый внешний URL для SharePoint (Intranet.domain.com). Я реализовал его через зоны и альтернативным сопоставлением доступа и до сих пор работает нормально. Они также перестали использовать свой внутренний URL и использовать интрасеть сейчас везде.

Теперь это произошло, что пользователи получили электронные письма Whos ссылки на внутренний URL-адрес SharePoint вместо URL-адреса внешнего интрасети. Вероятно, он не будет такой большой проблемы, если бы не будет проблемой аутентификации с SharePoint и доступом через внутренний URL (ServerName), поскольку некоторые изменения в методах аутентификации IIS.

Я нашел эту статью Technet, которая предлагает командлет для обновления URL-адресов старых предупреждений, и это нормально. Но теперь я спрашиваю себя, если новые оповещения снова могут использовать внутренний URL или, если сайт используется только через интранет, ссылки электронной почты из новых предупреждений также будут использовать URL-адрес интрасети.

Тогда я также хотел бы теперь, что произойдет, если я изменим зону по умолчанию для интранета [...]. Будет ли этот перевезти SharePoint или это хорошая идея (если внутренний URL больше не нужен), чтобы исправить больше этих «старых URL-адресов», используемой «использованной»?

Примечание: SharePoint 2010 используется

Answer 1

SharePoint использует URL по умолчанию для ссылок в оповещениях и рабочих процессах, которые автоматически выгнали.Что касается предупреждений, единственно реальный путь вокруг этого состоит в том, чтобы изменить URL-адрес зоны по умолчанию.Это можно сделать в CA с AAM, с помощью Cmdlet Set-Spalternateurl или (мои предпочтения) удалите веб-приложение (сохраняя данные конечно) и создавая новое веб-приложение для использования вашего нового URL.Опция, которую вы выбираете, зависит от того, сколько конфигурации вы сделали в веб-приложениях и ее поставщикам аутентификации.Первые два варианта могут работать для вас, но это действительно зависит от того, насколько вы выполняли конфигурацию после создания веб-приложения.Единственный способ быть уверенным, что ничего не сломается - воссоздать веб-приложение.

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