Envoyer des rapports de sauvegarde Azure par e-mail
La fonctionnalité Rapport de messagerie disponible dans Rapports de sauvegarde vous permet de créer des tâches automatisées pour recevoir des rapports périodiques par e-mail. Cette fonctionnalité fonctionne en déployant une application logique dans votre environnement Azure, qui interroge les données de vos espaces de travail Log Analytics (LA) sélectionnés, en fonction des entrées que vous faites. En savoir plus sur Logic Apps et sur ses tarifs.
Mise en route
Pour configurer les e-mails dans Rapports de sauvegarde, effectuez les étapes suivantes :
Accédez à Centre de sauvegarde>Rapports de sauvegarde, puis cliquez sur l’onglet Rapport de messagerie.
Créez une tâche en spécifiant les informations suivantes :
- Détails de la tâche : le nom de l’application logique à créer, ainsi que l’abonnement, le groupe de ressources et l’endroit où elle doit être créée. Notez que l’application logique peut interroger des données dans plusieurs abonnements, groupes de ressources et localisations (celles sélectionnées dans la section Filtres du rapport), mais qu’elle est créée dans le contexte d’un seul abonnement, d’un seul groupe de ressources et d’une seule localisation.
- Données à exporter : onglet qui contient les données à exporter. Vous pouvez soit créer une application monotâche pour chaque onglet, soit envoyer par e-mail tous les onglets à l’aide d’une même tâche, en sélectionnant l’option Tous les onglets.
- Options des e-mails : fréquence des e-mails, ID des destinataires et objet de l’e-mail.
Une fois que vous avez cliqué sur Envoyer et sur Confirmer, l’application logique est créée. L’application logique et les connexions d’API associées sont créées avec l’étiquette UsedByBackupReports: true afin qu’elles soient facilement découvrables. Vous devez effectuer une étape d’autorisation ponctuelle pour que l’application logique s’exécute correctement, comme l’explique la section ci-dessous.
Notes
La prise en charge des charges de travail de coffre de sauvegarde (Azure Database pour PostgreSQL Server, blobs Azure, disques Azure) est ajoutée aux modèles d’application logique en avril 2023. Par conséquent, si vous avez déployé ces applications logiques à une date antérieure, vous devrez les redéployer en suivant les étapes ci-dessus si vous souhaitez voir les données des charges de travail des coffres de sauvegarde dans vos rapports de messagerie.
Autoriser les connexions aux journaux Azure Monitor et à Office 365
L’application logique utilise le connecteur azuremonitorlogs pour interroger les espaces de travail Log Analytics, et utilise le connecteur Office 365 Outlook pour envoyer des e-mails. Vous devez accorder une autorisation ponctuelle pour ces deux connecteurs.
Pour accorder l’autorisation, suivez les étapes ci-dessous :
Accédez à Logic Apps sur le portail Azure.
Recherchez le nom de l’application logique que vous avez créée, puis accédez à la ressource.
Cliquez sur l’élément de menu Connexions d’API.
Deux connexions aux formats
<location>-azuremonitorlogset<location>-office365apparaissent : eastus-azuremonitorlogs et eastus-office365.Accédez à chacune de ces connexions et sélectionnez l’élément de menu Modifier une connexion d’API. Dans l’écran qui s’affiche, sélectionnez Autoriser, puis enregistrez la connexion une fois l’autorisation obtenue.
Pour vérifier que l’application logique fonctionne une fois l’autorisation accordée, vous pouvez revenir à l’application logique, ouvrir Vue d’ensemble, puis sélectionner Déclencheur d’exécution dans le volet supérieur afin de déterminer si un e-mail est bien généré.
Notes
Le compte d’expéditeur associé à l’e-mail est identique au compte utilisé pour autoriser la connexion Office 365 lors de la configuration du rapport de messagerie. Pour modifier l’expéditeur, vous devez utiliser un autre compte pour autoriser la connexion.
Contenu de l’e-mail
- Tous les graphiques et graphes qui s’affichent dans le portail sont disponibles sous la forme de contenu inséré dans l’e-mail. Apprenez-en davantage sur les informations affichées dans les rapports de sauvegarde.
- Les grilles qui s’affichent dans le portail sont disponibles sous la forme de pièces jointes au format *.csv dans l’e-mail.
- Les données de l’e-mail utilisent tous les filtres de rapport qui sont sélectionnés par l’utilisateur dans le rapport au moment de la création de l’e-mail.
- Les filtres au niveau de l’onglet, comme Nom de l’instance de sauvegarde ou Nom de la stratégie, ne sont pas appliqués. La seule exception à cela est la grille Optimisations des conservations sous l’onglet Optimiser, où les filtres de conservation Quotidienne, Hebdomadaire, Mensuelle et Annuelle des points de conservation sont appliqués.
- L’intervalle de temps et le type d’agrégation (pour les graphiques) sont basés sur l’intervalle de temps que l’utilisateur a sélectionné dans les rapports. Par exemple, si l’intervalle de temps sélectionné correspond aux 60 derniers jours (avec le type d’agrégation hebdomadaire) et que la fréquence des e-mails est quotidienne, le destinataire recevra un e-mail tous les jours avec des graphiques regroupant les données qui ont été collectées au cours des 60 derniers jours, avec une agrégation au niveau hebdomadaire.
Résolution des problèmes
Si vous ne recevez pas les e-mails comme prévu, même après avoir correctement déployé l’application logique, vous pouvez suivre les étapes ci-dessous pour résoudre les problèmes de configuration :
Scénario 1 : Aucun e-mail reçu (réussite ou échec)
Ce problème peut se produire parce que le connecteur API Outlook n’est pas autorisé. Pour autoriser la connexion, suivez les étapes d’autorisation fournies ci-dessus.
Ce problème peut également se produire si vous n’avez pas spécifié le bon destinataire lors de la création de l’application logique. Pour vérifier que le bon destinataire a été spécifié, vous pouvez accéder à l’application logique à partir du portail Azure, ouvrir le concepteur d’application logique, puis sélectionner l’étape E-mail pour déterminer si les bons ID d’e-mail sont utilisés.
Scénario 2 : Réception d’un e-mail indiquant que l’application logique n’a pas pu s’exécuter jusqu’au bout
Pour résoudre ce problème :
- Accédez à l’application logique à partir du portail Azure.
- Au bas de l’écran Vue d’ensemble, la section Historique des exécutions apparaît. Vous pouvez ouvrir la dernière exécution pour voir quelles étapes du workflow ont échoué. Les causes possibles sont les suivantes :
- Le connecteur des journaux Azure Monitor n’a pas été autorisé : pour résoudre ce problème, suivez les étapes d’autorisation fournies ci-dessus.
- Erreur dans la requête Log Analytics : si vous avez personnalisé l’application logique avec vos propres requêtes, une erreur dans l’une des requêtes Log Analytics peut provoquer l’échec de l’application logique. Vous pouvez sélectionner l’étape concernée pour voir l’erreur qui empêche la bonne exécution de la requête.
Scénario 3 : Erreur lors de l’autorisation de la connexion à l’API Microsoft 365
Lors de la tentative d’autorisation de connexion à l’API Microsoft 365, vous pouvez voir une erreur de type Échec du test de connexion. Erreur « L’API REST n’est pas encore prise en charge pour cette boîte aux lettres ». Cette erreur peut se produire pour les comptes de bac à sable (test) ou pour les comptes qui se trouvent sur un serveur de messagerie dédié (local).
Cette erreur peut se produire si la boîte aux lettres se trouve sur un serveur Microsoft Exchange dédié et qu’elle n’est pas une boîte aux lettres Office 365 valide. En savoir plus
Pour obtenir une boîte aux lettres Office 365 valide, envoyez une demande à votre administrateur général ou administrateur Exchange pour migrer le compte de boîte aux lettres. Les utilisateurs qui ne disposent pas d’autorisations d’administrateur ne peuvent pas migrer les comptes. Pour plus d’informations sur la procédure de migration du compte de boîte aux lettres, consultez Procédure de migration des données de boîte aux lettres à l’aide du centre d’administration Exchange dans Office 365.
Scénario 4 : Erreur lors de l’autorisation de la connexion aux journaux Azure Monitor
Lors de la tentative d’autorisation de connexion aux journaux Azure Monitor, vous risquez de rencontrer une erreur InvalidAuthenticationTokenTenant. Cela se produit généralement lorsque vous êtes connecté à un autre locataire au moment de l’autorisation de la connexion aux journaux Azure Monitor. Vous devez vous connecter au même locataire que celui dans lequel se trouve l’espace de travail Log Analytics pour terminer correctement l’autorisation.
Pour vous assurer d’être connecté au bon locataire, vous pouvez ouvrir portal.azure.com/< id-locataire-espace-de-travail > dans le navigateur et accorder l’autorisation. Pour trouver l’ID du locataire, accédez à Azure Active Directory ->Vue d’ensemble ->Gérer les locataires.
Si le problème persiste, contactez le support technique Microsoft.
Conseils destinés aux utilisateurs GCC High
Si vous utilisez l’environnement Azure Government et que vous disposez d’un compte Office365 GCC High, vérifiez que la messagerie est correctement configurée. En effet, un point de terminaison différent, utilisé afin d’autoriser cette connexion pour les utilisateurs GCC High, doit être explicitement spécifié. Suivez l’une des méthodes ci-dessous pour vérifier la configuration et configurer l’application logique afin qu’elle fonctionne dans les environnements GCC High.
Choisissez un client :
Pour mettre à jour le type d’authentification de la connexion Office 365 via le portail Azure, procédez comme suit :
Déployez la tâche d’application logique pour les onglets requis. Consultez les étapes disponibles dans Prise en main.
Apprenez à autoriser la connexion aux journaux Azure Monitor.
Une fois le déploiement effectué, accédez à l’application logique à partir du portail Azure, puis cliquez sur Concepteur d’application logique dans le menu.
Recherchez les emplacements où l’action Office 365 est utilisée.
Vous trouverez deux actions Office 365 utilisées, toutes deux au bas du flux.
Cliquez sur Changer la connexion, puis sur l’icône d’informations.
Une fenêtre contextuelle s’ouvre pour vous permettre de sélectionner le type d’authentification relatif à GCC High.
Une fois le type d’authentification qui convient sélectionné partout où la connexion Office 365 est utilisée, la connexion doit fonctionner comme prévu.
