Archives de mot-clé : MonSite

Que faire lorsque son nom d’utilisateur s’affiche comme propriétaire de tous les OneDrives ?

Récemment, j’ai commencé à effectuer un prototype avec OneDrive pour un groupe d’utilisateurs. Certains utilisateurs ont rapportés que mon nom d’utilisateur s’affichait comme administrateur de leur OneDrive.

Pourtant, je n’ai pas souvenir de m’avoir ajouté spécifiquement les droits sur quelconque OneDrive.

J’ai donc comparé mes autorisations au niveau du tenant avec celles des mes collègues et nous avions pourtant la même chose :

Role

On a donc essayé de créer un nouveau OneDrive et cette fois-ci mon nom ne s’affichait pas comme administrateur. Donc, ce n’est pas relié à une forme d’héritage des autorisations.

Cependant, j’avais un souvenir d’avoir « lancer » un rapport avec l’outil ShareGate pour obtenir un inventaire de nos différents OneDrive.

Problématique

C’est en creusant un peu plus là dessus que je suis tombé sur la problématique. En effet, il y a une configuration dans ShareGate qui semblait avoir été coché dans mon cas :

AutoAssign

This allows Sharegate to automatically grant your user account the required rights when you access a site collection.

Note: This option only works when you are connected directly to your SharePoint farm. This applies to the user account that is used to connect to the farm as Site Collection Administrator. Permissions added in this way will not be removed automatically. 

Source : https://bit.ly/2GiunMd

Le problème c’est qu’une fois le rapport exécuté, les droits ne sont PAS retirés ce qui cause l’effet indésirable.

Ce problème semble avoir été soumis à l’équipe de produit mais pour l’instant ce n’est pas corrigé : https://bit.ly/2pKvBJY

Solution

La solution est relativement simple si on dispose de ShareGate, on peut tout simplement sélectionner tout les OneDrives et ensuite faire « Remove from Site Collection Administrators » avec son nom d’utilisateur :

mceclip1

Source : https://bit.ly/2Iacz6h

Advertisements

Une topologie SharePoint avec une seule application web, est-ce possible ?

Introduction

Dans le passé, la topologie d’une ferme SharePoint 2010 incluait généralement plusieurs applications web de contenu. Un compte de service et un pool applicatif étaient également prévu pour héberger le MySite. Bien que ceci est totalement supporté, ceci ne répond plus aux meilleures pratiques en matière de performance. À moins d’une raison d’affaires nécessitant de le faire autrement, il serait possible d’avoir une seule application web. Dans ce billet, les différents avantages et inconvénients seront exposés ainsi que la façon de s’y prendre pour y arriver dans SharePoint 2013-2016.

Avantages et inconvénients

Avoir une seule application web apporte plusieurs avantages :

Cependant, cela vient aussi avec sa part d’inconvénients

  • Complexité au niveau de la création des certificats SSL lorsqu’il y a plusieurs domaines;
  • Nécessité d’avoir un nom de domaine dans le URL;
  • Nécessité de que l’ensemble des collections de sites utilisent les mêmes mode d’authentification.

One Web App to rule them all? Comment?

Dans SharePoint 2010, lorsqu’une entité voulais avoir sont propre URL, il fallait inévitablement passer par la création d’une nouvelle application web. Maintenant, il est possible d’avoir plusieurs URL de vanité (Vanity URL) sans créer une application web distincte en utilisant une collection de sites nommées par l’hôte (HNSC).

Étant donné que l’environnement Office 365 utilise des collections de sites nommées par l’hôte, les nouvelles fonctionnalités sont optimisées pour ces collections de sites et devraient être plus fiables.

Pour le déploiement de sites, il est recommandé d’utiliser des collections de sites nommées par l’hôte avec tous les sites situés dans une même application Web, comme illustré dans le diagramme suivant :

hnsc.jpg

Source

 

Plusieurs applications Web avec des collections de sites nommées par l’hôte ?

Si vous utilisez plusieurs applications Web, vous induisez une surcharge opérationnelle et rendez le système plus complexe. Il est recommandé d’utiliser une application Web pour les collections de sites. Toutefois, les raisons suivantes peuvent vous inciter à implémenter des collections de sites dans plusieurs applications Web :

  • Les stratégies de sécurité d’une organisation exigent des applications Web ou des pools d’applications distincts.
  • Les applications Web doivent être configurées différemment.
  • Une organisation exige l’utilisation de plusieurs groupes de proxys.

Il est plus complexe d’implémenter des collections de sites nommées par l’hôte avec plusieurs applications Web dans une batterie de serveurs en raison du travail de configuration supplémentaire que cela entraîne. Par exemple, les URL avec des sites nommés par l’hôte peuvent être réparties sur plusieurs applications Web qui partagent le même port dans une même batterie de serveurs. Ce scénario nécessite des étapes de configuration supplémentaire pour garantir le mappage des demandes avec les applications Web appropriées. Vous devez configurer manuellement les mappages sur chaque serveur Web de la batterie de serveurs en paramétrant une adresse IP par application Web, puis créer et gérer des liaisons d’en-tête d’hôte pour affecter des adresses IP uniques pour chaque site. Des scripts peuvent gérer et répliquer cette configuration d’un serveur à l’autre ; toutefois, cela rend la solution plus complexe. En outre, chaque URL unique nécessite un mappage dans le DNS. En général, si plusieurs applications Web sont obligatoires, nous vous recommandons de privilégier l’utilisation de collections de sites basées sur des chemins d’accès avec mappage des accès de substitution.

 Source

Qu’est-ce qui se passe avec mes certificats SSL ?

Un autre problème se pose lorsque vous souhaitez utiliser des certificats SSL. Il est possible d’utiliser le SSL, mais cela nécessite que vous utilisiez des certificats génériques (* .contoso.com). Les collections de sites nommées par l’hôte doivent être nommées site1.contoso.com, site2.contoso.com, etc. pour passer la validation du navigateur. C’est similaire à ce qui se produit dans vos sites SharePoint Online ex : https://tenant.sharepoint.com, où * .sharepoint.com sera le certificat SSL générique utilisé. Autrement, un certificat Multi-named (SAN) pourrait être utilisé pour site1.contoso.com et site2.contoso.com mais il devra être modifié si vous ajoutez une autre collection de site ex : site3.contoso.com.

Si vous avez plusieurs domaines, un certificat multi domaine (UCC) pourrait être utilisé :

Ex : contoso.com, fabrikam.com

Conclusion

Les avantages sont beaucoup plus nombreux d’y aller avec une topologie avec une seule application web alors il est préférable de s’en tenir aux meilleures pratiques autant que possible.