Ejemplos de diseño de SharePoint Server: Portal corporativo y sitios de extranet

Artículo
03/08/2023

SE APLICA A: yes-img-13 2013 yes-img-16 2016 yes-img-19 2019 yes-img-se Subscription Edition no-img-sop SharePoint en Microsoft 365

En este artículo se describen varios ejemplos de diseño que se pueden utilizar como arquitecturas de punto de inicio de sitios de SharePoint. Los ejemplos de diseño descritos en este artículo ilustran las arquitecturas estándares para los tipos más comunes de los sitios de SharePoint que se implementan dentro de una empresa u organización.

Importante

La información de este artículo se aplica a SharePoint Foundation 2013 y SharePoint Server. Sin embargo, el artículo trata algunas características, como Mis sitios y la búsqueda empresarial, que no están disponibles en SharePoint Foundation 2013.

Acerca de los ejemplos de diseño

Los siguientes ejemplos de diseño se describen en este artículo:

Los ejemplos de diseño muestran sitios de una empresa ficticia denominada Fabrikam, Inc. Los ejemplos de diseño abarcan casi todos los componentes de arquitectura lógica e ilustran cómo estos se incorporan al diseño general. En este artículo se describen los objetivos de diseño para los ejemplos y se explica cómo los componentes de arquitectura lógica que se ilustran en los ejemplos han conseguido estos objetivos.

Nota:

Los modelos tienen SharePoint 2013 en el título, pero todavía emplean SharePoint Server 2016

Ejemplo de diseño de portal corporativo: dos versiones

Las colecciones de sitios con nombre de host en SharePoint Server proporcionan la administración de direcciones URL y la escalabilidad de los sitios dentro de una sola aplicación web. Las dos versiones del ejemplo de diseño de portal corporativo muestran las implementaciones que se basan en el uso de las tradicionales colecciones de sitios basadas en las rutas de acceso o de las colecciones de sitios con nombre de host. Estos dos ejemplos de diseño utilizan autenticación basada en notificaciones con una sola zona. Estos ejemplos se describen con más detalle más adelante en este artículo.

Se recomienda el uso de colecciones de sitios con nombres de host basadas en el diseño siempre que los requisitos exijan que hay que emplear sitios basados en rutas de acceso con asignación alternativa de acceso (vea Host-named site collection architecture and deployment (SharePoint 2013) para obtener más información). Este diseño se recomienda porque es la misma arquitectura que usa el entorno de Microsoft 365. Por lo tanto, esta es la configuración más probada. Las nuevas funciones, como el modelo de aplicaciones y la administración de solicitudes, se optimizan para esta configuración y esta es la configuración más fiable a partir de ahora.

Extranet con zonas dedicadas para autenticación

El ejemplo de diseño de extranet con zonas dedicadas para la autenticación solo incluye el sitio web de asociados. Proporciona una configuración alternativa para la colaboración del asociado en la que se utilizan zonas dedicadas para cada método de autenticación. Cada ejemplo de diseño utiliza la autenticación de modo de notificaciones para las aplicaciones web. La diferencia entre los ejemplos de diseño de portal corporativo y el ejemplo de diseño de extranet está en el modo en que están configuradas las zonas. El ejemplo de diseño de extranet con zonas dedicadas para la autenticación utiliza varias zonas y se configura un método de autenticación para cada zona. Los ejemplos de diseño de portal corporativo utilizan una zona y se configuran varios métodos de autenticación para las distintas clases de usuarios.

El ejemplo de diseño Extranet with Dedicated Zones for Authentication también presenta una nueva recomendación para el acceso remoto a los empleados: acceso directo con Windows Server 2012. Una alternativa a esta recomendación es crear una red privada virtual (VPN). También puede utilizar la autenticación basada en formularios en el producto de firewall o puerta de enlace para recopilar y reenviar credenciales, si lo desea.

Cómo se implementan las colecciones de sitios en los ejemplos de diseño

Mientras que las versiones anteriores del ejemplo de diseño de portal corporativo utilizan las colecciones de sitios basadas en la ruta de acceso, es recomendable que a partir de ahora se empiecen a utilizar las colecciones de sitios con nombre de host a menos que los requisitos indiquen que son necesarios los sitios tradicionales basados en la ruta de acceso con asignación alternativa de acceso (AAM). Esto se refleja en los ejemplos de diseño de las siguientes formas:

Portal corporativo con colecciones de sitios basadas en la ruta de acceso: este ejemplo ilustra las colecciones de sitios basadas en la ruta de acceso de la forma tradicional con sitios organizados en aplicaciones web dedicadas y una única colección de sitios de nivel superior por aplicación web. Utilice este enfoque si desea disponer de la seguridad adicional que proporcionan varias aplicaciones web con los grupos de aplicaciones independientes.
Portal corporativo con colecciones de sitios con nombre de host: este ejemplo ilustra el uso de colecciones de sitios con nombre de host con todos los sitios que se implementan en una sola aplicación web en la granja de servidores. Este método es altamente escalable y ofrece más flexibilidad en la administración de direcciones URL.
Extranet con zonas dedicadas para la autenticación: este ejemplo ilustra muchos sitios de proyecto de nivel superior con direcciones URL mnemónicas mediante el uso de sitios con nombre de host para cada sitio de proyecto (en lugar de organizar los sitios de proyecto por debajo de una colección de sitios de nivel superior). Una ventaja de utilizar las colecciones de sitios con nombre de host de esta manera es la creación de aislamiento adicional entre direcciones URL del dominio, que es preferible en una solución de colaboración de asociados. Sin embargo, la desventaja de este enfoque son los costos adicionales de administración de un mayor número de nombres de host, incluida la administración de certificados SSL. Además, si se usa la autenticación SAML, se requiere una configuración adicional (consulte "Uso de la autenticación SAML con sitios con nombre de host" más adelante en este artículo).

