Lorsque l’on travaille avec un script PowerShell, il arrive que l’utilisateur connecté, même en étant administrateur de la ferme, n’ait pas les droits d’accès à telle ou telle ressource.

J’ai eu le cas, par exemple, lors de l’écriture d’un script d’inventaire de template de formulaire InfoPath. Certaines collections de sites, avec du contenu sensible, avait bridé les autorisations.

Pour obtenir tous les droits, il est alors possible d’exploiter la méthode SPSecurity.RunWithElevatedPrivileges directement en PowerShell : continuer la lecture…

Le Global Assembly Cache est un conteneur à assembly .Net global à la machine. Il permet notamment de faire coexister plusieurs versions d’une même assembly sur l’ordinateur. Consultez la page MSDN « Global Assembly Cache » pour plus d’information.

Si vous essayez d’accéder au GAC par l’explorateur Windows (c:\windows\assembly), vous ne verrez pas la structure physique du GAC, mais son contenu. Un composant COM « shfusion.dll » se chargeant en effet de présenter ces dll de manière simple et logique.

Il arrive toutefois d’avoir parfois besoin de parcourir le GAC. Le plus souvent, il s’agit de créér une référence dans Visual Studio d’un DLL du GAC, ce que Visual Studio ne propose pas par défaut.

Deux solutions s’offrent à vous : continuer la lecture…

J’ai été confronté à la demande suivante : sur un ensemble de site (des mysites en l’occurrence), un niveau d’autorisation personnalisé est défini par code lors de la création (Mysite Owner).

Une évolution a nécessité la modification de ce niveau d’autorisation pour ajouter la possibilité de créer des groupes.

La mise à jour du code créant le mysite est triviale, il aura suffi d’ajouter la permission. Mais qu’en est-il des sites déjà créés ?

La solution est assez simple. Le script Powershell suivant remplira ce rôle :

Param(
    [Parameter(Mandatory=$true)]
    [string]$url
    )

Add-PSSnapin Microsoft.SharePoint.PowerShell -EA 0

$mySites = Get-SPSite -WebApplication $url -Limit All | ? { $_.RootWeb.WebTemplate -Match "SPSPERS" }

$mySites | % {
    $site = new-object Microsoft.SharePoint.SPSite($_.Url)
    $web = $site.OpenWeb()
    $perm = $web.RoleDefinitions["MySite owner"]
    $current = [Microsoft.SharePoint.SPBasePermissions]$perm.BasePermissions
    if($perm.BasePermissions -Band [Microsoft.SharePoint.SPBasePermissions]::CreateGroups)
    {
        Write-Host "Not required for $_"
    }
    else {
        $perm.BasePermissions = $current -Bor [Microsoft.SharePoint.SPBasePermissions]::CreateGroups
        $perm.Update()
        Write-Host "Permission added for $_" -Foreground Green
    }

    $web.Dispose()
    $site.Dispose()
}

Write-Host "Press any key to exit" -NoNewLine
Read-Host

Ce script attend en entrée l’url de l’application Web hébergeant les sites mysites. Il va ensuite énumérer les collections de site de type mysite (template « SPSPERS »).

Il ajoute enfin, si nécessaire, la nouvelle permission.

Description du Developer Dashboard

Le Developer Dashboard est une nouvelle fonctionnalité introduite par Microsoft dans SharePoint 2010. Son objectif est d’aider le développeur à déboguer ses pages, à diagnostiquer l’origine de lenteur, etc.

Le Developer Dashboard propose trois niveaux d’affichage :

• On : toujours visible
• Off : toujours masqué
• OnDemand: s’ouvre/se ferme à la demande

Le Developer Dashboard peut également être restreint aux utilisateurs en appliquant un masque de permission (du type SPBasePermissions). La plupart du temps on mettra FullMask, car c’est très orienté développeur (qui a la plupart du temps tous les droits sur le poste de développement).

Plus de détails sur la page MSDN Using the Developer Dashboard.

Activer le Developer Dashboard

Plusieurs possibilités s’offrent à vous pour activer le Developer Dashboard : continuer la lecture…

Après quelque mois de non activité dans ce blog, me revoilà  Il faut que mes priorités avait un peu changé (ma belle et mes petits bouts).

Je redémarre cette année 2012 en préparant un petit projet utile aux développeurs : SharePoint Developer Toolbox.

L’objectif de ce projet est double :

• fournir à la communauté des outils/extensions orienté développement
• explorer certains concepts à des fins didactiques.

D’ailleurs vous verrez que ce projet est souvent du genre à « donner du lard aux cochons ». Sur un poste de développement, on peut se permettre de bidouiller des fichiers, patcher des web.configs, etc. Je choisis toutefois une approche ultra clean, histoire de savoir comment faire pour des sujets plus rigoureux que des outils de développements.

