Fonctionnement du people picker avec les comptes de messagerie

Tout d’abord, d’un point de vue Active Directory, il y a deux types de compte qu’il faut différencier :

  • Un compte de messagerie
    • Ni plus ni moins qu’une boîte de courriel partagé;
    • Désactivé dans l’AD par défaut lors de la création;
    • Ne peut pas être utilisé pour accorder des autorisations.
  • Un groupe de sécurité
    • Activé dans l’AD par défaut lors de la création;
    • Peut être utilisé pour accorder des autorisation.

Scénario

Des utilisateurs souhaiteraient recevoir des notifications par courriel (alertes) directement dans la boite courriel d’un compte de messagerie lorsqu’un nouvel élément est ajouté à une liste. Il n’est pas souhaitable d’utiliser le groupe de sécurité car dans ce cas, chaque individu recevrait un courriel dans sa boîte courriel.

Solution

Le compte de messagerie n’est pas disponible dans le champ « People picker » car celui-ci est désactivé. Il faut donc activer le compte dans l’AD et attendre la synchronisation des profils avant de pouvoir l’utiliser.

Lorsque ce compte est activé et qu’on l’utilise dans une collection de site, SharePoint conserve une copie dans la liste d’informations utilisateurs caché de la collection de site.

Voici en résumé comment fonctionne le people picker :

The People Picker control is used to search/find and select groups (as well as people and claims).  Where does the picker control pull its display data from?  SharePoint first checks if the user exists in the site collection (hidden User Information List), if it does not then it retrieves the user info from Active Directory and adds the user into the site collection. 

Donc, une fois que le compte a été utilisé une première fois, on peut le désactiver et celui-ci continuera d’être disponible dans le people picker de cette collection de site. Par contre, si vous devez l’utiliser dans plusieurs collections de site, il serait préférable de le laisser activé. D’un point de vue licence, les administrateurs AD préfèrent limiter le nombre de compte actif.

 

Un tenant consolidé vs une conception multi-tenant par département dans O365?

Introduction

Pour les grandes organisations ayant de nombreux départements et/ou des organismes associés, le choix de conception de tenant peut avoir beaucoup d’impact à long terme. J’ai récemment eu à évaluer les différents scénarios possibles pour un organisme associé à mon organisation. Dans ce billet, je vais énoncer les principaux avantages et inconvénients de la conception multi-tenant par département en comparaison à ceux de la conception par tenant consolidé.

Définition

Tenant: Un tenant Office 365 est en quelque sorte un espace locatif dans lequel on retrouve plusieurs applications cloud, ex:  Exchange,  SharePoint Online et autres.

Tenant consolidé: Un seul tenant Office 365 pour l’ensemble de l’organisation.

Multi-tenant par département: Un tenant principal pour l’organisation et des tenants supplémentaires pour les autres départements et/ou organismes associés.

Tenant consolidétenantConsolidé

Source

 

Principaux avantages :

  • Gestion TI centralisé des licences;
  • Jusqu’à 900 domaines différents supportés;
  • Règles de gouvernance s’appliquent à l’ensemble du tenant;
  • Pas de limitation avec Exchange, OneDrive et Skype;
  • Pas d’impact avec la recherche et le magasin de termes SharePoint qui sont liés à un seul tenant;
  • Simplicité et coûts moindre au niveau de la synchronisation des comptes Active Directory pour un seul tenant.

Principaux inconvénients :

  • Flexibilité réduite au niveau de la gestion des licences pour les départements et organismes associés;
  • Pas de régionalisation des données.

Multi-tenant par département

multiTenant

Source

Principaux avantages :

  • Gestion TI décentralisé des licences;
  • Régionalisation des données;
  • Flexibilité au niveau de la gestion des licences pour les départements et organismes associés.

Principaux inconvénients :

  • Possibilité d’écarts par rapport aux règles de gouvernance entre les tenants;
  • Impossibilité de partager le même nom de domaine dans 2 tenants différents;
  • Nécessite un administrateur global par tenant;
  • Limitations avec Exchange, OneDrive et Skype;
  • Impact avec la recherche et le magasin de termes SharePoint qui sont liés à un seul tenant;
  • Complexité et coûts supplémentaires au niveau de la synchronisation des comptes Active Directory pour chaque tenant.

Conclusion

Un tenant consolidé semble être le meilleur choix global, sauf si vous avez besoin d’avoir vos données dans des régions spécifiques par département/organisme. Bien évidemment, ce n’est pas toujours noir ou blanc. Il faut prendre les besoins d’affaires de vos différents départements/organismes et mettre le tout en perspective avec la vision de votre organisation.

