Guía rápida para configurar Kerberos para los servicios de SharePoint 2010

En muchas ocasiones que se configura Kerberos para los servicios relacionados con SharePoint 2010 es necesario recordar los códigos de los servicios, y algunos otros detalles que pueden pasársenos por alto.  La siguiente guía es precisamente para recordarnos esos detalles:

Para purgar el cache de Kerberos podemos utilizar la línea de comando kplist /purge.

Es Importante conocer la delegación que es necesario hacer en el Directorio Activo.  Hay 3 escenarios a continuación los describo:

Delegación para SQL Server Services

Delegación para Reporting Services

Delegación para servicios que dependen de c2WTS

SharePoint4Fun!,

Juan Manuel Herrera

Cómo programar un script de PowerShell para SharePoint 2010 para que se ejecute periódicamente

El problema:

Necesitamos realizar una tarea de mantenimiento periódicamente en el portal de SharePoint 2010, sin requerir mucho esfuerzo administrativo y que sea automático.

Solución:

Realizar un script que ejecute de lado del servidor en el Front-End de SharePoint 2010 y se ejecute periódicamente asistido por el Task Scheduler de Windows.

Para ello vamos a crear una tarea de Windows que se ejecute periódicamente y para ello necesitamos crear un archivo de lotes con extensión .bat para que el Task Scheduler lo ejecute el contenido de este archivo de lotes debe ser el siguiente:

C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe  c:\Directorio\MiScriptSharePoint2010.ps1

El script debe de validar si tiene el snap-in de SharePoint habilitado para ello escriba dentro del archivo ps1 la siguiente instrucción:

$snapin = Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.SharePoint.Powershell'}
if ($snapin -eq $null)
{
  Write-Host "Loading SharePoint Powershell Snapin"
  Add-PSSnapin "Microsoft.SharePoint.Powershell"
}

El procedimiento para crear una tarea en el Task Scheduler de Windows Server 2008 r2 es muy intuitivo y esta documentado por todas partes por lo que no lo voy a documentar en el artículo.  Aquí uno de estos enlaces: http://allcomputers.us/windows_server/windows-server-2008-r2--task-scheduler.aspx

Recomendación:

Para evidenciar que el script se ejecutó y realizó la operación requerida registre en un archivo log.  Para ello utilice Start-Transcript para iniciar el registro del log y Stop-Transcript para finalizarlo.  Para registrar cada evento utilice Write-Host.

Ejemplo:

Start-Transcript [ruta del archivo log]

Write-Host (“Mensaje”+Variable)

Stop-Transcript

El Script completo puede ver se de la siguiente forma:

Si quiere saber mas del propósito de este Script vea el siguiente artículo: http://jmhogua.blogspot.com/2012/02/script-de-power-shell-de-sharepoint.html .

La tarea en el Task Scheduler puede lucir similar a la siguiente imagen:

En esta ocasión revisamos el procedimiento para programar una tarea que se ejecuta periódicamente y nos apoya en una labor de mantenimiento para el servidor SharePoint 2010.

SharePointJust4Fun!,

Manolo Herrera

Script de Power Shell de SharePoint 2010 para eliminar los elementos de una lista mayor a 60 días de antigüedad

Problema:

Hay una lista que constantemente crece debido a que guarda los usuarios que ha visitado el portal y es necesario depurar esta lista luego de 60 días de caducidad.  La lista actualmente esta en más de 50,000 elementos y debería de mantenerse alrededor de 7,000 elementos como máximo.

Solución:

Utilizar Power Shell para crear un script que realice esta tarea.  El Script consta de 4 Partes que a continuación describo:

1) Cargar en memoria la biblioteca de clases de SharePoint para poder ejecutar el script desde una tarea de Windows.

[void][System.reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

2) Obtener el listado de elementos a eliminar.  Esto lo hacemos por medio del lenguaje de consultas de SharePoint llamado CAML.

$site    =     new-object Microsoft.SharePoint.SPSite("Dirección url de mi colección de sitios")                                                       
$web     =    $site.rootweb                                                                                               
$list    =    $web.Lists["Nombre de la lista"]                                                                             
$DeleteBeforeDate = [Microsoft.SharePoint.Utilities.SPUtility]::CreateISO8601DateTimeFromSystemDateTime([DateTime]::Now.AddDays(-60))
$caml='
   <Where>
      <Lt>
         <FieldRef Name="CampoFechaAComparar" />
         <Value Type="DateTime">{0}</Value>
      </Lt>
   </Where>
' -f $DeleteBeforeDate
$query=new-object Microsoft.SharePoint.SPQuery
$query.Query=$caml

$col=$list.GetItems($query)

3) Copiar los Id’s de los elementos selccionados a un arreglo para evitar el error “Collection was modified; enumeration operation may not execute”

$items = New-Object System.Collections.ArrayList
#Obtiene los elementos a eliminar (No los elimina de una sola vez para evitar el error de elementos perdidos dentro del loop)
$col |  % {
$items.add($_.id)
}

4) Se eliminado los elementos de la lista por su ID.

