Nouveautés

• Expérience utilisateur des paramètres de proxy après inscription

  Le journal d'inscription contient des messages concernant les paramètres de proxy utilisés et indiquant si les paramètres de proxy ont été enregistrés. Cela permet aux utilisateurs de vérifier les paramètres de proxy utilisés lors d'une inscription, surtout dans le cadre du dépannage d'un échec d'inscription. Il n'y a aucun changement de comportement concernant les proxies utilisés pendant l'inscription.

  L'un des trois messages suivants apparaît dans RegistrationLog.txt :

  • « Utilisation de paramètres de proxy personnalisés avec proxyServer='...', bypassList='...' et authentication=....' »

  Des paramètres de mode proxy personnalisés ont été fournis pour l'inscription. Voici les paramètres utilisés pendant l'inscription. Si un nom d'utilisateur a été indiqué pour le proxy, l'authentification est également utilisée, ce que signale la valeur authentication=1.

  • « Utilisation de la détection de proxy automatique avec authentication=... »

  Le mode Proxy est configuré sur Détection auto pour l'inscription. Si un nom d'utilisateur a été indiqué pour le proxy, l'authentification est également utilisée, ce que signale la valeur authentication=1.

  • « Aucun proxy n'est utilisé pour la communication réseau. »

  Le mode Proxy est configuré sur Aucun.

  Toutes les inscriptions réussies signalent que les paramètres de proxy utilisés pendant l'inscription ont été enregistrés, comme l'indique la ligne « Les paramètres de proxy utilisés pour l'inscription ont été enregistrés ».

  En cas d'échec de l'inscription, aucun paramètre de proxy n'est enregistré, comme l'indique la ligne « Les paramètres de proxy utilisés pour l'inscription n'ont pas été enregistrés ».

• Nouvel indicateur pour l'agent, pour éviter la configuration de WinHTTP

  L'agent comporte un nouvel indicateur qui permet d'éviter de configurer WinHTTP lors de l'inscription d'un agent Windows. Pour utiliser cet indicateur afin de ne pas configurer WinHTTP, le client doit gérer ses listes de révocation de certificats (CRL) par lui-même afin d'empêcher une dégradation des performances au fil du temps. Les clients qui n'ont pas besoin d'éviter ce comportement ou qui ne sont pas prêts à gérer leurs propres CRL n'ont rien à faire.

  Cet indicateur, nommé « Mettre à jour le proxy WinHTTP », peut servir à éviter le comportement par défaut en ajoutant la ligne suivante au fichier d'options :

  updateWinHttpProxy=0

  Où 0 signifie que la valeur WinHttpProxy n'est pas écrasée pendant l'inscription.

• URL de stockage Blob Azure : Le système fournit désormais la liste des URL de stockage Blob Azure qui doivent figurer dans la liste d'autorisations de votre pare-feu pour permettre les communications entre IvantiPlateforme Neurons et ses agents.
  En savoir plus sur les URL de stockage Blob Azure.

La fonction État de santé de l'agent permet aux administrateurs de garantir des performances optimales des agents Ivanti Neurons au sein de leur parc. En fournissant une vue d'ensemble centralisée de l'état de santé des agents, avec des options d'action, cette fonction simplifie le processus d'identification et de résolution des problèmes susceptibles de perturber les opérations.

Surveillance et diagnostic proactifs : La fonction État de santé de l'agent permet aux administrateurs d'autodiagnostiquer les problèmes sans avoir besoin du support du fournisseur. Cette approche proactive minimise les coupures de service et améliore la fiabilité de votre implémentation Ivanti Neurons.

Filtrage complet des agents : Les administrateurs peuvent rapidement filtrer les vues afin d'afficher les agents dont la prise de contact est en retard, ceux qui n'ont jamais pris contact ou ceux qui ont été dupliqués. Cette fonction garantit qu'aucun problème de poste client ne passe inaperçu, ce qui permet une action corrective rapide. En savoir plus sur les filtres d'état de santé.

