SHAREPOINT 2013 : Installation sous Windows Server 2012 R2

Lors de l'installation de SharePoint 2013 sous WS2012R2, vous pouvez rencontrez des soucis dans la phase d'installation des prérequis:
"The tool was unable to install Application Server Role, Web Server (IIS) Role"

 

Cette erreur survient avec ou sans l'utilisation de l'AutoSPInstaller.
Après quelques recherches, il s'avère que ce problème est plutôt fréquent. Un article a même été mis à disposition par Microsoft: https://support.microsoft.com/en-us/kb/2765260

 

La première erreur peut survenir du faire que vous ne possèdez pas le fichier "ServerManagerCmd.exe" sur le serveur. Il ne s'agit que d'une copie de l'exécutable "ServerManager.exe".
Pour se faire, vous pouvez lancer la commande PowerShell suivante:

Import-Module ServerManager
Copy-Item -Path "$($ENV:SystemRoot)\System32\ServerManager.exe" -Destination "$($ENV:SystemRoot)\System32\ServerManagerCmd.exe" -Force

Si le problème persiste, vous pourrez activez manuellement les fonctionnalités nécessaires "Application Server" et "Web Server" via PowerShell:

Add-WindowsFeature NET-WCF-HTTP-Activation45,NET-WCF-TCP-Activation45,NET-WCF-Pipe-Activation45
Add-WindowsFeature Net-Framework-Features,Web-Server,Web-WebServer, `
 Web-Common-Http,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing, `
    Web-Http-Errors,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext, `
    Web-ISAPI-Filter,Web-Health,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor, `
    Web-Http-Tracing,Web-Security,Web-Basic-Auth,Web-Windows-Auth,Web-Filtering, `
    Web-Digest-Auth,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression, `
    Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Metabase,Application-Server, `
    AS-Web-Support,AS-TCP-Port-Sharing,AS-WAS-Support, AS-HTTP-Activation, `
    AS-TCP-Activation,AS-Named-Pipes,AS-Net-Framework,WAS,WAS-Process-Model, `
    WAS-NET-Environment,WAS-Config-APIs,Web-Lgcy-Scripting,Windows-Identity-Foundation, `
    Server-Media-Foundation,Xps-Viewer

Il sera ensuite nécessaire de redémarrer le serveur et le tour est joué.

SHAREPOINT : Repackager un WSP manuellement

Le développement dans SHAREPOINT s'articule autour du déploiement de WSP:

• Conception de solutions plus ou moins complexes de type ferme ou Sandbox (WebParts, modèles de sites, timer jobs, types de contenus, pages applicatives métiers),
• Enregistrement de sites en tant que modèle (fonctionnalité offerte nativement par SharePoint qui se déploie en tant que Sandbox).

 

Dans chacun de ces cas, il peut-être demandé de réaliser des modifications sur des WSP en production alors que les sources ne sont plus disponibles (si si, cela arrive...).

Si la modification est minime (pas de DLL à modifier), plutôt que de faire du retro engeneering, il peut-être avantageux de simplement modifier un fichier dans le WSP.

 

Pour se faire, il faut tout d'abord comprendre l'architecture qu'un WSP. Il ne s'agit ni plus ni moins qu'un fichier CAB (ou archive) renommé en WSP. Il est donc possible d'extraire le contenu d'un WSP dans un répertoire après l'avoir renommé en CAB ou RAR puis l'avoir décompressé.

 

Vous accédez donc à présent à l'ensemble des fonctionnalités comprises dans votre WSP et vous pouvez réaliser les modifications apportées. Mais comment reconcevoir le package une fois modifiée? Ce qui ont travaillé avec des archives CAB connaissent l'outil "MAKECAB" mais il est facile de se retrouver avec un package incorrect.

 

Pour se faire, SharePoint intégre une méthode qui peut être appelée via le PowerShell pour SharePoint (il faudra être positionné sur un serveur SharePoint):

 

$destWSPfilename = "C:\TEMP\Repackage\MonNomdeWSP.wsp"
$sourceSolutionDir = [System.IO.DirectoryInfo]"C:\TEMP\Repackage\MonArchiveExtraite"

 

