Contexte

Chez un de nos clients il s’est avéré qu’aléatoirement lors de l’envoi d’un mail via le client de messagerie Microsoft Outlook 2007, le mail n’était pas réellement supprimé de la boite d’envoi. En effet, lors d’un envoi de mail classique, Outlook dépose le mail dans le dossier “Boite d’envoi”, puis déplace le message dans le dossier “Eléments envoyés” quand celui ci est bien envoyé par le serveur Exchange. Dans certains cas, le mail n’est plus visible de l’utilisateur mais n’est pas effacé de la boite d’envoi pour autant.

Ce comportement se traduit par une taille de la BAL de l’utilisateur qui ne cesse de croitre alors que celui-ci supprime ou archive ses mails. De plus, des erreurs d’indexation Exchange au niveau de SCOM apparaissait régulièrement sans savoir exactement pourquoi.

Dans le cas de notre client, il a fallu trouver un moyen de détecter et supprimer les mails en boite d’envoi pour l’ensemble des utilisateurs. Cette opération étant fastidieuse est très longue, l’équipe support ou même les administrateurs ne pouvaient la réaliser. Un script a été élaborer a cet effet.

Avertissement

Ce script, bien que simple et efficace, peut poser certaines questions de droits sur la légitimité de son exécution. En effet, dans la loi Française, la boite mail d’un utilisateur est personnel, même en entreprise. Dès lors qu’un administrateur va supprimer des mails dans la boite d’un utilisateur, sa responsabilité peut être engagée. Avant de se lancer dans une telle opération, il convient d’en parler avec son supérieur et le responsable sécurité de votre entreprise. De plus, il convient de vérifier le script plusieurs fois et de bien le comprendre avant de le lancer sur votre organisation. Le script ci-dessous est fourni tel quel, son utilisation est à vos risques et périls.

Solution

Le script suivant va utiliser un compte de service pour se connecter sur l’ensemble des BAL. Attention, ce compte doit avoir tous les droits Exchange, y compris l’impersonation. Pensez à vérifier vos stratégies de throttling EWS qui peuvent vous brider pour ce script.

Ce script fonctionne de la manière suivante. Il va parcourir l’ensemble des BAL de l’organisation, vérifier la présence de mails dans le dossier de la boite d’envoi. S’il trouve des éléments datant de plus de 7 jours, alors il supprime les mails. Pour chaque BAL, il affiche le nom de la BAL dans la console. Si des mails sont détectés et supprimés, le nom est surligné en rouge. De plus, pour tracer toutes les actions, un fichier de log est créer pour savoir exactement ce qui est fait.

Ne pas oublier d’installer le composant “EWS Managed API” en fonction de votre environnement.

Conclusion

Avec ce script, une très grande quantité d’espace disque a été récupérée suite au vidage de ces dossiers pour l’ensemble des BAL. Les performances Exchange se sont elles aussi nettement améliorée et les erreurs sur l’indexation ont disparus.

Contexte

Pour plusieurs raisons, il peut y avoir plusieurs proxy dans l’entreprise. Si vous devez changer de proxy régulièrement, cette opération peut être longue et source d’erreur. J’ai été confronté a ce cas de figure.

Solution

Pour résoudre ce casse tête, j’ai fait ce script, très simple, mais qui permet de changer de proxy très simplement et rapidement.

Grâce a ce script en Powershell, je vais afficher un menu avec les différents proxy que j’ai ajouter au code au préalable. Il ne me reste plus qu’a choisir quel proxy je veux appliquer et en 1 seconde le nouveau proxy est configuré.

Conclusion

Voici comment gérer simplement plusieurs proxy sur son poste de travail. Idéal pour les administrateurs ou développeurs.

Simple et efficace non ?

Part 1 – Pré requis et création de l’application

Cet article traite l’intégration de la suite Microsoft Office 2013 dans l’outil Microsoft Deployment Toolkit 2013.

Cette première partie est consacrée à la préparation de l’installation d’Office 2013 : Vérification des prérequis, explication sur les différentes versions office, ajout de l’application dans votre Deployment Share.

Pré requis

Environnement

Afin de préparer le déploiement d’Office 2013 via MDT, merci de vérifier que les points suivants sont validés dans votre environnement :

· Composants à installer sur votre server :

             o Microsoft Deployment Toolkit 2013

             o Windows Assessment and Deployment Kit 8.1

             o Le rôle Windows Deployment Services doit être configuré et actif

