Archives de catégorie : Architecture techno

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.

 

Advertisements

Erreur trompeuse lors de l’installation de SharePoint 2016 avec AutoSPInstaller

Introduction

Si vous avez déjà monté vous même vos serveurs SharePoint 2010/2013/2016, vous connaissez sans doute le projet Open Source AutoSPInstaller. Idéalement, il est préférable d’installer SharePoint en anglais puis d’ajouter les différents Language Packs. Vous rencontrerez également certaines erreurs si votre système d’exploitation est installé dans une autre langue que l’anglais comme expliqué dans ce billet.

Symptômes

Vous obtenez le message suivant : – Managed Metadata Service Application Proxy already provisioned.
– Granting rights to Metadata Service Application:
– DOMAIN\NomDuCompte…
PS>Erreur de terminaison (Grant-SPObjectSecurity) : « L’argument Rights n’est pas valide. Les valeurs valides sont : Magasin de termes avec accès en lecture, Magasin de termes avec accès en lecture et accès limité en écriture, Magasin de termes avec accès total »
Grant-SPObjectSecurity : L’argument Rights n’est pas valide. Les valeurs valides sont: Magasin de termes avec accès en
lecture, Magasin de termes avec accès en lecture et accès limité en écriture, Magasin de termes avec accès total
Au caractère E:\AutoSPInstaller\SP\AutoSPInstaller\AutoSPInstallerFunctions.ps1:2536 : 21
+ … Grant-SPObjectSecurity $metadataServiceAppSecurity -Princ …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument : (Microsoft.Share…tObjectSecurity:SPCmdletGrantObjectSecurity) [Grant
-SPObjectSecurity], SPException
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletGrantObjectSecurityPS>Erreur de terminaison () : «  – Error provisioning the Managed Metadata Service Application »
>> Erreur de terminaison () : «  – Error provisioning the Managed Metadata Service Application »
————————————————————–
– Script halted!
– Error provisioning the Managed Metadata Service Application
Press any key to exit…

Cause

À première vue, l’erreur semble indiquer un problème de d’autorisations puisque l’applet de commande utilisé est Grant-SPObjectSecurity et que l’erreur semble être l’argument « Rights ».

Cependant, si on regarde attentivement le fichier AutoSPInstallerFunctions.ps1 qui s’occupe de créer le service Managed Metadata Service Application à la ligne suivante :
Grant-SPObjectSecurity $metadataServiceAppSecurity -Principal $accountPrincipal -Rights « Full Access to Term Store »
On voit que l’argument « Rights » est en anglais « Full Access to Term Store » alors que dans le message d’erreur on voit que les valeurs valides sont : « Magasin de termes avec accès en lecture, Magasin de termes avec accès en lecture et accès limité en écriture, Magasin de termes avec accès total »

Résolution

Première résolution:

Modifier la langue d’affichage de Windows afin de mettre l’anglais par défaut :

Langue

Deuxième résolution :

Modifier les lignes « Grant-SPObjectSecurity » du fichier AutoSPInstallerFunctions.ps1 afin de mettre la valeur du paramètre « Rights » correspondant à la langue d’affichage de votre système d’exploitation.

Exemple :

En-Us
Grant-SPObjectSecurity $profileServiceAppPermissions -Principal $currentUserAcctPrincipal -Rights « Full Control »

Fr-Ca

Grant-SPObjectSecurity $profileServiceAppPermissions -Principal $currentUserAcctPrincipal -Rights « Contrôle total »

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

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.

Pourquoi est-il impossible d’ajouter certaines Apps à partir du SharePoint Store ?

Introduction

Nous avons récemment configuré le Service de gestion des applications chez un de nos clients pour permettre l’ajout d’applications (« Apps ») dans un site de développement. Cependant, certaines Apps étaient grisées et impossible à ajouter dans un site.

Exemple  :

AppStoreGreyedApps

 

Lors du clic sur une des Apps grisées on obtient le message « Désolé… votre serveur ne prend pas en charge cette application« .

Fonctionnalité des points de terminaisons

Après quelque recherches, j’ai trouvé sur le site de MSDN que certaines Apps par défaut ne sont pas disponibles (grisées et non mises en vente) car elles sont incompatibles avec la plupart des sites. J’ai donc activé la fonctionnalité des points de terminaisons sur la Web App. Malgré cela, les mêmes Apps n’étaient toujours pas disponibles.

Dépendances des applications de services

Puisque seulement certaines Apps étaient grisées, on s’est questionné à savoir s’ils n’y aurait pas de dépendances à d’autres applications de services.

L’article sur les dépendance d’application de MSDN montre qu’il est possible de définir des dépendances sur des Apps afin quelles ne soient pas disponible si un ou plusieurs services applicatifs ne sont pas installés sur la ferme.

Une Apps pourrait donc avoir une dépendances sur de ces services applicatifs :

  • Access Services 2010
  • Access Services
  • Service web de métadonnées gérées
  • Services PowerPoint
  • etc…

Maintenant, comment savoir si une Apps à des dépendances?

Il est possible de regarder le trafic réseau en utilisant un logiciel comme Fiddler. Il suffit de récupérer la balise AppPrerequistes dans la réponse JSON lorsque vous affichez la page de détails de l’Apps dans le magasin.

Lorsque vous regardez le trafic réseau sur la page de détails de votre Apps, trouver un URL commençant par « /_layouts/15/storefront.aspx?task=GetAppDetails[…]&appid=[app id] et à l’intérieur de la réponse JSON pour cette demande, regardez la valeur des dépendances de l’Apps.

Vous verrez alors un GUID sous la propriété ID :

<AppPrerequisites>

<AppPrerequisite Type= »Capability » ID= »{CDD8F991-B459-4512-8048-03D5A03FF27E} » MinimumVersion= »15.0.0.0" />

</ AppPrerequisites>

Ensuite sur le site de MSDN vous aurez la correspondances pour chacun de ces GUID afin de déterminer quel service applicatif il vous manque.

Dans notre cas, puisque certaine Apps grisées n’avaient pas de dépendances, cela nous a mené à conclure qu’il ne s’agissait pas réellement d’une dépendance manquante.

Localisation des applications pour le SharePoint Store

Ensuite, un de mes collègues à eu la bonne idée de vérifier les modules linguistiques (« Languages Packs ») installés. Dans notre cas, seulement le module linguistique en français avait été installé.

Lorsque vous spécifiez une localisation pour une Apps, vous spécifié les langues que l’application prend en charge. Si vous choisissez de localiser l’application à « en-US », seuls les clients ayant SharePoint en anglais ou ayant le pack de langue anglais pourront ajouter / acheter l’application.

Une fois le module linguistique anglais installés sur notre ferme, il était maintenant possible de télécharger toutes les Apps.

Conclusion

Finalement, une Apps peut être grisée pour plusieurs raisons : les points de terminaisons ne sont pas configurés, il y a dépendances des applications de services ou un module linguistique est manquant. Dans notre cas, ce problème aurait pu être évité si l’installation du SharePoint aurait été fait à partir de la version Anglaise et que par la suite on aurait ajouté le module linguistique Français. La majorité des Apps sont publié en Anglais seulement alors je vous recommande fortement d’installer au moins le module linguistique Anglais.