Autenticación basada en notificaciones para SharePoint Server

La forma en que la autenticación funciona en para SharePoint Server puede influir en las decisiones de diseño relacionadas con la implementación de opciones representadas por estos ejemplos de diseño. Estos son algunos ejemplos:

En SharePoint Server, la autenticación basada en notificaciones es el modo predeterminado y la única opción disponible a través de Administración central. La autenticación en modo clásico se puede implementar mediante PowerShell.
En SharePoint Server, no es necesario configurar la afinidad de servidor en el equilibrador de carga para usar la autenticación de notificaciones SAML. SharePoint Server admite totalmente el equilibrio de carga sin afinidad.

En SharePoint Server, la cuenta de rastreo de búsqueda requiere acceso al contenido a través de la zona Predeterminada mediante la autenticación de Windows integrada (NTLM o Kerberos). Dado que la autenticación basada en notificaciones permite múltiples tipos de autenticación en una zona, este requisito no debe afectar a otros requisitos de autenticación.

Resumen de las características de los ejemplos de diseño

La siguiente tabla resume los tres ejemplos de diseño que se tratan en este artículo.

Tabla: resumen de ejemplos de diseño

Ejemplo de diseño	Incluye	Elementos de diseño clave
Portal corporativo con sitios basados en rutas de acceso	Tipos de sitios más comunes implementados dentro de una organización.	Colecciones de sitios basadas en rutas de acceso Autenticación basada en notificaciones Proveedores de autenticación múltiple y tipos de autenticación implementados en una única zona
Portal corporativo con sitios con nombre de host	Tipos de sitios más comunes implementados dentro de una organización.	Colecciones de sitios con nombre de host Autenticación basada en notificaciones Proveedores de autenticación múltiple y tipos de autenticación implementados en una única zona
Extranet con zonas dedicadas para autenticación	Solo el sitio web de asociados. Proporciona una configuración alternativa para la colaboración de asociados	Colecciones de sitios con nombre de host Autenticación basada en notificaciones Zona distinta para cada método de autenticación

Sitios incluidos en los ejemplos de diseño

Esta sección describe los sitios de nivel superior que se incluyen en los ejemplos de diseño.

Sitios de intranet

El portal corporativo incluye los siguientes sitios para el uso de la intranet:

Contenido de intranet publicado (como HRweb)
Sitios de grupo de colaboración
Mis sitios

En conjunto, estos son los sitios de contenido y colaboración que los empleados utilizan de forma habitual. Individualmente, cada una de estas aplicaciones representa un tipo distinto de contenido. Cada tipo de contenido tiene las siguientes propiedades:

Destaca distintas características de SharePoint Server.
Hospeda datos con distintas características de datos.
Está sujeto a un perfil de uso diferente.
Requiere una estrategia de administración de permisos diferente.

Por lo tanto, las opciones de diseño de cada una de estas aplicaciones están pensadas para optimizar el rendimiento y la seguridad de cada aplicación.

El diseño de las aplicaciones de servicio reúne estas tres aplicaciones para proporcionar las siguientes funciones:

Búsqueda en toda la empresa
Metadatos empresariales y datos de perfiles compartidos

La siguiente ilustración, desde el portal corporativo con el ejemplo de diseño de las colecciones de sitios basadas en rutas de acceso, muestra los tres tipos de sitios que componen la intranet corporativa.

Tipos de sitios que componen la intranet corporativa

Sitios de intranet

Aplicación web de asociados

La aplicación web de asociados hospeda sitios disponibles de forma externa para la colaboración segura con empresas asociadas y asociados individuales. Esta aplicación está diseñada para que los empleados creen fácilmente sitios de colaboración segura. Los asociados no tienen permiso de acceso a otros tipos de contenido que no estén hospedados en la granja de servidores. El diseño de zonas y aplicaciones de servicio se ocupa de este objetivo. Además, los propietarios de sitios particulares administran permisos para sus sitios e invitan solo a los participantes necesarios a colaborar.

En el ejemplo de diseño de la extranet, este es el único tipo de sitio representado.

Objetivos de diseño generales

Los ejemplos de diseño proporcionan implementaciones prácticas de características de SharePoint Server dentro de varios tipos comunes de sitios. En este artículo, se describen las implementaciones de diseño para cada una de las aplicaciones individuales. A continuación, encontrará los objetivos de diseño clave para los ejemplos de diseño:

Crear un marco de trabajo para diseñar un entorno que puede crecer.

