Content search Webpart et le filtrage par type de contenu

Le content search Webpart permet d’effectuer une requête sur le moteur de recherche afin de proposer du contenu SharePoint peut importe où celui est stocké.

Ce composant WebPart très puissant est apparu avec la version 2013 de SharePoint. Sa configuration est assistée à l’aide d’une interface graphique.

Un bug se trouve sur cet assistant.

 En effet après avoir sélectionné la propriété « type de contenu », la requête créée utilise l’ID du type de contenu.

Hors la propriété ContentType attend le nom du type de contenu.

Le résultat est qu’aucun élément ne vous est retourné par la requête.

ContentSearchWPBadQuery

 Modifier dans la requête la propriété ContentType par ContentTypeId.

La requête retourne désormais des éléments.

ContentSearchWPGoodQuery

Damien.

Publicités

Le Shredded Storage de SharePoint 2013

Shredded Storage

 

Ou « stockage râpé » pour Google traduction est une nouvelle fonctionnalité de SharePoint 2013.

Son objectif est de limiter la taille du stockage nécessaire à SharePoint en n’enregistrant que le différentiel des éléments.

 

Exemple : Je créé une bibliothèque de document, j’active le versioning, lorsque j’enregistre plusieurs fois le document, seule les mises à jours sont ajoutées en bases.

Contrairement à SharePoint 2010 ou chaque enregistrement de document nécessite un enregistrement complet du document en bases de données.

Je vous propose de visualiser concrètement le résultat de cette techno. en réalisant plusieurs enregistrement sur une infra SharePoint 2010 et sur une infra SharePoint 2013.

 

Mise en place de l’infrastructure

 

Pour réaliser ces tests, je dispose

  • d’une infra SharePoint 2010 (Windows 2008 R2, SQL 2008 R2, SharePoint Foundation 2010)
  • d’une infra SharePoint 2013 (Windows 2008 R2, SQL 2008 R2, SharePoint Foundation 2013).

 Nous allons tout d’abord créer une nouvelle base de données sur le serveur SQL de chaque Infra.

Je configure la taille de départ à 3 Mo avec un agrandissement par pas de 1Mo pour le fichier de données.

Pour le fichier de log, je pars sur 1Mo de taille initiale et 1Mo de croissance.

  

 

Je vais ensuite ajouter ces bases de données à une application web existante.

Maintenant, nous allons créer une collection de site vide sur chaque webapp. Après la création vérifier que celle-ci a bien été créée sur la base de données souhaitée.

  

Nous allons maintenant créer une bibliothèque de document dans chaque collection de site.

 Je réduis les bases de données pour partir sur une base sans journaux de transaction.

 Après réduction des bases de données :

 

 

SharePoint Foundation 2010 SharePoint Foundation 2013
Fichier de données 21 632 Ko

26 112 Ko

  

Ajout du document de référence

 

Ajout du document de référence, un simple document Word 2010 avec comme contenu le mot « TEST ».

 Le document n’a qu’une taille de 18 ko, il ne permet donc pas d’augmenter la taille de la base de données.

 Nous allons donc commencer par ajouter quelques photos pour que le document soit plus conséquent.

Bien évidemment les mêmes photos sont ajoutés sur nos deux infras.

 Le document a désormais une taille de 3.8 Mo

 Les bases de données sont désormais décomposées comme suit :

 

Ajout doc 3,8Mo SharePoint Foundation 2010 SharePoint Foundation 2013
Fichier de données 29 824 Ko 34 304 Ko
Différence étape précédente 8 192 Ko 8 192 Ko

 L’ajout du document a eu exactement le même impact sur les deux infra.

  

Création de nombreuses versions

 

Nous allons maintenant créer 10 versions du document en ajoutant à chacune d’entre elle une nouvelle ligne à la fin du doc avec le numéro de version.

 

On remarque tout de suite une différence de comportement, l’enregistrement des différentes versions du document sur SharePoint 2010 est relativement long (2 ou 3 sec).

