SharePoint Latin Rotating Header Image

December, 2011:

Como restablecer el sitio web de IIS “SharePoint Web Services” cuando éste es eliminado por error en SharePoint 2010

Algo que me gusta de trabajar como ingeniero de soporte freelance es el orgullo que te da ganar esas pequeñas batallas contra la ignorancia.


Problema


El problema fue que se extendió una aplicación web de SharePoint usando el sitio web de IIS “SharePoint Web Services”. Antes que cualquier otra cosa, este sitio web de IIS hospeda algunos servicios WCF de sistema los cuales se configuran en todos los WFE de la granja y son utilizados por algunas aplicaciones de servicio, el asistente de configuración de SharePoint es el encargado de aprovisionar este sitio web en tiempo de instalación y configuración de la granja. 


image


Lo que sucedió es que al extenderse esta aplicación web en este caso “MySite” se detuvieron aplicaciones de servicio y quedo totalmente inoperable. El resultado fue desastroso para la granja ya que se detuvieron las aplicaciones de servicio Manage Metadata, User Profile y en este caso el portal de MySite de todo el corporativo. El mensaje de error al intentar acceder al portal fue Could not load user profile, adicional el visor de eventos empezó a regitrar An exception occurred when trying to issue security token: The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.


Como primera reacción de cualquier ser humano es la de des extender el portal.


image


Inyectando con esto un problema mayor ya que al remover vía herramienta de administración SharePoint el sitio web de IIS causa que las carpetas asociadas en el sitio web sean eliminadas de la ruta a la que apunta, en este caso C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\Root.


La solución


La solución a este escenario fue ejecutar el script mencionado en el post How to get back the SharePoint WebServices application in IIS if deleted, SharePoint 2010   para regenerar el sitio web de IIS “SharePoint Web Services”,  este proceso en efecto si aprovisiono de nuevo el sitio web de IIS, sin embargo, al dar clic sobre el marcaba un error indicando que no existía la ruta de los archivos lo cual es totalmente correcto ya que al des extender se elimino todos los archivos de la ruta a donde apuntaba.


image


Lo que se decidió fue buscar la carpeta Root de otra granja y copiarla sobre la carpeta en cuestión. Posteriormente se ejecuto de nuevo el siguiente codigo encontrado aqui: How to get back the SharePoint WebServices application in IIS if deleted, SharePoint 2010. Basicamente lo que el procedimiento hace es cargar una instancia de la place SPIisWebServiceInstanceSettings e invoca un par de metodos para realizar el aprovisionamiento del sitio web de IIS sobre el servidor. Una vez que es aprovisionado se procede a realizar un ciclo donde por cada aplicacion de servicio es aprovionado el nuevo sitio web de IIS restableciendo con esto la vinculacion y la dependencia al mismo.


$webservice = [System.Type]::GetType(“Microsoft.SharePoint.Administration.SPIisWebServiceSettings, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”)


$Instance = $webservice::Default


$Method = $webservice.GetMethod(“ProvisionLocal”, “Instance, NonPublic”, $null, @(), $null)


$Method.Invoke($Instance, $null)


$Method = $webservice.GetMethod(“Provision”, “Instance, Public”, $null, @(), $null)


$Method.Invoke($Instance, $null)


Get-SPServiceApplication | ForEach-Object {$_.Provision()}


En resumen


Cuando inicias con una nueva plataforma  y estas en proceso de aprendizaje es comun o normal que sucedan detalles, errores, situaciones de configuracion por error, la recomendacion es revisar cualquier procedimiento en una granja de pruebas para validar el proceso y los resultados previamente.  Aqui dos enlaces donde platico algunas consideraciones al respecto: Que se necesita para ser consultor y/o desarrollador SharePoint y Consideraciones para poner en marcha soluciones personalizadas SharePoint en ambientes de producción de nuestros clientes.


Saludos

Como entender las necesidades SharePoint de los amigos a los que no queremos hacer enojar

Cuando implementamos SharePoint y éste empieza a tener auge en la empresa vemos que de pronto tienes a gerentes, ejecutivos o jefes de área de esos que no quieres hacer enojar, interesados en tener su sitio SharePoint para su departamento. He notado que algunos ejecutivos piensan que con solamente tener un sitio SharePoint dedicado mágicamente ya colaboran y están totalmente comunicados. La realidad es que un sitio de equipo SharePoint es tan efectivo como irrelevante si no dedicamos tiempo a definir qué características del producto serán utilizadas, aprovisionadas y debidamente configuradas especialmente para resolver alguna carencia de colaboración y/o comunicación. Por lo tanto, cuando entrevisto a estas personas para entender realmente qué necesitan independientemente de lo que quieren utilizo el siguiente enfoque para realmente identificar que problema de negocio se intenta resolver para lo cual consideren que un flamante sitio de equipo SharePoint es una alternativa de solución.