Las decisiones de diseño para los tipos individuales de sitios no evitan la adición de otros tipos de sitios. Por ejemplo, una implementación inicial puede incluir solo sitios de grupos de colaboración o solo los tres tipos de sitios que componen una intranet (sitios de grupo, Mis sitios y contenido de intranet publicado). Si utiliza un diseño de arquitectura lógica similar, puede agregar sitios a la solución sin afectar al diseño de la solución inicial. En otras palabras, el diseño no incorpora opciones de diseño que limitan el uso del entorno.
Proporcionar acceso para varios grupos de usuarios sin poner en peligro la seguridad del contenido dentro de los distintos tipos de sitios.

Los usuarios de distintas zonas de red (internas y externas) con distintos proveedores de autenticación pueden participar en la colaboración. Además, los usuarios solo pueden tener acceso al contenido al que están destinados. Si sigue un diseño de arquitectura lógica similar, puede proporcionar acceso a los usuarios que se encuentran en varias ubicaciones y tienen diferentes objetivos. Por ejemplo, el diseño inicial puede que esté destinado solo para acceso de los empleados internos. Sin embargo, si utiliza un diseño similar, también puede permitir el acceso a los empleados remotos, los empleados de asociados, las empresas asociadas y los clientes.
Garantizar que se puede usar el diseño en un entorno de extranet.

Haga elecciones intencionales de diseño para garantizar que la solución se puede implementar de forma segura en una red perimetral.

En el resto de este artículo se describe cada uno de los componentes lógicos que aparecen en el ejemplo de diseño (de arriba a abajo) y se describen las opciones de diseño que se aplican en el ejemplo de diseño. El propósito de este enfoque es demostrar las distintas formas en que se pueden configurar los componentes de la arquitectura lógica en función de la aplicación.

Granjas de servidores

En esta sección se describen las topologías de los conjuntos de servidores que se muestran en el ejemplo de diseño y se analiza el escalado más allá de una granja de servidores única.

Topología de las granjas de servidores

Cada granja de servidores del ejemplo de diseño consta de seis servidores con la siguiente topología con tolerancia a errores:

Dos servidores front-end web
Dos servidores de aplicaciones
Dos servidores de base de datos con SQL Server instalados y configurados para admitir SQL Server agrupación en clústeres, creación de reflejo o Always On. Always On requiere SQL Server 2012.

El concepto de front-end y servidor de aplicaciones es diferente en SharePoint Server 2016; vea Información general sobre los roles de servidor MinRole en SharePoint Server.

En el ejemplo de diseño se ilustra la arquitectura lógica de SharePoint Server al mostrar lo siguiente:

Todos los sitios tienen reflejos en los servidores front-end web.
El sitio de Administración central está instalado en un servidor de aplicaciones para protegerlo del acceso de usuario directo.

En realidad, el número de equipos servidor y la topología de la granja de servidores son importantes para la arquitectura lógica, únicamente para aumentar la capacidad y mejorar el rendimiento. Puede diseñar la arquitectura lógica independientemente de la topología del conjunto de servidores. El proceso de planeación de rendimiento y capacidad le ayudará a planear el tamaño del conjunto de servidores para cumplir los objetivos de rendimiento y capacidad. Para obtener más información, vea Planeamiento del rendimiento en SharePoint Server 2013.

Usuarios, zonas y autenticación

Las notificaciones son el modo predeterminado de autenticación en SharePoint Server y cada ejemplo de diseño incorpora la autenticación basada en notificaciones. Puede usar Windows PowerShell para implementar la autenticación en modo clásico; sin embargo, algunas características de SharePoint Server no están disponibles en modo clásico. Para obtener más información sobre los ejemplos de diseño que incorporan la autenticación en modo clásico, vea Ejemplo de diseño: Implementación corporativa (SharePoint Server 2010)

En la tabla siguiente se enumeran las diferencias que existen en los dos enfoques que se representan mediante el ejemplo de diseño del portal corporativo y el ejemplo de diseño de la extranet.

Tabla: Enfoques opuestos para las configuraciones de zona en los ejemplos de diseño

Enfoque	Portal corporativo con sitios con nombre de host y portal corporativo con sitios basados en rutas de acceso	Extranet con zonas dedicadas para autenticación
Modo de autenticación	Notificaciones	Notificaciones
Configuración de zonas	Una zona con varios métodos de autenticación configurados para las distintas clases de usuarios.	Varias zonas con un método de autenticación configurado para cada zona.
Direcciones URL	Todas las clases de usuarios utilizan la misma dirección URL para cada sitio. Los empleados utilizan la misma dirección URL independientemente de si están dentro de la red corporativa o trabajan de forma remota.	Cada clase de usuario utiliza una dirección URL diferente para tener acceso a un sitio. Los empleados utilizan una dirección URL diferente dependiendo de si están dentro de la red corporativa o trabajan de forma remota.
Solicitudes internas	Las solicitudes que se inician dentro de la red corporativa se redirigen fuera de la red y, a continuación, vuelven a través del servidor de puerta de enlace o proxy. Estas solicitudes se protegen mediante el protocolo Capa de sockets seguros (SSL). Como alternativa, puede utilizarse DNS dividido para redirigir las solicitudes directamente a la interfaz interna para los servidores.	Las solicitudes que se inician dentro de la red corporativa permanecen internas a la red.
Experiencia del usuario	A todos los usuarios se les pedirá que elijan el tipo de cuenta que utilicen para iniciar la sesión.	El método de autenticación es el predeterminado. Los usuarios no tienen que seleccionar el tipo de cuenta con una página de inicio de sesión.