· Votre Deployment Workbench doit contenir les éléments suivants :

            o Un Deployment Share actif

            o Un système d’exploitation dans la section Operating Systems

            o Une séquence de taches

· Les sources d’installation d’Office 2013 Edition Professional Plus volume licence (détaillé dans la section suivante)

D’une manière générale, vérifier que votre environnement MDT est capable de déployer votre Séquence de Tache sans erreurs.

Office 2013

Microsoft livre avec les packages d’installations de la suite Office un outil nommé Office Customization Tools (OCT). Cet outil est dédié à la personnalisation d’Office. Avec celui-ci, un assistant nous offre la possibilité de personnaliser complètement l’installation du produit. Une fois la personnalisation terminée, un fichier de réponse est créé.

Remarque : L'outil OCT n'est pas disponible avec les versions Retail d’Office.

Cette remarque impose une explication sur les différences entre les versions d’Office 2013.

Il existe deux modes de licensing : Retail et Volume License. Le premier est utilisé par les utilisateurs des secteurs grand public et petites entreprises. Le second est adapté aux grandes entreprises.

Vous trouverez ci-dessous le détail des versions Office 2013 pour chaque mode de distribution :

· Office Retail

            o Office Famille et Étudiant 2013

            o Office Famille et petite Entreprise 2013

            o Office Professionnel 2013

· Office Volume License

            o Office Standard 2013

            o Office Professionnel Plus 2013

« Comment reconnaitre un produit Office Volume License ou Retail ? »

Les éditions Volume disposent de fichiers supplémentaires dans les sources de l’installation. Pour vous assurer que vous disposez bien d’une version VL, vérifier la présence d'un répertoire « Admin » à la racine de votre média (cf. les captures ci-dessous).

Notez que le déploiement d’Office est tout de même possible avec une édition Retail, mais sans la personnalisation avec Office Customization Tool.

Vu du répertoire Office en version Retail

Vu du répertoire Office en version Volume License

Création de l’application

Ce chapitre est consacré à l’ajout de Microsoft Office dans votre environnement de déploiement. Pour démarrer, rendez-vous dans la console Deployment Workbench.

Positionnez-vous sur l’onglet Applications de votre Deployment Share, faites un clic droit et sélectionnez New Application. Une nouvelle fenêtre s’ouvre.

Type de l’application

La première étape consiste à spécifier le type de notre application. Dans mon cas, je dispose des sources d’installation du produit donc je choisis la première option : Application with source files (ce qui devrait être probablement votre cas).

Informations sur l’application

Cette seconde partie nous permet de remplir diverses informations sur notre application.

Emplacement des fichiers d’installations

À présent, indiquons le répertoire qui contient les sources d'installation. Cliquez sur browse et recherchez le répertoire.

Nom du répertoire de l’application

Cette étape permet de définir le nom du dossier qui contiendra l’application sur votre répertoire applications.

Ligne de commande

Command Détails permet de renseigner la ligne de commande permettant l’installation du produit :

· Command Line : Ici, on inscrit setup.exe car c’est le nom de l’exécutable qui lance l’installation d’office 2013.

· Working Directory : Spécifier ici l’emplacement du répertoire qui contient le fichier d’installation. Dans notre cas, setup.exe est à la racine du dossier. Il n’y a aucun changement à effectuer.

Résumé

Cette dernière étape affiche un résumé du processus d’ajout de l’application. Vous retrouverez donc l’ensemble des informations renseignées

Progress

L’assistant copie le contenu du dossier d’installation et créer ensuite l’application.

Confirmation

À la fin de la création, la mention The process completed successfuly devrait s’afficher. L’application est maintenant disponible pour vos futurs déploiements.

L’application est visible depuis la console Deployment Workbench

Je vous propose de découvrir les options permettant d’automatiser l’installation de la suite Office dans la prochaine partie.

Part 2 – Paramétrage Office 2013

Cet article traite l’intégration de la suite Microsoft Office 2013 dans l’outil Microsoft Deployment Toolkit 2013.

Paramétrage et automatisation Office 2013

Ce chapitre nécessite que vous disposiez d’une version Office 2013 en version Volume License.

Pourquoi utiliser Office Customization Tool ?

