Tips info #14 Sharepoint 2013

1-Tabla de Decisión (Farm Solution | Sandboxed Solution | Apps for Sharepoint 2013)

	SharePoint Farm Solution	Sandboxed Solution	Apps for SharePoint
Definición	Son soluciones de full trust. Se utilizan para mejorar o agregar features a Sharepoint.	Sandbox solutions son similares a Farm Solution con capacidades limitadas. Suelen llamarse partial trust solution.	Apps For SharePoint son stand-alone applications que provee información o funcionalidad específica a un site.
Hosting	SharePoint Farm solutions son hosteadas dentro de la granja de SharePoint, son ejecutadas por el worker process (w3wp.exe).	Sandbox solutions son hosteadas dentro de la granja de SharePoint, pero son ejecutadas dentro de un sandbox worker process (SPUCWorkerProcess.exe).	Apps corren fuera del servidor de Sharepoint, el código se ejecutra dentro del contexto del cliente u en otro servidor que NO ejecuta Sharepoint (Ej: web site en Azure)
Deployment	Requieren de un Farm Administrator para deployarlas y la mayoría de las veces requiere realizar un iisreset.	Requieren de un site collection administrator . No afecta a la granja, puede causar problemas inesperados en el site collection donde se deploya.	Las apps son subidas al SharePoint app store o en un catalogo privado de Sharepoint On-premise. Puede ocasionar problemas en los clientes que la utilizan.Ej: error de javascript
Scope	Farm solutions pueden instalarse en cualquier scope: Farm, Web App, Site Collection, Site level.	Sandbox solution están limitadas al Site Collections donde se activan	Apps son instaladas en un SharePoint site/web o en un Tenancy Scope.
Locación de los archivos físicos	El contenido de la farm solution se guarda en la base de configuración de Sharepoint y en el file system en el caso que requiera deployar files (Ej: Application Pages)	Las Sandboxed solutions son almacenadas en la base de contenido donde está el site collection	Pueden residir en múltiples lugares: Externamente: cloud services, IIS externo, etc. En SharePoint: SharePoint components, tales como list templates, modules, workflows, site pages, Web Parts, ycustom content types, son guardados dentro de la base de contenido de SharePoint.
Opciones de código	En Farm Solutions puede ser usado Server side object model, el acceso es irrestricto.	En Sandbox Solutions puede ser usado un restringida API de Server side object model. La solución puede sólo acceder al contenido del site collection donde se deployó.	Podrá utilizar client object model, Silverlight o JavaScript Client Object model code, REST endpoints & Mobile client object model.

2-Ver la versión de build de Sharepoint por URL

Ver la versión de Sharepoint: htt://urlWebApplication/_vti_pvt/services.cnf

Ver la versión de build completa: http://urlWebApplication/_vti_pvt/buildversion.cnf

3-“The item and all items under it will not be crawled because the owner has set the NoCrawl flag to prevent it from being searchable”

Cuando realizo una búsqueda de un usuario en un Search Center, no obtengo resultados de su MySite. Al revisar el log verás el siguiente mensaje, donde indica que no se pudo indexar porque tiene el flag NoCrawl.

Para solucionarlo, ingresa a Site Settings, y ingresa a la sección “Search and offline availability”

Marca la opción “Yes”. La próxima vez que se realice un crawl aparece el sitio MySites del usuario.

 

4-Claims Authentication: propiedades LogonTokenCacheExpirationWindow y WindowsTokenLifetime

En Sharepoint 2013, la autenticación mediante claims es la default, a diferencia de 2010.

Cada item de seguridad (Ej: un Grupo de AD) son convertidos a claims y se empaquetan dentro de un token de seguridad (gracias al servicio STS – Security Token Service).

El tiempo de vida de este token de seguridad está definido en la propiedad WindowsTokenLifetime del SecurityTokenServiceConfig (el valor default es de 10 horas).

La propiedad LogonTokenCacheExpirationWindow (10 minutos por default) del SecurityTokenServiceConfig controla cuando Sharepoint considerará que el token de seguridad ha expirado y le preguntará al usuario que re-autentifique de nuevo para obtener un nuevo token. Sharepoint chequea si el token está expirado cada vez que se inicia un nuevo request.