Système intuitif de type feux tricolores : L'état de santé de chaque agent est catégorisé visuellement à l'aide d'un système de feux tricolores :

• Vert (Correct) : Agents qui fonctionnent comme prévu.
• Orange (Modéré) : Agents avec des problèmes mineurs qui peuvent nécessiter votre attention.
• Rouge (Médiocre) : Agents avec des problèmes critiques exigeant une résolution immédiate.

Ce système visuel facilite la priorisation des efforts de dépannage et permet de se concentrer sur les problèmes les plus urgents. En savoir plus sur les indicateurs d'état de santé.

Analyse en cascade (drill-down) détaillée : Pour les agents marqués Modéré ou Médiocre, les administrateurs peuvent effectuer une analyse en cascade de chaque poste client d'agent pour obtenir des informations détaillées sur chaque problème spécifique. Cette visibilité granulaire accélère l'analyse de cause première et garantit des délais de résolution plus courts.

Ressources d'aide intégrées : Des liens intégrés vers le contenu de l'aide fournissent une assistance à la remédiation sur mesure, en fonction des problèmes identifiés. Ces ressources donnent aux administrateurs les moyens de résoudre efficacement les problèmes sans expertise technique poussée.

La fonction État de santé de l'agent ne se contente pas d'améliorer l'efficacité opérationnelle. Elle booste aussi la confiance dans les implémentations Ivanti Neurons car elle fournit les outils et les informations nécessaires pour résoudre les problèmes de façon indépendante. Elle réduit le temps et les efforts nécessaires au dépannage, limite les risques de sécurité potentiels et garantit une expérience utilisateur transparente.

En savoir plus sur État de santé de l'agent.

