Interpréter le rapport d’évaluation des pages classiques

Une évaluation classique exporte les fichiers CSV partagés et spécifiques à la page. Sur Windows, la commande par défaut report crée ClassicAssessmentReport.pbitégalement .

Ces conseils couvrent les pages et les vues de couverture d’analyse. Le modèle classic partagé contient d’autres onglets de composant et de compatibilité, mais ils sont en dehors de cette étendue d’évaluation de page.

Valider d’abord la couverture de l’analyse

Avant d’interpréter la préparation de la page, vérifiez que l’étendue attendue s’est terminée :

1. Utilisez Vue d’ensemble de l’analyse, scans.csv, et history.csv pour passer en revue l’état et les messages de l’évaluation.
2. Utilisez sitecollections.csv et webs.csv pour identifier les emplacements défaillants, inachevés ou inhabituellement lents.
3. Vérifiez si l’évaluation a utilisé une étendue de locataire complète, --siteslistou --sitesfile.
4. Passez en revue classicpageauditusage.csv les status de couverture avant d’utiliser le nombre d’activités.

Une évaluation qui s’est terminée peut toujours contenir des échecs de site ou web. Traitez les emplacements manquants comme un écart de couverture, et non comme une découverte de l’absence de contenu classique.

Pour connaître les schémas de fichiers communs et les clés de jointure, consultez Référence CSV d’évaluation commune.

Hiérarchiser les pages

L’onglet Pages power BI actuel utilise les champs d’inventaire de page de base, tels que le type de page, l’URL, la date de modification et le code de correction.

Utilisez classicpages.csv pour les champs de préparation enrichis et pour segmenter les pages par :

• Type de page.
• Status de la page d’accueil.
• Date et modificateur de la dernière modification.
• Nombre de composants WebPart.
• Pourcentage de mappage.
• Types de composants WebPart non mappés.

Combinez cet inventaire avec classicpageauditusage.csv pour distinguer les pages fréquemment utilisées du contenu obsolète ou à faible utilisation.

Le modèle Power BI incorporé actuel n’inclut pas les champs cumulatifs de la page d’accueil enrichie, du composant WebPart, du mappage, de l’audit ou de la préparation des pages. Analysez ces champs directement dans les fichiers CSV ou étendez le modèle Power BI avant de les utiliser dans des visuels.

L’utilisation de l’audit est un signal de planification, et non un compteur d’analytique web brute. Toujours case activée QueryStatus:

Lorsque la requête d’audit d’un site a réussi, l’absence de ligne de page signifie qu’aucun événement correspondant n’a été retourné pour cette page dans la fenêtre demandée. Traitez une ligne absente comme une activité nulle uniquement après la confirmation de la couverture du site.

Si SkipReason commence par QueryTimeout, Microsoft Purview n’a pas terminé la requête pendant l’attente de 90 minutes de l’évaluation. Lorsqu’aucun bloc d’audit ne réussit, la ligne a QueryStatus=failedtraité ses nombres zéro comme une couverture ayant échoué, et non comme une preuve de l’absence d’activité. Cela est différent de NoPermission, ce qui indique une autorisation d’audit manquante.

Comprendre la couverture du type de page

Les pages Wiki, WebPart et Publication reçoivent une analyse détaillée de l’extraction et du mappage des composants WebPart.

Les pages de blog, ASPX et Delve Blog sont découvertes et enregistrées, mais ne reçoivent pas le même enrichissement de préparation de mappage. N’interprétez pas une valeur de mappage par défaut ou vide pour ces types de pages comme une analyse de préparation terminée.

Les pages de blog Delve apparaissent dans classicpages.csv , mais ne sont pas incluses dans les correctifs cumulatifs actuels du nombre de pages web et de sites.

Interpréter les résultats du mappage

MappingPercentage est le pourcentage de composants WebPart extraits qui ont un mappage utilisable dans le modèle de mappage incorporé :

• Une page sans composants WebPart extraits est 100 % par convention.
• Un résultat de 100 % signifie que tous les types de composants WebPart extraits ont des mappages. Il ne garantit pas la parité visuelle, de données, d’autorisation ou de comportement métier après la transformation.
• Une valeur inférieure à 100 et WebPartCount supérieure à zéro identifie un ou plusieurs types de composants WebPart qui nécessitent une correction, un remplacement ou un mappage personnalisé.
• Pour un wiki, un composant WebPart ou une page de publication, WebPartCount=0 et MappingPercentage=0 peut indiquer que l’extraction a échoué avant l’exécution du calcul de mappage. Passez en revue le journal d’évaluation pour Failed to assess the web parts of classic page.

Utilisez classicpagewebparts.csv pour la décision par page :