Específicamente, en las secciones siguientes se describe cómo se incorpora la autenticación mediante el uso de los dos enfoques diferentes.

Extranet con el ejemplo de diseño de zonas dedicadas

El ejemplo de diseño de extranet muestra tres clases diferentes de usuarios, cada una asignada a una zona diferente. En cada aplicación web, puede crear hasta cinco zonas con uno de los nombres de zona disponibles: Predeterminada, Intranet, Internet, Personalizada o Extranet. La cuenta de rastreo de búsqueda requiere acceso a la zona predeterminada mediante la autenticación integrada de Windows (NTLM o el protocolo Kerberos), que se tiene en cuenta en el ejemplo de diseño. En la tabla siguiente se muestra cómo las zonas se configuran en el ejemplo de diseño de extranet.

Tabla: Zonas, usuarios y tipo de autenticación que se indican en el ejemplo de diseño de extranet

Zona	Usuarios	Autenticación
Intranet	Empleados internos y remotos Cuenta de rastreo de búsqueda	NTLM o protocolo Kerberos Empleados remotos que utilizan el acceso directo o VPN para conectarse.
Predeterminada	Asociados particulares	Opciones: Directorio LDAP con autenticación basada en formularios Bosque de Servicios de dominio de Active Directory (AD DS) hacia el exterior con una confianza unidireccional al bosque interno y autenticación integrada de Windows Proveedor de identidades de confianza con autenticación SAML
Extranet	Empresas asociadas	Proveedor de identidades asociado de confianza con autenticación SAML

Ejemplos de diseño de portal corporativo

La autenticación basada en notificaciones permite varios tipos de autenticación en la misma zona. Las dos versiones del ejemplo de diseño de portal corporativo utilizan la zona predeterminada para todos los tipos de autenticación.

En la siguiente tabla se muestran las zonas, los usuarios y los tipos de autenticación que se indican en los ejemplos de diseño.

Tabla: Zonas, usuarios y autenticación para los ejemplos de diseño de portal corporativo

Zona	Usuarios	Proveedor y tipo de autenticación
Valor predeterminado	Empleados internos y remotos	Servicios de dominio de Active Directory (AD DS) o almacén LDAP con autenticación basada en formularios o autenticación SAML.
Predeterminada	Asociados particulares	Proveedor de identidades de confianza con autenticación SAML o base de datos de SQL Server con autenticación basada en formularios
Valor predeterminado	Empresas asociadas	Proveedor de identidades asociado de confianza con autenticación SAML
Predeterminada	Cuenta de rastreo de búsqueda	AD DS con autenticación NTLM de Windows

En el ejemplo de diseño, el sitio de contenido de intranet publicado, los sitios de grupo y Mis sitios solo son accesibles para los empleados, ya sean internos o externos a la red. En el ejemplo de diseño se implementa una sola dirección URL (que usa SSL) para cada uno de estos sitios que se puede usar tanto interna como externamente. Se usan cuentas de AD DS. Si es necesario, la autenticación basada en formularios o SAML puede usar LDAP, lo que requiere una configuración adicional.

En el ejemplo de diseño, la aplicación web de asociados representa un sitio de extranet al que pueden obtener acceso los empleados de asociados y las empresas asociadas. La autenticación basada en notificaciones en este caso requiere que configure la confianza con uno o varios proveedores de identidad externos. Puede utilizar uno de los siguientes enfoques:

Puede configurar la granja de servidores de SharePoint para confiar en un proveedor de identidades externo, como el proveedor que se encuentra en una empresa asociada (para realizar autenticaciones directamente ante el directorio de asociados).
Puede configurar el proveedor de identidades dentro del entorno corporativo para confiar en un proveedor de identidades externo. Los administradores de las dos organizaciones deben establecer esta relación explícitamente. En este caso, el conjunto de servidores de SharePoint confía en el proveedor de identidades desde su propio entorno corporativo. Cuando el proveedor de identidades envía un token, el conjunto de servidores utiliza el certificado de firma de tokens que se especificó cuando se estableció la confianza para confirmar la validez del token. Recomendamos este enfoque.

La autenticación basada en formularios es una alternativa a un entorno basado en notificaciones para autenticar a los asociados. Utilice un almacén independiente, por ejemplo, una base de datos, para administrar estas cuentas.

Zonas

Al diseñar zonas, debe tomar varias decisiones que son esenciales para que la implementación sea correcta. Se trata de decisiones relativas al diseño y la configuración de las zonas siguientes:

La zona predeterminada
Las zonas para acceso externo

En las secciones siguientes se describen las decisiones que se incorporan en el ejemplo de diseño.

Requisitos de configuración de la zona predeterminada

La zona que implica la mayor consideración es la zona predeterminada. SharePoint Server establece los siguientes requisitos sobre cómo configurar la zona predeterminada:

Cuando una solicitud de usuario no puede asociarse con una zona, se aplican la autenticación y las directivas de la zona predeterminada. Por lo tanto, la zona predeterminada debe ser la zona más segura.
Los mensajes de correo electrónico administrativo incluyen vínculos de la zona predeterminada. Estos incluyen los mensajes a propietarios de sitios que se aproximan a los límites de cuota. Por tanto, los usuarios que reciben este tipo de alertas y mensajes deben poder tener acceso a vínculos a través de la zona predeterminada. Esto es especialmente importante para los propietarios de sitios.

