Category Archives: 2213

Sharepoint List Adapters: The HTTP request is unauthorized with client authentication scheme ‘Ntlm’. The authentication header received from the server was ‘NTLM’.

En este caso estuve trabajando con el componente de CodePlex, SharePoint List Source and Destination (http://sqlsrvintegrationsrv.codeplex.com/releases/view/17652), que se integra con SSIS para gestionar los datos en las listas de sharepoint dentro de paquetes de ETL. En la consola de desarrollo de SSIS de forma repentina los paquetes que utilizan el Connection Manager de SharePoint generaron una advertencia:

Error: System.ServiceModel.Security.MessageSecurityException:
The HTTP request is unauthorized with client authentication scheme ‘Ntlm’.
The authentication header received from the server was ‘NTLM’.
—> System.Net.WebException: The remote server returned an error: (401) Unauthorized.

Al revisar algunos enlaces de referencia del error y el mensaje mismo, se identifico que la cuenta de usuario utilizada para conexión a Sharepoint, que utiliza por defecto el Connection Manager de Sharepoint de SSIS, estaba almacenada de forma errónea en el componente de administración de credenciales del sistema operativo. Se ejecutó el comando desde una ventana “Ejecutar… (run…):

rundll32.exe keymgr.dll,KRShowKeyMgr

Y se editó la credencial almacenada en el sitio de SharePoint. Se modificó tanto el nombre de usuario como la contraseña. Finalmente se cerró y abrió sesión nuevamente en el sistema operativo y SSIS con su paquete volvió a funcionar correctamente.

Referencias:

  • http://sqlstuff.weebly.com/ssis.html
  • http://support.microsoft.com/kb/555631/en-us

    Error "Archivo no encontrado" al crear "Mi sitio" – Office SharePoint Server 2007

    Posterior a la instalación de MOSS 2007, sin ningún tipo de problema o error, al tratar de crear un sitio personal se presentó el mensaje de error de “Archivo no encontrado” similar a la siguiente imagen:

    Al parecer es que no encontraba la página MySite.aspx que por defecto se instala con MOSS. Sin embargo luego de revisar todo ahí estaba. Revisé todas las configuraciones del Proveedor de Servicios Compartidos (Shared Service Provider – SSP) y todo estaba en orden.

    Igualmente luego de buscar y buscar en Internet no encontré una solución definitiva a mi problema. Finalmente se me ocurrió crear un nuevo “My Site host Location”, siguiendo los pasos del enlace http://technet.microsoft.com/en-us/library/cc263516.aspx, y al final funcionó y llegué a mi objetivo de crear sitios peronales.

    Cómo cambiar los formularios por defecto de una lista de SharePoint por formularios personalizados

    Toda lista de Sharepoint posee formularios por defecto para la creación (NewForm.aspx) y modificación (EditForm.aspx) que se encuentran ligados a la barra de herramientas de la lista o al desplegar el menú de un item ya creado. En muchos de los casos estos formularios por defecto deben ser cambiados por formularios personalizados. Para cambiar estos formularios por defectos de las listas de Sharepoint he utilizado Sharepoint Designer. Para esto seguir los siguientes pasos:


    – Previamente diseñar los formularios personalizados con los campos requeridos.


    – Ejecutar Sharepoint Designer y conectarse al sitio donde se encuentren implementadas las listas.



    – Hacer clic derecho sobre el nombre de la lista que se desea cambiar los formularios por defecto y seleccionar “Propiedades”.



    – En el cuadro de diálogo de propiedades de la lista, hacer clic en la viñeta “Archivos auxiliares”.



    – En la opción “Formularios específicos del tipo de contenido:” seleccionar “Elemento”.


    – Aparecen tres formularios en la parte inferior: de mostrar elementos, de nuevo elemento, y de editar elementor. Debajo de cada opción existe una linéa de texto deshabilitada indicando cual es el formulario por defecto, junto a esta línea de texto aparece un botón de “Examinar…” el mismo que debe ser presionado para seleccionar el formulario que reemplazará al que se encuentra por defecto.



    – Finalmente acepte los cambios realizados y compruebe en su lista que el cambio haya sido realizado.

    Error: 18452 – Login failed for user ”. The user is not associated with a trusted SQL Server connection. [CLIENTE: X.X.X.X]

    Un nuevo problema resuelto, pero antes explico mi escenario. Tengo un servidor Windows Server 2003 Std (controlador de dominio adicional) con SQL Server 2005 Std y MOSS 2007 Std. Desarrollé algunas formas en infopath para mantenimiento de información almacenada en SQL Server. Al momento de establecer la conexión con la base de datos, durante el proceso de diseño de los formularios, seleccioné el modo de autenticación integrado y asigné los permisos necesarios en SQL para que las distintas cuentas de usuario de dominio puedan ingresar sin problemas.


    Localmente en el servidor todos los formularios infopath funcionaron super bien, sin embargo cuando trataba de abrirlos en un equipo que no forma parte del dominio no podía ingresar a las formas y administrar los datos almacenados. Al revisar el log de SQL (C:\Archivos de programa\Microsoft SQL Server\MSSQL.1\MSSQL\LOG) se presenta el error así:


    Error: 18452, gravedad: 14, estado: 1.
    Login failed for user ”. The user is not associated with a trusted SQL Server connection. [CLIENTE: X.X.X.X]


    De entrada se trata de un error de validación. Luego de indagar algunos minutos en efecto me di cuenta que la validación de los usuarios contra SQL se hace mediante las cuentas de inicio de sesión de cada computador y no con las credenciales de MOSS. Para solucionar el problema cambié el modo de conexión de los formularios infopath a autenticación de SQL, cree una sola cuenta con los permisos de acceso necesarios, probé nuevamente y todo funcionó.


    Ahora me encuentro en el dilema de saber porque no funciona esto cuando se publica el servidor MOSS (extranet), me mantengo investigando.

    Content Deployment (WCM) con Office Sharepoint Server 2007 – Parte 4.1: Configuración de servidores (fuente y producción)

    Por la extensión del proceso de configuración de publicación de contenido (Content Deployment), lo voy a dividir en tres partes:




    • Parte 4.1: Configuración de servidores (fuente y producción)


    • Parte 4.2: Configuración de Content Deployment Path and Jobs


    • Parte 4.3: Pruebas y resultado final

    Configuración de servidor fuente
    Tal y como lo definí en la parte 3, el servidor fuente (generación de contenido) está configurado de la siguiente manera:




    • Sistema Operativo: Windows Server 2003 R2 Enterprise Edition – Español


    • Base de datos: SQL Server 2005 Standard Edition + SP2 – Inglés


    • Portal: Microsoft Office Sharepoint Server 2007 Standard Edition – Inglés


    • Componentes adicionales: .Net Framework 2.0, .Net Framework 3.0


    • Servicios adicionales: DNS, Directorio Activo, IIS 6.0 (soporte ASP.Net)


    • Nombre del servidor: MOSS1 


    • Dominio: INTRANET.LOCAL


    • Configuración IP:



      • Dirección: 172.16.10.25


      • Máscara: 255.255.255.0


      • DNS Primario: 172.16.10.25 (requisito de Directorio Activo)


      • DNS Secundario: 172.16.10.1 (servidor de producción de MOSS, necesario para que resuelva los nombres del otro dominio)

     La instalación y configuración de MOSS 2007 no lo cubriré ya que no es tema de este artículo. El sitio de MOSS de este servidor está configurado con la plantilla de “Publishing Portal”.



    El producto final luego de crear el sitio de generación de contenido, a partir de la plantilla, se muestra a continuación.



    Configuración de servidor de producción
    El servidor de producción (pulicación de contenido) está configurado de la siguiente manera:




    • Sistema Operativo: Windows Server 2003 R2 Enterprise Edition – Español


    • Base de datos: SQL Server 2005 Standard Edition + SP2 – Inglés


    • Portal: Microsoft Office Sharepoint Server 2007 Standard Edition – Inglés


    • Componentes adicionales: .Net Framework 2.0, .Net Framework 3.0


    • Servicios adicionales: DNS, Directorio Activo, IIS 6.0 (soporte ASP.Net)


    • Nombre del servidor: MOSS2 


    • Dominio: MOSS.LOCAL


    • Configuración IP:



      • Dirección: 172.16.10.1


      • Máscara: 255.255.255.0


      • DNS Primario: 172.16.10.1 (requisito de Directorio Activo)


      • DNS Secundario: 172.16.10.25 (servidor fuente de MOSS, necesario para que resuelva los nombres del otro dominio)

    El sitio de MOSS del servidor de producción está configurado con la plantilla de “Blank site”. No es necesario crear un sitio idéntico al de fuente en vista que toda la estructura y contenido es copiado de un sitio a otro.



    El sitio de producción o publicación de contenido es similar al mostrado a continuación.



    Como se puede apreciar, ambos sitios poseen un “look & feel” y estructura completamente distintas, luego de ejecutar la primera tarea de publicación de contenido, el sitio del servidor MOSS2 tendrá presentación y estructura idéntica al del servidor MOSS1.


    Configuración para recibir tareas de publicación – servidor MOSS2
    Para que el servidor MOSS2 pueda recibir información de publicación de contenido del servidor MOSS1 es necesario habilitar esta característica en la página de Administración Central de Sharepoint del servidor MOSS2. Ejecuten estos pasos:



    • Abrir el sitio de Administración Central de Sharepoint (clic en Inicio – Todos los programas – Microsoft Office Server – Administración Central de Sharepoint 3.0)

    • Una vez en el sitio de Administración Central, en la parte superior hacer clic en la viñeta “Operaciones” (Operations)

    • Ubicar la sección de “Content Deployment” y hacer clic en “Content Deployment Settings

    • En la página de Content Deployment Settings, seleccionar “Accept incoming content deployment jobs“, y en la sección de “Connection Security” seleccionar “Do not require encryption

    • Para finalizar, hacer clic en OK, y el servidor de publicación o producción se encuentra listo.

    En la parte 4.2 revisaré paso a paso la configuración de las tareas de publicación y “paths”.

    Content Deployment (WCM) con Office Sharepoint Server 2007 – Parte 3: Arquitectura del escenario de DEMO

    Ahora que están claros los conceptos acerca de Web Content Management, en esta tercera parte hablaré acerca de la arquitectura y configuración del escenario de demo para probar la funcionalidad de WCM.


    El escenario que construí para esta ocación es bastante simple. Dos máquinas virtuales con Windows Server 2003 R2 Enterprise, cada una configurada con un dominio de Directorio Activo distinto, SQL Server 2005 Standard y MOSS 2007 Standard. Ambos equipos virtuales tienen configurada una dirección IP de la misma subred. La siguiente figura ilustra de mejor manera el escenario.



    Para evitar estar instalando dos veces Windows Server 2003 R2 para crear cada máquina virtual, creé una sola y la cloné cambiando el SID de la segunda máquina virtual utilizando la herramienta de SYSINTERNALS newSID v4.10 http://www.microsoft.com/technet/sysinternals/Utilities/NewSid.mspx.


    Tal y como se recomienda en la documentación de Microsoft, el sitio del servidor MOSS1 fue creado utlizando la plantilla de “Publishing Portal”, que se encuentra en la viñeta de “Publishing”. El sitio del servidor MOSS2 fue creado nada más como un sitio de colaboración en blanco (viñeta de “Collaboration” seleccionar “Blank site”).


    Portal interno (generación de contenido)



    Sitio externo (publicación de contenido)



    En la cuarta y última parte de WCM explicaré las configuraciones paso a paso que se deben ejecutar en cada servidor y algunas pruebas sobre publicación de contenido.

    Como habilitar la opción de publicación de sitio en MOSS 2007 (Office Sharepoint Server Publishing)

    A manera de complemento de la serie de posts sobre WCM con MOSS, surgió la necesidad de investigar como habilitar la opción de publicación de sitio (Office Sharepoint Server Publishing) de un sitio de MOSS necesario para que las características y configuraciones de MOSS funcionen.


    Primero: ingresar a las Configuraciones del sitio (Site Settings)



    Segundo: ingresar a las configuraciones de las características del sitio (Site Features)



    Tercero: verificar si la opción de publicación se encuentra activa, sino, activarla.


    Content Deployment (WCM) con Office Sharepoint Server 2007 – Parte 2: Topologías

    En la parte 1 de esta serie de artículos sobre Content Deployment con MOSS 2007, hablé acerca de los conceptos claves y definiciones que se deben tener en claro antes de hacer una implementación de este servicio. En esta segunda parte hablaré acerca de las topologías comunes de Content Deployment.


    Para hablar acerca de las topologías comunes de Content Deployment utilizaré como base este link de Microsoft http://technet2.microsoft.com/Office/f/?en-us/library/1d6d6040-6cbb-4685-a40e-1e9086d426831033.mspx.


    Elementos básicos de la topología de Publicación de Contenido (Content Deployment)
    La gran mayoría de las topologías orientadas a publicación de contenido sobre MOSS 2007 utilizan una o varias granjas de servidores. Cada granja de servidores MOSS tiene un rol en específico y contenido exclusivo, ó en algunos casos puede ser igual. Un granja de servidores implementada en una arquitectura de Content Deployment puede tener varios roles o propósitos:




    • Authoring: la granja contiene una o varias colecciones de sitios donde el equipo de creación de contenido escribe o genera contenido nuevo.


    • Production: la granja de servidores contiene una o varias colecciones de sitios con el contenido definitivo presentado a su audiencia objetivo, y posee un nivel de seguridad alto al ser un servidor de producción accedido por usuarios externos.


    • Staging: esta granja de servidores es opcional y su finalidad es de mantener una copia del contenido de la granja de producción para ser revisada y probada antes de ser publicada. Esta granja se ubica justo entre la granja de “Authoring” y la granja de “Production”. 

    Nota: en este caso estoy utilizando el término “granja de servidores” tal y como se menciona en el artículo de Microsoft antes citado. Sin embargo en ambientes pequeños y medianos, como por ejemplo los que manejamos en la gran mayoría de la Región Andina, la realidad es que utilizaremos uno o dos servidores para cada segmento de la arquitectura de Content Deployment.


    Se sugiere que por cada segmento de la topología se implemente además un servidor front-end de importación y/o exportación según se requiera. Por ejemplo, en la granja de servidores del segmento “staging” el servidor front-end intervendrá tanto en funciones de exportación como de importanción, por lo tanto manejará ambos roles.


    Para detallar un poco más el proceso de publicación de contenido, la información intercambiada entre el servidor de generación de contenido (Authoring) y el servidor de producción (Production)  se realiza en paquetes CAB, de 10 MB de tamaño por defecto, que son almacenados en una carpeta temporal en el servidor de exportación. Luego de que todos los paquetes son almacenados en la ubicación temporal se ejecuta la tarea de publicación, y así mismo, cuando todos los paquetes llegan al servidor de destino el contenido es copiado a la colección de sitios de destino.


    Tanto el servidor de exportación como el de importación deben tener espacio suficiente para almacenar los paquetes CAB en caso de publicaciones de contenido grandes. Luego de finalizados los procesos de importación y exportación, los paquetes temporales son eliminados de las ubicaciones temporales.
    Es recomendable configurar una o varias tareas de publicación durante un día en caso de que exista una gran cantidad de generación o actualización de contenido, esto disminuirá en gran medida el volumen de información a ser intercambiado entre los servidores de producción y generación, y acelerará el proceso de publicación y obtención de información actualizada.


    Topologías de publicación de contenido comunes


    Topología de un sitio estandar de Internet


     


     


     


     


     


     


     


     


     


     


     


     


    Esta primera topología muesta tres segmentos de red bien definidos: intranet (red corporativa), red perimetral (DMZ) e internet. Dos firewalls controlan el acceso entre cada par de segmentos de red, lo que se conoce como una implementación de seguridad end-to-end. Detrás de cada firewall se encuentra configurada una granja de servidores, cada una de las cuales trabaja con un controlador de dominio por separado tal y como se recomienda. En cada granja además se encuentra un servidor de front-end que controlarán la importación y exportación de contenido al ejecutarse una tarea de publicación. En la DMZ exite una granja adicional de servidores de front-end que atienden y controlan las peticiones de acceso al sitio de producción de MOSS 2007 desde el internet.


    Para ambientes tipo PYMEs, todos los roles pueden estar operando en un solo servidor (Directorio Activo, Base de datos, y MOSS 2007), ó inclusive pueden estar separados pero sin la presencia de servidores de tipo front-end. A pesar que resulte ser una buena alternativa para reducir la inversión necesaria en hardware, el colocar todos los roles en un solo equipo representa un punto único de fallo. Se debe considerar al menos implementar por separado Directorio Activo y en un solo servidor mantener la base de datos y MOSS 2007. También habrá muy pocos escenarios en los cuales se encuentre implementada una topología end-to-end de servidores firewall; el mismo efecto se puede tener con un solo servidor firewall con tres interfaces de red.


    Existen dos variaciones posibles que pueden implementarse a partir de esta primera topología:




    • Un granja de producción para varias granjas de generación de contenido: en este escenario existen implementadas múltiples granjas de servidores de la DMZ, todas con igual o distinto contenido. Dependiendo de esto el esquema de replicación puede variar:



      • La granja de generación de contenido puede publicar contenido a todas las granjas de servidores en la DMZ, ó


      • La granja de generación de contenido puede publicar contenido a una sola granja en la DMZ, y ésta copiar el contenido al resto de granjas dentro de la DMZ.


    • Varias granjas de generación de contenido para una sola de producción: en la granja de producción se encuentran creadas varias colecciones de sitios, y cada granja de generación de contenido publica información a su respectiva colección de sitios en la granja de producción.

    Topología de tres etapas
    En la topología anterior intervinieron únicamente granjas de dos tipos: generación o creación de contenido y de producción. En esta segunda alternativa se consideran los tres tipos de granjas de servidores de MOSS: generación de contenido (authoring farm), “de paso” (staging farm) y de producción (production farm).



     


     


     


     


     


     


     


     


     


     


     


     


     


     


     


    La granja de generación de contenido y “de paso” se implementan en el segmento de la intranet. La granja “de paso” sirve para probar y revisar contenido antes de publicarlo en la granja de producción. En este mismo segmento se implementa un servidor adicional de front-end que controla y ejecuta las tareas de importación (desde la granja de generación de contenido) y exportación (hacia la granja de producción).


    Nuevamente, en ambientes PYME se tendrá un servidor para cada etapa de publicación de contenido: generación, “de paso”, producción; y en la gran mayoría de casos un solo servidor de firewall.


    Topología de granja simple
    En este escenario la colección de sitios de generación de contenido y de producción se encuentran implementados en un solo servidor. Cada colección mantiene un base de datos completamente separada y los permisos de acceso igualmente serán asignados por separado.


    En la parte 3 de esta serie de artículos hablaré acerca de la arquitectura y topología que implementaré para hacer una demo de Content Deployment con MOSS 2007.

    Content Deployment (WCM) con Office Sharepoint Server 2007 – Parte 1: Definiciones

    Con este primer post estoy iniciando mi camino a enriquecer mi blog con contenido acerca de temas que no se encuentran en Internet, o simplemente existen guías de planificación o arquitectura.


    Uno de los productos que siempre ha llamado mi atención por su gran funcionalidad y características es Sharepoint (Microsoft Office Sharepoint Server – MOSS 2007). En su última versión liberada, 2007, uno de los principales cambios que se dio fue en el tema de administración de contenido Web. En la versión 2003 de Sharepoint, la administración de contenido Web la realizaba Microsoft Content Management Server (CMS). CMS desapareció del listado de productos de MSFT y ahora toda la funcionalidad que tenía CMS se integra en MOSS, es así que uno de los principales pilares y componentes funcionales de MOSS 2007 es Enterprise Content Management (ECM).


    En este caso particular me concentraré en crear una guía paso a paso, desde los conceptos y arquitectura, de una parte de lo que involucra ECM, Content Deployment (Despliegue ó publicación de contenido), que es parte de Web Content Management (WCM) de MOSS.


    Para esta primera parte de conceptos y arquitectura, voy a tomar como base el link de planificación de Content Deployment de Microsoft http://technet2.microsoft.com/Office/f/?en-us/library/edcdacca-8013-460e-95a0-d2b83b6cc7ef1033.mspx


    ¿Qué es Content Deployment?
    Content Deployment no es más que copiar, parcial o totalmente, contenido de un sitio fuente de MOSS 2007 a un sitio destino igualmente de MOSS 2007. La parcialidad o totalidad de la copia de contenido hace referencia a la estructura como tal del sitio de MOSS y/o al contenido como tal publicado en el mismo. Es así que se puede copiar un sitio completo o parte de él, o inclusive copiar solo el contenido que ha cambiado (copia incremental).


    Un escenario común de Content Deployment tiene estas características:




    • El sitio fuente, desde donde se va a copiar la información, reside en un servidor distinto que el sitio de producción (sitio destino).


    • El servidor y sitio de producción se encuentran asegurados más fuertemente en vista de que éste es el servidor que será accedido por los usuarios.


    • No se espera, y no es lógico, que se hagan cambios manualmente en el servidor de producción debido a que el servidor de producción se actualizará en la medida que hayan tareas de publicación o despliegue de contenido desde el servidor fuente.


    • En algunos escenarios tanto el servidor fuente como el destino funcionan en dominios de Directorio Activo distintos. Nota: personalmente el que funcionen en un mismo dominio de Directorio Activo o no dependerá de si el contenido a ser publicado se encuentra controlado y protegido por credenciales de usuario de Directorio Activo (por ejemplo, bibliotecas de documentos, contenido basado en audiencias). Si se da ese caso yo recomiendo mantener a ambos servidores en un mismo dominio.


    • La dirección URL de la colección de sitios del origen y destino no necesariamente deben ser las mismas.


    • Content Deployment no funciona para: implementar assemblies de programas, configuraciones, características de sitios.

    Tareas de publicación (Deployment Jobs) y paths
    Una tarea de publicación determina cuando y que contenido copiar, de manera automática, desde una colección de sitios origen a una colección destino, especificados por un path (ruta de acceso). Para que una tarea de publicación se ejecute con éxito es necesario además:




    • Especificar las credenciales de autenticación válidas del servidor destino. Las tareas de publicación deben tener credenciales de Administración Central de Sharepoint en el servidor de destino.


    • Información acerca de si publicar o no información de nombres asociados con el contenido (por ejemplo, nombre del autor).


    • Información de como publicar información sobre permisos de acceso sobre el contenido.

    Se pueden definir una o más tareas de publicación dependiendo de cuan frecuente sea la actualización del contenido y la necesidad o premura de que dicho contenido sea accedido por usuarios en el servidor de producción. Una tarea de publicación además especifica:




    • Colección de sitios, en el servidor fuente, a ser publicados.


    • Frecuencia con la cual se ejecutarán las tareas de publicación.


    • Publicación de todo el contenido o simplemente de los cambios hechos luego de la última publicación.


    • Enviar una notificación vía correo electrónico indicando el éxito o fallo de la tarea de publicación.

    Tareas de publicación rápida (Quick Deployment Job)
    En sitios web empresariales puede existir contenido que cambia constantemente y es tan crítico que necesita ser publicado cuanto antes para que sea accedido por socios de negocios, empleados, gerentes, entre otros. Para estos casos se pueden configurar Tareas de publicación rápida que se ejecutan por defecto cada 15 minutos y publican todas las páginas que hayan sido marcadas para publicación luego de haberse ejecutado la última tarea de publicación. Para que este tipo de tareas se ejecuten es necesario que la característica de “Office Sharepoint Server Publishing Infraestructure” se encuentre habilitada.


    Seguridad en la publicación de contenido (Content Deployment Security)
    En muchos escenarios de publicación de contenido, como se mencionó anteriormente, es muy posible (y se recomienda) que tanto el servidor fuente como el servidor destino se encuentren funcionando en distintos dominios de Directorio Activo, y sin existir una relación de confianza entre los mismos. Para dar soporte a los distintos escenarios de funcionamiento integrado de MOSS 2007 con Directorio Activo, las tareas de publicación también pueden copiar información sobre cuentas de usuario y roles desde le servidor fuente al destino. Se presentan tres alternativas:




    • All, al seleccionar esta opción se copiará toda la información de seguridad de roles, usuarios y ACLs, del servidor fuente al destino. En este caso ambos servidores estarán funcionando en el mismo dominio para que pueda existir consistencia en la información intercambiada.


    • Role definitions only, en este caso solo se copiará información relativa a roles de usuario y ACLs.


    • None, con esta opción no se copiará información alguna del servidor fuente al destino y todo el control de acceso, definición de roles y ACLs quedará a cargo de un administrador. Esto permite asegurar que la seguridad de ambos servidores se administre y maneje por separado.

    En esta primera parte he logrado exponer los aspectos principales de la publicación de contenido, Content Deployment, de MOSS 2007. En la parte 2 definiré varias alternativas de topologías de publicación.