Serveur d'impression

Utilisation de PowerShell pour importer des photos de profil avec Importation Active Directory et SharePoint Server 2013/2016/2019 – Bien choisir son serveur d impression

Le 3 mai 2019 - 6 minutes de lecture

Impression | posté le vendredi 02 février 2018 à 19:02

L’une des demandes les plus courantes que j’ai reçues au cours des dernières années a été de savoir comment utiliser PowerShell pour obtenir des photos d’utilisateur à partir d’Active Directory (ou de tout autre emplacement réel) dans le magasin de profils utilisateur SharePoint. Avec la suppression de la synchronisation de profil utilisateur (UPS) dans SharePoint 2016, ce besoin a considérablement augmenté. Pour la plupart des clients du marché intermédiaire, il s’agit d’une exigence essentielle. Il n’est pas pratique de mettre en œuvre Microsoft Identity Manager (MIM) à cette fin.

Avant la publication de SharePoint 2016, j'ai passé beaucoup de temps à tenter de convaincre les pouvoirs en place que l'importation Active Directory (ADI) devait inclure cette fonctionnalité pour atténuer les problèmes de mise à niveau, etc. Hélas, l’objectif était de supprimer UPS, et non de combler les lacunes laissées par son retrait.

Quoi qu'il en soit, si ADI peut répondre aux besoins de l'entreprise, à l'exception de User Photos, MIM n'est absolument PAS la bonne solution. Du point de vue architectural, du point de vue de la gestion opérationnelle et, surtout, du point de vue des coûts, c’est tout simplement idiot. C'est pourquoi j'ai toujours suggéré que, pour cette exigence, un script PowerShell simple, une planification régulière soit l'approche appropriée.

Maintenant, en substance, un tel script est simple. Nous parcourons Active Directory, obtenons les photos à partir de thumbnailPhoto, puis nous les plaçons dans le dossier Images de profil de l'hôte Mon site. En fonction des exigences opérationnelles, nous pouvons améliorer cette capacité de base avec la journalisation et la mise en cache des images sur le système de fichiers, etc.

Active Directory nous fournit deux API clés pour ce travail. Nous pouvons utiliser les API de base exposées dans le module ActiveDirectory PowerShell ou utiliser DirSync. DirSync est plus compliqué, mais nettement préférable car il fournit un journal des modifications ainsi que des opérations beaucoup plus efficaces en général. C’est en fait la façon dont ADI fonctionne sous les couvertures (une autre raison pour laquelle c’est ridicule du point de vue technique pourquoi ADI n’inclut pas cette possibilité). Il n’ya donc rien à installer sur le boîtier, alors qu’AD PowerShell nous oblige à installer les outils RSAT et à importer le module, ce qui n’est généralement pas fait sur un serveur SharePoint. Cependant, nous avons besoin de la réplication des modifications de répertoire pour pouvoir utiliser le journal des modifications. Utilisez le même compte que vous utilisez pour effectuer ADI et vous êtes tous ensemble.

Mais alors nous arrivons à SharePoint! 🙂 Comme toujours, ça devient plus “intéressant”….

Tout d’abord, le dossier «Profile Pictures». Ce mauvais garçon n'est pas créé avant la création de la toute première photo de profil. Et il se trouve dans le dossier "Photos de l'utilisateur". i.e. https://mysitehost.fabrikam.com/User Photos / Images de profil. Quelqu'un, quelque part, pensa que c'était intelligent. Ce n'est pas. En tous cas. pas trop grave. nous devons nous adapter à sa vérification et, dans le cas contraire, à sa création.

Deuxièmement, le nom de fichier des images, avant qu'elles ne soient «traduites» en images utilisables par Update-SPProfilePhotoStore. C'est un problème réel car ils incluent un "ID de partition par défaut". Il n'y a pas d'API publique pour découvrir cette valeur. Il existe un moyen de l'obtenir, mais cela implique d'appeler un service Web hérité qui n'est pas pris en charge (c'est ainsi que Microsoft le fait lui-même dans l'agent de gestion MIM SharePoint). La bonne nouvelle est que ce GUID est le même sur chaque déploiement SharePoint 2013/2016/2019. Nous pouvons donc simplement le glisser en tant que variable et l'utiliser pour splatter le nom du fichier. Mais nous devons être conscients que cela signifie que la solution ne fonctionnera qu'avec un UPA non partitionné. et bien sûr, il est possible que ce GUID change à l'avenir.

Nous devons également exécuter Update-SPProfilePhotoStore une fois l’importation terminée pour créer les trois vignettes utilisées par SharePoint.

Nous devons également nous assurer que le script d'importation et Update-SPProfilePhotoStore sont exécutés sur une machine hébergeant l'instance de service de profil utilisateur. Ce dernier ne lèvera aucune exception s'il est exécuté ailleurs, il ne fait rien et quitte!

Avec tout cela dit en termes de brève explication, le script de base de Adam Sorenson peut être trouvé à https://gallery.technet.microsoft.com/SharePoint-User-Profile-928b39c0. Vous pouvez mettre à jour les variables initiales en fonction de votre environnement. Vous aurez également besoin d'un DNLookup.xml «factice», comme décrit à l'adresse https://blogs.technet.microsoft.com/adamsorenson/2017/05/24/user-profile-picture-import-with-active-directory-import /.

Maintenant, oui, il y a beaucoup de choses qui ne vont pas avec ce script. Certains sont la faute de SharePoint, comme indiqué précédemment, et d'autres concernent davantage la gestion opérationnelle. Mais le point de poster est que c'est un point de départ pour lequel vous pouvez construire ce dont vous avez besoin. Par exemple, vous souhaiterez peut-être ne pas mettre les images en cache sur le système de fichiers (bien que cela soit une bonne idée pour les grands environnements). De plus, vous voudriez nettoyer PowerShell et / ou en faire un module, etc. Faites également attention au filtre LDAP utilisé, cela peut ne pas correspondre à vos besoins. Je voudrais également supprimer l'horrible API héritée pour les informations d'identification alternatives. Sinon, ce script est en fait plus ou moins identique au mien, si ce n’est que j’ai divisé la collecte de photos pour prendre en charge les URL ainsi que les vignettes, et j’ai utilisé l’API «privée» pour l’ID de partition car je recherchais un manière d’encourager les pouvoirs en place à fournir une API publique (et avait besoin d’une solution pour Multi Tenant).

Si l'intérêt est suffisant, je publierai mon module PowerShell mais ce script est tout ce dont vous avez besoin pour commencer…

s.

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.