$a = [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$ctor = $a.GetType("Microsoft.SharePoint.Utilities.Cab.CabinetInfo").GetConstructors("Instance, NonPublic")[0]
$cabInf = $ctor.Invoke($destWSPfilename);

$mi = $cabInf.GetType().GetMethods("NonPublic, Instance, DeclaredOnly")
$mi2 = $null
foreach( $m in $mi ) {
    if( $m.Name -eq "CompressDirectory" -and $m.GetParameters().Length -eq 4 ) {
        $mi2 = $m;
        break;
    };
}

$mi2.Invoke($cabInf, @( $sourceSolutionDir.FullName, $true, -1,$null ));

 

Il faudra donc uniquement modifier les 2 variables $destWSPFileName (correspondant à l'emplacement de regénrération de votre WSP) et $sourceSolutionDir (correspondant à votre répertoire contenant les fichiers extraits du WSP).

 

Et le tour est joué, vous obtenez un magnifique WSP prêt à être déployé!

 

MICROSOFT : Fin de l'aventure MVP

C'est avec regret que j'ai appris lors de ces derniers jours mon non-renouvellement en tant que MVP (Microsoft Most Valuable Professional). C'est donc la fin d'une belle aventure après 4 ans de bons et loyaux services au sein de ce programme.

 

L'expertise "InfoPath" est supprimée du programme MVP étant donné que le produit est arrivé au terme de son cycle de vie.

Mais pour rappel, InfoPath sera supporté jusqu'en 2023 (10 ans après la dernière sortie du produit) et sera toujours disponible dans SharePoint 2016 via Forms Services.

Je continuerai donc malgré tout à poster des articles autour des technologies SharePoint et InfoPath avec un recentrage vers mon cœur de métier qui reste SharePoint.

SharePoint 2013 : Cache de sortie

Un des axes d'amélioration des performances de SharePoint reste l'utilisation de mécanismes de cache. Outre le cache pouvant être mis en place sur les développements (côté client ou serveur), il existe un mécanisme natif de SharePoint nommé "Output Cache" (ou cache de sortie en bon français).

Pour l'activer, il sera tout d'abord nécessaire de l'activer au niveau du web.config de chaque application web concernée. Pour cela, se positionner sur le tag nommé "BlobCache" dans le fichier de configuration. Il faudra préciser l'attribut "Enabled=True" et spécifier les types de fichiers pouvant être mis en cache localement sur le serveur.

 

Par la suite, il est possible de le configurer au niveau du Back-Office de votre site SharePoint en se positionnant sur "Configure output cache settings".
Il est de même possible de réaliser ceci par modèle objet SharePoint si vous souhaitez l'activer lors du provisioning de votre site.
Pour se faire, il faudra utiliser le code managé suivant:

 

// Enable output cache
 SiteCacheSettingsWriter cacheSettingsWriter = new SiteCacheSettingsWriter(site);
 cacheSettingsWriter.EnableCache = true;
 // Set Public internet (purely anonymous) for anonymous page
 cacheSettingsWriter.SetAnonymousPageCacheProfileId(site, 2);
 // Set profile Intranet (collaboration site) for authenticated page
 cacheSettingsWriter.SetAuthenticatedPageCacheProfileId(site, 4);
 cacheSettingsWriter.Update();

 

A présent, votre cache est à présent activé et vous pourrez noter l'amélioration des performances sur votre site SharePoint:

 

Office 365 ProPlus : Mise à jour Office

La sortie de Windows 10 étant à présent officielle, il était temps de faire un refresh de mon PC vers le nouvel OS Microsoft.
La qualité de celui-ci est une bonne surprise : pas de problème de mise à jour à déplorer, la plupart des logiciels est compatible, interface conviviale et performante.

 

Après l'installation de Office 365 ProPlus (version Office Click to run), quelle ne fut pas ma surprise de revoir apparaître un logiciel nommé "Lync" (remplacé en début d'année Skype for Business).

J'ai donc lancé une mise à jour de mon PC via Windows Update afin de corriger ceci, mais "Lync" était toujours présent. En fait, le problème ne vient pas de Windows mais d'un changement de mode de mise à jour des versions Office 365.

Il s'avère que sur une installation click to run de Office 2013, les mises à jour Office ne descendent plus par Windows Update comme précédemment. Pour procéder à la mise à jour, il est nécessaire d'ouvrir un logiciel Office (Word,Excel,...) puis d'aller dans "Fichiers"/"Compte office" et sélectionner "Mise à jour"...