Exportar (0) Imprimir
Expandir todo
Personas que lo han encontrado útil: 2 de 2 - Valorar este tema

Ejemplos de diseño de SharePoint 2013: portal corporativo y sitios de extranet

 

Se aplica a: SharePoint Server 2013, SharePoint Foundation 2013

Última modificación del tema: 2013-05-08

Resumen: describe opciones de diseño de arquitectura lógica para los ejemplos de diseño más comunes de SharePoint 2013.

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.

En este artículo:

ImportanteImportante:
La información de este artículo se aplica a SharePoint Foundation 2013 y SharePoint Server 2013. 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.

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.

Las colecciones de sitios con nombre de host en SharePoint 2013 proporcionan administración de las direcciones URL y escalabilidad de sitios reunidas en 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 (consulte Arquitectura e implementación de colecciones de sitios con nombre de host (SharePoint 2013) para obtener más información). Se recomienda este diseño porque es la misma arquitectura que en entorno de Office 365 utiliza. Por tanto, es la configuración que más se ha probado. 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.

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 de extranet con zonas dedicadas para la autenticación también presenta una recomendación nueva para el acceso remoto de empleados: el 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.

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 utiliza la autenticación SAML, tendrá que configurar opciones adicionales (vea "Uso de la autenticación SAML con sitios con nombre de host" más adelante en este artículo).

La forma en la que la autenticación funciona para SharePoint 2013 podría influir en las decisiones de diseño que están relacionadas con la implementación de opciones representadas por estos ejemplos de diseño. A continuación se describen algunos ejemplos:

  • En SharePoint 2013, la autenticación basada en notificaciones es el modo predeterminado y la única opción disponible en Administración central. La autenticación de modo clásico se puede implementar mediante Windows PowerShell.

  • En SharePoint 2013, no tiene que configurar la afinidad del servidor en el equilibrador de carga para utilizar la autenticación de notificaciones SAML. SharePoint 2013 es totalmente compatible con el equilibrio de carga sin afinidad.

En SharePoint 2013 la cuenta de rastreo de búsqueda requiere acceso al contenido a través de la zona predeterminada mediante el uso de 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.

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

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

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:

  • Enfatiza distintas funciones de SharePoint 2013.

  • 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

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.

En los ejemplos de diseño se proporcionan implementaciones prácticas de las características de SharePoint 2013 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.

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.

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 bases de datos con SQL Server instalado y configurado para admitir agrupación en clústeres, creación de reflejos o AlwaysOn de SQL Server. AlwaysOn requiere SQL Server 2012.

En el ejemplo de diseño se ilustra la arquitectura lógica de SharePoint 2013 al mostrar que:

  • 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, consulte Planeación del rendimiento y la administración de capacidad en SharePoint Server 2013.

Las notificaciones son el modo predeterminado de autenticación en SharePoint 2013 y cada ejemplo de diseño incorpora la autenticación basada en notificaciones. Puede utilizar Windows PowerShell para implementar la autenticación de modo clásico; sin embargo, algunas características de SharePoint 2013 no están disponibles en el modo clásico. Para obtener más información acerca de los ejemplos de diseño que incorporan la autenticación de 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

 

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.

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

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

Predeterminada

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

Predeterminada

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.

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.

La zona que implica la mayor consideración es la zona predeterminada. SharePoint 2013 exige los siguientes requisitos de configuración de 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 2013 se puede obtener acceso a las colecciones de sitios con nombre de host desde cualquier zona.

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 2013 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 Windows 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.

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.

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 particionados requieren el servicio de configuración de la suscripción que solo se puede implementar mediante el uso de Windows PowerShell.

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

Arquitectura de servicios

La implementación de servicios particionados agrega complejidad a la arquitectura y hace que sea difícil migrar sitios a Office 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 deben decidir cuánto se comparten los datos de 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.

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 en la seguridad afectan 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.

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. Los grupos de aplicaciones independientes son necesarios para las aplicaciones de servicios y para 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. Es un requisito de SharePoint 2013.

  • 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.