Références

Utiliser une validation de colonne pour valider l’adresse courriel de vos contacts

Un des problèmes courant lorsqu’on met en place une liste de contact est que les données ne sont pas toujours uniformes et valides. Puisque certains contacts n’ont pas d’adresse courriel, on ne peut pas mettre ce champ obligatoire. Cependant, on peut ajouter une validation au niveau de la colonne.

On peut ajouter une formule directement dans la colonne de type « Une seule ligne de texte » nommé « Courrier électronique » :

ValidationColonne.PNG

Les fonctions utilisés dans la formule doivent être dans la même langue que votre site (Français dans ce cas) :

=SI(ESTVIDE([Courrier électronique]);VRAI;
ET(
ESTERREUR(TROUVE(" "; [Courrier électronique];1));
ESTERREUR(TROUVE(";"; [Courrier électronique];1));
ESTERREUR(TROUVE(".."; [Courrier électronique];1));
ESTERREUR(TROUVE(".@"; [Courrier électronique];1));
SI(ESTERREUR(TROUVE("@"; [Courrier électronique];2)); FAUX;
ET( ESTERREUR(TROUVE("@";[Courrier électronique]; TROUVE("@"; [Courrier électronique];2)+1));
SI(ESTERREUR(TROUVE("."; [Courrier électronique]; TROUVE("@"; [Courrier électronique];2)+2)); FAUX;
TROUVE("."; [Courrier électronique]; TROUVE("@"; [Courrier électronique];2)+2) < NBCAR([Courrier électronique])
)
)
)
)
)

La formule ci-haut n’est pas aussi restrictive qu’une expression régulière mais elle constitue tout de même un bon départ :

  • Ignore la validation si le champ est vide;
  • Ne doit pas contenir d’espace;
  • Ne doit pas contenir le caractère « ; »;
  • Ne doit pas contenir deux points consécutifs;
  • Ne doit pas contenir un point précédent le @;
  • Ne doit pas contenir de plusieurs @;
  • Ne dois pas commencer par un @;
  • Ne dois pas se terminer par un « . »;
  • Doit contenir au moins un « . » après le @;
  • Doit contenir au moins un caractère entre le « . » et le @.

Par la suite, entrer le message d’erreur désiré et tester le tout :

ValidationColonneInvalide

 

Alternative à la WebPart Recherche de contenu (CSWP) lorsque celle-ci n’est pas disponible dans votre abonnement

Lorsque j’ai présenté ma session « Construisez votre intranet avec Microsoft Office 365 sans code », j’ai mis de l’avant la composante WebPart Recherche de contenu (CSWP) pour la majorité des composantes réalisées. On m’a alors posé la question suivante : « Que faire si mon client dispose uniquement d’un abonnement E1 et que cette composante de recherche n’est pas disponible? »

C’est une excellente question et effectivement la WebPart Recherche de contenu (CSWP) est uniquement disponible dans les abonnements Office 365 Enterprise E3, E4, E5, A3, A4, G3, G4. Cependant, on peut tout aussi bien utiliser la WebPart Résultats de la recherche qui est disponible dans tous les types d’abonnements O365 et sur SharePoint Server. Il suffit d’adapter légèrement les modèles d’affichage afin que ceux-ci fonctionnent.

Ce billet explique comment modifier un modèle d’affichage destiné au composant WebPart Recherche de contenu (CSWP) afin soit disponible dans le composant WebPart Résultats de la recherche.

Références

How to enable Content Search Web Part Display Templates for Search Result Web Part

Content Search Web Part vs Search Results Web Part

Search innovations for site and portal design in SharePoint Online

Retour sur le aOS Canadian Tour (QUÉBEC)

Introduction

Le 6 février 2017 avait lieu à l’Hôtel Palace Royal l’événement aOS Canadian Tour 2017. J’ai eu la chance de participer à la première journée de cet événement en tant que conférencier avec plusieurs autres experts provenant d’Europe et du Canada.

L’événement

La Tournée Canadienne aOS est une conférence qui à eu lieu dans quatre villes Canadiennes sur une période de cinq jours. À compter du 6 février 2017, ils ont fait la route en autobus de Québec vers Montréal, Ottawa et jusqu’à Toronto.

L’événement complet a présenté plus de 60 sessions à près de 360 participants et a permis le partage des connaissances et de l’expertise sur les défis rencontrés par la majorité des entreprises lors de l’intégration des technologies Azure, Office 365 et SharePoint dans leurs environnements technologiques.

Ma session

aos

Titre :  Construisez votre intranet avec Microsoft Office 365 sans code

Public: Tous