1.    Documento de Requerimientos de Negocio para Sitio de “area”
1.1.    Objetivo de Negocio / antecedentes de la solicitud
1.1.1.    Descripción del problema
1.1.2.    Prioridades
1.2.    Especificación (registrada por el dueño del negocio)
1.2.1.    Característica deseada 1
1.2.2.    Característica deseada 1
1.3.    Enfoque de aceptación por usuario final
1.4.    Plan de comunicación a usuarios finales


Por cada característica deseada pedimos que se capture un antecedente u observaciones que no tengan que ver con características de SharePoint sino de problemas o escenarios de negocio que se busquen tener o resolver. Por ejemplo, si el dueño del negocio nos dice que quiere un calendario o foro de discusión como una característica deseada, intento entender para que requieran ese calendario o foro, tratamos de ver cuál es el aspecto relacionado con la colaboración y/o comunicación que realmente está necesitando y para lo cual nuestro cliente considera que SharePoint sin duda es la herramienta ideal.


Al final este documento refleja las carencias, preocupaciones y sobre todo lo que realmente le duele o desea este ejecutivo preocupado por el empoderamiento de sus subordinados.


Como un consejo, durante la entrevista puedes ir llenando el documento con la información que estas recopilando, al finalizar comentas que mandaras un documento borrador para asegurar que realmente entendiste la necesidades y que solicitas una revisión y edición por parte del dueño de negocio integrando lo que considere necesario. Al terminar la sesión retocamos y editamos un poco mejor el documento quitando de momento aspectos relacionados con temas de SharePoint y orientando el texto a las necesidades y/o problemas de negocio lo mandas y esperas la retroalimentación del dueño de negocio.


Una vez teniendo, entonces inicias con la especificación técnica de solucion al problema y esto será otro post.


Saludos!

Configurando User Policy en SharePoint 2010

Como parte de los procesos internos de diagnóstico de amenazas y riesgos de seguridad que cualquier área de IT anualmente realiza, se tienen herramientas automatizadas para evaluar aplicaciones y su nivel de vulnerabilidad. Se nos ha solicitado dar permisos de acceso a una cuenta de usuario temporal para realizar una prueba de la superficie de seguridad de SharePoint. Y la pregunta que surge es en donde le daremos permisos a esta cuenta temporal para acceder a evaluar. Uno pensaría que en el Top Level Site Collection en algún grupo de seguridad podríamos asignarle permisos de acceso a dicha cuen

ta, sin embargo, que pasa cuando tenemos gran cantidad de site collections, ¿tendríamos que acceder a dar permisos de acceso en cada una?

Una alternativa aceptable para lograr dar permisos globales y de forma temporal a esta cuenta es la opción de User Policy que existe en las propiedades de un Web Application dentro del Central Administration.

Seleccionamos Manage Web applications y de la lista elegimos la aplicación web donde aplicaremos la política, después damos clic sobre User Policy.

image 

Dentro de User Policy seleccionamos Add User y especificamos sobre qué zona dentro del Web Application estaremos otorgando permisos. En este caso utilizare All Zones, sin embargo podríamos ser lo suficientemente estrictos como para especificar en cuál de las zonas disponibles esta política de acceso tendría efecto.

image

A dar clic en Next capturamos la cuenta de usuario temporal y el nivel de permisos que tendrá sobre la zona previamente especificada. Lo interesante aquí es que para la cuenta en cuestión podemos elegir el nivel de permiso y para no dejar rastro de la cuenta o proceso automatizado de evaluación sobre los cambios o accesos realizados seleccionemos la opción de que la cuente se muestre como System Account.

image

El resultado es el control de los permisos que las cuentas tienen sobre nuestras aplicaciones web de SharePoint. En cualquier momento un administrador puede acceder y remover los permisos.

image

Con esto durante damos una alternativa de solución para el escenario de acceso temporal para pruebas de seguridad realizadas por el área de IT como parte de sus procesos regulatorios internos.

Como hemos aprendido lo que hasta ahora sabemos

Interesante lo que encontré en un viejo manual. Sucede que el proceso de aprendizaje se estimula a través de los 5 sentidos. La mente y los músculos se activan cuando éstos son estimulados por cada uno de nuestros sentidos y no debemos olvidar que los participantes de nuestros cursos no son ajenos a esto, por lo tanto hay que buscar estimularlos de alguna forma. El equipo sensorial de las personas debe ser activado antes que sus mentes comiencen a digerir conceptos, técnicas, métodos, procedimientos que como instructor queremos transmitir.

Tomemos en consideración la siguiente comparación de cómo hemos aprendido lo que hasta ahora sabemos.

 

clip_image002[4]