Una aplicación web es un sitio web de IIS que SharePoint 2013 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.

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 Office 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 aplique 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 2013.

    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).

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 Zonas y direcciones URL 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.

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 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 de Mis sitios incorpora un sitio de nivel superior con la dirección URL del tipo 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 en el formulario http://my personal/nombre de usuario. En la siguiente ilustración se muestran Mis sitios.

Jerarquía de sitios para Mis sitios

Mis sitios

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 las 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.

El sitio web de asociados está pensado para usarse en la colaboración con asociados externos en proyectos que tienen ámbitos finitos o duraciones limitadas. De manera intencional, los sitios dentro de la aplicación web de asociados no están diseñados para relacionarse. Entre los requisitos para la aplicación web de asociados se incluye garantizar lo siguiente:

  • Los propietarios del proyecto pueden crear fácilmente sitios para la colaboración de asociados.

  • Los asociados y otros colaboradores solo pueden tener acceso al proyecto en el que trabajan.

  • Los propietarios de los sitios administran los permisos.

  • Los resultados de la búsqueda desde dentro de un proyecto no exponen contenido de otros proyectos.

  • Los administradores pueden identificar fácilmente los sitios que ya no se usan y eliminarlos.

Para satisfacer estos requisitos, en el ejemplo de diseño se incorpora una colección de sitios para cada proyecto. Ambos ejemplos de diseño del portal corporativo utilizan una ruta de acceso administrada para crear un segundo nivel de colecciones de sitios por debajo de una colección de sitios raíz. Como alternativa, el ejemplo de diseño de la extranet hace de cada sitio de asociados una colección de sitios de nivel superior mediante el uso de colecciones de sitios con nombre de host. Ya sea de un modo u otro, las colecciones de sitios individuales proporcionan el nivel de aislamiento adecuado entre proyectos.

Si piensa utilizar la característica de creación de sitios sin intervención del administrador que forma parte de la instalación predeterminada de SharePoint 2013 (a diferencia de una solución personalizada desarrollada para su organización), utilice entonces las colecciones de sitios basadas en rutas de acceso. Las colecciones de sitios con nombre de host aún no funcionan con esta característica.

Puede usar los dos enfoques siguientes para incorporar bases de datos de contenido en el diseño (en el ejemplo de diseño se incorporan ambos enfoques):

  • Establezca tamaños de destino para las bases de datos de contenido con umbrales de advertencia de tamaño apropiados. Cree una nueva base de datos cuando la base de datos alcance los umbrales de advertencia de tamaño. Con este enfoque, las colecciones de sitios se agregan automáticamente a la base de datos o bases de datos disponibles, únicamente en función de los objetivos de tamaño. Este es el enfoque más usado.

  • Asocie colecciones de sitios a bases de datos de contenido específicas. Este enfoque permite colocar una o varias colecciones de sitios en una base de datos dedicada que los administradores podrán administrar de forma independiente con respecto a las demás.

Si opta por asociar colecciones de sitios a bases de datos de contenido específicas, puede usar los métodos siguientes para hacerlo:

  • Utilice Windows PowerShell para crear una colección de sitios en una base de datos específica.

  • Dedique una base de datos a una sola colección de sitios mediante la aplicación de la siguiente configuración de capacidad de la base de datos:

    • Número de sitios antes de que se genere un evento de advertencia = 1

    • Número máximo de sitios que se puede crear en esta base de datos = 1

  • Para agregar un grupo de colecciones de sitios a una base de datos dedicada, complete los siguientes pasos:

    1. Dentro de la aplicación web, cree la base de datos y establezca el estado de la base de datos en Listo.

    2. Establezca el estado del resto de bases de datos en Sin conexión. Mientras las bases de datos de contenido están sin conexión, no se pueden crear nuevas colecciones de sitios. Sin embargo, las colecciones de sitios existentes de las bases de datos sin conexión siguen estando accesibles para operaciones de lectura y escritura.

    3. Cree las colecciones de sitios. Se agregan a la base de datos automáticamente.

    4. Vuelva a establecer el estado del resto de bases de datos en Listo.