Dans le passé, de nombreuses organisations réalisaient leurs intranets et hébergeait celui-ci à l’interne.
La tendance à changé et les organisations s’orientent maintenant vers le cloud pour répondre à leurs besoins d’intranet.
Lors de cette session nous allons tenter de répondre aux questions suivantes : « Est-ce que notre intranet doit être construit avec Microsoft Office 365 ? Est-ce possible de réaliser un intranet sans développement majeur? ».
Dans cette session, Samuel Lévesque abordera :
• Les avantages d’utiliser Microsoft Office 365 pour un intranet;
• Les meilleures pratiques à considérer;
• Des composantes clés en main sans code.
Si vous ne pouviez y être voici la présentation :

 

Les autres sessions

Plusieurs autres conférenciers ont présentés des sessions très intéressante.
Pour ma part, j’ai particulièrement apprécié la présentation de Joelle Ruelle « Domptez votre tenant Office 365 », dans laquel celle-ci a présenté plusieurs scénario pour administrer un tenant avec entre autre du PowerShell.

Conclusion

Un succès sans équivoque pour la premiere édition de l’événement complet que l’on espère revoir l’an prochain! Merci à tous les commanditaires, participants et au comité organisateurs.

Ajouter des formes dans Visio pour vous aider à créer des représentations visuelles de déploiements Office 365

Visio est un outil indispensable pour créer des représentations visuelles. La création de représentations visuelles de vos architectures Microsoft Office et Office 365, y compris Microsoft Exchange, SharePoint et Skype for Business est un moyen utile de communiquer votre déploiement.

Cependant, même avec la dernière version de Visio 2016, les formes disponibles avec les gabarits de base sont vraiment limitées :

visioformes

Il est cependant possible d’ajouter d’autres formes afin de rendre vos représentations visuelles plus intéressante .

Voici un aperçu de plusieurs formes disponibles suite au téléchargement :

visioformesnew1visioformesnew2visioformesnew3

telecharger-bouton

Il suffit de copier les fichiers *.vss dans votre dossier « C:\Users\\Documents\Mes formes ».

Ensuite, ces formes seront disponible sous « Mes formes ».

Ces nouvelles formes fournissent plus de 300 icônes incluant des :

  • représentation de serveurs;
  • rôles de serveur;
  • services;
  • applications.

Il est possible de les utiliser dans les diagrammes d’architecture, des tableaux, etc… Ces icônes sont principalement centrées sur les déploiements de Microsoft Exchange Server, Microsoft Skype pour les entreprises et Microsoft SharePoint Server ainsi que les déploiements hybrides Office 365 des technologies susmentionnées.

Comment configurer Google Analytics dans SharePoint sans avoir un domaine complet (FQDN) ?

Voici mon dernier vidéo publié sur le site Channel 9 :

Dans plusieurs déploiements SharePoint On-Premise, des URL comme ceux-ci sont utilisés :

Bon nombre d’articles indiquent qu’il n’est pas possible de configurer Google Analytics lorsque le URL ne contient pas un nom de domaine complètement qualifié (FQDN) :

Pour pouvoir générer des rapports dans Analytics aux fins de l’utilisation par votre intranet d’entreprise, votre réseau d’entreprise doit pouvoir accéder au fichier JavaScript de Analytics (analytics.js). Essayez de charger le fichier dans votre navigateur à l’aide de l’un des liens suivants :

Si vous pouvez accéder à l’une de ces URL à partir de votre réseau interne, vous pouvez utiliser Analytics pour collecter les données provenant de votre intranet. Ce dernier doit également être accessible via un nom de domaine complet tel que http://intranet.example.com. Le fichier JavaScript de Analytics ne fonctionnera pas si votre intranet est uniquement accessible à l’aide d’un nom de domaine incomplet, tel que http://intranet.

Source : https://support.google.com/analytics/answer/1009688?hl=fr

Malgré tout cela, je vous rassure c’est possible d’obtenir des statistiques malgré cette contrainte. Il suffit de « flouer » Google Analytics afin qu’il pense que notre URL est un FQDN lors de l’ajout d’une propriété.

Technologies utilisées

  • SharePoint 2016 On-Premise (Hébergé dans Azure)
  • SharePoint Designer 2013
  • Google Analytics

Meilleurs pratiques

À des fins de démonstration seulement, la page maître a été modifié directement. Sachez toutefois que la meilleure pratique consiste plutôt à effectuer l’injection JavaScript du script de suivi afin d’éviter d’avoir à maintenir une page maître personnalisé.

Si vous avez apprécié, je vous invite à commenter et à évaluer ce vidéo !