Ivanti Neurons Power Management (Gestion de l'alimentation) permet à un administrateur de gérer et d'optimiser la consommation d'énergie des périphériques de son environnement. Les administrateurs peuvent désormais configurer les paramètres d'économie d'énergie et les affecter à une stratégie. La gestion de l'alimentation n'a aucun impact sur les performances des périphériques. Vous pouvez gérer des paramètres comme Éteindre le disque dur, Veille après, Veille prolongée après et Autoriser les minuteries de réveil depuis la page Paramètres Gestion de l'alimentation.

En savoir plus sur les Paramètres Gestion de l'alimentation.

La gestion de l'alimentation est disponible uniquement sur les périphériques Windows.

Lorsqu'un déploiement de correctif échoue sur le périphérique, l'agent effectue un certain nombre de nouvelles tentatives avant d'abandonner. Le compteur de tentatives de déploiement peut être réinitialisé manuellement, et les événements sont capturés dans le but de signaler le nombre de tentatives épuisées dans Historique de déploiement.

Nous avons ajouté un nouveau rapport pour Patch Management : Historique de déploiement - Récapitulatif. Ce rapport présente une vue récapitulative des périphériques et de l'état global des correctifs, sous forme de pourcentage des redémarrages réussis, en échec ou en attente.

En savoir plus sur les rapports.

Sous Windows, vous pouvez désormais définir la criticité de redémarrage. Elle spécifie la priorité de la demande de redémarrage envoyée à l'agent, pour que ce dernier puisse planifier le redémarrage en fonction des paramètres de la stratégie d'agent. La demande de redémarrage n'est satisfaite que si la valeur définie dans la configuration d'agent est supérieure ou égale à la valeur Criticité minimale de redémarrage fixée par la stratégie d'agent.

En savoir plus sur les Comportement de redémarrage.

Patch for Intune prend désormais en charge la publication dans plusieurs langues. Des options de langue sont disponibles lors de la gestion des produits dont les fournisseurs proposent des programmes d'installation propres à une langue. Vous pouvez ainsi publier des versions dans une langue différente pour les différents groupes.

En savoir plus sur la configuration de la gestion d'un produit.

Le succès d'App Control repose sur la fonction Trusted Ownership, qui garantit qu'aucun exécutable ne peut s'exécuter s'il n'appartient pas à un compte de confiance, comme Administrateur ou Programme d'installation de confiance. Cela signifie que tout ce qui est installé ou modifié par un utilisateur standard ne peut pas s'exécuter. Dans les entreprises matures, cela peut provoquer le blocage d'applications légitimes installées par des utilisateurs. Pour éviter cela, App Control permet aux utilisateurs d'identifier les applis potentiellement bloquées et de créer des exceptions pour elles, appelées règles Autoriser, qui garantissent que la productivité reste intacte tout en préservant la sécurité. Vous pouvez configurer ces règles pour qu'elles s'appliquent à des versions de logiciel, des emplacements, des personnes, des périphériques ou des plages IP spécifiques.

Pour identifier les logiciels susceptibles d'être affectés par Trusted Ownership, il est recommandé de commencer par une configuration en mode Audit uniquement. Cela permet à App Control de collecter des informations sur les éléments exécutés sans imposer aucune restriction. Les données collectées sont présentées sous forme graphique, ce qui permet aux administrateurs de déterminer les règles d'autorisation à créer.

De plus, vous pouvez créer des règles Refuser, qui empêchent une application de s'exécuter dans certaines circonstances même si elle appartient à un propriétaire de confiance. Cela s'avère utile pour les applications sensibles installées automatiquement sur tous les périphériques mais auxquelles seules certaines personnes doivent accéder.

Voir une vidéo connexe sur Trusted Ownership (4:39)

La deuxième fonction clé d'App Control est la possibilité de réduire le nombre d'administrateurs dans votre environnement en activant l'élévation des privilèges uniquement pour les tâches nécessaires et des utilisateurs spécifiques. Comme pour le blocage d'applis, App Control peut collecter des données sur les personnes et les éléments qui nécessitent actuellement des privilèges Administrateur. Ces informations aident les administrateurs à créer des règles qui permettent aux utilisateurs ayant besoin de privilèges élevés pour des activités spécifiques de réaliser ces opérations sans posséder un accès Administrateur permanent.

Voir une vidéo connexe sur les privilèges élevés (2:00)

Les utilisateurs ont accès à 10 Go de stockage gratuit. Le téléchargement et la suppression de fichiers de cet espace sont gérés via l'explorateur de stockage Cloud, accessible à partir de l'action Télécharger dans un paquet d'appli.

App Distribution fonctionnera désormais correctement lorsque l'agent Neurons est configuré pour utiliser un serveur proxy.

Les utilisateurs peuvent déployer App Portal sur des périphériques Windows. Il contient les applis affectées à l'utilisateur final, ce qui lui permet de les installer selon ses besoins. Le déploiement de cette fonction sera progressif, disponible pour un nombre limité de clients. Nous prévoyons que le déploiement complet aura lieu fin novembre.

Ces nouvelles requêtes affichent une vue d'ensemble de toutes les configurations Ivanti Application Control (AC) et Environment Manager (EM) disponibles sur les périphériques. La requête renvoie des données uniquement si des configurations AC/EM ont été déployées via un déploiement Neurons AC/EM (Hybride).

De nouveaux capteurs ont été ajoutés pour interroger les événements Ivanti Environment Manager (EM) sur vos périphériques. Il s'agit notamment des capteurs Récapitulatif des événements, Vue d'ensemble des événements, Détails, Performances d'action et Détails des performances d'action Ivanti Environment Manager. Prérequis pour que ces capteurs fonctionnent : l'agent EM doit être installé sur les périphériques.

Le paramètre de localisation, sous Paramètres Edge Intelligence, est désormais pris en charge sur les périphériques Mac Cela signifie que la configuration complète du paramètre de localisation peut désormais être effectuée sous Paramètres Edge Intelligence. L'ancien paramètre de l'interface utilisateur (UI) Edge Intelligence a été supprimé car il n'est plus nécessaire.

En savoir plus sur Paramètres Edge Intelligence.

Diverses requêtes fonctionnaient avec des paramètres Date source et Date cible, pour définir une période. Ces paramètres sont désormais remplacés par un paramètre unique appelé « Plage de dates », qui prend en charge certaines options intégrées pour spécifier une plage de dates « X derniers jours ». Il est toujours possible de définir une plage personnalisée.

Diverses requêtes ont été améliorées. La propriété supplémentaire « Système d'exploitation » a été ajoutée à la page d'accueil Vue d'ensemble des agents. La requête Tableau de bord Périphérique affiche désormais l'heure locale du périphérique. La requête Informations BIOS a été restructurée pour rendre les propriétés plus claires.

Pour l'utilisation d'entrées de bot, nous avons ajouté le nouveau type « Liste d'entrées texte/chaînes », qui permet de transmettre une liste de valeurs à un bot au moment de l'exécution. De plus, si l'étape Demande Web pointe vers une API qui renvoie plusieurs matrices de niveau champ dans sa réponse, les bots peuvent désormais servir à travailler avec cette réponse.

Désormais, l'étape Demande Web tente par défaut de mapper automatiquement une réponse JSON sur une commande get dans les cases à cocher, en déterminant automatiquement le type de données (Date, Nombre, Booléen, etc.). Ainsi, l'Admin n'a plus qu'à sélectionner les types de données à utiliser dans le bot et ils seront disponibles comme options de sortie.

Nous avons ajouté une nouvelle étape pour renvoyer les détails des périphériques de stockage amovibles récemment utilisés, tels que récupérés dans le journal des événements Windows via le capteur Edge Intelligence. Vous y trouverez une vue historique des périphériques, que vous pouvez filtrer sur des dates spécifiques selon vos besoins.

Plusieurs étapes de liste nouvelles ont été ajoutées pour accompagner la prise en charge des matrices de niveau champ, pour plus de flexibilité lors de l'utilisation de données de liste. Il existe de nouvelles étapes pour Moyenne de la liste, Filtrer la liste, Trouver dans la liste, Aplatir la liste contenant une liste, Longueur de liste, Choisir le premier de la liste, Trier la liste et Somme de la liste. Nous avons aussi optimisé les performances de l'étape For-Each (Pour chaque) et l'avons déplacée vers la section des étapes de liste. Vous trouverez des détails supplémentaires sur les étapes dans les descriptions Informations d'étape.

En savoir plus sur les étapes Fonction de liste.

Nous avons ajouté une nouvelle fonction qui permet de générer une date dans un format lisible pour l'être humain dans les étapes applicables. Elle figure sous Paramètres avancés dans les étapes compatibles, et peut être utilisée dans les inserts de zone de texte (jetons) ou le corps des e-mails.

Nous avons ajouté la possibilité de cibler des groupes privés lors de la construction d'un bot, et d'utiliser la fonction Exécuter maintenant. Cela rationalise le processus de construction et évite l'obligation de polluer des groupes publics avec des périphériques de test.

Nous avons ajouté une nouvelle expérience à l'écran d'accueil des bots. Elle permet d'afficher une vue des bots exécutés au fil du temps, avec des détails sur le nombre d'interactions de poste client exécutées, pour chaque bot. Vous disposez aussi d'une bonne visibilité des bots Planification à fort impact dont l'exécution s'étale sur une durée légèrement plus longue, afin d'optimiser la charge et de réduire les pics de demande sur le réseau. Un bot à fort impact est un bot qui effectue plusieurs milliers d'interactions au cours d'une période de 5 minutes. Cela dépend du nombre d'étapes traitées, multiplié par le nombre de postes client ciblés. Les bots Déclenchement humain contournent ce mécanisme.

L'interface utilisateur de création de rapports peut filtrer les données par déclencheur. Elle est donc également utile pour afficher l'utilisation des actions personnalisées au fil du temps, depuis les vues Périphériques ou Personnes.

En savoir plus sur les interactions de poste client.

Nous avons ajouté la nouvelle zone Paramètres à la page d'accueil des bots. Elle permet à un Admin de sélectionner les utilisateurs ou rôles qui doivent recevoir des notifications par e-mail en fonction des options des bots Planification en cours d'exécution, ou qui ont réussi et/ou échoué.

Nous avons créé les nouvelles étapes Inventaire de périphériques et Inventaire de personnes. Elles permettent d'enrichir les données concernant les périphériques ou personnes qui passent par le bot, et d'exploiter ces données dans des filtres pour création de branches ou insertion dans d'autres étapes, comme les rapports par e-mail, les demandes Web ou les tickets ITSM. Ces options sont disponibles en accès anticipé et seront déployées plus largement en fonction des commentaires.

Pour les utilisateurs qui exécutent ServiceNow, il est désormais possible de créer ou de mettre à jour des tickets à l'aide de bots. Il existe notamment une option permettant de lier le bien au ticket et d'éviter la duplication des tickets s'il en existe déjà un pour le périphérique/cas d'usage. Elle peut aussi servir à gérer le cycle de vie complet d'un ticket au sein d'un bot, par exemple détecter un problème, ouvrir un ticket, effectuer des diagnostics et les enregistrer dans le ticket. Exécutez une action, enregistrez le résultat dans le ticket et passez ce ticket à l'état Fermé si le problème est résolu. Vous pouvez également réaffecter le ticket dans le workflow si nécessaire ou modifier d'autres métadonnées comme la priorité.

Nous avons ajouté une nouvelle étape qui permet à un Admin de désactiver un compte Entra ID à l'aide de bots (en mode Personnes). C'est la première d'une série de nouvelles étapes d'action Personnes visant à offrir davantage de possibilités de remédiation pour différents scénarios.

Mise en place de nouvelles fonctionnalités de création de rapports pour Patch Management, notamment deux modèles de rapport prédéfinis : Correctifs par périphérique - Récapitulatif et Périphériques par correctif - Récapitulatif.

Les utilisateurs peuvent appliquer différents filtres pour personnaliser les rapports, et les exporter au format PDF, Excel ou CSV. Ces fonctions constituent un moyen simple pour le suivi de la conformité et pour traiter efficacement les questions de sécurité.

En savoir plus sur les rapports.

Ajout de deux jeux de données Patch Management à Concepteur de tableau de bord. L'un des jeux de données se concentre sur l'historique de déploiement, tandis que l'autre fournit des données sur les analyses de correctifs de périphérique. Ces nouveaux jeux de données permettent aux utilisateurs de créer des tableaux de bord interactifs complets, couvrant les principaux aspects de la gestion des correctifs, notamment les périphériques, les correctifs, les vulnérabilités et l'historique de déploiement.

Précédemment, le dernier rapport de connecteur exécuté déterminait l'état d'installation du correctif. L'état d'installation du correctif est désormais extrait de l'analyse la plus récente du moteur de correctifs Neurons, s'il en existe une. L'analyse effectuée par un connecteur Ivanti Endpoint Manager est utilisée si elle est plus récente que l'analyse Neurons, et les analyses d'autres connecteurs sont utilisées uniquement si l'analyse Neurons précédente date de plus de 7 jours.

Avec l'aggravation des risques liés aux vulnérabilités et aux exploitations au fil du temps, l'application en continu des correctifs sur tous les périphériques de l'entreprise devient un défi, c'est pourquoi les équipes IT et de sécurité de l'information doivent veiller à déployer les correctifs les plus critiques, suivis des plus importants.

Ivanti Neurons for Patch Management vous permet désormais de définir des critères de déploiement en fonction de divers modèles de risque :

• VRR (Score de risque de la vulnérabilité) – Ce modèle de notation prend en compte le risque d'exploitation ou la possibilité d'une exploitation active, en plus de données CVSS (Système de notation des vulnérabilités courantes), CWE (Énumération des faiblesses courantes), OWASP (Projet de sécurité des applications Web ouvertes), de données d'intelligence des menaces Open Source, d'une expertise du sujet, d'informations sur les tendances, etc. Vous pouvez saisir un score VRR personnalisé comme critère de sélection lors de la configuration du correctif.
• CVSS (Système de notation des vulnérabilités courantes) – Ce système de notation est largement accepté comme norme d'évaluation des vulnérabilités et utilise divers facteurs pour déterminer le score. Cependant, ce score est en grande partie statique, et ne tient pas compte de l'évolution des scénarios d'attaque et d'exploitation au fil du temps. Vous pouvez saisir un score CVSS personnalisé comme critère de sélection lors de la configuration du correctif.
• Vulnérabilités exploitées – Ce critère permet de cibler en priorité les correctifs des vulnérabilités connues qui sont activement exploitées, d'après les informations collectées.

Notez que vous pouvez appliquer simultanément ces trois critères, si vous le souhaitez.

En savoir plus sur le Comportement de configuration.

Vous pouvez désormais définir des critères de déploiement, dans une configuration de correctifs, en fonction des niveaux de gravité Linux (Critique, Important, Modéré, etc.) pour les correctifs de sécurité et autres que Sécurité.

En savoir plus sur le Comportement de configuration.

Plusieurs versions de Windows 10 et Windows 11 partagent le même système d'exploitation principal et les mêmes fichiers système. Un certain nombre de fonctions exposées dans les versions les plus récentes existent également dans les versions précédentes à l'état dormant. Par conséquent, vous pouvez déployer un paquet d'activation pour activer ces fonctions, ce qui ne nécessite qu'un seul redémarrage.

Vous pouvez désormais déployer un paquet d'activation pour un périphérique Windows directement depuis la console, via Maintenance de routine. Il est possible de sélectionner plusieurs paquets, en fonction des versions d'OS des périphériques, et vous pouvez afficher et choisir les correctifs remplacés.

Exemple : Avec le paquet d'activation MSNS20-12-W10-4562830, vous pouvez activer les nouvelles fonctions publiées dans Win 10 version 20H2 dans Win 10 version 2004.

En savoir plus sur le Comportement de configuration.

La fonction Historique de déploiement a été enrichie de filtres interactifs et de cartes d'état liés à l'état du déploiement (Succès, Échec ou En cours). La période d'affichage pour les vues Correctifs et Périphériques peut être modifiée à l'aide d'une liste déroulante offrant une multitude d'options : Dernière heure, 4 heures, 24 heures, 7 jours et Plage personnalisée. Les données d'historique de déploiement affichées dans la grille changent dynamiquement selon la période sélectionnée.

Vous pouvez afficher la liste Top 10 des échecs de déploiement, ainsi que la raison de ces échecs, dans un graphique à barres interactif. Les périphériques impactés sont affichés dans la grille figurant au-dessous.

En savoir plus sur l'Historique de déploiement.

Actuellement, cette fonction est disponible uniquement pour Patch Management (Gestion des correctifs) ; toutes les autres fonctionnalités utilisent par défaut le niveau de criticité Obligatoire.

Les redémarrages constituent une ressource partagée dans l'agent Ivanti Neurons. Dans la plateforme d'agent, chaque moteur peut demander que les redémarrages soient différés ou qu'un poste client redémarre immédiatement.

Résultat : plusieurs demandes de redémarrage peuvent s'accumuler alors que le redémarrage est empêché. Dans ce scénario, l'agent lance un seul redémarrage pour satisfaire toutes ces demandes distinctes.

Comme différents moteurs demandent des planifications de redémarrage différentes, cela peut créer des défaillances cachées dans les moteurs qui nécessitent un redémarrage pour fonctionner.

Nous avons donc introduit des niveaux de criticité pour décider quand un redémarrage est prioritaire.

Chaque fonctionnalité ou configuration de produit informe le mécanisme de redémarrage centralisé de son propre niveau de criticité.

Ces niveaux sont les suivants :

• Critique : Pour les éléments qui nécessitent un redémarrage immédiat pour résoudre des dépendances critiques (comme un correctif Zero Day).
• Obligatoire : Pour les cas où un redémarrage est requis pour que les fonctions nouvelles ou mises à jour opèrent correctement (par exemple, une nouvelle mise à jour du moteur).
• Conseillé : Pour les cas où une opération peut nécessiter un redémarrage, mais qui n'est pas urgent

À partir d'une stratégie d'agent, les clients peuvent ensuite décider de mode de traitement de chaque niveau de criticité, en termes de configuration des reports, des messages et des délais de redémarrage.

Il est possible de configurer un niveau de criticité minimal pour chaque stratégie, de limiter les redémarrages au seul niveau d'urgence voulu ou de définir la préférence « Ne pas redémarrer ».

Cela fournit aux utilisateurs un mécanisme de redémarrage centralisé et standardisé, qui répond aux limitations de redémarrage existantes et connues, notamment :

• Les utilisateurs de Patch Management doivent configurer les opérations avant et après redémarrage, dans la même zone de l'interface utilisateur, de préférence avec des options de redémarrage différentes.
• Les paramètres de correctif Zero Day exigent un redémarrage immédiat et doivent remplacer tous les reports de redémarrage déjà en attente.
• De nombreux utilisateurs ont besoin que les serveurs critiques, comme les contrôleurs de domaine ou les clusters SQL, restent en ligne. Ils ont donc besoin de pouvoir interdire complètement le redémarrage de ces périphériques.

En savoir plus sur Expérience de redémarrage Agent Policy (Stratégie d'agent).

Pour faciliter l'identification du contenu utile, les rubriques d'aide « URL, adresses IP et ports requis » et « Matrice de compatibilité des systèmes d'exploitation » contiennent désormais un historique des révisions.

Notre version précédente du regroupement des périphériques n'autorisait qu'un seul niveau de regroupement. La solution prend désormais en charge le « regroupement conditionnel » ou regroupement au sein d'un groupe. Cela rend le regroupement plus puissant et vous permet de mieux filtrer les données d'après les périphériques voulus.

Les versions précédentes des options de filtrage des groupes permettaient uniquement de saisir une date dans le filtre. Désormais, vous disposez d'une nouvelle option de filtre qui permet de saisir un nombre de jours. Cela rend le filtre plus dynamique.

Il existe désormais une permission qui masque le bouton Supprimer. Cela renforce la sécurité, et limite la liste des personnes autorisées ou non à supprimer des périphériques de la vue Périphériques.

Il existe désormais une permission qui peut être affectée à un membre pour l'autoriser à créer/modifier un groupe public. Elle permet de restreindre la liste des personnes autorisées ou non à créer et à modifier un groupe public dans votre entreprise.

Vous pouvez désormais créer un paramètre Gestion de l'alimentation et le déployer sur vos périphériques via une stratégie. Les paramètres sont les suivants :

• Éteindre le disque dur
• Mise en veille après
• Veille prolongée après
• Autoriser les délais de réveil

Ajout de trois jeux de données Score DEX à Concepteur de tableau de bord : Périphériques - Score DEX, Personnes - Score DEX et Entreprise - Score DEX. Pour ces trois jeux de données, les scores tirés des enquêtes menées via les bots Neurons sont également disponibles. De plus, pour le score DEX de l'entreprise, la solution effectue désormais un suivi quotidien de ce score, ce qui permet une analyse des tendances au fil du temps.