En el caso del contenido de intranet publicado, los ejemplos de diseño incorporan una base de datos para facilitar la administración. Agregue bases de datos en función de los objetivos del tamaño de destino, si fuese necesario.

Para Mis sitios, en los ejemplos de diseño del portal corporativo se logra que la escala sea eficaz mediante la administración de bases de datos en el tamaño de destino máximo. Para conseguir este objetivo, se configuran las siguientes opciones:

  • Limitar el almacenamiento del sitio a un máximo de: esta opción, que puede configurar en la página Plantillas de cuota en Administración central, limita el tamaño de un sitio personal.

  • Papelera de reciclaje de segunda etapa: esta opción, que se configura en la página Configuración general de la aplicación web, determina la cantidad de espacio adicional que se asigna a la papelera de reciclaje de la segunda etapa.

  • Número máximo de sitios que se puede crear en esta base de datos: esta opción se configura al crear una base de datos. Calcule el tamaño total permitido de los sitios mediante los números especificados para los dos valores anteriores. A continuación, según el objetivo de tamaño para cada base de datos, determine cuántos sitios entrarán en la base de datos.

En los ejemplos de diseño se proporciona la siguiente configuración de tamaño de ejemplo en función de un tamaño de base de datos de destino de 175 gigabytes (GB) y un tamaño de Mi sitio de destino de 1 GB:

  • Límites de tamaño por cada sitio = 1 GB

  • Tamaño de destino de la base de datos = 175 GB

  • Reservado para la papelera de reciclaje de la segunda etapa = 15 %

  • Número máximo de sitios = 180

  • Advertencia de nivel de sitio = 150

Cuando se alcance la advertencia de nivel de sitio, cree una nueva base de datos. Después de crear la nueva base de datos, se agregarán Mis sitios nuevos a la base de datos de contenido que tenga el menor número colecciones de sitios.

Se espera que los sitios de grupo de la mayoría de las organizaciones sean mucho mayores que los sitios de Mis sitios. Los sitios de grupo se crean bajo una ruta de acceso administrada, que permite una base de datos de contenido por colección de sitios de grupo. En el ejemplo de diseño se proporciona una configuración de la base de datos según un límite de 30 GB para las colecciones de sitios. Elija un límite que sea apropiado para los sitios de grupo de la organización.

De forma similar que Mis sitios, el sitio web de asociados logra que la escala sea eficaz mediante la administración de bases de datos en el tamaño de destino máximo.

En el ejemplo de diseño se proporciona la siguiente configuración de tamaño:

  • Tamaño de destino de la base de datos = 200 GB

  • Cuota de almacenamiento por sitio = 5 GB

  • Número máximo de sitios = 40

  • La colección de sitios de creación se hospeda en una base de datos dedicada

En los ejemplos de diseño se muestra cómo coordinar direcciones URL a través de varios sitios dentro de una implementación corporativa. Los siguientes objetivos tienen influencia en las decisiones de diseño para las direcciones URL:

  • Las convenciones de direcciones URL no limitan las zonas a través de las cuales se puede tener acceso al contenido.

  • Los puertos estándar HTTP y HTTPS (80 y 443) se pueden usar en todas las aplicaciones del ejemplo de diseño.

  • Los números de puerto no se incluyen en las direcciones URL. En la práctica, no se suelen usar números de puerto en entornos de producción.

Al crear una aplicación web, se debe elegir una dirección URL de carga equilibrada para asignar a la aplicación. La dirección URL que elija se aplicará a la zona predeterminada. Además, se debe crear una dirección URL de carga equilibrada para cada zona adicional que se cree dentro de una aplicación web. La dirección URL de carga equilibrada incluye el protocolo, el esquema, el nombre de host y el puerto, si se usan. La dirección URL de carga equilibrada debe ser única en todas las zonas y aplicaciones web. Por lo tanto, cada aplicación web y cada zona dentro de cada aplicación web requieren una dirección URL única en el ejemplo de diseño.