En SharePoint Server se tiene acceso a las colecciones de sitios con nombre de host desde cualquier zona.

Configuración de zonas para un entorno de extranet

En un entorno de extranet, el diseño de zonas es imprescindible por las siguientes dos razones:

Varias redes distintas pueden iniciar las solicitudes de usuario. En los ejemplos de diseño, los usuarios inician solicitudes desde la red interna, Internet y las empresas asociadas.
Los usuarios consumen contenido en varias aplicaciones web. En el ejemplo de diseño, la intranet consta de tres aplicaciones web. Además, los empleados internos y remotos potencialmente pueden contribuir al contenido y administrarlo en la aplicación web asociada.

Si un entorno de extranet incluye varias zonas, compruebe que sigue estos principios de diseño:

Configure las zonas de varias aplicaciones web para que se reflejen mutuamente. La configuración de la autenticación y los usuarios a los que está dirigida deben coincidir. Sin embargo, las directivas asociadas a zonas pueden ser diferentes en las aplicaciones web. Por ejemplo, asegúrese de que utiliza la zona de intranet para los mismos empleados en todas las aplicaciones web. Es decir, no configure la zona de intranet para empleados internos en una aplicación web y para empleados remotos en otra.
Si utiliza colecciones de sitios basadas en rutas de acceso, configure las asignaciones de acceso alternativas de forma precisa y correcta para cada zona y cada recurso. Las asignaciones alternativas de acceso se crean automáticamente durante la creación de una zona. Sin embargo, puede configurar SharePoint Server para rastrear contenido en recursos externos, como un recurso compartido de archivos. Debe crear los vínculos a estos recursos externos manualmente para cada zona mediante asignaciones de acceso alternativas.
Si utiliza colecciones de sitios con nombre de host, asegúrese de que PowerShell asigna las direcciones URL a las zonas apropiadas

Si las zonas entre las aplicaciones web no se reflejan entre sí y los vínculos a recursos externos no son adecuados, pueden producirse los siguientes riesgos:

Los nombres de servidor, los nombres del Sistema de nombres de dominio (DNS) y las direcciones IP se pueden quedar expuestos fuera de la red interna.
Es posible que los usuarios no puedan acceder a los sitios web y otros recursos.

Uso de la autenticación SAML con sitios con nombre de host

Si un diseño incluye el uso de la autenticación SAML con sitios con nombre de host, cada dirección URL mnemónica requiere lo siguiente:

Un dominio nuevo en SPTrustedIdentityTokenIssuer
Una parte de usuario de confianza correspondiente en el proveedor de identidades.

Servicios

Las arquitecturas de servicio varían en función del ejemplo de diseño. El portal corporativo con el ejemplo de diseño de sitios con nombre de host incluye la arquitectura más sencilla para los servicios. Esto es porque utiliza una aplicación web, que puede dar cabida a un único grupo de aplicaciones de servicio (también conocido como grupo de servidores proxy).

El ejemplo del portal corporativo con sitios basados en rutas de acceso utiliza servicios particionados para los sitios asociados con el objeto de aislar datos entre proyectos. En este ejemplo de diseño se incorporan dos grupos de servicios, uno para los sitios de intranet y otro para los sitios de colaboración de asociados. Las instancias independientes de metadatos administrados y de búsqueda se implementan para los sitios asociados y estos servicios se dividen en particiones. Los servicios con particiones requieren el servicio de configuración de suscripción, que solo se puede implementar mediante PowerShell.

Arquitectura de servicio para el portal corporativo con sitios basados en rutas de acceso

Arquitectura de servicios

La implementación de servicios con particiones agrega complejidad a la arquitectura y dificulta la migración de sitios a Microsoft 365 más adelante. Otra opción más sencilla para los sitios asociados es implementar instancias dedicadas pero sin particiones del servicio de metadatos administrados y del servicio de búsqueda si fuese necesario que sean independientes. Muchas organizaciones dependen de la característica de recorte de seguridad de la búsqueda, en lugar de implementar instancias dedicadas del servicio de búsqueda.

El ejemplo de diseño de extranet incluye un único grupo de servidores proxy, pero también utiliza los servicios particionados para ambas aplicaciones: la del servicio de metadatos administrados y la del servicio de búsqueda.

La decisión principal de diseño para implementar aplicaciones de servicio es cuánto se propaga la taxonomía de la organización. Para simplificar la arquitectura de servicios, comparta los metadatos administrados, el perfil de usuario y la búsqueda en todas las aplicaciones web y básese en el recorte de seguridad para administrar el acceso al contenido. En el ejemplo de diseño del portal corporativo con sitios basados en rutas de acceso, una instancia del servicio de metadatos administrados se comparte en todos los sitios. Sin embargo, con esta configuración, todos los usuarios tienen acceso a la taxonomía corporativa. Los arquitectos de la solución deben decidir si se van a implementar varias instancias del servicio de metadatos administrados. También tendrán que decidir la amplitud con la que compartir los datos del perfil de usuario.

