Jean-Sébastien DUCHENE Blog's

Actualité, Tips, Articles sur l'ensemble des Technologies Microsoft (SCCM/SMS, EMS, Microsoft Intune, Microsoft Azure, Windows 10, SCOM, MDOP...)
    • 20/2/2019

    [SCCM] La Technical Preview 1902.2 de System Center Configuration Manager est disponible

    Microsoft vient de mettre à disposition la Technical Preview 1902.2 (5.0.8787.1000) de System Center Configuration Manager. Pour rappel, ConfigMgr a subi une refonte de sa structure pour permettre des mises à jour aisées de la même façon que l’on peut le voir avec Windows 10. Si vous souhaitez installer cette Technical Preview, vous devez installer la Technical Preview 1804 puis utiliser la fonctionnalité Updates and Servicing (nom de code Easy Setup).

     

    System Center Configuration Manager TP 1902.2 comprend les nouveautés suivantes :

    Administration

    • Intégration avec l’Analytics d’Office pour l’évaluation du client Office 365 ProPlus afin de donner une vision des périphériques qui peuvent être mis à niveau vers une version supérieure. Ceci permet de détecter des problèmes de compatibilité éventuels avec les composants additionnels d’Office ou les macros. L’intégration se fait au niveau du tableau de bord Office 365 Client Management avec une nouvelle tuile Office 365 ProPlus Upgrade Readiness pour afficher les périphériques prêts à être mis à jour ou nécessitant une attention. Les périphériques doivent avoir une connectivité à l’Office CDN pour télécharger le fichier d’évaluation des composants.
    • Amélioration des critères de succès pour les déploiements phasés (Phased Deployments). Vous pouvez maintenant spécifier un nombre de périphériques comme critère et non plus qu’un pourcentage. Ceci peut être intéressant quand la taille de la collection est variable avec un faible nombre par exemple.
    • Amélioration au mode Enhanced HTTP avec la possibilité de l’activité par site primaire ou pour le Central Administration Site (CAS) uniquement. Le paramétrage est donc applicable au site où il est activé et non plus à la hiérarchie.

     

    Gestion des mises à jour logicielles

    • Support de toutes les langues supportées pour les mises à jour du client Office 365. Les différents assistants (Création ADR, Téléchargement de mises à jour, Déploiement de mises à jour, etc.) séparent maintenant les 38 langues pour les mises à jour Windows des 103 langues pour les mises à jour du client Office 365.

     

    Plus d’informations sur : https://docs.microsoft.com/en-us/sccm/core/get-started/2019/technical-preview-1902-2

    • 20/2/2019

    [SCCM CB] Les versions obsolètes des applications téléchargées du Microsoft Store for Business ne sont pas nettoyées

    En faisant un peu de nettoyage sur une de mes plateformes de tests System Center Configuration Manager, je me suis rendu compte que près de 50 GB d’espace disque était pris par les applications que j’avais approuvé dans le Microsoft Store for Business.

    On retrouve deux modes de licences pour ces applications :

    • Hors ligne : Configuration Manager s’occupe de récupérer le contenu et le client vient le récupérer sur les points de distribution. La gestion des licences se fait via ConfigMgr et non pas via le Microsoft Store
    • En ligne : Le téléchargement est réalisé via le Microsoft Store et Windows Update. Configuration Manager ne fait que diriger le Microsoft Store. Le compte Azure AD de l’utilisateur est utilisé pour réaliser les différentes opérations de téléchargement. Dans ce cas de figure, on en retrouve aucun contenu dans la hiérarchie ConfigMgr.

    Actuellement, toutes les applications approuvées dans un mode Hors ligne sont téléchargées dans le répertoire utilisées par le connecteur Microsoft Store for Business et ce même si vous ne les avez pas créé et déployé. System Center Configuration Manager télécharge toute nouvelle version publiée par le développeur. Néanmoins, le produit n’effectue pas de nettoyage des versions obsolètes et précédentes.

    C’est pourquoi aujourd’hui après 2 ans, les quelques applications (Word, OneNote, Reader, Surface, Sway, etc.) que j’avais approuvé, prennent jusqu’à 50 GB. C’est particulièrement vrai si l’application est mise à jour fréquemment par l’éditeur/le développeur.

    En regardant dans le dossier utilisé par le connecteur, on peut voir les différentes applications et l’ensemble des versions publiées par le développeur. Par exemple pour Word :

     

    Comment nettoyer ces versions obsolètes ?

    Le travail n’est pas si simple qu’on pourrait le penser. Il ne suffit pas de prendre toutes les anciennes versions et de simplement les supprimer. En réalité, il faut vérifier si l’application que vous déployez correspond bien à la dernière version. En effet, même si ConfigMgr télécharge les nouvelles versions, il en revient à l’administrateur de créer une nouvelle application et de la déployer !

    Si vous n’avez jamais recréer l’application, alors vous déployez la première version synchronisée. Pour ce faire, vous pouvez vérifier de la façon suivante (par exemple dans mon cas pour Word), naviguez dans Software Library – Applications. Ciblez l’application puis ouvrez un des types de déploiement :

     

    Récupérez le chemin vers le contenu :

     

    Identifiez dans l’explorateur de quand date la version :

     

    Dans mon cas, la version date de 2017 et n’est clairement pas la dernière version. Deux solutions sont possibles :

    • Recréer l’application (à partir de License Information for Store Apps) et déployer la dernière version. Ceci constitue surement la solution la plus adéquate.
    • Supprimer toutes les versions exceptées celles que vous déployez ainsi que la dernière version.

     

    Pour faire ce nettoyage, vous devez pour chaque application :

    • Créer l'application en dernière version !
    • Regarder TOUS les types de déploiement pour toutes les versions de l'application que vous déployez et le chemin associé au contenu.
    • Cibler ce contenu afin de le conserver
    • Supprimer les autres dossiers du répertoire (exception faite du dossier images).

    Attention ! L’opération est à réaliser à vos risques et périls et sans support.

    Vous pouvez aussi voter pour l’UserVoice afin que le nettoyage soit nativement intégré au produit.

    • 19/2/2019

    Les résultats des certifications MS-100 et MS-101 passées en Bêta sont en ligne

    Si vous avez passé les nouvelles certifications Bêta pour Microsoft 365, Microsoft vient de mettre en ligne les résultats des certifications MS-100: Microsoft 365 Identity and Services et MS-101: Microsoft 365 Mobility and Security.

    Pour rappel, voici les différents éléments qui sont évalués :

    • MS-100: Microsoft 365 Identity and Services
      • 20-25% sur la conception et l’implémentation des services Microsoft 365 : Ceci inclut la gestion des domaines, la planification, la mise en œuvre des abonnements et tenants Microsoft 365, la gestion des abonnements et de la santé du tenant, planifier la migration des données utilisateurs.
      • 35-40% sur la gestion des identités et rôles utilisateurs : Ceci inclut la conception de la stratégie d’identité, la planification de la synchronisation avec Azure AD Connect, la gestion de la synchronisation, la gestion des identités Azure AD, et la gestion des rôles utilisateurs
      • 20-25% sur la gestion des accès et des authentifications : Ceci inclut la gestion de l’authentification, l’implémentation de l’authentification à facteurs multiples, la configuration des accès aux applications, l’implémentation des accès pour les utilisateurs externes.
      • 10-15% sur la planification des charges de travail et applications Office 365
    • MS-101: Microsoft 365 Mobility and Security
      • 30-35% sur l’implémentation des services de périphériques modernes : Ceci inclut l’implémentation de la gestion des périphériques mobiles, la gestion de la conformité de périphérique, la planification des périphériques et applications, et la planification du déploiement Windows 10.
      • 30-35% sur l’implémentation de la gestion des menaces et de la sécurité avec Microsoft 365 : Ceci inclut l’implémentation de Cloud App Security, l’implémentation de la gestion des menaces, l’implémentation de Windows Defender Advanced Threat Protection (ATP), et la gestion des rapports et alertes de sécurité
      • 35-40% sur la gestion de la conformité et de la gouvernance Microsoft 365 : Ceci inclut la configuration de la prévention de la perte de données (DLP), l’implémentation d’Azure Information Protection, la gestion de la gouvernance de données, la gestion de l’audit, et la gestion d’eDiscovery.

     

    Note : Les résultats pour les certifications MD-100, MD-101, et MS-500 sont toujours attendus.

    • 19/2/2019

    Nouvelle version (10.2.7) du Client Remote Desktop pour macOS

    Microsoft vient de publier une nouvelle application (10.2.3) du client Remote Desktop pour macOS. Cette version apporte :

    • Dans cette version, Microsoft a géré les erreurs d'encodage graphique (causées par un bug d'encodage du serveur) qui apparaissaient lors de l'utilisation du mode AVC444.
    • Ajout du support du codec AVC (420 et 444), disponible lors de la connexion aux versions actuelles de Windows 10.
    • En mode Fit to Windows, un rafraîchissement de la fenêtre se produit immédiatement après un redimensionnement pour s'assurer que le contenu est rendu au niveau correct.
    • Correction d'un bug de mise en page qui entraînait le chevauchement des en-têtes de flux pour certains utilisateurs.
    • Nettoyage de l'interface utilisateur dans la partie Préférences d'application.
    • L’interface d’ajout/édition de bureau a été nettoyée
    • De nombreux ajustements et finitions ont été effectués sur la tuile Connection Center et les vues de liste pour les postes de travail.

    Tester le client Remote Desktop pour Mac

    • 19/2/2019

    [SCCM 1806/1810] Problème de téléchargement des mises à jour logicielles sur Windows 10 avec une séquence de tâches

    De plus en plus d’utilisateurs rapportent (via les forums) des problèmes lors de l’installation de mises à jour logicielles pendant des séquences de tâches de déploiement de système d’exploitation (OSD) avec System Center Configuration Manager. Ce problème semble concerner Windows 10 uniquement et certaines versions spécifiques de Windows 10 (1709 notamment mais aussi 1803 ou 1809).

    Le fichier smsts.log affiche indéfiniment des messages comme suit :

    Waiting for job status notification ...
    Waiting for job status notification ...
    Waiting for job status notification ...
    Waiting for job status notification ...
    Waiting for job status notification ...

    Microsoft est en train d’identifier le problème plus en détails pour l’adresser.

    Il semble qu’utiliser la version 1802 du client System Center Configuration Manager permette d’adresser le problème et installer les mises à jour lors du déploiement de cette séquence de tâches.

    Toutes ces informations sont à prendre avec des pincettes. Si vous rencontrez un problème de ce type, n’hésitez pas à ouvrir un ticket chez Microsoft pour enrichir les informations déjà remontées.

    • 19/2/2019

    [Windows 10] Un webinar sur le packaging MSIX.

    Microsoft va tenir une série de trois webinars sur le packaging via le format MSIX. Le premier a lieu mercredi 20 février de 7h à 8h30 (heure française). Pour rappel, le format MSIX est un nouveau format standardisé lancé par Microsoft pour remplacer l’ensemble des formats de packaging existants tout en bénéficiant des avancés des différentes solutions : Click-To-Run (C2R), App-V, APPX et plus généralement du Framework d’applications universelles (UWP). Il offre donc des mécanismes de conteneurisation et les bénéfices des applications universelles avec une installation, mise à jour et désinstallation aisée sans laisser aucune trace sur le système. Il fournit aussi des mécanismes de sécurisation avancés permettant de valider l’intégrité du code exécuté. Ce format permet aussi de créer des personnalisations pour les applications packagées et de les faire perdurer au travers des différentes mises à jour de l’application.

    Pour s’enregistrer : MSIX - Packaging Desktop applications for Modernization" – Part 1 of 3

    • 18/2/2019

    [Autopilot] Le scénario de Autopilot pour périphériques existants échoue avec l’erreur MDM enroll failed: 0x80180014

    Voici une considération importante si vous souhaitez implémenter Windows Autopilot avec Microsoft Intune pour le scénario (Autopilot for existing devices) qui concerne des périphériques existants. Ce scénario implique l’utilisation de System Center Configuration Manager pour descendre une image de Windows 10 et ensuite lancer le processus Windows Autopilot via un fichier JSON présent localement sur la machine.

    Dans ce scénario, le périphérique n’est pas préalablement connu du service Windows Autopilot et de Microsoft Intune. Si vous bloquez l’enregistrement des périphériques personnels (BYOD) pour Windows 10, alors le déploiement échoue lors de l’enregistrement du périphérique dans Microsoft Intune avec l’erreur 0x80180014. En regardant le journal d’événements DeviceManagement-Enterprise-Diagnostics-Provider, vous pouvez voir des événements 71, 11, 52 et 59 avec notamment le message:

    Specific platform (e.g. Windows) or version is not supported.

    La problématique vient du fait que le périphérique n’est pas connu de Microsoft Intune. Aujourd’hui, le seul moyen de pré-enregistrer des périphériques est d’importer le périphérique comme étant un périphérique Windows Autopilot (dans Device enrollment – Windows Enrollment – Windows Autopilot devices). L’autre moyen ne concerne pour l’instant que les périphériques iOS, Android et mac OS via la fonction Corporate device identifiers (dans Device enrollment - Corporate device identifiers)

    Deux possibilités s’offrent à vous :

    • Vous souhaitez utiliser le scénario Autopilot for existing devices pour des périphériques existants équipés de Windows 10. Vous devez donc extraire le numéro de série, le hash matériel via le script suivant et l’intégrer dans la console Microsoft Intune dans Device enrollment – Windows Enrollment – Windows Autopilot devices. Ceci permettra de garder la restriction sur les périphériques BYOD.
    • Vous souhaitez utiliser le scénario Autopilot for existing devices pour des périphériques existants équipés d’une version antérieure (Windows 7, Windows 8.1, etc.). Ces versions ne permettent pas d’extraire le numéro de série et le hash matériel. Vous devez donc tout baser sur le fichier JSON et sur le fait que Microsoft Intune ne connaitra pas préalablement votre périphérique. Dans ce cas de figure, vous devez réactiver l’enregistrement des périphériques personnels Windows (BYOD) dans Device Enrollment – Enrollment Restrictions – Device Type Restrictions (Default – All Users). Validez d’abord que la plateforme Windows (MDM) est bien autorisée dans select platforms :

    Ensuite dans Configure platforms, activez l’enregistrement des périphériques personnels

    Après ces considérations et modifications, le scénario fonctionnera comme attendu.

    • 18/2/2019

    [Remote Desktop] Nouvelle version 1.0.7 du client Web Remote Desktop

    Microsoft vient de mettre à disposition une nouvelle version (1.0.7) du client Web pour Remote Desktop pour Windows Server 2016 et Windows Server 2019. Vous pouvez ajouter le client web à une infrastructure existante via les commandes PowerShell.

    Cette version apporte les éléments suivants :

    • L'accès hors ligne sur les réseaux internes est désormais supporté.
    • Amélioration du rendu sur autres navigateurs que Edge.
    • Mise en place d'une limite pour les tentatives de réessaie de récupération des abonnements/feed afin d'empêcher du DoS.
    • Correction de bugs d'accessibilité afin de permettre aux utilisateurs ayant une déficience visuelle d'utiliser le client Web.
    • Amélioration des messages d'erreur affichés à l'utilisateur pour les erreurs de feed/abonnements.
    • Ajout des raccourcis Ctrl + Alt + Fin (Windows) et fn + control + option + delete (Mac) pour invoquer Ctrl + Alt + Del en session distante.
    • Amélioration de la télémétrie en cas de crash.
    • Diverses corrections de bugs

    Cette version web est simplifiée avec les fonctionnalités essentielles telles que :

    • L’accès au bureau ou aux applications publiées via un abonnement (feed)
    • Le Single Sign-on
    • L’impression vers un fichier PDF
    • L’audio en sortie
    • Les résolutions dynamiques et le plein écran
    • Le copier/coller de texte en utilisant les raccourcis (Ctrl + C et Ctrl + V)
    • Le support des entrées par le clavier et la souris
    • La localisation en 18 langues (dont le français)

    Le client web est supporté par les principaux navigateurs :

    • Microsoft Edge
    • Internet Explorer 11
    • Google Chrome
    • Mozilla Firefox
    • Apple Safari

    Ceci permet de couvrir les principales plateformes : Windows, macOS, Chromebook et Linux.

    • 17/2/2019

    [Azure AD] Un livre blanc sur la sécurité d’Azure Active Directory

    Microsoft a rédigé un livre blanc très complet sur la sécurité d’Azure Active Directory et notamment des données associées. On retrouve des éléments sur les algorithmes de chiffrement utilisés aux différents niveaux. Ce dernier résume :

    • Les composants Azure Active Directory
    • Azure AD et les données : le modèle de la solution Azure AD, l’emplacement des données et le stockage des données à travers les composants
    • Les considérations sur la protection des données (contrôle d’accès, sécurité des données, la suppression des données d’Azure AD, etc.)
    • Les considérations pour le flux de données (Azure AD Connect, les services de provisionnement Azure AD, etc.)
    • Les considérations opérationnelles pour les données (fichiers de logs, etc.)

     

    Télécharger et lire Azure Active Directory Data Security Considerations

    • 16/2/2019

    [Azure AD/Office 365] Comment sécuriser les accès privilégiés au Cloud ?

    Quand on intervient dans les entreprises, certains services tels qu’Office 365 ou Azure Active Directory ont été mis en place sans prendre en compte les enjeux de sécurité.  On peut donc voir des administrateurs qui se connectent avec leur compte possédant directement les droits d’administrateur global (Global Admin) d’Azure Active Directory et n’ayant aucune protection tels que l’authentification à facteurs multiples (MFA).

    Microsoft propose un article plutôt bien réalisé permettant de définir une feuille de route à 4 étapes visant à aborder la sécurisation des accès privilégiés à Azure Active Directory et plus généralement aux services qui gravitent autour :

    • Etape 1 :
      • Activer Azure AD Privileged Identity Management (PIM)
      • Identifier et catégoriser les comptes à haut privilèges (Global Admin, Exchange Online Administrator, Intune Administrator, etc.)
      • Définir au moins deux comptes d’accès d’urgence
      • Activer l’authentification à facteurs multiples et enregistrer tous les autres comptes administrateurs non fédérés à hauts privilèges.
    • Etape 2 :
      • Conduire un inventaire des services, propriétaires et administrateurs
      • Identifier les comptes Microsoft dans des rôles d’administration qui auraient besoin d‘être changé vers des comptes d’entreprise
      • Vérifier que les comptes utilisateurs et le transfert de courrier sont séparés pour les comptes d’administrateur global.
      • Vérifier que le mot de passe des comptes d’administration est changé fréquemment
      • Activer la synchronisation du hash du mot de passe
      • Demander l’authentification à facteurs multiples pour tous les utilisateurs dans des rôles à privilèges ainsi qu’aux utilisateurs exposés (VIP, etc.)
      • Configurer Azure AD Identity Protection
      • Prendre en compte le Secure Score d’Office 365
      • Revoir le guide de conformité et de sécurité d’Office 365
      • Configurer la supervision d’activité d’Office 365
      • Etablir des propriétaires de plan de réponse en cas d’incident/d’urgence
      • Securiser les comptes d’admnistrations privilégiés On-Premises
      • Faire un inventaire des abonnements Azure
      • Supprimer les comptes Microsoft des rôles d’administration Azure
      • Superviser l’activité d’Azure
      • Configurer des stratégies d’accès conditionnel
    • Etape 3
      • Faire une revue des accès des utilisateurs sur les rôles à privilèges
      • Continuer le déploiement d’authentification forte pour tous les utilisateurs
      • Utiliser des stations de travail dédiés pour l’administration d’Azure AD.
      • Implémenter le Just-In-Time priviléges pour les rôles d’administration supplémentaires via PIM
      • Déterminer l'exposition aux protocoles de connexion basés sur des mots de passe

    Plus d’informations sur : Securing privileged access for hybrid and cloud deployments in Azure AD

    • 16/2/2019

    Version finale (1.2019.110.0) de l’outil de packaging MSIX

    Microsoft vient de finaliser la version 1.2019.110.0 de son outil de packaging (MSIX Packing Tool). Cet outil permet de prendre un package d’application Win32 existant et de la convertir au format MSIX. Vous utilisez pour cela une machine de référence pour exécuter l’outil et obtenir le package MSIX que vous pouvez ensuite déployer à la main, par votre outil de télédistribution ou depuis le Microsoft Store.

    Pour rappel, le format MSIX est un nouveau format standardisé lancé par Microsoft pour remplacer l’ensemble des formats de packaging existants tout en bénéficiant des avancés des différentes solutions : Click-To-Run (C2R), App-V, APPX et plus généralement du Framework d’applications universelles (UWP). Il offre donc des mécanismes de conteneurisation et les bénéfices des applications universelles avec une installation, mise à jour et désinstallation aisée sans laisser aucune trace sur le système. Il fournit aussi des mécanismes de sécurisation avancés permettant de valider l’intégrité du code exécuté. Ce format permet aussi de créer des personnalisations pour les applications packagées et de les faire perdurer au travers des différentes mises à jour de l’application.

    Cette version ajoute les fonctionnalités :

    • Amélioration du temps de packaging
    • Mise à jour de la liste d'exclusion des fichiers par défaut
    • Intégration des journaux d'erreurs MSIExec dans les outils de rapports
    • Mise à jour des journaux pour ajouter plus de clarté et des étapes de dépannage
    • Ajout du support de la capture d'installation à partir de PowerShell ISE pendant le packaging manuel
    • Ajout du support pour déclarer les scripts PowerShell comme argument d'installation dans l'interface utilisateur et dans le fichier modèle de ligne de commande.
    • Ajout d'un indicateur de journalisation Verbose (--verbose | -v) pour l'interface de ligne de commande
    • Correction d'un problème où les chemins réseau sur la VM étaient parfois inaccessibles
    • Correction d'un problème où la validation des exigences de version du Store échouait lors de l'utilisation de la ligne de commande.
    • Correction d'un problème où les chemins d'accès aux fichiers entre guillemets n'étaient pas acceptés
    • Correction d'un problème où la VM n'était pas nettoyée correctement après la conversion
    • Correction d'un problème où l'ajout de fichiers aux packages dans l'éditeur de packages ne fonctionnait pas correctement
    • Nettoyage de l'interface utilisateur

    Pour accéder à l’outil, vous devez :

    • Participer au programme Windows Insider Fast ou Slow Ring
    • Avoir Windows 10 17701 ou plus
    • Avoir les droits d’administrateur sur la machine
    • Avoir un compte Microsoft pour accéder au Microsoft Store.

    Plus d'éléments sur le format MSIX sur MSIX Intro

    Télécharger MSIX Packing Tool

    • 15/2/2019

    [SCCM CB] La synchronisation des mises à jour Office 365 ProPlus échoue (Could not establish trust relationship for the SSL/TLS)

    Le problème décrit concerne System Center Configuration Manager et la gestion des mises à jour logicielles du client Office 365 et se produit depuis le 31 octobre 2018. La synchronisation peut échouer sur les métadonnées (fichier manifest) et vous observez les erreurs suivantes dans le fichier wsyncmgr.log :

    Synchronizing update 90eb5ec4-0e70-4498-8814-e2e90fe0b447 - Office 2019 Perpetual Enterprise Client Update Version Perpetual for x64 based Edition (Build 10338.20019)       
    ProcessFileManifest() failed to process O365 file manifest. Caught exception: System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.~~   at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)~~   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)~~   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)~~   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)~~   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)~~   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)~~   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)~~   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)~~   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)~~   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)~~   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)~~   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)~~   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)~~   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)~~   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)~~   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)~~   at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)~~   at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)~~   at System.Net.ConnectStream.WriteHeaders(Boolean async)~~   --- End of inner exception stack trace ---~~   at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)~~   at System.Net.WebClient.DownloadString(Uri address)~~   at Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.ProcessFileManifest_O365Service(String sO365ServiceUrl, XmlWriter xml)

    Failed to synchronize O365 update 90eb5ec4-0e70-4498-8814-e2e90fe0b447 - Office 2019 Perpetual Enterprise Client Update Version Perpetual for x64 based Edition (Build 10338.20019)

    Le problème peut venir de plusieurs éléments :

    • 15/2/2019

    [Windows 10] Le support de MSIX arrive sur Windows 10 1709 et 1803

    Microsoft vient d’annoncer que le support du format de packaging/application MSIX arrive sur Windows 10 1709 et 1803. Intégré dans Windows 10 1809, Microsoft permet ainsi de couvrir plus de cas d’usages et d’entreprises avec cette annonce. Vous pourrez donc facilement déployer ces packages via System Center Configuration Manager, Microsoft Intune, PowerShell, etc. Pour les versions 1709 et 1803, il n’est pas possible de les déployer via le Microsoft Store for Business puisque ce scénario requiert Windows 10 1809.

    Pour rappel, le format MSIX est un nouveau format standardisé lancé par Microsoft pour remplacer l’ensemble des formats de packaging existants tout en bénéficiant des avancés des différentes solutions : Click-To-Run (C2R), App-V, APPX et plus généralement du Framework d’applications universelles (UWP). Il offre donc des mécanismes de conteneurisation et les bénéfices des applications universelles avec une installation, mise à jour et désinstallation aisée sans laisser aucune trace sur le système. Il fournit aussi des mécanismes de sécurisation avancés permettant de valider l’intégrité du code exécuté. Ce format permet aussi de créer des personnalisations pour les applications packagées et de les faire perdurer au travers des différentes mises à jour de l’application.

    Pour plus d’informations pour ce support, rendez-vous sur l’article : MSIX support on Windows 10 builds 1709 and 1803

    Pour adapter des applications qui ne marcheraient pas sur Windows 10 1709/1803, vous pouvez consulter le lien suivant.

    Plus d'éléments sur le format MSIX sur MSIX Intro

    Source : https://techcommunity.microsoft.com/t5/MSIX-Blog/MSIX-Support-for-Windows-10-1709-and-1803-MSIX-Packaging-Tool/ba-p/325749

    • 14/2/2019

    [SCCM CB] Résoudre le prérequis en avertissement sur la version de SQL Server Native Client

    Depuis System Center Configuration Manager 1806, un nouveau prérequis tagué en avertissement et n’étant pas totalement bloquant pour la mise à niveau est apparu. Ce prérequis concerne la version de la dépendance SQL Server Native Client. Ce prérequis doit être mise à jour pour permettre notamment la prise en charge de TLS 1.2.

    Vous devez alors télécharger Microsoft SQL Server 2012 Native Client (ou directement ici) et remplacer la version actuellement installée sur votre système.

    Lancez l’installation. L’installeur vous signale qu’une version précédente est présente et qu’elle doit être mise à jour :

    Suivez ensuite les différentes étapes de l’installeur :

     

    Une fois installé, vous pouvez relancer le vérificateur de prérequis depuis la console pour valider que ce prérequis est correctement corrigé :

    • 13/2/2019

    [SCCM 1810] Le PXE ne fonctionne plus sur des points de distribution après la mise à niveau vers CM 1810 First Wave

    C’est un problème qui peut être rencontré lors de la mise à niveau d’une infrastructure System Center Configuration Manager vers la version 1810. Cela fait le second client avec qui nous rencontrons ce problème, c’est pourquoi je vous propose ce billet. Après la mise à niveau, il se peut que le PXE de votre point de distribution ne fonctionne plus. Ce problème touche les clients qui auraient utilisé la première version (first wave) de Configuration Manager 1810.

    En regardant le point de distribution, on peut observer que le rôle Windows Deployment Services (WDS) n’est plus présent :

    En allant voir, la vue v_DistributionPointInfo dans la base de données, on peut observer que :

    • Le flag IsPXE est à 0
    • Le flag RemoveWDS est à 1

    Pour résoudre le problème, vous devez décocher la case PXE sur le point de distribution, appliquer les paramètres et attendre un cycle de Site Component. Vous pouvez ensuite réactiver le PXE pour que l’installation de WDS soit ré initiée.

    • 12/2/2019

    [Windows 10] Quelles sont les applications incluses dans Windows ?

    A chaque nouvelle version de Windows 10, Microsoft ajoute ou supprime des applications universelles en fonction de sa stratégie. On retrouve deux types d’applications :

    • Les applications système: Celles-ci ne peuvent être modifiées/supprimées du système.
    • Les applications provisionnées (Solitaire, StickyNote, OneNote, etc.) qui pour la plupart peuvent être retirées du système afin qu’elles ne soient pas réinstallées à chaque création de profil utilisateurs.
    • Les applications Windows installées (Power BI, Pandora, etc.) qui peuvent être présentes en fonction de l’édition utilisées ou téléchargées automatiquement à l’ouverture de session. Ces applications peuvent aussi être supprimées.

    Les entreprises ont l’habitude de filtrer et adapter la liste des applications à leurs besoins via des cmdlets PowerShell (Remove-AppXProvisionedPackage) ou des scripts.

    L’article proposé par Microsoft résume les applications, le nom du package, les versions où elles sont présentes et s’il est possible de les désinstaller par l’interface. Cette page est un bon moyen d’adapter ses stratégies de déploiement de système d’exploitation (OSD) lors de la sortie d’une nouvelle version.

    Lire : Understand the different apps included in Windows 10

    • 12/2/2019

    [SCCM CB] Le téléchargement des mises à jour/mises à niveau échoue avec l’erreur 3 ou 0x80070003

    Lorsque vous utilisez la fonctionnalité de gestion des mises à jour logicielles de System Center Configuration Manager, vous pouvez rencontrer une erreur lors du téléchargement des mises à jour ou des mises à niveau. Ceci est particulièrement vrai si vous télécharger des mises à jour de type Unified Updates Platform (UUP). Néanmoins, vous pouvez tout de même rencontrer ce problème avec des mises à jour classiques.

    Le problème peut survenir que vous téléchargiez les mises à jour manuellement via l’assistant ou avec une règle de déploiement automatique.

    Le fichier Patchdownloader.log affiche les erreurs suivantes :

    Checking machine config

    Cert revocation check is disabled so cert revocation list will not be checked. To enable cert revocation check use: UpdDwnldCfg.exe /checkrevocation

    Verifying file trust C:\Users\JSDUCH~1.WIN\AppData\Local\Temp\CAB5042.tmp

    File trust C:\Users\JSDUCH~1.WIN\AppData\Local\Temp\CAB5042.tmp verified:

    Verifying file hash C:\Users\JSDUCH~1.WIN\AppData\Local\Temp\CAB5042.tmp

    File hash verified: C:\Users\JSDUCH~1.WIN\AppData\Local\Temp\CAB5042.tmp

    Failed to move C:\Users\JSDUCH~1.WIN\AppData\Local\Temp\CAB5042.tmp to \\WT-CM-PR1\ContentSources\Software Updates\SUP-Windows10-1803-Upgrade-UUP\acaef162-aec3-4f1f-9f7b-b31718b4c089.1\0C0449C21CB61182BD54FE6400F6AF42847A388F_Microsoft-Windows-LanguageFeatures-Fonts-PanEuropeanSupplementalFonts-Package~31bf3856ad364e35~amd64~~.cab, error 3

    Will retry in 5000ms

    Failed to move C:\Users\JSDUCH~1.WIN\AppData\Local\Temp\CAB5042.tmp to \\WT-CM-PR1\ContentSources\Software Updates\SUP-Windows10-1803-Upgrade-UUP\acaef162-aec3-4f1f-9f7b-b31718b4c089.1\0C0449C21CB61182BD54FE6400F6AF42847A388F_Microsoft-Windows-LanguageFeatures-Fonts-PanEuropeanSupplementalFonts-Package~31bf3856ad364e35~amd64~~.cab, error 3

    Will retry in 5000ms

    Failed to move C:\Users\JSDUCH~1.WIN\AppData\Local\Temp\CAB5042.tmp to \\WT-CM-PR1\ContentSources\Software Updates\SUP-Windows10-1803-Upgrade-UUP\acaef162-aec3-4f1f-9f7b-b31718b4c089.1\0C0449C21CB61182BD54FE6400F6AF42847A388F_Microsoft-Windows-LanguageFeatures-Fonts-PanEuropeanSupplementalFonts-Package~31bf3856ad364e35~amd64~~.cab, error 3

    ERROR: DownloadContentFiles() failed with hr=0x80070003

     

    En regardant de plus près, je vois la longueur du nom de fichier et j’essaye donc de récupérer le fichier tmp dans le dossier source puis de le renommer et le copier vers mon répertoire de source cible. La copie remonte que l’opération engendre un chemin trop long :

    Vous devez donc modifier et réduire la taille de votre répertoire source. Dans mon cas, voici le nom du répertoire avant : \\WT-CM-PR1\ContentSources\Software Updates\SUP-Windows10-1803-Upgrade-UUP

    L'erreur est plus susceptible d'arriver avec les mises à jour UUP car les binaires qui les en constituent ont des noms particulièrement long (par exemple acaef162-aec3-4f1f-9f7b-b31718b4c089.1\0C0449C21CB61182BD54FE6400F6AF42847A388F_Microsoft-Windows-LanguageFeatures-Fonts-PanEuropeanSupplementalFonts-Package~31bf3856ad364e35~amd64~~.cab)

    L’ensemble du chemin et du nom de fichier ne doit pas dépasser 260 caractères.

    • 11/2/2019

    [SCCM 1806] Les mises à jour logicielles ne se téléchargent pas si WSUS est déconnecté

    J’étais passé à côté de ce correctif (KB4465865) à destination de System Center Configuration Manager 1806 mais qui a toute son importance ! Ce dernier corrige plusieurs problèmes avec les mises à jour logicielles lors de l’utilisation des fichiers Express Updates. Le correctif est disponible directement dans la console depuis mi-octobre et je vous recommande sincèrement de l’appliquer.

    Problème 1 : Les mises à jour logicielles peuvent ne pas être téléchargées.

    Ceci survient dans le scénario suivant :

    • Après la mise à jour vers ConfigMgr 1806,
    • Ceci se produit dans les environnements qui utilisent Windows Server Update Services (WSUS) sur un réseau déconnecté.

    Ce changement a été introduit dans la version 1806 puisqu’elle recherche toujours les fichiers CAB d'installation express qui, par défaut, ne sont pas présents dans un scénario WSUS déconnecté.

    Une tentative de téléchargement a lieu pour toute mise à jour du logiciel (y compris les mises à jour non Windows 10) qui contient des fichiers d'installation express. La tentative de téléchargement se produit également si le support des Express Updates n'est pas activé.

    Le fichier Patchdownloader.log affiche des messages comme suit :

    Downloading content for ContentID = <ContentID>, FileName = <Filename-EXPRESS.cab>
    Download \\<server>\WsusContent\<Filename-EXPRESS.cab> to <Temporary Files>\CABA83C.tmp returns 2
    Download \\<server>\WsusContent\<Filename-EXPRESS_hash.cab> to <Temporary Files>\CABA83D.tmp returns 2
    Download \\<server>\WsusContent\WsusContent\C1\<hash.cab> to <Temporary Files>\CABA83E.tmp returns 3
    Download \\<server>\WsusContent\C1\<hash.cab> to <Temporary Files>\CABA84F.tmp returns 2
    ERROR: DownloadContentFiles() failed with hr=0x80070002

    Problème 2 :  Quand vous migrez à partir ou vers ConfigMgr 1806, la migration des packages de contenu pour les mises à jour qui prennent en charge les Express Updates échoue ou peut ne pas contenir toutes les mises à jour.

    Ce problème se produit dans les hiérarchies qui n'ont pas activé l'option suivante dans l'onglet "Update files" des propriétés de Software Update Point : Download both full files for all approved updates and express installation files for Windows 10

     

    Problème 3 : Pour les mises à jour logicielles qui contiennent des Express Updates, Configuration Manager synchronise le fichier Express.cab et le distribue au client. Ce comportement se produit même si le client n'a pas besoin du fichier Express.cab pour un déploiement donné.

    L'installation du correctif interrompt les tentatives de téléchargement inconditionnel des fichiers CAB express pour les nouvelles mises à jour. Une fois le correctif installé, le téléchargement n'aura lieu que si la prise en charge du fichier d'installation express est activée pour les mises à jour Windows 10.

    • 11/2/2019

    [Intune] Changement de comportement sur le téléchargement des applications sur Windows 10

    Microsoft a réalisé un changement sur le comportement du téléchargement des applications sur des périphériques Windows 10 gérés de manière moderne avec Microsoft Intune. Les clients avaient l’habitude de tomber en timeout après 10 minutes de téléchargement. Ce timeout a été augmenté à 12 heures pour permettre de prendre en compte de larges applications qui pourraient faire jusqu’à 8GB (la limite actuelle)

    • 10/2/2019

    [Intune] Le module PowerShell est disponible dans la galerie PowerShell

    Il y a quelques mois, je vous annonçais que Microsoft publiait le module PowerShell pour Microsoft Intune sur GitHub. Aujourd’hui, Microsoft publie ce module directement sur Microsoft PowerShell Gallery. Ce module utilise directement l’API Microsoft Graph pour administrer Intune.

    Pour l’installer, vous pouvez directement utiliser la commande :

    Install-Module -Name Microsoft.Graph.Intune

    Vous pouvez retrouver des exemples d’usages.

    Accéder au module sur la galerie PowerShell

    • 10/2/2019

    [AIP] Considérations lors de l’implémentation d’Azure Information Protection

    Aujourd’hui, je souhaitais partager une considération lors de l’implémentation d’Azure Information Protection dans votre entreprise. Pour rappel, Azure Information Protection permet de classifier et labéliser la donnée au moment de la création en fonction de différentes étiquettes et catégories. L’administrateur peut ensuite appliquer des stratégies de protection embarquée dans la donnée en fonction de la classification appliquée. Ce service est issu du rachat de Secure Islands et du retravaille d’Azure Rights Management (RMS).

    Parmi les questions que l’on a lors des phases d’Avant-Vente sur ce genre de solutions ainsi que pour le Cloud, c’est : Est-ce que l’on peut faire un retour arrière ?

    La réponse est oui puisque les super utilisateurs (super user) peuvent déchiffrer tous les fichiers de l’entreprise. Vous pouvez aussi utiliser les cmdlets PowerShell via Unprotect-RMSFile

    Plus globalement, je pense que le point d’attention n’est pas nécessairement sur la sortie de la solution mais sur les éventuels scénarios qui pourraient survenir lors de la vie de l’entreprise. On peut par exemple penser aux rachats, fusions, etc. Ou tout simplement à un changement de tenant Azure Active Directory.

    Il est possible d’exporter la clé de chiffrement d’un tenant et l’importer sur un nouveau tenant mais ceci ne peut pas être réalisé avec la clé par défaut.

    Dans ce cas de figure, il faut peut-être penser à ces aspects en avance de phase lors de l’implémentation pour éviter à devoir déchiffrer entièrement le contenu pour le rechiffrer. On retrouve plusieurs capacités :

    • Se donner la possibilité d’exporter une clé de chiffrement afin de la déplacer entre tenants. Pour cela vous pouvez :
      • Utiliser votre propre clé via le principe de Bring Your Own Key (BYOK).
      • Créer une clé dans l’Azure Key Vault (sans BYOK) et suivre la procédure BYOK avec cette clé.

    Lors de la migration, vous devez exporter la clé puis supprimer la clé du tenant original et enfin importer la clé sur le nouveau tenant. Vous devez aussi recréer les modèles, les utilisateurs, etc. Bien entendu, je ne peux que conseiller de valider la procédure sur un tenant de tests pour s’assurer qu’il n’y a pas d’effets de bord.

    • Utiliser Active Directory Rights Management Services (AD RMS) comme source de clés.
      • Déployer AD RMS avec le type de clé voulu
      • Exporter la clé et les modèles vers Azure RMS en utilisant le guide Azure RMS Migration
      • Répéter l’opération sur l’éventuel nouveau tenant.

    Personnellement, je préfèrerais le scénario 1.

    Bien entendu, il existe d’autres considérations sur les étiquettes/labels, etc.

    • 9/2/2019

    [SCCM] La Technical Preview 1902 de System Center Configuration Manager est disponible

    Microsoft vient de mettre à disposition la Technical Preview 1902 (5.0.8782.1000) de System Center Configuration Manager. Pour rappel, ConfigMgr a subi une refonte de sa structure pour permettre des mises à jour aisées de la même façon que l’on peut le voir avec Windows 10. Si vous souhaitez installer cette Technical Preview, vous devez installer la Technical Preview 1804 puis utiliser la fonctionnalité Updates and Servicing (nom de code Easy Setup).

    System Center Configuration Manager TP 1902 comprend les nouveautés suivantes :

    Administration

    • Microsoft permet de remplacer les notifications (ou toast) du client pour un déploiement requis ou un redémarrage par des fenêtres plus intrusives (non personnalisables). Vous pouvez configurer cette option en déployant une application/de mise à jour ou de séquences de tâches comme requise puis sur la page User Experience, vous devez sélectionner Display in Software Center and show all notifications avec l’option When software changes are required, show a dialog window to the user instead of a toast notification. L’autre option permet de le faire plus globalement depuis les paramétrages du client.

    • C’est une problématique fréquemment abordée par les utilisateurs du HelpDesk lors de l’utilisation de l’outil Remote Control avec plusieurs écrans. Ce dernier permet maintenant de choisir entre voir tous les écrans ou uniquement le premier écran (situé en haut à gauche des paramètres d’affichage de Windows). Il n’est pas possible de choisir un écran spécifique.
    • Vous pouvez maintenant modifier ou copier un script PowerShell existant utilisé avec la fonction Run Scripts. Au lieu de recréer un script que vous devez modifier, éditez-le directement. Lorsque vous modifiez ou copiez un script, ConfigMgr ne maintient pas l'état d'approbation. Il n’est pas recommandé de modifiez un script qui s'exécute activement sur des clients. Ils ne finiront pas d'exécuter le script original, et vous n'obtiendrez peut-être pas les résultats attendus de ces clients.
    • Vous pouvez maintenant Cloud Management Gateway (CMG) à un groupe de limites. Cette configuration permet aux clients de communiquer avec la CMG par défaut ou de basculer en fonction des relations entre les groupes de limites. Ce comportement est utile dans les scénarios de sites distants et de VPN. Vous pouvez détourner le trafic client des liens WAN lents et coûteux pour utiliser des services plus rapides dans Microsoft Azure.
    • De nouvelles améliorations au Software Center permettant de :
      • Définir la mise en page par défaut des applications, soit sous forme de tuiles, soit sous forme de liste. Si un utilisateur modifie cette configuration, la configuration du Software Center persiste dans les préférences de l'utilisateur à l'avenir.
      • Configurer le filtre d'application par défaut, soit toutes les applications, soit uniquement les applications requises. Le Software Center utilise toujours vos paramètres par défaut. Les utilisateurs peuvent changer ce filtre, mais le Software Center ne persiste pas le choix de l’utilisateur.
      • Utiliser une nouvelle interface pour configurer la visibilité des onglets

    • Amélioration du tableau de bord sur l’état de santé du client (Client Health Dashboard) :
      • Amélioration et rationalisation de la mise en page
      • Possibilité de cliquer sur les tuiles pour accéder aux listes des périphériques
      • Modifications visant à améliorer le rendement pour de gros environnements

     

    Déploiement de système d’exploitation

    • La barre de progression des séquences de tâches de mises à niveau de Windows 10 affiche plus de détails avec l’état d’avancement du Setup (Installeur) de Windows.

    Gestion de conformité et des paramétrages

    • Configuration Manager permet de déplacer les dossiers Windows connus (Bureau, Documents, etc.) vers OneDrive for Business. Cette fonctionnalité intégrée à Windows est apparue dans la version 1809. Elle est configurable par GPO et dorénavant par SCCM. Ceci permet de simplifier l’accompagnement utilisateur et le scénario de mise à niveau vers Windows 10 pour ne plus avoir à gérer la récupération des données utilisateurs.
      Note : Un bug dans cette Technical Preview engendre un crash de la console. Une fois la stratégie créée, il est recommandé de réaliser le déploiement ou la suppression via des cmdlets PowerShell.

     

    Plus d’informations sur : https://docs.microsoft.com/en-us/sccm/core/get-started/2019/technical-preview-1902

    • 9/2/2019

    [AIP] Utiliser l’intégration d’Adobe pour protéger vos documents

    Microsoft et Adobe se sont associés pour permettre l’intégration du framework Microsoft Information Protection afin de protéger les documents PDF avec Azure Information Protection. On voit apparaître certaines demandes où les labels (étiquettes) n’apparaissent pas dans Adobe Reader après l’installation du plugin.

    En outre, vous devez configurer la valeur de registre (DWORD) bShowDMB à 1 dans : Computer\HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\DC\MicrosoftAIP

    Notez que la clé MicrosoftAIP ne doit pas être créée à la main. Cette dernière est créée automatiquement lors de l’ouverture d’un document PDF protégé (PPDF)

    Outre ce prérequis, il est nécessaire que les labels/étiquettes apparaissent dans le centre de Sécurité et Conformité (Security and Compliance Center). Si les labels sont visibles et publiés par une stratégie d’étiquette (label policy) depuis le portail SCC, alors l’intégration d’Adobe Reader fonctionnera. Ceci fait appel à la fonctionnalité d’Unified Labeling qui est toujours en Preview. La migration des labels entre AIP et Office 365 SCC peut ne pas être disponible sur votre tenant.

    Pour implémenter l’intégration d’AIP et Adobe, vous pouvez suivre le lien : https://aka.ms/AdobeMIPGA

    • 5/2/2019

    [Intune] Changement du processus d’enregistrement pour iOS 12

    Microsoft a publié dans le Message Center à propos d’un changement qui va survenir pour l’enregistrement des périphériques iOS 12. Ce changement a été annoncé par Apple et concerne tous les services MDM tels que Microsoft Intune. Avec les versions d’iOS 12 qui seront publiées au printemps, l’utilisateur devra changer les étapes d’enregistrement de son périphérique :

    • Téléchargement du portail d’entreprise
    • Lancement du processus d’enregistrement dans le portail d’entreprise et téléchargement du profil d’administration.
    • L’utilisateur doit aller dans Settings > General > Profiles puis sélectionner le profil correct et sélectionner Install.
    • Retourner sur le portail d’entreprise pour finaliser l’enregistrement.

    Les périphériques qui sont déjà enregistrés et mis à jour vers cette nouvelle version d’iOS ne seront pas affectés à part si le périphérique est désenregistré et procède à un nouvel enregistrement.

    Vous devez donc mettre à jour vos documentations à destination des utilisateurs mais aussi informer correctement votre help desk.

    Plus d’informations sur : https://aka.ms/iOS_enrollment_changes

    • 5/2/2019

    [Intune] Mise à jour d’un paramétrage pour les périphériques iOS supervisés (Enabling restrictions in the device settings)

    Microsoft a publié dans le Message Center à propos d’un changement qui va survenir dans la mise à jour de Février 2019 de Microsoft Intune. Le paramétrage ‘Enabling restrictions in the device settings’ pour les périphériques supervisés iOS est renommé en ‘Screen Time (supervised only)

    Il faut surtout noter que le comportement côté utilisateur final va changer en fonction de la version d’iOS :

    • Pour les périphériques iOS 11.4 et antérieur : Le paramétrage peut être utilisé pour empêcher les utilisateurs de modifier les restrictions de périphériques comme auparavant. Dans ce cas, il n’y a pas de changement de comportement.
    • Pour les périphériques iOS 12 et plus, les utilisateurs ne pourront plus voir l’onglet Restrictions tab sous Settings > General > Device Management > Management Profile > Restrictions. En lieu et place ceci sera présent dans Settings > General > Screen Time.

    La configuration du paramétre Screen Time (Supervised Only) à Block, bloquera les utilisateurs sur le changement des paramétrages Temps d’écran, ce qui inclut le contenu et les restrictions de vie privée.