SharePoint 2010 : Problème restauration d'un backup

J'ai rencontré récemment un problème lors de la restauration d'un backup SharePoint.
Le message d'erreur était très explicite:
Restore-SPSite: Your backup is from a different version of Microsoft SharePoint Foundation and cannot be restored to a server running the current version. The backup file should be restored to a server with version ’14.0.0.4762′ or later.

Ce problème provient du fait que le backup est issu d'une ferme SharePoint basique alors que mon environnement est configuré en SharePoint 2010 SP1...
Figurez-vous qu'à présent, il n'est pas possible de restaurer un backup classique sur un serveur SharePoint en version SP1.
La raison invoquée est le fait du changement du schéma des bases de données de contenu entre ces 2 versions.

Malheureusement, je ne vous donnerai pas dans ce post de solutions miracle!
La seule technique viable est d'utiliser un serveur transitoire en suivant la méthode suivante:
- Créer une machine SharePoint de base,
- Restaurer votre backup sur cette machine,
- Mettre à jour le serveur à l'aide du SP1 (avec la CU corrigée de Juin si possible...),
- Réaliser un backup de votre site précédemment restauré,
- Restaurer ce backup sur votre ferme en SP1...

Désolé mais cela est la seule solution envisageable!

SharePoint 2010 : Créer un sous-site dans une collection de type Publishing

Aujourd'hui j'ai été confronté à un petit problème lors de la mise en place d'une collection de sites de type "Publication".
En effet, lorsque l'on crée un site de ce genre, il s'avère seulement possible de créer 2 types de sous-sites : Publication et wiki.

Seulement, il est possible de remédier à cela assez rapidement. Pour cela, il faut réaliser les actions suivantes:
- Se placer dans les "Paramètres du site",
- Dans la section "Aspect", cliquer sur "Mises en page et modèles de sites",
- Permettre de rendre tous les modèles de site accéssibles.

A présent vous avez accès à tous les templates pour créer un sous-site!

INFOPATH 2010 : Optimiser les performances du code managé

Aujourd'hui, voici un petit article concernant l'optimisation de vos formulaires InfoPath comprenant du code managé.
Il peut arriver que vous ayez des actions assez longues à réaliser sur le XML de votre formulaire.
Je penses notamment à l'ajout automatique de lignes dans une section extensible.

Les vues InfoPath étant liées directement au XML, une modification dans ce dernier entraine une mise à jour de la vue.
Pour s'abstenir de ce genre de comportement, il est possible d'utiliser la méthode DisableAutoUpdate.
Cette méthode permet d'attendre la fin des modifications du XML avant de rafraichir la vue InfoPath (ce qui permet de gagner un gain non négligeable de performances).

Pour se faire, il faut utiliser la méthode de la manière suivante:

// Décorrelation de la vue avec le XML
this.CurrentView.DisableAutoUpdate();

// Modification sur le XML (par exemple ajout de 100 lignes dans un tableau extensible)
...

// Corrélation de la vue avec le XML
this.CurrentView.EnableAutoUpdate();

Vous pourrez trouver un article du MSDN concernant cette méthode à cette adresse:
http://msdn.microsoft.com/en-us/library/microsoft.office.infopath.view.disableautoupdate(v=office.11).aspx

Attention toutefois à bien repositionner le "EnableAutoUpdate() à la fin du traitement sous peine d'avoir de sérieux dysfonctionnements dans le formulaire...

SharePoint 2010 : Changer l'ordre des propriétés utilisateur

En utilisant SharePoint 2010, on est souvent amené à travailler avec le service applicatif "Profil Utilisateur".
Il est possible d'enrichir les propriétés avec des propriétés personnalisées.
L'interface se présente de la manière suivante:

Les petite flêches bleus permettent de remonter ou descendre les propriétés dans le profil utilisateur.
Cela permet même de les déplacer à travers différentes catégories (Informations de base, Détails,...).

Autant dire que si vous souhaitez déplacer une propriété que vous venez de rajouter vers le haut du profil utilisateur, il va falloir vous armer de patience.
Heureusement, il existe une commande powershell permettant de positionner les propriétés exactement à l'emplacement que vous souhaitez.
La commande PowerShell se présente de la manière suivante:

$mySite = "http://mysite"
$site = Get-SPSite $mySite
$context = Get-SPServiceContext $site
$upConfigManager = New-Object Microsoft.Office.Server.UserProfiles.UserProfileConfigManager($context)
$profilePropertyManager = $upConfigManager.get_ProfilePropertyManager()
$upConfigManager.GetProperties().SetDisplayOrderByPropertyName("PutYourInternalPropertyName", PositionNumber)
$upConfigManager.CommitDisplayOrder();

Il suffira de changer dans ce script l'url du site, le nom interne de la propriété et la position à laquelle placer la propriété.

SHAREPOINT 2010 : Recherche sur propriété

Aujourd'hui un petit post sur la recherche dans SharePoint et un petit problème de configuration auquel j'ai du faire face.
Considérons qu'un utilisateur veut réaliser une recherche d'utilisateurs sur une propriété "Numéro de téléphone".
Dans ce cas la, la syntaxe de la recherche SharePointvveut que l'on écrive la requête suivante "WorkPhone:0559*".
Malheureusement cette requête ne renvoie aucun résultat avec la configuration native de la recherche.

Cela provient d'un défaut de paramètrage de la recherche SharePoint.
Pour pouvoir chercher de cette façon, il faut que la propriété "WorkPhone" soit désignée en tant que FullTextQueriable.
Pour cela, il faut utiliser le code PowerShell suivant:

$app=Get-SPEnterpriseSearchServiceApplication "Search Service Application"
$mp=Get-SPEnterpriseSearchMetadataManagedProperty -SearchApplication $app -Identity WorkPhone
$mp.FullTextQueriable=$true
$mp.Update()

Ensuite il faudra réinitialiser l'index de recherche puis lancer une recherche complète (en non incrémentale) sur votre source de recherche.
Vous pourrez à présent recherche sur la propriété "WorkPhone".