Dentro del portal corporativo con el ejemplo de colecciones de sitios basadas en rutas de acceso, el sitio web de asociados está configurado para utilizar las aplicaciones de servicios dedicadas de búsqueda y de metadatos administrados mediante el uso de un grupo de servicios personalizados. Otras aplicaciones de servicios se agregan al grupo personalizado y estas se comparten con el grupo predeterminado. La aplicación de servicio de perfiles de usuario no se incluye en el ejemplo de diseño para impedir que los usuarios asociados busquen datos de otras personas de la organización.

En la arquitectura simplificada del portal corporativo con colecciones de sitios con nombre de host (un grupo de servicios), los asociados pueden obtener acceso a toda la taxonomía corporativa y pueden examinar los datos de las personas de la organización. Sin embargo, la búsqueda limita los resultados a sitios y contenido a los que los asociados tienen acceso.

Si los sitios de asociados requieren aislamiento de contenido entre proyectos, la implementación de aplicaciones de servicio dedicadas es una buena opción, tal como se describe en este artículo. Esto aumenta la complejidad de la arquitectura de servicios, pero garantiza que los asociados no tengan acceso a los metadatos vinculados al contenido de intranet o incluso a otros proyectos en el sitio web de asociados. El ejemplo de diseño de extranet también utiliza los servicios particionados.

Sitios de administración

En el ejemplo de diseño, un servidor de aplicaciones hospeda el sitio web de Administración central de SharePoint para cada granja de servidores. Esto protege al sitio del contacto directo con el usuario. Si un cuello de botella de rendimiento o un riesgo de seguridad afecta a la disponibilidad de los servidores front-end web, el sitio web de Administración central de SharePoint sigue estando disponible.

Las direcciones URL de carga equilibrada de los sitios de administración no se mencionan en el ejemplo de diseño ni en este artículo. Entre las recomendaciones se incluyen las siguientes:

Si las direcciones URL administrativas usan números de puerto, use puertos no estándar. Las direcciones URL incluyen números de puerto de forma predeterminada. Aunque los números de puerto no se usan normalmente en las direcciones URL orientadas al cliente, el uso de números de puerto en los sitios de administración puede aumentar la seguridad al limitar el acceso a estos sitios a los puertos no estándar.
Cree entradas DNS independientes para los sitios de administración.

Además de estas recomendaciones, opcionalmente puede equilibrar la carga de el sitio web de Administración central de SharePoint entre varios servidores de aplicaciones para conseguir redundancia.

Grupos de aplicaciones

Los grupos de aplicaciones independientes de Internet Information Services (IIS) se suelen implementar para lograr el aislamiento de procesos entre el contenido. Los grupos de aplicaciones proporcionan una forma para que varios sitios se ejecuten en el mismo equipo servidor pero sigan teniendo sus propios procesos de trabajo e identidad. Esto ayuda a evitar que otros servidores o sitios en otros sitios se vean afectados si un atacante inserta código en un sitio.

Si un único dedicado de aplicaciones y una aplicación web se utilizan junto a las colecciones de sitios con nombre de host, se proporciona aislamiento entre direcciones URL de dominio, pero solo en el nivel de secuencias de comandos.

Si decide implementar más de un grupo de aplicaciones, considere la posibilidad de utilizar un grupo de aplicaciones dedicado para cada una de las siguientes situaciones:

Para separar el contenido autenticado del contenido anónimo. Si la misma granja de servidores hospeda el sitio de Internet de la empresa, coloque este sitio en un grupo dedicado de aplicaciones y una aplicación web.
Para aislar los sitios que almacenan contraseñas e interactúan con sistemas de datos de back-end (aunque, en su lugar, se puede usar el Servicio de almacenamiento seguro para este fin).

Tanto el portal corporativo con el ejemplo de diseño de sitios con nombre de host, como la extranet con zonas dedicadas para el ejemplo de diseño de autenticación implementan un grupo de aplicaciones y una aplicación web únicos para todo el contenido. Se requieren grupos de aplicaciones independientes para las aplicaciones de servicio y el sitio web de Administración central de SharePoint.

El ejemplo de diseño del portal corporativo con sitios basados en rutas de acceso implementa el aislamiento de procesos entre el contenido mediante el uso de grupos de aplicaciones independientes de las formas siguientes:

El sitio de administración se hospeda en un grupo de aplicaciones dedicado. Este es un requisito de SharePoint Server.
Todas las aplicaciones de servicio se implementan en un solo grupo de aplicaciones. A menos que exista un motivo convincente para implementar aplicaciones de servicio en diferentes grupos de aplicaciones, esta es la configuración recomendada. El uso de un grupo de aplicaciones para todas las aplicaciones de servicio optimiza el rendimiento y reduce la cantidad de grupos de aplicaciones que tendrá que administrar.
El contenido de intranet se divide en dos grupos de aplicaciones diferentes. Un grupo de aplicaciones hospeda contenido de colaboración (Mis sitios y sitios de grupo). Un grupo de aplicaciones independiente hospeda el contenido de intranet publicado. Esta configuración proporciona aislamiento de procesos para el contenido de intranet publicado en el que es más probable que se usen las conexiones de datos profesionales.
Un grupo de aplicaciones dedicado hospeda la aplicación web asociada.

Aplicaciones web