• IsMappable signifie que le composant WebPart a un mappage utilisable non vide.
• WebPartProperties est renseigné uniquement lorsque --exportwebpartproperties a été sélectionné.
• Les valeurs row, column, zone, order, hidden et closed permettent d’expliquer la mise en page active.

Utilisez classicwebpartunique.csv pour identifier les types de composants WebPart qui affectent de nombreuses pages. InMappingFile est plus faible que IsMappable: cela signifie uniquement que le type a une entrée dans le fichier de mappage.

L’implémentation actuelle de l’évaluation traite délibérément les mappages de la communauté pour ScriptEditorWebPart et SimpleFormWebPart comme étant indisponibles. Il ne prend pas non plus en charge un remplacement de fichier de mappage sur disque.

Ce résultat d’évaluation signifie que le modèle de préparation par défaut n’approuve pas ces composants WebPart. La transformation PnP peut éventuellement acheminer le contenu de l’éditeur de script et du formulaire simple vers l’éditeur de script communautaire open source une fois cette solution installée et -UseCommunityScriptEditor sélectionnée.

Consultez Mappages de composants WebPart classiques.

Décider de l’action suivante

Évaluez le tableau de haut en bas et utilisez la première ligne correspondante. Les décisions basées sur le mappage s’appliquent uniquement une fois la couverture et le routage de type de page terminés.

Utiliser des correctifs cumulatifs

Utilisez classicwebsummaries.csv et classicsitesummaries.csv pour identifier :

• Sites web et collections de sites avec les pages les plus classiques.
• Pages avec des composants WebPart entièrement mappables ou non mappés.
• Pourcentage moyen de mappage entre les pages qui contiennent des composants WebPart.
• Pages d’accueil qui nécessitent un backlog approuvé distinct pour la planification de l’URL, de la navigation et de la restauration.

Les correctifs cumulatifs sont utiles pour le séquencement, mais retournent aux fichiers CSV de la page et du composant WebPart avant de prendre une décision de correction.

Passer en revue les portails de publication

classicpublishingsitesummaries.csv fournit un résumé de la publication au niveau de la collection de sites. La configuration détaillée de la publication au niveau du web héritée n’est pas incluse.

Consultez Comprendre la couverture du portail de publication avant de planifier la transformation de page de publication.

Passer de l’évaluation à la transformation

Transformez le rapport en backlog de transformation :

1. Excluez les emplacements d’analyse ayant échoué ou incomplets.
2. Hiérarchisez les pages actives et les pages d’accueil importantes.
3. Regroupez les pages par type de page, disposition et combinaison de composants WebPart non mappés.
4. Résolvez les blocages courants avant de transformer une grande vague.
5. Mappez l’identité de la page CSV à la connexion source PowerShell PnP et aux paramètres d’applet de commande.
6. Transformez un exemple représentatif et validez le résultat avant de procéder à un scale-out.

Mapper des champs CSV à PnP PowerShell

L’application Évaluation est en lecture seule. Utilisez une connexion PowerShell PnP distincte avec l’autorisation de créer ou de mettre à jour des pages dans le site web source ou cible.

Poursuivre la tâche de transformation

Utilisez le mappage de champs pour approuver la ligne d’évaluation exacte et enregistrer le contenu attendu. Ensuite, suivez Transformer les pages classiques sélectionnées avec PnP PowerShell pour les protections actuelles de l’application, de l’autorisation, de l’identité source, du brouillon de sortie, de la journalisation et de la validation.

Router d’autres types de pages délibérément :

• PublishingPage: utilisez -PublishingPage, un site web cible et le modèle de mise en page de publication.
• BlogPage: utilisez -BlogPage, PageName comme identité de titre de blog et un site web cible. Les lignes de blog ne reçoivent pas l’enrichissement détaillé de mapping-readiness décrit pour les pages Wiki, WebPart et Publication.
• ASPXPage et DelveBlogPage: excluez-les de cette file d’attente de transformation automatisée ; l’évaluation de la page ne fournit pas de chemin de préparation équivalent pour eux.

Commencez par Transformer les pages classiques sélectionnées avec PnP PowerShell, puis validez chaque page transformée. Utilisez le modèle de transformation de page pour les mappages de composants WebPart personnalisés et le modèle de publication pour la publication de mises en page.

Power BI et CSV

Le modèle Power BI est une couche de visualisation sur la sortie CSV. Les fichiers CSV restent la source pour :

• Automatisation.
• Validation au niveau du schéma.
• Jointure des enregistrements de page, de composant WebPart, d’utilisation, web et de site.
• Conservation d’un instantané de preuve pouvant être examiné.

La génération de modèles Power BI nécessite Windows. La génération csv fonctionne sur Windows, macOS et Linux.

Référence

• Informations de référence csv sur l’évaluation des pages classiques
• Informations de référence sur les csv d’évaluation courantes