Ej, si el WindowsTokenLifetime = 10 minutos y LogonTokenCacheExpirationWindow = 2 minutos

Esto significa que después de 11 minutos de haberme autenticado en el sitio, Sharepoint preguntará las credencias al usuario (lo realiza de forma automática el navegador mediante una negociación).Un error que suele presentarse es “The context has expired and can no longer be used”

Mi recomendación de las propiedades es la siguiente:

$sts = Get-SPSecurityTokenServiceConfig
$sts.FormsTokenLifetime = (New-TimeSpan -minutes 10)
$sts.WindowsTokenLifetime = (New-TimeSpan -minutes 10)
$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 2)
$sts.Update()
iisreset

Errores comunes que se presentan:

• No se ve reflejado cambios de seguridad en el sitio, Ej: agrego un usuario a un grupo de Sharepoint y el usuario no puede ingresar . Access denied.
• No se ve reflejado cambios de seguridad que se realizaron en el AD (AD security groups)

Importante: asegurate que LogonTokenCacheExpirationWindow sea menor que WindowsTokenLifeTime, en caso contrario tendrás problema de performance.

Para mayor información: http://blogs.technet.com/b/speschka/archive/2010/08/09/setting-the-login-token-expiration-correctly-for-sharepoint-2010-saml-claims-users.aspx

5-Ver los field de una lista o libreria mediante REST

Se puede usar REST para obtener información de los campos (fields), sólo se deberá agregar lo siguiente a la url del site: _api/web/lists/GetByTitle(NombreLibreria)/Fields

Ej:

https://urlSharepoint/sites/contoso/News/_api/web/lists/GetByTitle('Documents')/Fields

Si lo abres con IE, haz click derecho sobre la página, y elige ViewSources.

Ej: Scheduling Start Date

Links útiles #43 - Sharepoint 2013

1-Fill Factor para Sharepoint 2013

En la versión de Sharepoint 2010 el fill factor recomendado para los indices era de 80%, en cambio en 2013 ese valor cambio. Este valor indica cuanto puede llenar SQL Server las páginas cuando crea un nuevo índice.

http://sharepoint.nauplius.net/2013/04/the-fill-factor-mystery/

2-Social tags en Sharepoint 2013

El artículo nos explica el uso de tags en sharepoint 2013

http://www.chrisweldon.net/blog/2012/12/18/sharepoint-2013-tagging-social-tags/

3-Agregar un proveedor de búsqueda en Internet explorer para que apunte a un Sharepoint Center

http://www.ntsystems.it/post/SharePoint-2013-Search-Center-Windows-8.aspx

http://msdn.microsoft.com/en-us/library/dd742958(v=VS.85).aspx

http://sprider.org/2013/04/10/advertise-sharepoint-search-provider-in-internet-explorer/

http://consultingblogs.emc.com/pawangulati/archive/2011/01/10/adding-sharepoint-as-ie-search-provider.aspx

http://lassewikmark.wordpress.com/2010/10/13/integrating-sharepoint-search-with-the-desktop/

4-Shared Workbooks usando Excel Services en Sharepoint 2013

Excel Services permite compartir contenido de Excel  compartiendo un excel completo o secciones del mismo.

http://technet.microsoft.com/en-us/library/dn198294.aspx

http://www.youtube.com/watch?v=3cwRLDJuM5U

5-Excluir contenido del Spell Check de Sharepoint

http://blog.cube4.com.au/?p=1016

Migrar Managed Metadata entre ambientes (Migrate Managed Metadata to diferrent enviroments) Sharepoint 2013

Antes de iniciar el proceso de migrado, repasaremos algunos conceptos.

La administración de los managed metadata se realiza con Term Store Management Tool, la cual es accesible desde el central Administration o desde el Site Collection.

Un término (Term) es una palabra o frase que puede asociarse a un elemento de SharePoint Server 2013. Un conjunto de términos (Term Set) es una colección de términos relacionados. Se puede especificar que una columna contenga un término de un determinado conjunto de términos. Los metadatos administrados (Managed Metadata) son un modo de indicar que los términos y los conjuntos de términos se pueden crear y administrar independientemente de las propias columnas.