Dès maintenant, l'application Office 2013 est prête à être déployée. Cependant, il n’y a aucun mécanisme d’automatisation adapté à un déploiement via MDT. L’installation du produit sera similaire à une installation classique par un DVD (ou tout autre support) avec l’assistant d’installation. L’intérêt de cette option n’est pas adapté à un mode de déploiement de postes de travail industrialisé.

Pour automatiser l’installation de la suite Office, il est nécessaire de générer un fichier de configuration depuis l'outil Office Customization Tool.

Premier paramétrage

Pour commencer, sélectionner dans le Deployment Workbench l'application puis un clic droit. Sélectionner ensuite Properties

Dans la nouvelle fenêtre, vous constaterez qu’il y a quatre Onglets :

          o General

          o Details

          o Dependencies

          o Office Products

Onglet général (commun pour toutes les applications):

Cet onglet permet de définir les informations suivantes :

· Nom, Commentaire, Version, Langage, Répertoire source, le GUID de l’application.

Sur la partie inférieure de la fenêtre, nous trouvons deux options:

· Masquer l’application

· L’application ne sera pas visible sur la partie Applications lors d’un déploiement Lite Touch

· Activer l’application

          o Décocher cette option rend l’application indisponible pour les déploiements

Onglet Détails (commun pour toutes les applications):

Onglet Dependencies (commun pour toutes les applications):

Onglet Office Products (propre et dédié à la personnalisation des applications Office):

C’est dans cet onglet que l’automatisation du logiciel va prendre forme. Pour le moment, une grande partie des champs sont bloqués. Sélectionner le menu déroulant Office Product to Install et Cliquez sur ProPlus.

Remarque : Si vous ne voyez pas le bouton Office Customization Tooll en bas à droite de la fenêtre, c’est que vous utilisez une version Retail. Néanmoins vous pourrez tout de même configurer l’installation sans l’Office Customization Tool. (Traité dans le paragraphe ci-dessous)

Sélectionner l’élément ProPlus dans le menu déroulant. Les champs sont maintenant accessibles et paramétrables. Voici quelques une des options :

· Office language : Si votre répertoire d’installation comporte plusieurs langues, sélectionner celle que vous souhaitez installer.

· Product Key : Ajoute la licence du produit

· Display Level : Paramètre le niveau d’information durant l’installation à l’utilisateur. Trois niveaux sont disponibles :

          o None : Aucune fenêtre ne sera affichée durant l’installation

          o Basics : Le minimum d’information vous sera présenté, l’utilisateur peut suivre la progression de l’installation

          o Full : Niveau par défaut. L’intégralité de l’interface est proposée à l’utilisateur. Aucune automatisation.

· Accept EULA : accepte les termes du contrat d’utilisation

Le bouton Add permet d’ajouter un pack de langue ou une application

Il est possible d’éditer directement ce fichier en cliquant sur Edit Config.xml. La modification des paramètres met à jour le fichier Config.xml dans cette boite de dialogue

Le bouton Office Customization Tool permet de lancer l’assistant. Notez qu’il faut en amont appliquer les modifications avant de pouvoir lancer OCT, sinon le message suivant s’affichera

Je vous propose de traiter dans le troisième article les différentes options permettant de personnaliser l’installation de l’application avec Office Customization Tool.

Part 3 - Office Customization Tool

Cet article traite l’intégration de la suite Microsoft Office 2013 dans l’outil Microsoft Deployment Toolkit 2013

Office Customization Tool

Vous avez maintenant accès à la console Office Customization Tool

Au lancement de l’outil, un message vous indique qu’il faudra enregistrer le fichier MSP dans le répertoire suivant : %VotreDeploymentShare%\Applications\ Microsoft Office Professional Plus 2013\Updates
Dans le cas contraire, votre configuration ne sera pas prise en compte. Cliquez sur OK

Une fenêtre vous propose deux options :

       o Créer un nouveau fichier de configuration d’installation

       o Ouvrir un fichier existant

Gardez la première option, puis cliquez sur OK

Une nouvelle fenêtre vous propose de définir le support pour l’ouverture et la fermeture des fichiers. Laissez l’option par défaut et cliquez sur OK

Comme vous pouvez le constater, il y a quatre catégories dans l’outil Microsoft Office Customization Tool.

Première catégorie : Installation

Il est possible de spécifier :

       o Le chemin d’installation par défaut

       o Le nom de l’organisation

La page Sources réseau supplémentaires vous permet d’ajouter des partages réseau supplémentaires contenant les fichiers d’installation d’Office 2013. Ce paramétrage permet  de rendre l’installation du produit Office hautement disponible.