L’enregistrement sur SharePoint 2013 est quasiment instantané.

Cela s’explique, le « shredded storage » permet de n’envoyer au serveur SharePoint que les mises à jour du document.

 

Le résultat final est le suivant :

 

Après 10 versions du document

SharePoint Foundation 2010 SharePoint Foundation 2013

Fichier de données

49 280 Ko

34 304 Ko

Différence étape précédente 19 456 Ko

0 Ko

 

 Stupéfiant, là ou SharePoint 2010 nécessite 20 Mo pour enregistrer nos 10 versions de document, qui pour rappel ne se différencie que de quelques mots.

SharePoint 2013 et le « stockage râpé  😉 » (Shredded Storage), n’ont même pas fait grossir la base de données. Effectivement, nous avons configuré l’agrandissement par pas de 1 Mo nos modifications n’ont pris en base que quelques Ko.

 

Copie de document

 

Je vais maintenant dupliquer le document dans la même bibliothèque en modifiant uniquement le titre de celui-ci.

Après 5 duplication du document

SharePoint Foundation 2010 SharePoint Foundation 2013

Fichier de données

65 664 Ko

51 172 Ko

Différence étape précédente 13 684 Ko

22 976 Ko

 

Le shredded storage n’a pas su déduire que nous avons dupliqué le même document, de plus le stockage nécessaire sur SharePoint 2013 est plus important.

 

Duplication du document dans différentes DocLib

 

 Je vais créer 10 DocLibs et y déposer à chaque fois le même document.

 Après la création des 10 DocLibs voici la taille des bases de données.

 

Après création des 10 DocLibs

SharePoint Foundation 2010 SharePoint Foundation 2013
Fichier de données 65 792 Ko

51 904 Ko

 

Ajoutons maintenant le même document dans les différentes bibliothèques de documents.

 

Après ajout des 10 documents

SharePoint Foundation 2010 SharePoint Foundation 2013

Fichier de données

104 704 Ko

91 840 Ko

Différence étape précédente 38 912 Ko

39 936 Ko

 

L’ajout du même document dans différentes bibliothèques de documents ne permet pas de tirer parti du « shredded storage »

Conclusion

 

Le « shredded storage » de SharePoint 2013 est d’une puissance redoutable lorsque vous travaillez sur des documents avec versioning.

La volumétrie des bases de données ne va plus augmenter de façon importante à cause du versioning.

De plus, l’enregistrement des documents ne nécessite plus l’envoie de la totalité de celui-ci.

Nous avons donc des gains de bande passante importants et pouvons envisager plus sereinement des scénarios de travail collaboratif à distance sur SharePoint.

Encore un point qui devrait vous faire rapidement migrer sur SP2013 …

Téléchargements de SharePoint 2013

Voici venu le temps …. des téléchargements de SharePoint 2013 :

Téléchargement RTM

Téléchargement Preview