Los conjuntos de términos locales (Local Term Sets) se crean en el contexto de una colección de sitios. Por ejemplo, si se agrega una columna a una lista en una biblioteca de documentos y se crea un nuevo conjunto de términos para enlazar la columna, el nuevo conjunto de términos es local para la colección de sitios que contiene la biblioteca de documentos.

Los conjuntos de términos globales (Global Term Set) se crean fuera del contexto de una colección de sitios. Por ejemplo, el administrador del almacén de términos puede crear un grupo de conjunto de términos denominado "Recursos humanos" y designar a una persona para que lo administre. El administrador del grupo podría crear conjuntos de términos relacionados con recursos humanos, como cargos y categorías salariales en el grupo de conjunto de términos Recursos humanos.

Los usuarios pueden ver solo los conjuntos de términos globales y los conjuntos de términos locales de la colección de sitios del usuario.

Groups

Los grupos representan límites en el governance de la taxonomía. Múltiples grupos pueden ser creados dentro de un Managed Metadata Service, cada grupo puede tener múltiples Terms Sets.

 

Term Sets

Uno o más Term Sets (hasta 1,000) son definidos dentro de un Group. Term Sets pueden ser creados manualmente o importados a través de la interface . Ej: Company

 

Terms

Palabras individuales o frases son agregadas a un Term Set. Un máximo de 30,000 términos pueden ser agregados a un simple Term Set.

A continuación explicaré los pasos para migrar la metadata de un ambiente (DEV) a otro (PRD).

El servicio de Managed Metadata se llama “Managed Metadata Service”

Cuando se migra un site (site collection) de un ambiente a otro, la managed metadata no es migrada, requiere realizar algunos pasos para que quede consistente la migración.