# Procede a desplegar los elementos a borrar
$contador = 0
Foreach($item in $items)
{
$contador ++
$detalle = "No.: "+$contador+" |Id: "+$item
write-host $detalle
$col.DeleteItemById($item)
}
$mensaje = "total de elementos eliminados: "+$contador
write-host $mensaje
$web.Dispose()
$site.Dispose()  

Abajo todo el código.

Parte de la solución fue extraída del siguiente sitio:

http://blogs.flexnetconsult.co.uk/colinbyrne/2008/02/26/PowerShellSharePointThreeWaysToDeleteAListItemIDCAMLStringMatching.aspx

Mejoras:

En cuando a desempeño el realizar la operación DeleteItemById() demora 10 a 15 segundos en realizarla así que 40,000 elementos demorará aproximadamente 11 horas que no es muy eficiente, pero será solo una vez ya que no se permitirá luego crecer la lista con demasiados elementos para eliminar.

SharePoint4Fun,

Juan Manuel Herrera O.

Sabias que en Project Server puedes mantener versiones de los proyectos

Esta funcionalidad esta disponible desde Project Server 2007, pero es poco conocida sin embargo es muy útil en casos donde necesitamos recuperar el proyecto antes de cambios que no fueron aceptados.

Para la versión 2007 la opción se llama “Schedule Backup”

En la versión 2010 la opción se llama acertadamente “Daily Schedule Backup”  (Algo que le hizo falta aclararlo en la versión 2007).

Ambas opciones despliegan la misma pantalla que permite definir el número de versiones que retendrá de los proyectos.  Es importante distinguir que la información es almacenada en la base de datos de archivo (Usualmente ProjectServer_Archive) y no la de publicación (ProjectServer_Published) la que usualmente se utiliza en el Centro de Proyectos y es mas de naturaleza transaccional.

Tome en cuenta que este número incrementará considerablemente el tamaño de la base de datos ProjectServer_Archive de Project Server.

Para realizar el respaldo “Administrativo” seleccione la opción “Administrative Backup”

Esta opción realizará la copia de respaldo hacia la base de datos ProjectServer_Archive en ese preciso momento cuando presione el botón “Backup”.

Para restaurar una versión anterior diríjase a la opción “Administrative Restore”

Seleccione la versión que desea restaurar (Esto trasladará la información del proyecto de la base de datos ProjectServer_Archive a la base de datos ProjectServer_Draft; donde están los proyectos borradores) y presione el botón Restore.

Nota: Para poder mover los proyectos restaurados de la base de datos de borradores ProjectServer_Draft es necesario ejecutar nuevamente el proceso de publicación.  Un usuario con suficientes permisos puede visualizar este proyecto en borrador desde el MS Project Professional y seleccionar la opción de publicación. Ojo que el que publique el proyecto será el nuevo administrador del mismo.

 

Esta opción nos permitirá depurar los proyectos muy antiguos sin desaparecerlos del todo.  Si deseamos consultarlos podemos utilizar Reporting Services que viene integrado con SharePoint para mostrar la información de estos proyecto que ya no estarán en la base de datos de publicación pero si en la de Archivo.

Hasta la próxima,

Juan Manuel Herrera O.

Desarrollo en SharePoint 2010: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible

 

Escenario:

Una Solución de granja o Farm solution, realizaba una conexión hacia el mismo servidor de SQL Server 2008 R2 donde estaban las bases de datos de SharePoint 2010, pero reportaba el siguiente mensaje:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)    at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject)     at System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject)     at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)     at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)     at System.Da...      8b06f50c-8cdf-49aa-a527-63b636efc09d

Lo extraño de esto es que si se ingresaba al servidor WFE de SharePoint 2010 y se ingresaba a la´solución desde el navegador habilitaba la conexión al servidor de SQL Server 2008 y desplegaba al información  y luego los demás usuarios podían acceder a la solución sin problemas.

La solución:

Aunque al final fue obvia al principio no fue así, fuimos validando y descartando los problemas uno a uno. De la siguiente forma:

1) Se revisó el código línea por línea registrando en el visor de eventos cada paso para validar que si obtuviera la conexión y se determino que al momento de ejecutar el Query reportaba el error de arriba.

2) Se verificó que no estuvieran habilitados los Firewall de Windows Server 2008 r2 en ambos servidores.

3) Se verificó que la cuenta de SQL Server tuviese acceso a la base de datos.

4) No se verificó si los servicios de SQL Server estuviesen levantados ya que eran los mismos que usaba SharePoint y el portal estaba arriba y funcionando correctamente.

5) La conexión hacia la base de datos parecía correcta ya que era la instancia predeterminada es decir el nombre del servidor.  El detalle estaba que este servidor de SQL Server tenía un alias porque no se conectaba por el puerto predeterminado de SQL Server 1433 sino uno personalizado 4050 por ejemplo y esto era todo el problema la conexión debía hacerse a través del alias.

En conclusión algo que debemos de verificar siempre es si la base de datos utiliza un alias y la rezón de porque lo hace ya que esto puede afectar nuestra conexión hacia la misma.

SharePoint4Fun!,

Juan Manuel Herrera O.