Le projet est open-source, et hébergé sur github: Hand.SharePoint.DeveloperToolbox.

Je vous invite à forker le projet et ajouter/modifier ce qui vous semble pertinent (vive Github!).

D’autres posts vont suivrent, qui mettront le focus sur les fonctionnalités au fur et à mesure de leur apparition.

Lorsque votre code SharePoint doit exécuter des actions pour lesquelles l’utilisateur n’a pas les droits, vous pouvez utiliser la méthode SPSecurity.RunWithElevatedPrivileges. Cette dernière attend un delegate en argument. Le delegate est alors appelé sans restriction d’autorisation, au lieu de brider les appels aux autorisations de l’utilisateur connecté. Bien entendu à utiliser avec précaution, pensez à bien verrouiller la portée de votre code.

Toutefois, l’utilisation de cette méthode peut amener quelques surprise. Par exemple, j’ai sur un de mes site SharePoint un groupe dont l’option « Qui peut consulter l’appartenance au groupe? » est positionnée sur « Membres du groupe ». Ainsi, un utilisateur non administrateur ne peut consulter les membres de ce groupe. Si dans votre code, vous devez découvrir les membres de ce groupe (on peut imaginer un scénario ou on a un groupe de personne responsable d’une étape de workflow, sans que les utilisateurs les connaissent), vous écrirez naturellement le code suivant : continuer la lecture…

Lors de l’installation (en mode graphique), le port de l’administration centrale est définit de manière aléatoire. Vous pouvez le changer si vous choisissez l’installation « Serveur Web frontal » ou « Complète ». En mode « autonome », il n’est tout simplement pas possible de le choisir au moment de l’installation.

Personnellement, entre mes machines de développement, mes machines de production au bureau, les environnements clients (dev, pré-prod, prod, etc.), j’ai choisi d’uniformiser le numéro de port pour l’administration centrale.

Il est possible très simplement et très rapidement de changer ce port. Voici la procédure. Je rappelle qu’il ne faut bien évidement pas changer le port dans IIs sous peine de délier la configuration connue par SharePoint et la configuration réelle (message à passer à vos clients… tous les admins chez les clients ne sont pas au fait de cette règle).

Bref, voici les commandes magiques pour opérer : continuer la lecture…

Pour un site Wiki qui fonctionne avec SharePoint 2010, j’ai eu besoin d’afficher sur toutes les pages les liens entrants, sans avoir besoin d’aller dans le ruban->page->afficher les liens entrants.

La solution la plus simple que j’ai trouvée est de modifier la page de disposition EnterpriseWiki.aspx avec SharePoint Designer (la modification ne sera valable que sur ce site Wiki).

Ajoutez ce bloc de code, au dessus du menu « Catégories » (par exemple):

<div class="ewiki-slink">
    <div>
    	<b>
    		<SharePoint:EncodedLiteral runat="server" text="<%$Resources:wss,incoming_links%>" EncodeMethod='HtmlEncode'/>
    	</b>
    	<div>
    		<SharePoint:FormComponent TemplateName="BackLinksDisplay" ControlMode="Display" runat="server"/>
    	</div>
    </div>
	<div>
		<b>
		<SharePoint:EncodedLiteral runat="server" text="<%$Resources:cms,enterwiki_pagerating%>" EncodeMethod="HtmlEncode"/></b>
		<div>
			<SharePointPortalControls:AverageRatingFieldControl FieldName="5a14d1ab-1513-48c7-97b3-657a5ba6c742" runat="server"/></div>
	</div>

Ce bloc est issu directement du fichier BackLinks.aspx situé dans le dossier Layouts. Le premier contrôle affiche le libellé « Les pages suivantes mènent à cette page : » (dans la langue de l’utilisateur) et le second est le contrôle qui affiche les liens entrant.

Le résultat est alors le suivant :

Backlinks wiki toujours visibles

A noter que la page d’accueil, par défaut, utilise la disposition « Page de projet de base ». Les backlinks n’apparaitrons pas si vous conservez cette disposition, à moins de répéter la manœuvre pour ce fichier.

Beaucoup d’opérations de maintenance avec SharePoint 2010 s’effectuent depuis une console PowerShell. Voici la marche à suivre pour créer une console PowerShell sur votre Poste, plutôt que d’avoir à vous connecter sur le serveur. continuer la lecture…

Microsoft organise un concours de développement autour de la plateforme Windows Phone 7 afin de promouvoir cette dernière.

Les gagnants pourront présenter leur application à un jury composé notamment de Steve Ballmer himself.

Plusieurs téléphones seront également mis en jeu pour les participants les plus productifs.

Toutes les infos sur cette page : Compétition Windows Phone 7.

A vos claviers !