Una aplicación web es un sitio web de IIS que SharePoint Server crea y usa. Cada aplicación web se representa por medio de un sitio web diferente en IIS.

Si decide implementar más de una aplicación web, tenga en cuenta los siguientes casos de uso:

Separar el contenido autenticado del contenido anónimo.

Si la misma granja de servidores hospeda el sitio de Internet de la empresa, coloque este sitio en un grupo dedicado de aplicaciones y aplicaciones web.
Aislar a los usuarios

En el ejemplo de diseño, un grupo dedicado de aplicaciones y aplicaciones web hospeda el sitio web asociado para asegurarse de que los asociados no tienen acceso al contenido de intranet.
Exigir permisos

Una aplicación web dedicada ofrece la oportunidad de implementar directivas en las zonas de la aplicación web para exigir los permisos. Por ejemplo, puede crear directivas para el sitio de Internet de la empresa para denegar explícitamente el acceso de escritura a uno o varios grupos de usuarios. Las directivas se exigen independientemente de los permisos configurados en sitios o documentos individuales en la aplicación web.
Optimizar el rendimiento

Las aplicaciones consiguen un mejor rendimiento si se colocan en aplicaciones web con otras aplicaciones de características de datos similares. Por ejemplo, las características de datos de Mis sitios incluyen una gran cantidad de sitios cuyo tamaño es pequeño. Por el contrario, los sitios de grupo contienen normalmente una cantidad más pequeña de sitios de tamaño muy grande. Si estos dos tipos de sitios se colocan en aplicaciones web independientes, las bases de datos resultantes se componen de datos con características similares, lo cual optimiza el rendimiento de la base de datos. En el ejemplo de diseño, Mis sitios y los sitios de grupo no tienen requisitos de aislamiento de datos únicos: comparten el mismo grupo de aplicaciones. No obstante, Mis sitios y los sitios de grupo se colocan en aplicaciones web independientes para optimizar el rendimiento.
Optimizar la manejabilidad

La creación de aplicaciones web independientes da como resultado sitios y bases de datos independientes, por lo que puede implementar distintos límites al sitio (papelera de reciclaje, expiración y tamaño) y negociar distintos contratos de nivel de servicio. Por ejemplo, puede permitir más tiempo para restaurar el contenido de Mi sitio si este no es el tipo de contenido más importante de la organización. Esto permite restaurar el contenido más importante antes de restaurar el contenido de Mi sitio. En el ejemplo de diseño, Mis sitios se colocan en una aplicación web independiente para que los administradores puedan administrar el crecimiento de forma más dinámica en comparación con otras aplicaciones.

Si implementa las colecciones de sitios con nombre de host con una sola aplicación web, cada sitio de nivel superior es un dominio independiente que le permite alcanzar algunos de estos objetivos, tales como la optimización de la manejabilidad mediante la implementación de distintos límites de sitio.

Colecciones de sitios

La configuración recomendada para implementar sitios utiliza colecciones de sitios con nombres de host con todos los sitios ubicados dentro de una única aplicación web. Esta configuración se recomienda para implementar sitios porque es la misma arquitectura que usa el entorno de Microsoft 365. En consecuencia, esta es la configuración más probada. Las nuevas características, incluidos el modelo de aplicación y el Administrador de solicitudes, están optimizadas para esta configuración y es la configuración más fiable de aquí en adelante.

Aunque se recomiendan las colecciones de sitios con nombre de host para la mayoría de las arquitecturas, debe usar las colecciones de sitios tradicionales basadas en rutas de acceso, así como una asignación de acceso alternativa en caso de que se apliquen cualquiera de las condiciones siguientes:

Debe utilizar la característica de creación de sitios sin intervención del administrador que forma parte de la instalación predeterminada de SharePoint Server 2016.

Esto no se aplica a las soluciones de creación de sitios sin intervención del administrador.
Una aplicación web requiere inclusiones de comodín únicas o inclusiones explícitas.

Las inclusiones se crean para colecciones de sitios con nombre de host en el nivel de la granja de servidores y están disponibles para todos los sitios con nombre de host. Todas las colecciones de sitios con nombre de host de un conjunto de servidores comparten las mismas inclusiones, pero no necesitan utilizarlas. En cambio, las inclusiones que se crean para las colecciones de sitios basadas en rutas de acceso solo se aplican a una única aplicación web.
La terminación SSL es necesaria pero no se puede configurar el dispositivo de terminación SSL para producir el encabezado HTTP personalizado necesario.

Puede seguir utilizando el protocolo de puente SSL con colecciones de sitios con nombre de host con estos dispositivos si no se requiere la terminación SSL.
Planea usar distintos grupos de aplicaciones para la seguridad adicional que ofrecen o necesita usar varios grupos de proxy.

Para más información acerca de colecciones de sitios con nombre de host, incluida una comparación con colecciones de sitios basadas en la ruta de acceso, vea Arquitectura e implementación de colecciones de sitios con nombre de host (SharePoint 2013).

Objetivos de diseño de colecciones de sitios

Las colecciones de sitios enlazan la arquitectura lógica y la arquitectura de información. Los objetivos de diseño para colecciones de sitios consisten en el cumplimiento de los requisitos para el diseño de direcciones URL y en la creación de divisiones lógicas de contenido. Para cada colección de sitios, las rutas de acceso administradas incorporan un segundo nivel de colecciones de sitios de nivel superior. Para obtener más información sobre los requisitos de las direcciones URL y el uso de rutas de acceso administradas, vea Zones and URLs más adelante en este artículo. Más allá del segundo nivel de las colecciones de sitios, cada sitio es un subsitio.

