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

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

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

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 :

• Le pare-feu de l’entreprise. Assurez-vous que l’URL suivante est autorisée https://config.office.com/api/filelist/*. Vous pouvez valider en faisant un telnet config.office.com 443.
• Les APIs Office ont été mises à jour pour supprimer le support de TLS 1.0 et TLS 1.1. Vous devez maintenant utiliser TLS 1.2. Dans ce cas de figure, vous devez activer TLS 1.2 pour ConfigMgr via la procédure : https://support.microsoft.com/en-us/help/4040243/how-to-enable-tls-1-2-for-configuration-manager

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

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é :

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.

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

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.

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.

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)

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

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.

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

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

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

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.

Un client a fait face à une problématique assez intéressante avec Windows 10. Lors du déploiement du poste de travail lors de la phase OOBE et de premier démarrage, le poste reste bloqué sur Please Wait/Veuillez Patienter indéfiniement. L’arrêt et le redémarrage du poste permet de résoudre le problème.

Ce problème est lié à l’utilisation de la GPO de Groupes Restreints (Restricted Groups) pour configurer le groupe des administrateurs Locaux. Si vous utilisez ce paramètre, vous devez ajouter le compte utilisateur defaultuser0 au BUILTIN\Administrators.

Microsoft vient de publier une nouvelle version du pack d’administration ou Management Pack (MP) pour le rôle DNS Server en version 10.0.9.2. Il supporte uniquement le rôle DNS sur Windows Server 2016. Il supporte aussi la configuration avec Nano Server. Pour rappel, System Center Operations Manager (SCOM) fait partie de la gamme System Center, il propose une supervision souple et évolutive de l’exploitation au niveau de toute l’entreprise, réduisant la complexité liée à l’administration d’un environnement informatique, et diminuant ainsi le coût d’exploitation. Ce logiciel permet une gestion complète des événements, des contrôles proactifs et des alertes, et assure une gestion des services de bout en bout. Il établit des analyses de tendance et des rapports, et contient une base de connaissances sur les applications et le système.

Il apporte les éléments suivants :

• Correction d'un bug : Problème avec la découverte des zones DNS pour un grand nombre de zones.
• Correction d'un bug: Problème avec la découverte de zones stub.
• Correction d'un bug: Fausses alertes pour "DNS unused Zone Detected".
• Support de Windows Server 1709+.
• ebranding des chaînes d'affichage et des articles de la base de connaissances en fonction des versions prises en charge des systèmes d'exploitation : Microsoft Windows Server 2016 et 1709+.

Lisez le guide d’implémentation et n’oubliez pas de créer un Management Pack non scellé dédié.

Télécharger Microsoft System Center Management Pack for DNS 2016

Microsoft vient de publier le SDK 1.1 de Microsoft Information Protection (MIP). Pour rappel, Microsoft Information Protection est l’extension d’Azure Information Protection pour permettre de l’intégrer à des applications tierces ou développées en interne. Cette version apporte le support :

• iOS (Policy API uniquement)
• Android (Policy API et Protection API)

Microsoft a aussi amélioré la performance et la fiabilité.

Plus d’informations sur les nouveautés.

Télécharger le SDK sur ce site ou via NuGet (Microsoft.InformationProtection.*)

Microsoft vient de lancer globalement le programme Desktop App Assure annoncé à l’occasion de Microsoft Ignite. Ce programme gratuit pour toutes les entreprises ayant acheté Windows Enterprise, permet d’obtenir une assistance de la part de Microsoft pour adresser les problèmes de compatibilité applicative avec Windows 10 et Office 365 ProPlus. Ce programme se fait au travers de FastTrack pour permettre d’aider les clients dans la transition vers Windows 10. Les scénarios suivants peuvent être envisagés :

• Application (ou Plugin Office) acheté : Dialogue et mise en relation avec l’éditeur afin de le convaincre et l’aider dans la démarche de mise en compatibilité
• Application Métier (ou Plugin Office) développée en interne : Evaluation du travail de mise en compatibilité et échange pour réaliser les développements nécessaires.

Plus d’informations sur : https://www.microsoft.com/en-us/fasttrack/microsoft-365/desktop-app-assure