Hay dos posibilidades para migrar un site collection entre ambientes Export (http://technet.microsoft.com/en-us/library/ee428301.aspx) o Backup (http://technet.microsoft.com/en-us/library/ee748617.aspx).

La operación mediante el Export/Import genera un nuevo GUID para cada objeto en el ambiente de PRD, en cambio Backup/Restore preserva los GUID.

La metadata puede ser exportada (en DEV) mediante powershell o vía UI, pero cuando se importa en el nuevo ambiente (PRD) Sharepoint genera nuevos GUID´s para los términos importados, y por lo cual queda inconsistente el ambiente (las columnas de metadata apuntan a un GUID que no existe).

Para mantener la consistencia haremos uso de dos comandos: Export-SPMetadataWebServicePartitionData, Import-SPMetadataWebServicePartitionData

1- Crear un Shared en el servidor de SQL Server de Sharepoint (eso se debe a que Sharepoint trata de importar los archivos .bak al servidor de SQL Server para poder importar los Term Set). A continuación exportar la partición de metadata. Ejecutar este script en el servidor del ambiente de DEV

Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue 
$proxyName = "Managed Metadata Service Proxy"
$serviceName = "Managed Metadata Service"
$filePath = "\\NombreServerSQLServer\TermStore\terms.bak"
$svc = Get-SPServiceApplication | ?{$_.TypeName -eq "Managed Metadata Service" -and $_.DisplayName -eq $serviceName}
Export-SPMetadataWebServicePartitionData $svc.Id -ServiceProxy $proxyName -Path $filePath

2- Importar el archivo .bak en el servidor de PRD. Ejecuta este script en el servidor de PRD. Supongo que tienen el mismo nombre el servicio de Managed Metadata.

Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue 
$proxyName = "Managed Metadata Service Proxy"
$serviceName = "Managed Metadata Service"
$filePath = "\\NombreServerSQLServer\TermStore\terms.bak"
$svc = Get-SPServiceApplication | ?{$_.TypeName -eq "Managed Metadata Service" -and $_.DisplayName -eq $serviceName}
Import-SPMetadataWebServicePartitionData $svc.Id -ServiceProxy $proxyName -Path $filePath -OverwriteExisting

En el caso que se haya utilizado Backup/Restore debería haber quedado correctamente configurado la managed metadata, ya que se mantuvo el GUID del sitio, y los GUID de la metadata.

En el caso que se haya utilizado Export/Import, tendrás que realizar un par de pasos más para que los ambientes queden consistentes.

Supongo que el sitio en DEV se llamaba http://DEVserver/sites/sitecollection, y en PRD se llama http://PRDserver/sites/sitecollection.

Para verificar que se hay importado correctamente la partición de metadata, con sus grupos asociados puedo usar el siguiente comando.

Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue 
$siteURL = "http://prdserver/sites/sitecollection"
$mmsServiceName = "Managed Metadata Service Proxy"
$taxonomySite = Get-SPSite $siteURL
$taxSession = Get-SPTaxonomySession -site $taxonomySite
$termStore = $taxSession.TermStores[$mmsServiceName]
$AllGroups = $taxSession.DefaultSiteCollectionTermStore.Groups
$AllGroups
$siteTermGroup = $taxSession.DefaultSiteCollectionTermStore.Groups | where-object {$_.Id -eq 'd0e7f5c9-3713-4fc5-9245-04b55a452147'}
$siteTermGroup

Este comando nos retornará una lista de Grupos que se habían creado en DEV y los que se crearon en PRD (tanto local terms set como global terms set).

Ej:

Lo que tenés que hacer a continuación es buscar el grupo que importaste de DEV, y revisar la propiedad SiteCollectionAccessIds, la misma indica los sites collection que tienen acceso al grupo.

Defino lo siguiente:

IDSiteCollectionErroneo: supongo que el ID que está en la propiedad no es el ID del site Collection de PRD: http://PRDserver/sites/sitecollection

IDGrupo: es el ID del grupo. En la imagen anterior es “af334650-….”

$NombreGrupo: es el nombre del grupo. IMPORTANTE: si no lo definis correctamente, ej: Collección de sitios – PRDserver-sites-sitecollection no lo verás como local term set. Suele definirse de la siguiente manera (en castellano, en inglés varía): webapplicationURL-managedpath-sitecollection. Mi recomendación es que crees un local term set temporal (mediante una nueva columna de metadata), ejecute de nuevo el script donde retorna los grupos de la partición, y registres el nombre del grupo. A continuación borra el local term group (tendrás conflictos sino con la propiedad IsSiteCollectionGroup).

A continuación ejecuto el siguiente script con los datos previamente definidos, el cual mapea el grupo con el site collection mediante la propiedad AddSiteCollectionAccess

Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue 
$siteURL = "http://PRDserver/sites/sitecollection"
$mmsServiceName = "Managed Metadata Service Proxy"
$taxonomySite = Get-SPSite $siteURL
$taxSession = Get-SPTaxonomySession -site $taxonomySite
$termStore = $taxSession.TermStores[$mmsServiceName]
$AllGroups = $taxSession.DefaultSiteCollectionTermStore.Groups
$AllGroups
$IDGrupo = 'es el ID del grupo que quiero attachar al site collectio de PRD como local term set'
$siteTermGroup = $taxSession.DefaultSiteCollectionTermStore.Groups | where-object {$_.Id -eq $IDGrupo}
$siteTermGroup
$siteTermGroup.AddSiteCollectionAccess($taxonomySite.Id)
$NombreGrupo = 'nombre del grupo DEFINIDO POR REGLAS DE SHAREPOINT, VER la sección de suposiciones';
$siteTermGroup.Name = $NombreGrupo
$IDSiteCollectionErroneo = 'ID erroneo que aparece en la propiedad SiteCollectionAccessIds'
$siteTermGroup.DeleteSiteCollectionAccess([System.Guid]($IDSiteCollectionErroneo))
$termStore.CommitAll();

Recuerda reemplazar las variables $IDGrupo, $NombreGrupo, $SiteURL

Una vez ejecutado este script ya podrás ver el Local term set que tenías en DEV, ahora en PRD, sin haber perdidos los GUID´s de los term set, y con una ambiente consistente.