En el siguiente diagrama se ilustra la jerarquía del sitio de los sitios de grupo.

Jerarquía del sitio de los sitios de grupo

Sitios de grupo

Tanto para las colecciones de sitios basadas en rutas de acceso como para las colecciones con nombre de host, la arquitectura de información gira en torno a la segunda capa de colecciones de sitios. En la siguiente sección se describe cómo los ejemplos de diseño incorporan opciones basadas en la naturaleza de los sitios.

Contenido de intranet publicado

La suposición en la que se basa la aplicación web de contenido de intranet publicado es que varias divisiones dentro de la empresa hospedarán contenido publicado. En el ejemplo de diseño, una colección de sitios independientes hospeda contenido de cada división. Esto proporciona las siguientes ventajas:

Cada división puede administrar el contenido y los permisos de forma independiente.
Cada división puede almacenar su contenido en una base de datos dedicada.

Las desventajas de varias colecciones de sitios son, entre otras, las siguientes:

No se pueden compartir las páginas maestras, los diseños de página, las plantillas, los elementos web y la navegación por las colecciones de sitios.
La coordinación de las personalizaciones y la navegación por las colecciones de sitios requieren más esfuerzo.

En función de la arquitectura de información y del diseño de los sitios de intranet, el contenido publicado puede parecerle al usuario una experiencia más libre. Como alternativa, cada colección de sitios puede parecer un sitio web independiente.

Mis sitios

Mis sitios tienen características distintas y las recomendaciones de implementación para Mis sitios son sencillas. En los ejemplos de diseño, la colección de sitios Mis sitios incorpora un sitio de nivel superior con la dirección URL de http://my. La primera colección de sitios de nivel superior que se crea utiliza la plantilla de host de Mi sitio. Una ruta administrada se incorpora (mediante el uso de la inclusión de caracteres comodín), lo que permite un número indefinido de sitios creados por el usuario. Todos los sitios por debajo de la ruta de acceso administrada son colecciones de sitios independientes que usan la plantilla de sitio personal. El nombre de usuario se anexa a la dirección URL con el formato http://my personal/ nombre de usuario. En la siguiente ilustración se muestran Mis sitios.

Jerarquía de sitios para Mis sitios

Mis sitios

Sitios de grupo

Puede utilizar cualquiera de los dos enfoques siguientes para diseñar las colecciones de sitios en una aplicación de sitios de grupo:

Permita que los grupos creen colecciones de sitios a través de la creación personalizada de sitios. La ventaja de este enfoque es que los grupos pueden crear fácilmente un sitio, según sea necesario, sin ayuda de un administrador. Entre las desventajas de este enfoque se incluyen:
- Pierde la oportunidad de implementar una taxonomía exhaustiva.
- No puede compartir las plantillas ni la navegación por los proyectos o grupos que de lo contrario podrían compartir una colección de sitios.
Cree un número finito de colecciones de sitios para la organización según el funcionamiento de la organización. En este enfoque, un administrador de SharePoint crea colecciones de sitios. Después de crear una colección de sitios, los grupos pueden crear los sitios dentro de la colección de sitios. Este enfoque proporciona la oportunidad de implementar una taxonomía exhaustiva que proporciona la estructura a la forma en que los sitios de grupo se administran y desarrollan. También existen más oportunidades de compartir las plantillas y la navegación entre proyectos y grupos que comparten una colección de sitios. Sin embargo, este enfoque también incluye algunas desventajas.

Los ejemplos de diseño incorporan el segundo enfoque, que da como resultado una jerarquía de colecciones de sitios similar para sitios de grupo y contenido de intranet publicado. El desafío para los arquitectos de la información es crear un segundo nivel de colecciones de sitios que tenga sentido para la organización. En la siguiente tabla se proponen diferentes tipos de organizaciones.

Tabla: Taxonomías sugeridas de las colecciones de sitios

Tipo de organización	Taxonomías sugeridas de las colecciones de sitios
Desarrollo de productos	Cree una colección de sitios para cada producto en desarrollo. Permita que los grupos de colaboración creen sitios dentro de la colección de sitios. Para cada proyecto de desarrollo a largo plazo, cree una colección de sitios para cada grupo de gran tamaño que contribuya al producto. Por ejemplo, cree una colección de sitios para cada uno de los grupos siguientes: diseñadores, ingenieros y desarrolladores de contenido.
Investigación	Cree una colección de sitios para cada proyecto de investigación a largo plazo. Cree una colección de sitios para cada categoría de proyectos de investigación.
Centro de enseñanza superior	Cree una colección de sitios para cada departamento académico.
Oficina legislativa estatal	Cree una colección de sitios para cada partido político. Los funcionarios de gobierno que comparten afiliación partidista pueden compartir plantillas y navegación. Cree una colección de sitios para cada comité. O bien cree una colección de sitios para todos los comités.
Bufete de abogados corporativo	Cree una colección de sitios para cada cliente corporativo.
Industria	Cree una colección de sitios para cada línea de productos.