Cada una de las tres colecciones de sitios que forman la intranet necesitan una dirección URL única. En los ejemplos de diseño del portal corporativo, la audiencia de destino para el contenido de intranet consta de los empleados internos y remotos. Los empleados usan las mismas direcciones URL para cada uno de estos sitios independientemente de que sean remotos o internos. Este enfoque agrega una capa de seguridad al diseño de SharePoint (todo el tráfico es SSL). Sin embargo, este enfoque requiere que elija una alternativa a la configuración adicional:

  • Redirija el tráfico interno a través del producto de servidor de seguridad o puerta de enlace junto con el tráfico remoto.

  • Establezca un entorno de DNS dividido para resolver las solicitudes internas dentro de la red interna.

En los ejemplos de diseño, los empleados internos, los empleados remotos y los empleados de asociados tienen acceso al sitio web de asociados. En los ejemplos de diseño del portal corporativo, todos los usuarios escriben la misma dirección URL, independientemente del método de autenticación. En el ejemplo de diseño de la extranet, cada tipo distinto de usuario escribe una dirección URL diferente. Aunque los asociados particulares y las empresas asociadas utilizan SSL (HTTPS) para obtener acceso al sitio web de asociados de forma externa, cada grupo necesita una dirección URL diferente para aplicar las ventajas de usar zonas separadas; es decir, distintos métodos de autenticación y distintas directivas de zona.

Dado que el ejemplo de diseño de la extranet utiliza acceso directo o VPN para el acceso remoto de empleados, tanto los empleados internos como los empleados remotos utilizan las mismas direcciones URL. Si se configura el acceso para los empleados remotos a través de un dispositivo de proxy inverso, los empleados remotos requerirían una URL independiente mediante SSL, que necesita de una zona adicional. Por último, el ejemplo de diseño de la extranet incorpora las colecciones de sitios con nombre de host en lugar de una sola colección de sitios de nivel superior. Por lo tanto, cada sitio de proyecto tiene una dirección URL diferente.

En la siguiente tabla se muestran las direcciones URL de ejemplo que los empleados internos, los empleados remotos y los asociados usan para tener acceso al sitio web de asociados, tal como se muestra en el ejemplo de diseño de la extranet.

Tabla: Direcciones URL de ejemplo del ejemplo de diseño de la extranet

Zona URL de ejemplo

Empleados internos y remotos

http://project1

Asociados particulares

https://project2.fabrikam.com

Empresas asociadas

https://TrustedPartnerProject1.fabrikam.com

Las rutas de acceso administradas permiten especificar qué rutas del espacio de nombres URL de una aplicación web se usan para colecciones de sitios. Puede especificar que existen una o varias colecciones de sitios en una ruta de acceso distintiva situada por debajo del sitio raíz. Sin rutas de acceso administradas, todos los sitios por debajo de la colección de sitios raíz forman parte de la colección de sitios raíz.

Puede crear los dos tipos siguientes de rutas de acceso administradas:

  • Inclusión explícita: una colección de sitios con la dirección URL explícita que asigne el usuario. Una inclusión explícita se aplica a una sola colección de sitios. Puede crear varias inclusiones explícitas por debajo de una colección de sitios raíz. Una dirección URL de ejemplo para una colección de sitios creada con este método es http://intranet/hr. Hay un impacto en el rendimiento para cada ruta de acceso explícita agregada, por lo que se recomienda limitar el número de colecciones de sitios creadas con una inclusión explícita a aproximadamente 20.

  • Inclusión de caracteres comodín: se agrega una ruta de acceso a la dirección URL. Esta ruta de acceso indica que todos los sitios especificados directamente después del nombre de la ruta de acceso son colecciones de sitios únicas. Esta opción se suele usar para colecciones de sitios que admiten la creación de sitios sin intervención del administrador, como Mis sitios. Una dirección URL de ejemplo para una colección de sitios creada con este método es http://my/personal/user1.