Sur la page suivante nommée Licences et interface utilisateur, nous pouvons :

       o Saisir la clé d’activation du produit

       o Accepter les termes du contrat de licence

       o Choisir le niveau d’affichage

       o Aucun

       o Simple

       o Complet – par défaut

Spécifier certaines options dans le cas d’une installation en Affichage de niveau               Complet

       o Avertissement de fin d’opération : Activer le récapitulatif post installation

       o Supprimer la boite de dialogue modale : ne pas afficher les messages d’erreur qui pourrait survenir dans le cas d’une installation en affichage Complet

       o Annulation interdite : Ne pas laisser la possibilité à l’utilisateur d’annuler l’installation

Vous trouverez également quatre autres pages permettant de :

       o Supprimer les anciennes installations

       o Ajouter des programmes supplémentaires en exécutant par exemple des fichiers : .exe .com .bat .src

       o Ajuster les paramètres de sécurité. Peut être utile dans le cas d’utilisation d’un outil basé sur les Macros par exemple

       o Modifier des propriétés de l’installation

Première catégorie : Fonctionnalités

Modification des paramètres utilisateurs
Il est possible de changer les paramètres de sécurité, désactiver certains éléments de l’interface utilisateur, activer/désactiver les notifications.

Mise à disposition des fonctionnalités
Cette page importante propose de gérer les produits Office qui seront: disponibles, indisponibles, imposés et aux choix de l’utilisateur. Voici l’interface permettant de choisir les fonctionnalités.

En dépliant un produit, on accède aux différents modules qui le composent.

Un clic droit sur un produit permet d’obtenir le menu suivant :

       o Tout exécuter à partir du disque dur: le produit sera installé avec les composants par défaut

       o Tout exécuter à partir du disque dur: le produit sera installé avec la totalité des composants par défaut

       o Non disponible: Le produit ne sera pas installé

Les options suivantes permettent de paramétrer l’application dans le cas d’un Niveau d’affichage = Complet

       o Masqué: L’application ne sera pas visible lors de l’installation

       o Verrouillé: L’application sera bloquée dans l’état défini dans OCT

       o Rétablir: Réinitialise les valeurs par défauts

Troisième et quatrième catégories : Contenu additionnel et Outlook

La troisième catégorie permet d’ajouter du contenu additionnel en proposant :

       o Gérer les fichiers

       o Gérer les clés de registre

       o Gérer les raccourcies

La quatrième et dernière catégorie est orientée sur la personnalisation de l’application Outlook.

Enregistrement du fichier MSP

La configuration est prête. La dernière étape consiste à enregistrer votre fichier de réponse. Sélectionner Fichier \ Enregistrer sous.

N’oubliez pas d’enregistrer le fichier de réponse au format MSP dans le répertoire Updates. Sans quoi votre configuration ne sera pas prise en compte. Par exemple : %VotreDeploymentShare%\Applications\Microsoft Office Professional Plus 2013\Updates

Déploiement

L’installation de l'application Office 2013 est maintenant personnalisée et prête à être déployée. Grâce à votre environnement Microsoft Deployment Toolkit l’installation est automatisée et capable d'être déployée en masse lors de la création d’un nouveau poste de travail.

Le mécanisme de découverte est un des principe fondamentaux de SCOM et constitue un de ses atout majeur : il permet de trouver automatiquement les objets à superviser sur tous les serveurs disposant d’un agent, sans qu’un opérateur n’ait besoin d’indiquer manuellement à chaque nouveau serveur ce qu’il faut superviser dessus.

L’inverse est également vrai : lors de la suppression d’une application ou d’un service sur un serveur, SCOM est capable de s’en rendre compte et cesse de le superviser.

Du moins, la plupart du temps : il arrive parfois que SCOM ne se rende pas compte de ces désinstallations et génère alors un grand nombre d’erreurs infondées.

Quelle en est la raison, et comment y remédier?

Prenons un exemple concret :

Un serveur hébergeait le rôle contrôleur de domaine et ce rôle a été décomissionné.

Cependant, les objets de type SysVol (et d’autres objets propres à un contrôleur de domaine comme Netlogon, NTDS..) sont toujours présents dans SCOM et toujours supervisés, et remontent donc en erreur en générant des alertes.

