PowerShell

[SharePoint Online] – Modifier la Timezone sur une collection de sites

Posted on Updated on

Bonjour à tous,

Aujourd’hui un script utile pour modifier la Timezone (fuseau horaire) sur l’ensemble des sites d’une collection sur SharePoint Online (Office 365). J’ai eu ce besoin suite à une migration d’un tenant O365 vers un autre tenant O365 hébergé sur une autre plaque (Europe vers Etats-Unis).

J’ai décidé ici d’utiliser le CSOM de SharePoint Online mais c’est tout à fait réalisable avec du Powershell ou en utilisant le Pattern & Practice (https://dev.office.com/patterns-and-practices).

Voici le script que j’ai utilisé (qui est sans doute perfectible et optimisable !).

Tout d’abord, il vous faudra installer les binaires Microsoft.SharePoint.Client.dll et Microsoft.SharePoint.Client.Runtime.dll via le setup : https://www.microsoft.com/en-US/download/details.aspx?id=35588 (à télécharger & installer donc). Ces dlls seront installées par défaut dans C:\Program Files\SharePoint Online Management Shell\Microsoft.Online.SharePoint.PowerShell\.

Une fois ceci fait, vous pourrez les référencer dans votre script de cette manière :


add-type -Path 'C:\Program Files\SharePoint Online Management Shell\Microsoft.Online.SharePoint.PowerShell\Microsoft.SharePoint.Client.dll'
add-type -Path 'C:\Program Files\SharePoint Online Management Shell\Microsoft.Online.SharePoint.PowerShell\Microsoft.SharePoint.Client.Runtime.dll'

Ensuite, j’initialise la connexion vers la collection de site que je souhaite mettre à jour (remplacer par vos valeurs ce qui est entre [ ]) :

$SiteCollectionUrl = "https://[MONTENANT].sharepoint.com/sites/[MACOLLECTIONDESITES]"
$username = "[LOGIN]@[DOMAIN].com"
$password = "[PASSWORD]"

Puis ensuite, on initialise le contexte :

function GetClientContext($SiteCollectionUrl, $username, $password) {
    $securePassword = ConvertTo-SecureString $password -AsPlainText -Force
    $context = New-Object Microsoft.SharePoint.Client.ClientContext($SiteCollectionUrl)
    $credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($username, $securePassword)
    $context.Credentials = $credentials
    return $context
}

 

Et enfin la fonction qui permet de mettre la Timezone à jour. Pour ma part, je la positionne sur la Timezone “(UTC) Dublin, Edinburgh, Lisbon, London”. Une petite recherche sur le net pour trouver votre zone… (http://blog.jussipalo.com/2013/10/list-of-sharepoint-timezoneid-values.html).

Cette fonction est récursive et permet d’itérer sur l’ensemble des sites de la collection :

function ProcessSites($subsiteurl){
    $clientContext = GetClientContext $subsiteurl $username $password
    $rootWeb = $clientContext.Web
    $childWebs = $rootWeb.Webs
    $clientContext.Load($rootWeb)
    $clientContext.Load($childWebs)
    $clientContext.ExecuteQuery()
 
    write-host $rootWeb.url -ForegroundColor Yellow
    $TimeZones = $rootWeb.RegionalSettings.TimeZones
    $clientContext.Load($TimeZones)
    $clientContext.ExecuteQuery()

    $RegionalSettings = $rootWeb.RegionalSettings
    $clientContext.Load($RegionalSettings)
    $clientContext.ExecuteQuery()
    $TimeZone = $TimeZones| Where {$_.Description -eq "(UTC) Dublin, Edinburgh, Lisbon, London"}

    $TimeZone | Select ID,Description
    Write-Host "TimeZone " $TimeZone.Description -ForegroundColor Yellow
    $RegionalSettings.TimeZone = $TimeZone
    $RegionalSettings.Update()

    $rootWeb.Update()
    $clientContext.ExecuteQuery()
    foreach ($childWeb in $childWebs)
    {
        write-host $childWeb.url -ForegroundColor Yellow
        $clientContext.Load($childWeb)
        $clientContext.ExecuteQuery()

        $TimeZones = $childWeb.RegionalSettings.TimeZones
        $clientContext.Load($TimeZones)
        $clientContext.ExecuteQuery()

        $RegionalSettings = $childWeb.RegionalSettings
        $clientContext.Load($RegionalSettings)
        $clientContext.ExecuteQuery()
        $TimeZone = $TimeZones | Where {$_.Description -eq "(UTC) Dublin, Edinburgh, Lisbon, London"}

        $TimeZone | Select ID,Description
        Write-Host "TimeZone " $TimeZone.Description -ForegroundColor Yellow
        $RegionalSettings.TimeZone = $TimeZone 
        $RegionalSettings.Update()

        $childWeb.Update()
        $clientContext.ExecuteQuery()

        Write-Host "Done :" $childWeb.Title "-" $TimeZone.ID

        ProcessSites $childWeb.url
    }
}


ProcessSites $SiteCollectionUrl

Il ne reste qu’à lancer dans Powershell ou Powershell ISE.

[SPOnline] – Verrouiller un site en lecture seule

Posted on

Bonjour à tous,

Aujourd’hui une astuce toujours utile et en particulier pour lors des migrations de sites ou les fermetures pour maintenance.

Sur SharePoint OnPremise, il est facile de jouer avec le “Lockstate” qui l’on passe en readonly via quelques lignes de PowerShell… Mais sur SharePoint Online, ce statut n’existe pas ! Vous avez juste la possibilité de le passer à “NoAccess” (aucun accès pour personne, sauf les administrateurs de la collection de sites) ou “Unlock” qui déverrouille donc…

L’astuce consiste à utiliser une politique de site (Site Policy) qu’il faut créer à la racine de la collection de sites. Pour cela, il faut se rendre dans les paramètres du site (racine de la collection de sites) :

01

Puis accéder au menu “Site Policies” :

02

Et enfin créer une nouvelle Policy :

03

On lui donne un nom, description et surtout :

  • Ne pas fermer le site automatique et ne pas le supprimer !
  • Cocher la case : le site sera en readonly quand il sera fermé

On enregistre ensuite :

04

On revient dans les paramètre du site :

05 06

Et cette fois-ci on va dans le menu “Site Closure and Deletion” :

07

On choisit dans la liste déroulante notre nouvelle policy et on valide la page :

08

On revient de nouveau dans le même menu :

09

Et cette fois-ci on clique sur le bouton “Fermer le site maintenant” (Close this site now) :

10

Immédiatement, un bandeau rouge apparaît en haut de la page nous informant que le site est bien en ReadOnly :

11

 

En espérant que cela vous soit utile !

 

[SharePoint] – Script PowerShell pour afficher les tailles des bases de données

Posted on Updated on

Bonjour à tous,

Aujourd’hui un petit script bien utile qui vous permettra d’afficher la taille des bases de données d’une ferme SharePoint OnPremise.

Cela permettra à l’administrateur de ferme principalement de suivre l’évolution du stockage dans la ferme SharePoint, afin d’affiner ses quotas, optimiser son serveur / cluster SQL Server.

Le but est donc de créer un petit script qui parcourra les Web Applications, puis les bases de données qui leur sont associées (on ne sélectionne donc pas les bases de données des Applications de Service) et d’afficher le tout dans une GridView par exemple.

Dans cette démo, j’utiliserai l’environnement PowerShell ISE (Integrated Scripting Environment), avec Windows Server 2012 et une plateforme SharePoint Server 2013 Enterprise (Pré-SP1).

Première étape, lancer PowerShell ISE avec le compte Administrateur de la ferme SharePoint :

02

Et entrer le script tout fait 🙂

Ok, je vais détailler un peu son contenu :

Première étape, afin que l’on puisse lancer le script avec PowerShell, sans utiliser le SharePoint Management Shell, on ajoute l’import des Cmdlets SharePoint :

If ((Get-PSSnapIn -Name Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue) -eq $null ) 
{ Add-PSSnapIn -Name Microsoft.SharePoint.PowerShell }

$host.Runspace.ThreadOptions = "ReuseThread"

Puis on démarre un scope pour les objets utilisés dans le script afin qu’ils soient automatiquement “Disposés” à la fin de l’exécution. Pour cela, nous allons utiliser les commandes (au début et à la fin du script) :

Start-SPAssignment –Global
Stop-SPAssignment –Global

Plus de détails ici : http://technet.microsoft.com/fr-fr/library/ff607664(v=office.15).aspx

On commence ensuite la construction dun tableau (Hashtable plus particulièrement) en parcourant les WebApplications, les bases de contenu et en calculant leur taille en GB :

$webApps = Get-SPWebApplication -IncludeCentralAdministration
foreach($WebApp in $spWebApps)
{
    $ContentDBs = $webApp.ContentDatabases
    foreach($ContentDB in $ContentDBs)
    {    
        $size = [Math]::Round(($ContentDB.disksizerequired/1GB),2)

        $DBdetails = New-Object PSObject
        $DBdetails | Add-Member -Name "Web Application Name" -MemberType NoteProperty -Value $WebApp.DisplayName
        $DBdetails | Add-Member -Name "Database Name" -MemberType NoteProperty -Value $ContentDB.Name
        $DBdetails | Add-Member -Name "Database Size (in Gb)" -MemberType NoteProperty -Value $size         $data += $DBdetails
    }
}

Puis pour terminer, on affiche le tout dans une GridView :

$DB = $data | Out-GridView -Title "SharePoint Databases Size" –PassThru

Il nous faut ajouter un try/catch pour gérer les exceptions… ce qui donne au final :

03

Puis on lance l’exécution du script (sauvegardé dans un fichier PS1) ou avec le bouton “Play” de PowerShell ISE :

05

Et voilà !

[SP2010 – SP2013] – Modifier la période de rétention des corbeilles

Posted on Updated on

 

Bonjour à tous,

Un petit article aujourd’hui pour apprendre à modifier la période de rétention de la corbeille utilisateur, sur une Web Application spécifique.

Petit rappel au passage, 2 niveaux de corbeilles sont proposés dans SharePoint (Server ou Foundation), et ce depuis…. presque toujours !

Ces deux niveaux de corbeilles ont des particularités :

Le premier niveau est aussi appelée “corbeille utilisateur” et est donc personnelle à chaque utilisateur. Pour faire le parallèle cela correspond à la corbeille “Windows” de l’utilisateur. Les documents supprimés par un utilisateur dans SharePoint sont déplacés dans cette corbeille où ils resteront pour une durée définie. Par défaut, SharePoint limite cette période à 30 jours et les documents supprimés y sont donc conservés durant cette période. C’est ce paramètre que nous allons apprendre à modifier.

Le second niveau de corbeille est aussi appelé “Corbeille de l’administrateur”. Les documents ayant atteint la période de rétention du premier niveau de corbeille sont déplacés dans cette corbeille (et non pas supprimés définitivement). Ils y sont conservés… non pas dans le temps mais par rapport au quota fixé sur la collection de sites. Par défaut, le ratio est fixé à 50%. Par exemple, si le quota de la collection de sites est fixé à 1Go, l’administrateur pourra conserver 500Mo de documents supprimés. Ensuite les plus anciens documents sont collectés puis supprimés.

 

Nous allons donc voir comment modifier la période de conservation du niveau 1 de la corbeille. Pratique pour automatiser le paramétrage de vos Web Applications par exemple. Oui, parce que ce paramètre est bien disponible sur la Web Application.

Première chose à faire, charger les Cmdlets pour SharePoint. :

If ((Get-PSSnapIn -Name Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue) -eq $null )
{ Add-PSSnapIn -Name Microsoft.SharePoint.PowerShell }
$host.Runspace.ThreadOptions = “ReuseThread”

 

Puis fixer les quelques paramètres nécessaires : Url de la Web Application et rétention souhaitée :

$webAppUrl = “http://URL DE VOTRE WEB APPLICATION”
$ConservationInDays = 90

 

Puis on récupère et on affiche la rétention actuellement appliquée sur la Web Application :

$Webapp = Get-SPWebApplication -Identity $webAppUrl $days = $Webapp.RecycleBinRetentionPeriod

Write-Host(“Conservation actuelle ” + $days + ” jours”) -ForegroundColor Yellow

 

Et enfin modifier la période de rétention si elle est différente de celle fixée :

if($days -ne $ConservationInDays)

{

$Webapp.RecycleBinRetentionPeriod = $ConservationInDays $Webapp.Update()

Write-Host(“La période de conservation a été fixée à ” + $ConservationInDays + ” jours”) -ForegroundColor Green

}

Ce qui donne :

01

02

 

Et pour changer le quota appliqué à la corbeille de niveau 2 (pour le fixer à 30% par exemple) :

$Webapp.SecondStageRecycleBinQuota = 30

$Webapp.Update()

03

 

Et voilà !

[SP2010 & SP2013] – Envoyer les résultats de l’analyseur de santé et d’intégrité par e-mail

Posted on Updated on

 

Bonjour à tous.

Cela fait quelques temps que je n’avais rien publié, je reviens avec un script bien pratique permettant d’envoyer les résultats produits par l’analyseur de santé et d’intégrité de SharePoint (SharePoint Health Analyzer) par e-mail, à l’administrateur par exemple.

Le but étant de ne plus avoir à se connecter à l’administration centrale de SharePoint pour consulter et monitorer l’état de la plateforme, mais d’automatiser cela par un envoi de courrier électronique.

Pour cela, nous allons écrire un script permettant de récupérer le contenu des résultats, récupérer les paramètres d’envoi de courrier électronique et enfin automatiser le tout via une tâche planifiée. Et bien sûr compatible avec SharePoint 2010 et SharePoint 2013 !

1/ Récupérer les paramètres d’envoi d’e-mail

NB : le script doit être exécuté avec un compte possédant les droits nécessaires pour effectuer les opérations. Dans mon cas c’est l’administrateur de ferme SharePoint.

Pour cela, c’est très simple. Nous allons écrire un script PowerShell permettant de récupérer l’instance du site d’administration centrale de SharePoint puis récupérer les paramètres de courrier sortant (Outgoing e-mail parameters).

Pour récupérer la Web Application de l’administration centrale, soit on connait l’URL soit on ne la connait pas.

Dans le cas où on la connait (il faudra la modifier lorsque l’on changera de ferme… et si elle change d’url / serveur) :

$w = Get-SPWebApplication http://sitename

Si on ne la connait pas, et si on veut faire un script portable (mon cas) :

$CAWebApp = (Get-SPWebApplication -IncludeCentralAdministration) | ? { $_.IsAdministrationWebApplication -eq $true }

$CARootWeb = Get-SPWeb -Identity $CAWebApp.Url

Ce qui donne :

01

On récupère bien l’adresse du site Web (racine) de la Web Application contenant la centrale d’administration de notre ferme SharePoint.

Ensuite, nous allons récupérer les paramètres :

  • L’adresse de provenance (From)
  • L’adresse (le nom) du serveur d’envoi d’e-mails (renseigné dans la console d’administration centrale de SharePoint).
$from = $CAWebApp.OutboundMailReplyToAddress

$mailserver = $CAWebApp.OutboundMailServiceInstance.Server.Address

Et également fournir l’adresse où l’on souhaite envoyer le courrier électronique :

$to = "admin.sharepoint@demo.local"

02

2/ Récupérer le contenu du SharePoint Health Analyzer

Le SharePoint Health Analyzer enregistre ses résultats dans une liste SharePoint dont l’adresse est statique (toujours la même), dans le site racine de l’administration centrale SharePoint.

Il suffit donc de se connecter à cette liste, d’en récupérer le contenu pour le formater dans le corps du courrier électronique.

Récupérons l’instance de la liste de résultats :

$list = $CARootWeb.GetList("\Lists\HealthReports")

03

Il nous reste ensuite à récupérer le contenu de cette liste et le formater dans un contenu HTML qui deviendra le corps de l’e-mail. Pour récupérer le contenu, rien ne vaut une petite requête CAML !

Ici nous voulons récupérer seulement les cas qui ne sont pas en réussite (succès), c’est-à-dire les problèmes. Il faut donc filtrer sur un champ qui s’appelle “HealthReportSeverity” (internalName, en anglais dans mon ca), en ne récupérant que les items où la valeur est différente de “4 – Success” :

$where = "<Where><Neq><FieldRef Name='HealthReportSeverity' /><Value Type='Text'>4 - Success</Value></Neq></Where>"
$query = New-Object Microsoft.SharePoint.SPQuery
$query.Query = $where
$items = $list.GetItems($query)

Dans mon cas, je récupère 3 items ($items.Count) :

04

3/ Construire le contenu du courrier électronique

Le contenu étant récupéré, il nous faut construire le corps du message en HTML (très basique !). Pour ma part, je suis parti sur quelque chose de simple: un tableau.

Ce tableau contiendra :

  • Le nom de l’erreur avec un lien pointant vers le détail (vers la page DispForm.aspx de SharePoint)
  • Le Type (catégorie) d’erreur
  • Le contenu du message
  • Le type d’erreur : avertissement, erreur, etc.
  • La date d’exécution (de la tâche planifiée SharePoint)

Nous allons également ajouter un peu de texte avant et après le tableau pour préciser :

  • La date et l’heure courante
  • Le nom du rapport
  • Une signature

On construit l’entête et la signature :

NB : Attention à l’encodage des simples et double quotes !!! => Passer par NotePad / Notepad++, ça vous aidera 🙂

$entete = "Bonjour, voici le rapport d’exécution de l’analyseur de santé et d’intégrité de la ferme SharePoint : " + $CAWebApp.Farm.Name

$titre = "<Title>" + $entete + "</Title>"

$signature = "Bonne journée, <br/><br/>L’équipe SharePoint."

05

Puis nous allons construire le tableau en itérant sur la collection d’Items chargée via la requête CAML :

$corps = "<h2>" + $entete + "</h2><br />"

$corps = $corps + "<table cellspacing='5' cellpadding='5' style='width: 100%;border:1px solid #bbbbbb'>" 
foreach ($item in $items)
{
$itemTitle = $item.Title
$itemUrl = $CARootWeb.Url + ($list.Forms | where { $_.Type -eq "PAGE_DISPLAYFORM" }).ServerRelativeUrl + "?ID=" + $item.ID

$itemSeverity = $item["Severity"]
$itemCategory = $item["Category"]
$itemExplanation = $item["Explanation"]
$itemModified = $item["Modified"]

$corps = $corps + "<tr>"
$corps = $corps + "<td><a href=`"" + $itemUrl + "`">" + $item.Title + "</a></td>"
$corps = $corps + "<td>" + $itemCategory + "</td>"
$corps = $corps + "<td>" + $itemExplanation + "</td>"
$corps = $corps + "<td>" + $itemSeverity + "</td>"
$corps = $corps + "<td>" + $itemModified + "</td>"
$corps = $corps + "</tr>"
}

$corps = $corps + "</table><br /><br />" + $signature

$corpshtml = ConvertTo-Html –Head $titre –Body $corps

06

07

4/ Envoyer un e-mail en PowerShell

Ensuite il nous faut envoyer cet e-mail via des cmdlets PowerShell. Pour cela, nous allons recourir à l’API System.Net.Mail bien connue dans le monde Microsoft :

$CARootWeb.Dispose()
Send-MailMessage –From $from –To $to –Subject $titre –BodyAsHtml $corps –SmtpServer $mailserver

Puis fermer la connexion sur la Web Application :

$CARootWeb.Dispose()

Attention, dans cet exemple j’ai configuré le service SMTP sur mon serveur SharePoint, et en renseignant correctement les paramètres d’e-mails sortants dans la console d’administration centrale de SharePoint.

5/ Automatiser l’envoi par une tâche planifiée Windows

Dernière étape, l’automatisation. Pour cela nous allons créer une tâche planifiée Windows, exécutée sur l’un des serveurs SharePoint de la ferme. Dans mon cas ce sera sur le serveur hébergeant l’Administration Centrale de SharePoint.

Cette tâche planifiée devra lancer PowerShell, puis appeler le script. Il nous faut donc modifier à nouveau ce script pour intégrer l’appel du Snap-In permettant de charger le contexte SharePoint dans PowerShell (ce que fait le Management Shell de SharePoint, automatiquement).

Je vous invite à vous reporter à http://technet.microsoft.com/fr-fr/library/ee806878(v=office.15).aspx.

Nous allons alors ajouter en haut du fichier du script PowerShell :

if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" –ErrorAction SilentlyContinue) -eq $null)
{
Add-PSSnapin "Microsoft.SharePoint.PowerShell"
}

Et enregistrer le tout dans un fichier avec l’extension ps1. Pour moi SPHealthAnalyzerSendMail.ps1, que je tente d’exécuter avec PowerShell (et non pas le Management Shell de SharePoint :

14

 

Voici le fichier obtenu, vous pouvez le télécharger ici : http://1drv.ms/1ot9VJI

Créons donc cette tâche planifiée ! Pour cela, il faut ouvrir l’assistant de création des tâches panifiées de Windows Server :

Dans Démarrer > Outil d’administration > Tâches planifiées :

image

image

 

Cliquer sur “créer une tâche” dans le panneau Actions à droite et donnez-lui un nom, description, et surtout le compte exécutant la tâche (l’administrateur de la ferme dans mon cas) :

image

 

Aller dans l’onglet Triggers (déclencheur) et fournir une planification (schedule), dans mon cas chaque jour à 2h00 du matin :

image

 

Puis aller dans l’onglet Actions et entrer les paramètres :

  • Commande : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  • Arguments : –command “.\\SPHealthAnalyzerSendMail.ps1”
  • Répertoire de démarrage : Répertoire où est enregistré votre fichier sur le serveur, dans mon cas dans le répertoire 14 == C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14

image

 

Enregistrer le tout, l’assistant vous demande le mot de passe du compte utilisé pour lancer la tâche :

image

 

La tâche est créée :

image

 

Faites un clic droit, Démarrer pour tester :

image

 

Les résultats de l’exécution sont présentés dans la fenêtre en bas :

image

 

Voici l’e-mail reçu… C’est simple et épuré dira-t’on. Si vous rencontrez des problèmes d’encodage pour les caractères accentués par exemple, n’hésitez pas à jouer avec la fonction :

[System.Web.HttpUtility]::HtmlEncode(“MON TEXTE A ENCODER”)

15

 

Il n’y a plus qu’à revoir un peu le Html envoyé dans l’e-mail pour peaufiner, et c’est tout bon !

[SharePoint 2013] – Indexation anormalement longue

Posted on Updated on

 

Bonjour à tous.

Aujourd’hui un article / KB concernant le moteur de recherche de SharePoint Server 2013.

Suite à la mise en place de ce moteur de recherche, j’ai pu constater un problème… que je n’avais jamais eu jusque ici !

Concernant le contexte, il s’agit de l’installation de SharePoint Server 2013 Standard en Français, sur Windows Server 2008R2 en Français également et couplé au moteur SQL Server 2008R2 SP1 en Français, installé sur un second seveur.

 

1/ Le problème

 

Lors du déploiement de l’application de service de recherche, j’ai utilisé l’assistant depuis la page de gestion des applications de service dans l’administration centrale de SharePoint.

J’ai nommé mon service “Application de recherche”, utilisé un pool dédié aux applications de service. Lors de la création, aucun problème constaté, le service est bien créé/configuré, les bases de données sont également ok.

Le problème est survenu lors de l’indexation d’une source de données SharePoint (Site SharePoint locaux par défaut) sur un site vide… La première indexation a duré plus de 25 heures !!!!

Evidemment ce n’est pas normal ! Après investigations, sur l’observateur d’évènements, les logs, etc. et activation du mode ‘Verbose” des logs, il s’est avéré que cette erreur se reproduisait constamment lors de l’indexation des données :

 

System.ArgumentException: La longueur de la valeur de la clé ‘application name’ dépasse sa limite fixée à ‘128’.

à System.Data.SqlClient.SqlConnectionString..ctor(String connectionString)     à System.Data.SqlClient.SqlConnectionFactory.CreateConnectionOptions(String connectionString, DbConnectionOptions previous)     à System.Data.ProviderBase.DbConnectionFactory.GetConnectionPoolGroup(DbConnectionPoolKey key, DbConnectionPoolGroupOptions poolOptions, DbConnectionOptions& userConnectionOptions)     à System.Data.SqlClient.SqlConnection.ConnectionString_Set(DbConnectionPoolKey key)     à System.Data.SqlClient.SqlConnection.set_ConnectionString(String value)     à System.Data.SqlClient.SqlConnection..ctor(String connectionString, SqlCredential credential)     à Microsoft.Office.Server.Data.SqlSession.OpenConnection()     à Microsoft.Office.Server.Data.TransactionalSqlSession.RetrySqlConnectionInitialization(Action`1 initializer)     à Microsoft.Office.Server.Data.TransactionalSqlSession.OpenConnection()     à Microsoft.Office.Server.Data.SqlSession.ExecuteNonQuery(SqlCommand command) à Microsoft.Office.Server.Search.ManagedSqlSession.ExecuteNonQuery()

SqlCommand: ‘SET XACT_ABORT ON’     CommandType: Text CommandTimeout: 0

 

 

Bon évidemment premier réflexe… un coup de moteur de recherche… pas vraiment concluant. J’ai donc supprimé l’application de service, recréé… et même erreur !

 

 

La solution

 

En fait… ce n’est pas si compliqué que ça ! En nommant mon application de service de recherche “Application de recherche”, l’assistant nomme les bases de données :

“Application_de_recherche_[UN MEGA GUID PAS BEAU]”.

Et il semblerait que la connectionstring soit trop longue !!!!!!! (dépasse les fameux 128 caractères stipulés dans le log de l’erreur)

 

La solution peut donc être de deux formes. Soit on recréé une application de service de recherche à l’aide de l’assistant, en choisissant un nom plus court… et en priant pour qu’il soit assez court.

Soit on déploie le service avec notre ami PowerShell / Management Shell pour SharePoint.

Et vous l’aurez compris… je préfère largement la seconde option.

Voici donc le script que j’ai utilisé pour recréer ce service :

 

Création du pool d’application pour notre service :

  • $appPoolName = Nom du pool : SharePointSearchAppPool
  • $appPool = Pool d’application créé
    • Compte : DEMO\spapppool ==> domaine : Demo, compte utilisé : spapppool

 

$appPoolName = “SharePointSearchAppPool”
$appPool = New-SPServiceApplicationPool -Name $appPoolName -Account “DEMO\spapppool”

 

 

Divers paramètres :

  • $searchServerName  = Nom du serveur de recherche
  • $serviceAppName = Nom du service d’application
  • $searchDBName = Nom de la base de données du service

 

$searchServerName = (Get-ChildItem env:computername).value
$serviceAppName = “Application de recherche”
$searchDBName = “SPSearch_DB”

 

 

Démarrage des services sur le serveur :

 

Start-SPEnterpriseSearchServiceInstance $searchServerName
Start-SPEnterpriseSearchQueryAndSiteSettingsServiceInstance $searchServerName

 

 

Création de l’application de service de recherche et récupération de l’instance :

 

$searchServiceApp = New-SPEnterpriseSearchServiceApplication -Name $serviceAppName -ApplicationPool $appPoolName -DatabaseName $searchDBName
$searchProxy = New-SPEnterpriseSearchServiceApplicationProxy -Name “$serviceAppName Proxy” -SearchApplication $searchServiceApp

$searchServiceInstance = Get-SPEnterpriseSearchServiceInstance

 

 

Clonage de la Topologie de recherche par défaut :

 

$clone = $searchServiceApp.ActiveTopology.Clone()

New-SPEnterpriseSearchAdminComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

New-SPEnterpriseSearchContentProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

New-SPEnterpriseSearchAnalyticsProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

New-SPEnterpriseSearchCrawlComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

New-SPEnterpriseSearchIndexComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

New-SPEnterpriseSearchQueryProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance

$clone.Activate()

 

 

Et voilà !

SP2010 – Configurer Search Server avec PowerShell – Part 3

Posted on Updated on

Et enfin… la troisième partie !

La première partie expliquant comment créer des sources de contenu se trouve ici : https://kazoumoulox.wordpress.com/2011/10/06/confsearchpowershell-part1/

La seconde partie expliquant comment créer les étendues personnalisées, des des propriétés gérées se trouve ici : https://kazoumoulox.wordpress.com/2012/01/17/confsearchpowershell-part2/

Cette troisième partie permettra d’ajouter des règles d’inclusion/exclusion dans l’étendue personnalisée en utilisant les propriété gérées de la partie 2.

Rappelons-nous tout d’abord dans quel état était notre ferme SharePoint 2010. Nous avons créé le service de recherche de SharePoint, créé une source de contenu, une étendue personnalisée, une propriété gérée pointant sur la propriété indexée Type de Contenu des enregistrements SharePoint (Document ou Items). Bien sûr le tout à l’aide du Management Shell de SharePoint !

L’objectif est presque rempli… il nous reste toutefois quelques petites choses à faire !

Vous en souvenez peut-être, mais voici l’état dans lequel nous avons laissé l’étendue personnalisée après nos précédentes et trépidantes aventures :

Nous avons une étendue avec une seule règle, celle limitant les résultats inclus dans la source de contenu “Nouvelle Source”. Nous allons donc en ajouter une nouvelle qui sera cette fois-ci requise et limitera les résultats aux documents et enregistrements dont le type de contenu est “Demande de congés” (qui a été au préalable déclaré dans une collection de sites inclue dans la source de contenu).

Première étape (si ce n’est déjà fait), lancer le Management Shell pour SharePoint 2010, depuis le menu Démarrer > Tous les programmes > Microsoft SharePoint 2010 Products > SharePoint 2010 Management Shell :

Ensuite, il faut récupérer l’instance du service de recherche avec la ligne (Entre les quotes, c’est le nom de l’application de service qui a été créée dans les précédents articles):

  • $searchapp = Get-SPEnterpriseSearchServiceApplication “Service de Recherche de SharePoint 2010 créé par Powershell”
Puis récupérer l’étendue personnalisée avec :
  • $MyScope = GetSPEnterpriseSearchQueryScope -SearchApplication $searchapp -Identity “Première Etendue en PowerShell”
  • $MyScope
Nous avons déja vu, dans la partie 2 qu’il fallait utiliser le cmdlet New-SPEnterpriseSearchQueryScopeRule pour ajouter une nouvelle règle à une étendue personnalisée. On reprend donc cette commande :
  • New-SPEnterpriseSearchQueryScopeRule -RuleType PropertyQuery -ManagedProperty ContentTypeForSearch2 -PropertyValue “Demande de congés” -FilterBehavior Require  -scope $MyScope -SearchApplication $searchapp -url http://labs-sp2010/
Voici le résultat dans SharePoint :
Nous avons donc bien créé une nouvelle règle requise, utilisant la propriété gérée ContentTypeForSearch2 (=”Demande de congés”).
Mais pour le moment, il y a 0 éléments remontés… peut être parce qu’il n’y a pas de demande de congés déposées ! …
Dernière opération, lancer la mise à jour des étendues, pour cela, rien de plus simple !
  • $searchapp.StartScopesCompilation()

Cette commande lance la compilation comme on peut le voir dans l’administration centrale de SharePoint :

Et à la fin de la mise à jour :

Donc tout à l’air prêt… y’a plus qu’à tester ! Pour cela je vais ajouter quelques documents utilisant le type de contenu “Demande de congés” dans une bibliothèque de documents de la collection de sites http://labs-sp2010/.

Il faudra bien sûr relancer l’indexation du contenu (incrémentielle ou complète) et vérifier que l’étendue personnalisée contient bien nos documents. Allez c’est parti ! (ça sent la fin ;))

 

Une fois quelques documents ajoutés, il faut bien sûr relancer une indexation (complète pour ma part) afin que le composant crawler (indexeur) parcoure ces documents et indexe le contenu & les méta-données du document… et en particulier notre type de contenu !

Après donc quelques minutes/heures d’indexation, alors voir dans notre nouvelle étendue combien de documents ont été indexés avec le type de contenu souhaité :

 

 

Les données sont donc bien indexée et l’on retrouve nos documents ajoutés dans l’étendue de recherche de SharePoint. Cette étendue pourra alors être utilisée soit dans la liste déroulante des étendues juste devant la searchbox (barre de recherche des sites SharePoint) soit dans les centres de recherche (SharePoint 2010 Server Editions Standard ou Enterprise) et permettront de filtrer à priori ou à posteriori les données. Ces filtres amélioreront l’expérience utilisateur avec le moteur de recherche et leur permettront de trouver plus rapidement les documents recherchés au travers du moteur de recherche de SharePoint.

Cette suite d’articles est donc terminée, en espérant avoir été clair, concis et efficace. Je recherche des sujets pour mes prochains posts… donc si vous avez des idées, laissez moi un message !

[SP2010] – Limitation à 2000 enregistrements dans le BCS SharePoint 2010

Posted on Updated on

Lorsqu’on réalise un BCS (Business Connectivity Service) à l’aide de SharePoint Designer 2010 par exemple, il arrive qu’on se heurte à une limitation imposée par l’application de service BCS. Cette limitation ne permet par de retourner plus de 2000 éléments lors de l’exécution de la méthode “Read List”.

Pour augmenter cette limite, rien de tel qu’un petit script PowerShell !

$appbcs = Get-SPServiceApplicationProxy | where{$_.GetType().FullName -eq (‘Microsoft.SharePoint.BusinessData.SharedService.’ + ‘BdcServiceApplicationProxy’)}

$BCSLimit = Get-SPBusinessDataCatalogThrottleConfig -ServiceApplicationProxy $appbcs -Scope database -ThrottleType items

Set-SPBusinessDataCatalogThrottleConfig -Identity $BCSLimit -Maximum 100000 -Default 20000

On vérifie que cela fonctionne : $BCSLimit = Get-SPBusinessDataCatalogThrottleConfig -ServiceApplicationProxy $appbcs -Scope database -ThrottleType items

$BCSLimit

Le Management Shell doit vous afficher la limite par défaut à 20000 et le maximum à 100000.

Et voilà !