Cuando se implementan las rutas de acceso administradas para colecciones de sitios con nombre de host, estas rutas de acceso administradas se crean en el nivel de la granja de servidores y se aplican en todas las aplicaciones web, si se han incluido varias aplicaciones web en la solución. Cuando se implementan las rutas de acceso para los sitios basados en rutas de acceso, estas rutas administradas se aplican solo en la aplicación web en la que se han creado.

En el ejemplo de diseño se incorpora el uso de ambos tipos de rutas de acceso administradas (inclusiones explícitas e inclusiones de caracteres comodín), tal y como se describe en las secciones siguientes.

En las muestras de diseño, la colección de sitios de intranet publicada incorpora las inclusiones explícitas para cada subsitio, por ejemplo, recursos humanos, instalaciones y compras. Cada una de estas colecciones de sitios puede asociarse con una base de datos de contenido diferente, si es necesario. A menos que se utilicen las colecciones de sitios con nombre de host, el uso de inclusiones explícitas en este ejemplo supone que no se crea ningún otro tipo de sitio en la aplicación web, incluidas las inclusiones de caracteres comodín.

El uso de inclusiones explícitas da como resultado las siguientes direcciones URL:

  • https://intranet.fabrikam.com

  • https://intranet.fabrikam.com/hr

  • https://intranet.fabrikam.com/facilities

  • https://intranet.fabrikam.com/purchasing

En este ejemplo, la colección de sitios raíz, http://intranet.fabrikam.com, representa la página principal predeterminada de la intranet. Este sitio está pensado para hospedar contenido para los usuarios.

Los sitios de grupo, Mis sitios y la aplicación web de asociados incorporan el uso de una inclusión de caracteres comodín. Las inclusiones de caracteres comodín son ideales para las aplicaciones que permiten a los usuarios crear sus propias colecciones de sitios y para las aplicaciones web que incluyen muchas colecciones de sitios. Una inclusión de caracteres comodín indica que el siguiente elemento después del carácter comodín es un sitio raíz de una colección de sitios.

Dentro de la aplicación de sitios de grupo, la inclusión de caracteres comodín se usa para cada colección de sitios de grupo. Las prácticas de buen gobierno recomiendan que se mantenga el número de sitios de grupo de nivel superior dentro de un número manejable. Además, la taxonomía para sitios de grupo debe ser lógica para el funcionamiento de un negocio.

El uso de inclusiones de caracteres comodín da como resultado las direcciones URL:

  • https://teams.fabrikam.com/sites/Team1

  • https://teams.fabrikam.com/sites/Team2

  • https://teams.fabrikam.com/sites/Team3

En este ejemplo, la colección de sitios raíz, https://teams.fabrikam.com, no necesariamente hospeda contenido para los usuarios.

