Pregunta

Recientemente, un cliente quería una nueva URL externa para SharePoint (intranet.Domain.com). Lo implementé a través de las zonas y el mapeo alternativo de acceso y hasta ahora funciona bien. También dejaron de usar su URL interna y usaron la intranet ahora en todas partes.

Ahora ocurrió que los usuarios obtuvieron correos electrónicos whos enlaces apuntan a la URL interna de SharePoint en lugar de la URL intranet externa. Probablemente no sería tanto un problema, si no habría un problema de autenticación con SharePoint y el acceso a través de su URL interna (nombre de servidor), ya que algunos cambios en los métodos de autenticación IIS.

Encontré un artículo de TechNet que propone un cmdlet para actualizar las URL de las alertas antiguas y esto está bien. Pero ahora me pregunto si las nuevas alertas podrían usar nuevamente la URL interna, o si el sitio solo se usa a través de Intranet, los enlaces de correo electrónico de las nuevas alertas también usarán la URL de Intranet.

Entonces también me gustaría ahora qué sucede si cambio la zona predeterminada a la intranet [...]. ¿Sería una buena idea o es una buena idea (si ya no es necesario la URL interna) para solucionar más de estos "URL antiguos utilizados"?

Nota: SharePoint 2010 se utiliza

¿Fue útil?

Solución

SharePoint utiliza la URL predeterminada para los enlaces en alertas y flujos de trabajo que se inician automáticamente.Con respecto a las alertas, la única forma real de esto es cambiar la URL de la zona predeterminada.Esto se puede hacer en CA con la AAM, por el conjunto de cmdlet-spalternateurl o (MI PREFERENCIA), elimine la aplicación web (preservando los datos del curso) y creando una nueva aplicación web para usar su nueva URL.La opción que selecciona depende de la configuración que haya realizado a las aplicaciones web y sus proveedores de autenticación.Las dos primeras opciones pueden funcionar para usted, pero realmente depende de la configuración que haya realizado después de que se haya creado la aplicación web.La única forma de asegurarse de que nada se romperá es recrear la aplicación web.

El artículo de TechNet que hace referencia es para una aplicación web migrada que aún está utilizando la URL del entorno antiguo y no lo ayudará aquí.

Licenciado bajo: CC-BY-SA con atribución
scroll top