Si l’on remonte la piste de la découverte de ces objets, on se rend compte qu’il s’agit ici comme souvent d’une découverte en 2 étapes :
- D’abord une découverte légère ciblée sur Windows Computer qui se base sur une requête WMI pour découvrir les instances de la classe Windows Domain Controller :

- Puis une découverte beaucoup plus lourde ciblée sur ces Windows Domain Controllers et qui utilise elle un gros script VBS. C’est cette dernière qui découvre les instances des différentes classes Sysvol, Netlogon & co :

Jusqu’ici, rien d’inhabituel, ce mécanisme est très commun dans les gros management pack.

Imaginons maintenant que nous supprimions le rôle Contrôleur de Domaine d’un serveur. Que se passe t’il dans SCOM?

1. La première découverte ciblée sur Windows Computer s’exécute normalement, se rend compte que la requête WMI n’indique plus la présence d’un DC et supprime donc l’instance de la classe Windows Domain Controller pour notre serveur.

2. Comme il n’existe plus d’instance de la classe Windows Domain Controller pour notre serveur, la seconde découverte ne s’exécute plus sur ce serveur.

Seulement voilà : une découverte qui ne s’exécute pas, ce n’est pas la même chose qu’une découverte qui indique qu’un élément n’existe plus sur le serveur, et les objets Sysvol & co. ne sont donc jamais “dé-découverts”!

Comment maintenant remédier à cette situation?

Il existe un cmdlet Remove-SCOMDisabledClassInstance (Remove-DisabledMonitoringObject dans SCOM 2007) dont l’utilité est de parcourir toutes les règles de découverte présente dans votre environnement SCOM et de supprimer les instances des objets découverts par une règle donnée quand celle-ci est désactivée (via un override) pour l’objet cible de cette découverte.
Autrement dit, il suffirait de créer un Override > for a specific object of class Windows Domain Controller > Enabled = False sur la règle de découverte AD DC local discovery (DC Role), pour l’objet Windows Domain Controller correspondant à notre DC décommissionné.

Sauf que justement, cet objet n’existe plus puisque la première découverte a elle parfaitement fonctionné…
Il faut donc ruser un peu en créant un groupe qui contient l’objet Windows Computer correspondant au DC décommissionné, et d’ensuite créer notre override pour ce groupe :

Une fois l’override crée, on peut enfin exécuter le cmdlet Remove-SCOMDisabledClassInstance. Selon la taille de votre infrastructure, son exécution peut être assez longue comme vous l’indique le message en rouge (à titre d’exemple, il a pris environ 1 à 2 minutes sur un environnement contenant ~200 serveurs et autant de MP).

Et si tous s’est bien passé, les objets découverts par la règle AD DC local discovery (DC Role) sur le contrôleur de domaine décomissionné doivent maintenant avoir disparu.

Ici, nous allons voir comment créer un Switch virtuel Hyper-V de type convergé.

Sur un unique Switch virtuel Hyper-V, nous allons ici créer plusieurs Management OS qui permettront de séparer de façon logique via différences vNICs, des réseaux de type Live Migration, Cluster, Management ou autres.

Dans notre exemple, nous créons tout d'abord le switch virtuel Hyper-V.

New-VMSwitch "SwitchVirtuel" -MinimumBandwidthMode weight -NetAdapterName "NICsTeam" –AllowManagement $false

Nous allons maintenant ajouter 3 vNICs.

vNIC LiveMigration
Add-VMNetworkAdapter -ManagementOS -Name "LiveMigration" -SwitchName "SwitchVirtuel"

vNIC Cluster
Add-VMNetworkAdapter -ManagementOS -Name "Cluster" -SwitchName "SwitchVirtuel"

vNIC Management
Add-VMNetworkAdapter -ManagementOS -Name "Management" -SwitchName "SwitchVirtuel"

Dans l’affichage des cartes réseaux, trois nouvelles interfaces virtuelles sont apparues :

Maintenant afin de contrôler les différents flux réseaux véhiculés par ces interfaces, nous pouvons appliquer à chacune d’entre elle une politique de QOS.

QOS vNIC LiveMigration
Set-VMNetworkAdapter -ManagementOS -Name "LiveMigration" -MinimumBandwidthWeight 20

QOS vNIC Cluster
Set-VMNetworkAdapter -ManagementOS -Name "Cluster" -MinimumBandwidthWeight 30

QOS vNIC Management
Set-VMNetworkAdapter -ManagementOS -Name "Management" -MinimumBandwidthWeight 50