Mis sitios ofrecen creación de sitios sin intervención del administrador. Cuando un usuario que examina la intranet hace clic por primera vez en Mi sitio, se crea automáticamente un sitio para el usuario. En el ejemplo de diseño, Mis sitios incluyen una inclusión de caracteres comodín denominada /personal (http://my/personal). La característica de Mi sitio anexa automáticamente el nombre de usuario a la dirección URL.

Esto da como resultado las direcciones URL con el formato:

  • https://my.fabrikam.com/personal/User1

  • https://my.fabrikam.com/personal/User2

  • https://my.fabrikam.com/personal/User3

Si se utilizan las colecciones de sitios basadas en rutas de acceso, puede implementar la característica de creación de sitios sin intervención del administrador para permitir que los empleados creen sitios seguros para la colaboración con asociados externos. Si se utilizan las colecciones de sitios con nombre de host, puede implementar una característica de creación de sitios sin intervención del administrador o los administradores pueden crear sitios de proyecto asociados si así se solicita.

En los ejemplos de diseño del portal corporativo, la aplicación web de asociados incluye una inclusión de caracteres comodín denominada /sites (http://partnerweb/sites). Esto da como resultado direcciones URL con el siguiente formato:

  • https://partnerweb.fabrikam.com/sites/Project1

  • https://partnerweb.fabrikam.com/sites/Project2

  • https://partnerweb.fabrikam.com/sites/Project3

Si se implementan las colecciones de sitios basadas en rutas de acceso, configure las asignaciones alternativas de acceso (AAM) para cada dirección URL del sitio de la granja de servidores. Esto garantiza que las solicitudes web se asignen al sitio correcto, especialmente en entornos que usan tecnologías de servidor proxy inverso o de equilibrio de carga.

Las direcciones URL de nombre único, como http://teams, se pueden configurar para obtener acceso a la intranet. Un equipo cliente resuelve estas direcciones URL al agregar el sufijo DNS del equipo cliente, como fabrikam.com, y emitir luego una búsqueda DNS del nombre con el sufijo. Por ejemplo, cuando un equipo cliente en el dominio fabrikam.com solicita http://teams, el equipo envía una solicitud a DNS de http://teams.fabrikam.com.

Es necesario configurar DNS para usar un registro A, o AAAA para IPv6, para cada nombre de dominio completo (FQDN). El registro apunta a la dirección IP con carga equilibrada para los servidores web que están hospedando un sitio. En una implementación de producción típica, los servidores se configuran para usar direcciones IP asignadas estáticamente, además de registros A o AAAA asignados estáticamente en DNS.

Una vez que un explorador cliente recibe la dirección IP con equilibrio de carga, el explorador del cliente se conecta con un servidor front-end web de la granja de servidores y, a continuación, envía una solicitud HTTP con la dirección URL de un solo nombre original, http://teams. IIS y SharePoint 2013 reconocen esta como una solicitud de zona de intranet, basada en la configuración establecida en las asignaciones alternativas de acceso. Si, de lo contrario, un usuario solicita https://teams.fabrikam.com, el proceso es similar, pero IIS y SharePoint 2013 reciben este FQDN en su lugar y, por lo tanto, reconocerán esta solicitud para la zona predeterminada.

En entornos que tienen varios dominios, especifique los registros CNAME para DNS en los dominios donde no residen los sitios. Por ejemplo, si el entorno de red Fabrikam incluye un segundo dominio llamado europe.fabrikam.com, los registros CNAME se especifican para estos sitios en el dominio Europe. Para el sitio de intranet de los sitios de grupo (http://teams), se agrega un registro CNAME llamado teams al dominio europe.fabrikam.com que apunta a teams.fabrikam.com. A continuación, cuando el sufijo DNS de un equipo cliente se agregue a las solicitudes de búsqueda DNS, una solicitud para http://teams desde el dominio Europe emitirá una búsqueda DNS de teams.europe.fabrikam.com y el registro CNAME la dirigirá a teams.fabrikam.com.

NotaNota:
Existe un problema conocido con algunos clientes que utilizan la autenticación Kerberos y la resolución de registros CNAME. Para obtener más información, vea Problemas conocidos de la configuración de Kerberos (SharePoint Server 2010).

Puede configurar directivas para una o varias zonas para exigir los permisos de todo el contenido en una aplicación web. En el modo de notificaciones, se puede definir una directiva solo para una zona específica (no para la aplicación web en general). Una directiva exige permisos en todo el contenido al que obtienen acceso los usuarios mediante una zona. Los permisos de directiva invalidan todas las demás opciones de seguridad configuradas para los sitios y el contenido. Puede configurar la directiva según usuarios o grupos de usuarios, pero no según grupos de SharePoint. Si agrega o cambia una directiva de zona, la búsqueda debe volver a rastrear los sitios para aplicar los nuevos permisos.

Los ejemplos de diseño no utilizan directivas porque o bien se habilitan varios tipos de autenticación en una sola zona o bien todos los sitios están dentro de una aplicación web (o ambas opciones).

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft. Reservados todos los derechos.