Documentation

  • Module 1: SharePoint 2013 ITPro introduction and overview. Get an overview of key changes and new concepts in SharePoint Server 2013 and SharePoint Foundation 2013.
  • Module 2: SharePoint 2013 system requirements. Learn about the hardware and software requirements for SharePoint 2013 and supported browser levels and setup considerations.
  • Module 3: SharePoint 2013 architectural changes. Learn about key architectural changes in SharePoint 2013 platform. We’ll highlight the most relevant changes from overall architectural perspective.
  • Module 4: SharePoint 2013 server farms and site architecture planning. Plan for server farms and sites in SharePoint 2013. Learn about planning for the distributed cache, changes in alternate access mappings and self-service site creation, new features in themes and branding, new ways to share sites, lists, and libraries.
  • Module 5: Office Web Apps 2013 architecture and deployment. Learn about the new architecture and deployment model for Office Web Apps including architectural changes, deployment options, and operation aspects for Office Web apps.
  • Module 6: SharePoint 2013 service application architecture and individual service applications. Get an overview of about changes in individual service applications in SharePoint 2013, including new service applications, general considerations, and changes in service application architecture.
  • Module 7: SharePoint 2013 enterprise search overview. Learn about the redesigned Enterprise Search in SharePoint 2013 including architectural changes to physical and logical topologies, deatils about configuration options for crawling, content, and query.
  • Module 8: SharePoint 2013 social features. Social is one of the largest investments in SharePoint 2013. New features and capabilities provide a better and more comprehensive story for social computing in SharePoint 2013. Get a walthrough of social features in SharePoint 2013.
  • Module 9: SharePoint 2013 enterprise content management and web content management considerations. Get an overview of key changes and improvements in enterprise content management (ECM) and web content management (WCM) in SharePoint 2013. Learn about new capabilities from eDiscover improvements to major new capabilities for WCM-driven sites.
  • Module 10: SharePoint 2013 customization options and management. Learn about the new customization capabilities in SharePoint 2013 and what does that actually mean from IT Pro perspective. Learn about required infrastructural changes for new customization capabilities and setting up team development environments.
  • Module 11: SharePoint 2013 authentication and authorization overview. Get an overview of changes in claims-based authentication in SharePoint 2013. Learn about new support for OAuth and how it’s used in SharePoint 2013. Also see how OAuth is used in Server to Server (S2S) authentication scenarios.
  • Module 12: Overview of SharePoint 2013 business continuity management. Learn about the approaches and techniques to use when devising a meaningful and cost effective business continuity management (BCM) strategy for SharePoint 2013.
  • Module 13: Upgrading to SharePoint 2013. Learn about the different facets of upgrade preparation and understand the key skills and techniques you’ll need to successfully upgrade to SharePoint 2013.

VHD boot to Hyper-V => blue screen

VHD’s boot to Hyper-v

  

Depuis peu sur Windows 8 RP, j’ai souhaité utilisé mes disques VHD sur l’Hyper-V de ce nouvel OS.