Remarque : la somme des Weights ici appliqués est de 100. (Ceci est hautement recommandé mais non requis d’avoir une somme à 100).

A l’aide de la commande Get-VMNetworkAdapter –ManagementOS vous pouvez voir les différentes vNICs créés. (non visible depuis l’interface graphique Hyper-V).

Depuis la console de gestion Failover Cluster Manager, il est facile de sélectionner les réseau devant être utilisé par le Live Migration.

Allez sur Network ==> clique droit Live Migration Settings

Et il ne vous reste plus qu’a sélectionner les interfaces réseaux souhaitées.

Maintenant pour effectuer la même opération en Powershell, veuillez taper:

Get-ClusterResourceType -Name "Virtual Machine" | Set-ClusterParameter -Name MigrationExcludeNetworks -Value ([String]::Join(";",(Get-ClusterNetwork | Where-Object {$_.Name -notmatch "LM" -and $_.Name -notmatch "VN -"}).ID))   

Dans le filtre de la commande:

Where-Object {$_.Name -notmatch "XXX" -and $_.Name -notmatch "XXX"}).ID))

Veuiller taper comme valeurs pour les XXX une partie de la chaine de caractère du nom matchant vos interfaces réseaux afin de les identifier.

Vous souhaitez modifier les propriétés générale de la ressource cluster DHCP server en Powershell.

Récupérer dans 3 variables les Paths que vous voulez définir pour :

• Database path
• Audit file path
• Backup path

$DatabasePath="j:\dhcp\db"
$AuditFilePath="j:\dhcp\logs"
$BackupPath="j:\dhcp\backup"

Récupérer maintenant votre ressource de type DHCP Service
$RessDHCP=get-ClusterResource "DHCP Server"

Nous allons maintenant manipuler des instances basées sur Microsoft.FailoverClusters.PowerShell.ClusterParameter qui va nous permettre de manipuler nos propriétés.

Modification du Database Path
$param1 = New-Object Microsoft.FailoverClusters.PowerShell.ClusterParameter $RessDHCP,DatabasePath,$DatabasePath

$param1 | Set-ClusterParameter

Modification de l'Audit File Path
$param2 = New-Object Microsoft.FailoverClusters.PowerShell.ClusterParameter $RessDHCP,LogFilePath,$AuditFilePath

$param2 | Set-ClusterParameter

Modification du Backup path
$param3 = New-Object Microsoft.FailoverClusters.PowerShell.ClusterParameter $RessDHCP,BackupPath,$BackupPath

$param3 | Set-ClusterParameter

Les propriétés sont maintenant définis.

Depuis la sortie du RU 2 pour SCOM 2012 R2 (et du RU6 pour SCOM 2012 SP1), de nouveaux widgets sont disponibles et enrichissent grandement les possibilités de dashboards.

Une bonne occasion de centraliser ce qu’il est possible de faire en la matière et de résumer brièvement les possibilités offertes par ces modules!

Widgets

Les widgets sont les éléments qui composent les dashboards, il en existe de nombreux types.

Types de dashboards

Pour rappel, un dashboard SCOM est une vue synthétique permettant d’afficher des informations de différentes manières et depuis différentes sources. 

On retrouve 4 types de disposition de dashboards :

• Affichage de widgets en colonne
• Affichage de widgets en grille
• Template de niveau de service (Service Level Dashboard)
• Template de résumé (Summary Dashboard)

Widgets en colonne

Jusqu’à 5 colonnes cote à cote contenant un widget chacune

Exemple 2 colonnes:

Exemple 4 colonnes:

Widgets en grille

Il est possible de créer des grilles de 1, 2, 3, 4, 5,6 et 9 cellules avec les dispositions suivantes:

Exemple 5 cellules:

Service Level Dashboard:

Ce dashboard est préconfiguré, on ne peut pas modifier sa disposition ni ses widgets  mais seulement leur configuration.

Il affiche un apercu de l’état de SLA pour des objets prédéfinis

Summary Dashboard:

Le dashboard summary (résumé) est préconfiguré pour créer une grille de 3 cellules contenant les widgets 'Object by Performance’, ‘Performance’ et ‘State’ : 

Vous disposez maintenant de tous les éléments pour réaliser des dashboards à la fois utiles, pertinents et agréables à l’oeil!

Note : les captures d’écran de ce billet proviennent de différentes sources web