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...)
    • 22/2/2019

    [AIP] Choisir l’option définie par défaut avec le bouton Encrypt dans Outlook

    Depuis la version 16.0.11023+ du client Office 365 ProPlus, il est désormais possible de choisir l’option sélectionnée par défaut quand on choisit le bouton Encrypt dans Outlook lors de l’utilisation d’Azure Information Protection (AIP).

    Par défaut le bouton Ecnrypt applique l’option Encrypt-Only (pour les utilisateurs d’Exchange Online). Dans Outlook Web Access, le bouton Protect applique aussi la stratégie Encrypt-Only.

    Sur Outlook, vous pouvez changer cette valeur en configurer la valeur de registre DefaultPermissionTemplateGuid au niveau de la clé HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\DRM en spécifiant :

    • Un GUID correspondant au modèle que vous souhaitez appliquer quand l’utilisateur clique sur le bouton Encrypt. Si le GUID n’est pas valide ou disponible, alors le bouton réagit comme prévu par défaut (Encrypt Only)
    • smime: L’option de chiffrement S/MIME est alors utilisée.
    • Irmdnf : L’option Do Not Forward est appliquée
    • Irmencrypt : L’option Encrypt est appliquée.

    Vous pouvez aussi configurer ces options via les modèles d’administration d’Office dans la partie User Configuration > Administrative Templates > Microsoft Outlook 2016 > Security > Cryptography. Le paramétrage Configure default encryption option for the Encrypt button permet de gérer ce comportement avec les mêmes options que spécifiées plus haut.

    Notez que pour l’instant ces possibilités en sont pas offertes pour Outlook sur Mac.

    • 21/2/2019

    Disponibilité Générale de Windows Admin Center 1902

    Microsoft vient d’annoncer la disponibilité générale de la nouvelle interface graphique permettant de gérer les infrastructure Windows Server : Windows Admin Center en version 1902. Outre cette publication, Microsoft propose aussi le Software Development Kit (SDK) pour étendre les capacités de l’interface. Pour rappel, Windows Admin Center permet de gérer tous les rôles des infrastructures Windows Server (File Server, Hyper-V, Storage Replica, Cluster, etc.) ainsi que de s’interconnecter à des services Azure.

    Parmi les nouveautés, on retrouve notamment les capacités :

    • Microsoft publie la capacité de créer une liste de connexions unique qui peut être partagée entre tous les utilisateurs de WAC. Pour ajouter des serveurs, des clusters et des PC comme connexions partagées, vous devez être un administrateur de WAC. Allez dans Gateway Settings > Shared Connections, puis ajoutez des serveurs, des clusters et des PC comme vous le feriez normalement. Vous pouvez également baliser les serveurs dans ce volet, et ces balises apparaîtront pour tous les utilisateurs. Les balises sont immuables depuis la page d'accueil "Toutes les connexions", ce qui signifie que les utilisateurs WAC ne peuvent pas modifier les balises sur les connexions de serveur partagé.

    Pour les personnes qui utilisent RDCman, Microsoft a publié un script que vous pouvez utiliser pour exporter vos connexions RDCman sauvegardées vers un fichier.CSV que vous pouvez ensuite importer avec PowerShell pour maintenir toute votre hiérarchie de regroupement RDCman en utilisant des balises.

     

    Pour le Software Defined Networking (SDN) :

    • Nouvel outil de gestion des Access Control List. Avec le SDN, vous pouvez utiliser des listes de contrôle d'accès (ACL) pour gérer le flux de trafic de données à l'aide du pare-feu du datacenter et des ACL des sous-réseaux virtuels. Vous pouvez activer et configurer les règles du pare-feu du datacenter en créant des listes de contrôle d'accès qui seront appliquées à un sous-réseau virtuel.
    • Nouvel outil SDN Gateway est un logiciel multi-tenant conçu pour les routeurs BGP à destination des Cloud Service Providers (CSPs) et entreprises qui hébergent plusieurs réseaux virtuels de tenants en utilisant la virtualisation de réseau d’Hyper-V. Vous pouvez gérer et surveiller les connexions aux passerelles dans un environnement SDN en supportant trois types de connexions : IPSEC, GRE, L3
    • Nouvel Outil Logical Network Management permettant de gérer et superviser les réseaux logiques.
    • Vous pouvez maintenant choisir de connecter une VM à un VLAN ou à un réseau virtuel dans un environnement SDN

     

    Pour les entreprises qui utilisent la version 1809 de Windows Admin Center, vous devez mettre à jour vers la version 1902 dans les 30 jours pour rester supporter.

    Télécharger Windows Admin Center 1902

    • 21/2/2019

    [SCCM CB] Maximiser la réussite de la mise à niveau vers une nouvelle version de Windows 10

    Beaucoup d’entreprises utilisent System Center Configuration Manager Current Branch pour mettre à niveau les machines Windows 10 vers une version (Build) plus récente du système. On retrouve différentes possibilités de mises à niveau :

    • Utiliser une séquence de tâches qui comprend l’orchestration de prérequis (mise à jour de l’antivirus, etc.) puis chargement de l’image ISO afin de mettre à jour le système d’exploitation.
    • Utiliser la fonctionnalité Windows 10 Servicing qui implique l’usage des mises à jour pour déployer ces nouvelles versions. Cette méthode a un inconvénient : Elle ne permet pas l’orchestration d’actions de pré-installation (mise à jour de l’antivirus, mise à jour de certaines applications etc.). En outre, actuellement elle ne permet pas de prendre en compte les packs de langues, les fonctionnalités à la demande (On-Demand Features) mais ces limitations vont être levée avec l’arrivée des mises à jour Unified Updates Platform (UUP). Cette méthode reste la plus adéquate pour l’utilisateur car la majorité du travail peut se faire en tâche de fond et l’indisponibilité de la machine est alors fortement réduite.

    Comment optimiser la mise à niveau d’une version de Windows 10 via la fonctionnalité Windows 10 Servicing ?

    Outre les problèmes de compatibilité (antivirus, chiffrement, applications, et drivers, etc.), un des principaux problèmes est lié au temps d’exécution de ces mises à niveau qui peuvent dépasser le temps maximal défini par défaut (60 minutes sur les précédentes versions : 1709, 1803, 1809). Le timeout n’est appliqué que lors de la phase s’exécutant sur le système d’exploitation d’origine.

    Ceci est devenu problématique car à partir de Windows 10 1709, l’installeur Windows est configuré pour s’exécuter avec une priorité faible afin de ne pas impacter la productivité de l’utilisateur (Ceci n’est pas valable pour mise à niveau avec une séquence de tâches).  En outre, Microsoft a transféré l’exécution de nombreuses opérations dans le système d’exploitation d’origine et non plus dans la phase Windows RE ou de premier démarrage.

    Afin d’assurer un meilleur taux de succès, vous pouvez :

    Possibilité N°1 : Manuellement augmenter la durée maximale d’exécution timeout à une valeur plus adéquate à votre parc (en fonction des performances matérielles par exemple). Vous pourriez ainsi passer ce seuil de 60 minutes à 180 minutes.

    Pour ce faire, ouvrez la console d’administration et naviguez dans Software Library – Windows 10 Servicing – All Windows 10 Updates.

    Identifiez la mise à niveau que vous devez/avez déployé :

    Ouvrez les propriétés et l’onglet Maximum Run Time. Passez la valeur de 60 minutes à 120 par exemple. Adaptez la valeur selon vos besoins et votre expérience.

    Appliquez la valeur et réajuster au fil de vos tests.

     

    Possibilité N°2 : ajuster la priorité depuis ConfigMgr Technical Preview 1901 ou 1902 d’exécution de faible (Low) à Normal en ouvrant la console d’administration et naviguant dans Software Library – Windows 10 Servicing – All Windows 10 Updates.

    • 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

    • 17/2/2019

    [SCCM 1810] Publication du Correctif (KB4486457) pour Configuration Manager 1810

    L’équipe ConfigMgr a publié un correctif à destination de System Center Configuration Manager 1810. Le correctif s’applique au serveur de site, aux consoles, et aux clients pour des infrastructures qui ont installé l’une des versions avec les GUIDs suivants :

    • 699975FE-B5BA-43EB-8BE9-E2399F2F309A
    • 85475BAD-8669-4D36-8D64-C625BFE7DEDB
    • ACF6EECC-1C94-44E3-887E-D3349775816D
    • C8799F92-DC23-42A0-96FA-1862414C3967

    Note : les sites secondaires doivent être mis à jour manuellement et une procédure permet de vérifier la mise à jour effective de leurs bases de données.

    Parmi les corrections pour la première vague, on retrouve :

    • La synchronisation des mises à jour Office 365 peut échouer après la mise à jour de la de Configuration Manager, version 1810. Les messages d'erreur qui ressemblent à l'un des messages suivants sont enregistrés dans le fichier WSyncMgr.log :
      ProcessFileManifest() failed to process O365 file manifest. Caught exception: System.Net.WebException: An exception occurred during a WebClient request.
      ProcessFileManifest() failed to process O365 file manifest. Caught exception: System.UriFormatException: Invalid URI: The URI scheme is not valid.
    • Le processus de mise à niveau du point de distribution peut échouer. Cela entraîne un bloc de distribution de contenu supplémentaire vers ce serveur. Les messages d'erreur qui ressemblent à ce qui suit sont enregistrés dans le fichier distmgr.log :
      Failed to copy D:\SRVAPPS\Microsoft Configuration Manager\bin\x64\ccmperf.dll to \\{server}\SMS_DP$\sms\bin\ccmperf.dll. GLE = 32
    • Toutes les mises à jour remplacées sont supprimées et ne sont plus applicables à un client, même avant leur expiration. Ce problème se produit même si l'option Do not expire a superseded software update until the software update is superseded for 3 months est activée.
    • Des améliorations de performance ont été apportées au service de réplication des données pour les données de découverte des périphériques.
    • La deuxième phase et les phases successives d'un déploiement démarrent automatiquement après le succès de la première phase, quelles que soient les conditions de démarrage.
    • Les paramètres de comportement des délais de déploiement échelonné ne sont pas cohérents entre les propriétés de l'Assistant de Create Phased Deployment et celles des Phase Settings.
    • Lorsque vous exécutez un Servicing Plan après avoir sélectionné une catégorie de produit, le filtre n'est pas ajouté correctement.
    • Le service de contenu CMG (Cloud Management Gateway) n'est pas créé correctement lorsque le rôle CMG est ajouté après la mise à jour de Configuration Manager, version 1810.
    • L'option No deployment package est sélectionnée lorsque vous modifiez les propriétés d'une règle de déploiement automatique (ADR). Après l'application de ce rollup de mise à jour, les ADRs affectés peuvent être recréés et leurs propriétés peuvent être modifiées sans autre problème.
    • Le moteur de traitement des messages (Message Processing Engine) ne traite pas toujours les données de découverte Active Directory lorsque des attributs optionnels sont ajoutés. Les erreurs qui ressemblent à ce qui suit sont enregistrées dans le fichier SMS_Message_Processing_Engine.log :
      ERROR: Got SQL exception when handle discovery message. Exception: System.Data.SqlClient.SqlException (0x80131904): String or binary data would be truncated.~~
    • L'outil Service Connection Tool (serviceconnection.exe) échoue et vous recevez le message d'erreur suivant lorsque vous utilisez le paramètre -connect :
      ERROR: System.IO.Exception : The directory is not empty.
    • Un utilisateur ne disposant pas des droits d'administrateur complet peut ne pas être en mesure de créer ou de modifier des stratégies ATP Windows Defender, même si vous les ajoutez au rôle de sécurité de Endpoint Protection Manager.
    • Le Vérificateur d'installation des conditions préalables donne incorrectement la possibilité de réessayer une installation sur site. Si une deuxième tentative est tentée, l'administrateur doit exécuter l'outil CMUpdateReset.exe (Configuration Manager Update Reset Tool) pour résoudre le problème.
    • Le traitement des fichiers .bld par le composant SMS_Notification_Manager prend plus de temps que prévu. Cela entraîne des retards dans le traitement des données et un arriéré de fichiers dans le dossier \inboxes\bgb.box.
    • Après la mise à jour de Configuration Manager, version 1810, les providers SQL distants qui utilisent Microsoft SQL Server 2014 ou une version antérieure peuvent ne pas toujours interroger la base de données. Les erreurs qui ressemblent à ce qui suit sont enregistrées dans le fichier smsprov.log :
      *** [42000][2571][Microsoft][SQL Server Native Client 11.0][SQL Server]User <provider_server>$' does not have permission to run DBCC TRACEON.
    • Le composant Software Updates Patch Downloader effectue jusqu'à trois tentatives de mise à jour. Ces tentatives échouent et renvoient le code d'erreur 404.
    • Les mises à jour de Windows Server 2016 s'affichent de manière incorrecte lorsque vous planifiez les mises à jour d'une image du système d'exploitation Windows Server 2019.
    • La recherche du prénom, du nom de famille ou du nom complet d'un utilisateur ne renvoie aucun résultat dans la section Overview du nœud Assets and Compliance de la console Configuration Manager. Ce problème se pose même lorsque des données complètes sur la découverte sont disponibles.

     

    Parmi les corrections pour le déploiement généralisé, on retrouve :

    • Après avoir activé le support des fichiers d'installation express, le contenu peut ne pas toujours être téléchargé à partir des serveurs Windows Server Update Services (WSUS) dans les scénarios suivants :
      • Installation du client Configuration Manager via le Software Update Point
      • Installer les mises à jour directement à partir de WSUS
      • Acquisition d'une fonctionnalité à la demande (Features On Demand) ou d'un pack de langues (LP) sous Windows.
    • Après la mise à jour vers Configuration Manager, version 1810, l'enregistrement des périphériques peut écraser les valeurs de collecte de télémétrie de Windows qui étaient précédemment définies par la stratégie de groupe. Ce problème peut entraîner le basculement de la valeur entre le mode complet et le mode basique, par exemple, lorsque la stratégie de groupe est appliquée.
    • L'inventaire matériel est mis à jour pour inclure des informations sur les modules complémentaires pour Office365 et les produits Office autonomes.
    • Les plans de déploiement de Desktop Analytics montrent un plus grand nombre de périphériques dans la console Configuration Manager que dans le portail Desktop Analytics.
    • L'installation du client Configuration Manager peut échouer à cause d'une connexion réseau taxée (par exemple, cellulaire). Cela peut se produire même si les paramètres de stratégie du client le permettent. Un message d'erreur qui ressemble à ce qui suit est enregistré dans le fichier Ccmsetup.log du client :

    Client deployment cannot be fulfilled because use of metered network is not allowed.

    • L'installation du client peut échouer à cause des changements de schéma CE de SQL Server. Les erreurs qui ressemblent à ce qui suit sont enregistrées dans le fichier Ccmsetup-client.log du client :
      MSI: Setup was unable to compile Sql CE script file %windir%\CCM\DDMCache.sqlce. The error code is 80040E14.
    • Si une application est dans un état de conformité partielle et que le client voit qu'une dépendance est installée mais que l'application principale ne l'est pas et nécessite une ré application, le déploiement disponible entraîne les problèmes suivants :
      • L'application est affichée comme requise ou en retard même si le déploiement est disponible et qu'il n'y a pas de relation de remplacement.
      • Cliquer sur Installer n'a aucun effet.
    • La connexion aux services Azure échoue lorsque vous utilisez le workflow de création dans l'assistant Azure Services Wizard, même lorsque les informations d'identification correctes sont utilisées.
    • L’installeur Configuration Manager peut échouer la vérification préalable lors de l'installation ou de la mise à jour d'un serveur de site. Ce problème se produit si l'environnement utilise SQL Always On. La règle "Firewall exception for SQL Server" affiche l'état d'échec et les messages d'erreur qui ressemblent à ce qui suit sont enregistrés, même si les exceptions pare-feu correctes sont configurées :
      ERROR: Failed to access Firewall Policy Profile.

    ERROR: Failed to connect to WMI namespace on <SQL Listener>

    Firewall exception for SQL Server; Error; The Windows Firewall is enabled and does not have exceptions configured for SQL Server or the TCP ports that are required for intersite data replication.

    • Le serveur de téléchargement alternatif répertorié dans la fenêtre " pecify intranet Microsoft update service location" ne se propage pas dans les paramètres de stratégie de groupe du client.
    • Le téléchargement des mises à jour Office 365, telles que "Semi-annual Channel Version 1808 for x86 Build 10730.20264" ou "Monthly Channel Version 1812 for x64 Build 11126.20196" peut échouer. Aucune erreur n'est enregistrée dans le fichier Patchdownloader.log. Toutefois, les entrées qui ressemblent à ce qui suit sont enregistrées dans le journal AdminUI.log :
      (SMS_PackageToContent.ContentID={content_ID},PackageID='{package_ID}') does not exist or its IsContentValid returns false. We will (re)download this content.

    Pour installer la mise à jour, rendez-vous dans la partie Updates and Servicing de la console d’administration.

     

    Plus d’informations sur la KB4486457 : Update rollup for System Center Configuration Manager current branch, version 1810

    • 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.