Pour rappel, Windows 8 embarque désormais Hyper-V.

 Jusqu’alors, sous Windows 7, j’utilisai le principe de Boot sur VHD (http://technet.microsoft.com/en-us/windows/windows-7-vhd-boot-demonstration.aspx) pour basculer d’un environnement de travail classique, à des environnements de développement sous SharePoint 2010 ou sous SharePoint 2007.

 Le problème de ce genre de basculement, c’est que l’on perd complètement son environnement de travail habituel.

D’où l’intérêt, de rester sur son OS classique (Windows 8) et de démarrer au besoin l’environnement de dév.

 

Le problème

 L’avantage du Boot sur VHD est que l’on tire parti de la couche hardware (

Intel® Storage Technology, par exemple). Et dans mon cas de l’Advanced Host Controller Interface (AHCI).

Le passage vers l’hyper-v est donc problématique puisqu’il ne gère par l’AHCI.

 Cela se termine donc souvent par un « blue screen » lors du boot. Cela se produit lors du chargement du pilote classpnp.sys (visible lors d’un démarrage sans échec).

  

Résolution

 Nous allons voir donc comment désactiver la prise en charge de l’AHCI sur la machine virtuelle.

 Démarrer la machine virtuelle sur le DVD d’installation de Windows 2008 ou Seven.

 Sélectionner votre langue, puis sélectionner « Réparer l’ordinateur ».

 

Sélectionner l’OS.

  

Sélectionner Invite de commandes

 

Lancer l’éditeur de registre à l’aide de la commande REGEDIT.

 

Se placer sous HKEY_LOCAL_MACHINE (HKLM)

 

Cliquer sur Fichier, puis sur Charger la ruche.

 

Se déplacer sous C:\Windows\System32\Config

Charger la ruche SYSTEM.

 

Indiquer le nom de cette ruche (cela n’a pas d’importance).

 

Se déplacer dans la ruche précédemment chargée, sous  ControlSet001/services/

 

Rendez-vous dans les clés (dossier) suivantes :

  • aliide => Modifier la valeur “Start” à 3

  • amdide => Modifier la valeur “Start” à 3
  • atapi => Modifier la valeur “Start” à 0
  • cmdide => Modifier la valeur “Start” à 3
  • iaStorV => Modifier la valeur “Start” à 3
  • intelide => Modifier la valeur “Start” à 0
  • msahci => Modifier la valeur “Start” à 3
  • pciide => Modifier la valeur “Start” à 3
  • viaide => Modifier la valeur “Start” à 3

 Certaines valeurs seront déjà correctement paramétrées.

 Se déplacer ensuite sur la racine de la ruche, cliquer sur « Fichier » puis sur « Décharger la ruche ».

  

Taper « exit » pour fermer l’invite de commande, puis cliquer sur le bouton redémarrer.

Et voilà, vous venez de désactiver l’utilisation de l’AHCI dans le système d’exploitation virtualisé.

Conclusion

 Nous venons de voir comment, désactiver l’AHCI sur une machine virtuelle Hyper-V.

Cette action peut également être réalisée lorsque vous partagez votre VHD à un de vos collègues qui souhaite réutiliser un de vos environnements mais qui ne dispose pas de l’AHCI.

Dernier cas d’utilisation le P2V.

 

SharePoint et les entreprises multi-sites 2/2

SharePoint et les entreprises multi-sites (la technique)

 

Nous venons de voir dans un article précédent les raisons qui nous poussent à interconnecter deux fermes SharePoint.

Regardons en pratique cette configuration.

 

Dans la suite de cet article, j’appellerai Ferme du siège la ferme SharePoint sur laquelle les applications de services sont démarrées et publiées.

La ferme qui se connectera aux applications de services à distance se nommera Ferme de la succursale.

 

Configuration de la relation d’approbation de fermes

 

Export des certificats sur la ferme du siège

 Commandes PowerShell :

 $rootCert = (Get-SPCertificateAuthority).RootCertificate

 $rootCert.Export(« Cert ») | Set-Content E:\Sharepoint2010\Cert\PublishingFarmRoot.cer -Encoding byte

 Cette commande exporte le certificat Racine de la ferme

 Copier ce certificat sur l’autre ferme.

 

Export des certificats sur la ferme de la succursale

 Commandes PowerShell :

 $rootCert = (Get-SPCertificateAuthority).RootCertificate

 $rootCert.Export(« Cert ») | Set-Content C:\Cert\RecievingFarmRoot.cer -Encoding byte

 

Cette commande exporte le certificat Racine de la ferme

 $stsCert = (Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate

 $stsCert.Export(« Cert ») | Set-Content C:\Cert\ReceivingFarmSTS.cer -Encoding byte

 Cette commande exporte le certificat du service “Security Token”

 Copier ces 2 certificats sur l’autre ferme.

  

Création de la relation d’approbation

 Depuis la ferme de la succursale (ferme consommatrice des applications), lancer les commandes PowerShell suivantes :

 $trustCert = Get-PfxCertificate C:\cert\PublishingFarmRoot.cer

 New-SPTrustedRootAuthority PublishingFarm -Certificate $trustCert

 Depuis la ferme du siège, lancer les commandes PowerShell suivantes :

 $trustCert = Get-PfxCertificate C:\Cert\ReceivingFarmRoot.cer

 New-SPTrustedRootAuthority ReceivingFarm -Certificate $trustCert

 $stsCert = Get-PfxCertificate c:\Cert\receivingFarmSTS.cer

 New-SPTrustedServiceTokenIssuer ReceivingFarm -Certificate $stsCert

 

Ajout des permissions

 Depuis la ferme de la succursale (ferme consommatrice), lancer la commande PowerShell suivante :

 (Get-SPFarm).Id

  

Copier l’ID de la ferme

 Puis depuis la ferme du siège, lancer les commandes PowerShell suivantes :

 $security = Get-SPTopologyServiceApplication | Get-SPServiceApplicationSecurity

$claimProvider = (Get-SPClaimProvider System).ClaimProvider

$principal = New-SPClaimsPrincipal -ClaimType http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid -ClaimProvider $claimProvider -ClaimValue « GUID »

Grant-SPObjectSecurity -Identity $security -Principal $principal -Rights « Contrôle total »

Get-SPTopologyServiceApplication | Set-SPServiceApplicationSecurity -ObjectSecurity $security

 

Sur la ligne « $claimProvider –ClaimValue « GUID«  » remplacer GUID par l’ID de la ferme de la succursale.

Faites également attention sur la ligne « Grant-SPObjectSecurity -Identity $security -Principal $principal -Rights « Contrôle total » » ,la valeur « Contrôle total » est valable uniquement sur une installation française de SharePoint.

 

Publications des applications de service

Publication de la recherche

Depuis la centrale d’administration de la ferme du siège, sélectionner l’application de service de recherche puis cliquer dans le bandeau sur « Publier ».

Cocher la publication de l’application de service avec le protocole HTTPS.

 Copier l’URL publiée qui va être utilisée sur la ferme de la succursale.

 

Attribution des droits à la ferme distante

Ouvrir les autorisations de l’application de recherche de la ferme du siège.

Lancer une recherche avec l’ID de la ferme de la succursale.

  Ajouter l’élément du type ID de batterie.

 Donner le contrôle total à la batterie sur cette application de service.

  

Connexion à l’application de recherche

 Depuis la ferme de la succursale, ouvrir la gestion des applications de service.

Lancer la connexion à une application de service de recherche.

Coller l’URL du service de recherche de la ferme du siège précédemment copiée.

Sélectionner le service de recherche.

 

Indiquer le nom de la connexion.

  

Paramétrage de la recherche

Il est nécessaire de créer une source de contenu spécifique pour l’indexation des sites de la ferme de la succursale. Ainsi vous pourrez planifier à intervalles moins fréquents l’indexation afin de ne pas encombrer inutilement la bande passante.

 

Conclusion

 

Après avoir configuré la relation d’approbation entre nos 2 fermes, nous avons publié une application de service puis nous nous sommes connectés à cette application depuis notre ferme distance.

Vous pouvez reproduire la publication et la connexion sur les autres applications de services.

Nous avons donc fédérer nos fermes SharePoint pour que les utilisateurs puissent collaborer.

SharePoint et les entreprises multi-sites 1/2

SharePoint et les entreprises multi-sites (la théorie)

De nombreuses entreprises réparties sur différents sites géographiques souhaitent utiliser SharePoint afin de rendre plus facile la collaboration au sein de l’entreprise.

Après tout, c’est fait pour ça SharePoint !

Oui mais, il est nécessaire de prendre en compte quelques aspects.

Prenons le scénario suivant, une entreprise composée de :

  • 1 siège social de 5000 employés,
  • 1 succursale de 1000 employés,
  • 1 site distant de 20 employés.

 

L’utilisation souhaitée de SharePoint est la GED et le réseau social d’entreprise.

Les utilisateurs vont donc désormais travailler sur leurs documents directement sur SharePoint et non plus sur un serveur de fichier.

Je vous rappelle que nous avons des utilisateurs qui ne sont pas physiquement dans les mêmes locaux se pose donc la question du débit.

 
Si j’installe mon environnement SharePoint au siège, je vais avoir 1020 utilisateurs qui vont faire transiter leur document à chaque enregistrement sur des réseaux WAN à débits modérés.

Les temps de réponses seront beaucoup trop longs, les utilisateurs vont voir rouge.

Autre solution, j’installe un environnement SharePoint sur chaque site. Les utilisateurs enregistreront  désormais leurs documents localement (sur l’environnement SharePoint local), donc plus de problème de débits.

Par contre, plus de réseau social, plus de métadonnées gérées communes, plus de recherche globale. Chaque site est autonome, on a vu mieux en terme de collaboration !

 

Heureusement, SharePoint 2010 nous offre la possibilité d’interconnecter différentes fermes. Et donc de partager les applications de services.

 Voici donc l’architecture envisagée :

Nous ne mettrons pas en place de ferme SharePoint sur le site distant de 20 employés, le rapport nombres d’utilisateurs / débit est acceptable au vu du coût de l’installation et de la maintenance d’une autre ferme SharePoint.

 

Nous avons donc un compromis entre la localisation du contenu au plus près des utilisateurs et la fédération autour d’un ensemble commun : recherche globale, réseau social commun, métadonnées gérées communes.

Ready to collaborate !

La suite ici

Mise à jour automatique et SharePoint

 

Le saviez-vous

 

Windows Update ou Windows Server Update Services (WSUS) sont en mesure de déployer des mises à jour SharePoint.

Je l’ai découvert à ma grande surprise très récemment. D’où cet article !

  

Mais, pourquoi ?

 

Vous le savez surement, l’installation de patch ou de service pack sur SharePoint s’effectue en deux temps : l’installation des binaires puis la mise à niveau.

Or l’installation via Windows Update n’effectue que le déploiement des binaires, il reste donc à effectuer manuellement la mise à niveau.

L’installation des patchs SharePoint de façon automatique via Windows Update n’a donc que peu d’intérêt.

 

Petit problème d’ « Applicabilité »

 

Vous ne vous êtes peut être jamais rendu compte que Windows Update peut vous installer des mises à jours SharePoint. Oui, car cela fonctionne uniquement sur des installations « Stand-Alone » de SharePoint (installation à server unique : SharePoint + SQL Express).

Or dans la majeure partie des cas, nous utilisons SharePoint en mode ferme (au moins 2 serveurs).

Sur ces installations, WSUS vous indiquera que les mises à jour SharePoint ne sont pas applicables.

It’s by design :

Remarque concernant Microsoft Office SharePoint Server 2007 et Microsoft Office SharePoint Server 2010 : Le tableau de détection décrit ci-dessus repose sur des déploiements à serveur unique de Microsoft Office SharePoint Server 2007 et Microsoft Office SharePoint Server  2010. Les outils de détection ne trouvent pas l’applicabilité de la mise à jour sur des systèmes configurés comme élément de batteries de serveurs SharePoint avec plusieurs systèmes.

(Réf : http://technet.microsoft.com/fr-fr/security/bulletin/ms11-091)

 

Résultat des courses !

 Il est fort probable que dans votre système d’information, vous disposez d’installation SharePoint en mode Stand-Alone et d’installation en mode ferme (ou Batterie). Les « stand-alone » pour faire des tests ou encore pour des postes de développement, la prod et la pré-prod en mode batterie.

 Et c’est là que ça se complique !

 Les versions Stand-Alone, vont être patchées (n’oubliez pas de faire la mise à niveau manuellement) et les versions en batterie ne le seront pas forcément. A partir de là, il ne vous est plus possible d’effectuer les commandes Backup-SPSite/Restore-SPSite à cause de l’incompatibilité de version.

 

 

Vous ne pouvez donc plus récupérer le contenu de la prod pour l’envoyer en débug sur les postes de dév, c’est facheux 😦

  

Le retour arrière

  

Avez-vous une sauvegarde de vos postes de dév avant l’installation des patchs SharePoint ?

Si oui, allez-y restaurer.

Sinon je vous informe qu’il n’est pas possible de désinstaller ces patchs même si la mise à niveau SharePoint n’a pas été réalisée.

Donc dans ce cas pas de retour arrière, donc on va de l’avant et on installe les patchs sur les installations de SharePoint en mode ferme.

Petit rappel sur l’installation des patchs, ici.

 

Le conseil

 

Si vous ne souhaitez pas avoir de problème, faites en sorte que les postes SharePoint en stand-alone n’applique pas les mises à jour SharePoint.

Désactivez l’installation automatique des mises à jour dans Windows Update, c’est vous qui déciderez quels sont les patchs à installer.

Dans le cas de WSUS, n’approuvez pas les mises à jour SharePoint 2010 qui se trouvent d’ailleurs dans la catégorie Office 2010.

 

%d blogueurs aiment cette page :