Dans Intune, les stratégies de déploiement des mises à jour Windows sont découpés en deux principales catégories :
- Update rings for Windows 10 and later
- Feature updates for Windows 10 and later
Si vous créez une stratégies de déploiement Update rings for Windows 10 and later et la déployez sur un groupe d'ordinateurs, les appareils Windows 10/11 vont récupérer les dernières mises à jour de qualité mais aussi de fonctionnalités (Feature updates).
Exemple : un ordinateur sous Windows 10 20H2 passera à 21H2
Dans un scénario où on souhaite bloquer les mises à jour de fonctionnalités Windows 10/11 sur une version bien définie, il faut cibler les ordinateurs concernés par une stratégie Feature updates for Windows 10 and later.
Exemple : dans les paramètres de la stratégie, on définie la version 20H2 --> les ordinateurs seront bloqués sur cette version jusqu'à ce que l'administrateur choisisse de les mettre à jour vers une version ultérieure de Windows.
Tant que la version de fonctionnalités reste statique, les ordinateurs peuvent continuer à installer les mises à jour de qualité et de sécurité disponibles pour leur version de fonctionnalité.
Windows Error reporting aussi abrégé WER a été introduit depuis Windows Vista et permet de générer un fichier de dump lorsqu'un processus crash. C'est particulièrement utile car tous les processus ne génèrent pas forcément leur propre logs.
Identifier le processus fautif
L'identification du processus qui crash se fait à l'aide du gestionnaire d'événement ou event viewer en anglais. Il permet d'accéder à plusieurs informations du crash tel que l'heure et le nom du processus en erreur.
Dans l'exemple suivant, on voit que c'est une défaillance du process lsass.exe qui fait planter la machine et le module responsable du crash de lsass.exe est ntdll.dll
Activer la génération de crash dump pour le processus en erreur
- Ouvrir l'éditeur de registre regedit sur le serveur qui est concerné par le crash
- Naviguer jusqu'à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
- Créer une nouvelle Key qui a comme valeur le nom du processus défaillant, dans notre exemple lsass.exe
- Dans la précédente clé, créer un premier DWORD (32-bit)
- Name : DumpCount
- Valeur : le nombre de crash dump a sauvegarder, par exemple 5
- Créer un deuxième DWORD (32-bit) value
- Name : DumpType
- Valeur : 2 cela permet de générer un full crash dump, celui-ci est le plus complet
- Créér une String value
- Name : DumpFolder
- Valeur : le chemin complet du dossier qu'il faudra créer et qui contiendra les dumps, par exemple c:\temp
- Créer un dossier temp dans le disque C:
Récupérer le fichier de log et l'analyser
Au prochain crash du processus, un fichier de log sera créé dans le dossier choisi dans la base de registre.
Pour pouvoir lire les fichiers de log, il est nécessaire d'installer un outil tel que WinDbg
Supprimer la génération de fichiers de dump
Pour supprimer la génération de log, il faut supprimer la clé précédemment créée dans la base de registre, dans notre exemple cela reviendrait à supprimer la clé lsass.exe
Pour aller plus loin
Documentation officielle Microsoft sur l'activation de Windows Error Reporting
Si vous déplacez tout vers Microsoft 365 et Azure AD, l'un des problèmes qui peuvent être rencontrés, c'est quand vous supprimez un ordinateur du domaine OnPrem et vous faites sa jonction à l'Azure AD, Windows est toujours activé à l'aide de l'hôte KMS.
Afin de passer à l'activation step-up (licence numérique), il faut installer la clé de produit Firmware-embedded (OEM), puis elle va automatiquement changer à la licence numérique.
Pour remplacer la clé de produit par la clé Firmware-embedded, tapez dans l'invite de commande élevée :
wmic path SoftwareLicensingService obtenir OA3xOriginalProductKey
slmgr -ipk <clé de produit de la dernière étape>
Un redémarrage peut être nécessaire et l'ouverture de session avec un utilisateur disposant d'un abonnement E3/E5 valide.
Après cela, l'activation devrait indiquer "L'abonnement Windows 10 Enterprise est actif" et "Windows est activé à l'aide d'une licence numérique".
Note:
Il semble que pour utiliser l'activation step-up, Windows 10 a besoin d'une clé d'activation/produit valide avant de pouvoir effectuer la mise à niveau.
Contrairement aux versions précédentes de Windows, les Feature Updates de Windows 11 dans MECM Servicing nécessitent de définir toutes les langues nécessaires dans le point de mise à jour logicielle. Sinon, ils seront synchronisés mais pas téléchargés.
Configuration classique pour Windows 10
Prenant un exemple où on souhaite télécharger les Feature updates Windows 10 en Anglais, Français, Italien, Allemand et Espagnol :
--> Uniquement deux langues cochées dans la configuration SUP, mais les Feature Updates Windows 10 peuvent être synchronisés et téléchargés en plusieurs langues.
Configuration pour Windows 11
Le Windows Servicing dans MECM ne télécharge les maj d'upgrade Windows 11 que si les langues sont configurées dans SUP.
Prenant le même exemple ci-dessus (Anglais, Français, Italien, Allemand et Espagnol) :
Si on ne coche que Français et Anglais, les Feature Updates Windows 11 seront synchronisés en plusieurs langues mais ne peuvent être téléchargés que en langue française et anglaise.
Pour afficher le bouton SSPR (Self-Service Password reset) sur l'écran d'ouverture de session Windows 10, il faut ajouter la clé de registre ci-dessous manuellement ou via GPO (sous réserve d'avoir SSPR déjà activé pour l'utilisateur et l'ordinateurs est joint à Azure AD en mode Hybride) :
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AzureADAccount]
"AllowPasswordReset"=dword:00000001
.png)
Dans certains cas, même après l'ajout de cette clé de registre, le bouton SSPR ne s'affiche pas sur l'écran d'ouverture de session.
En regardant sur Azure AD, l'état de la machine qui n'a pas fonctionné, nous avons constaté qu'elle est bien Hybrid Azure AD Joined mais le statut d'enregistrement est en Pending
Afin de résoudre ce problème, il faut forcer l'enregistrement de la machine à Azure AD en ajoutant les deux valeurs de la clé de registre ci-dessous :
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD]
"TenantId"="<YourTenantId>"
"TenantName"="<YourCompany.com>"
Une fois ajoutés, redémarrez l'ordinateur et il sera enregistré dans Azure AD.
Sur l'écran d'ouverture de session, le bouton SSPR doit maintenant s'afficher.
Dans un projet de migration de Windows 10 vers une nouvelle version en utilisant les mises à jour de fonctionnalités de Microsoft Endpoint Configuration Manager, il y a une erreur connue qui bloque la migration et bloque même le Retry.
L'erreur est la suivante : "L'opération n'a pas été effectuée car il n'y a pas d'utilisateur interactif connecté"
Cette erreur aura lieu quand il y a vraiment besoin d'une intervention utilisateur et que le mécanisme de mise à niveau Windows 10 en arrière plan ne peut pas remédier au problème automatiquement, généralement c'est l'un de ces deux cas :
1. Il y a un antivirus qui bloque la migration ou tout autre outil qui doit être mis à jour ou désinstallé
On peut détecter ce genre de problème en se connectant sur la machine, ouvrir le chemin suivant C:\$WINDOWS~BT\Sources\Panther, puis ouvrir le fichier CompatData*.xml le plus récemment modifié (c'est le fichier qui contient les données de scan de compatibilité)
Dans la capture ci-dessus, c'est l'outil de sécurité Check Point Endpoint Security qui a bloqué la migration Windows 10.
Vous pouvez utiliser le lien Microsoft qui est proposé dans le fichier xml pour trouver une solution.
2. Reset manuel de la migration
Pas mal de fois, le fichier de compatibilité CompatData*.xml ne contient aucun bloqueur dur de la migration et pourtant elle est bloquée.
Dans ce cas, il faut manuellement faire un reset de la migration par la suppression du dossier "$WINDOWS~BT" et le nettoyage du contenu du dossier "C:\Windows\SoftwareDistribution\Download".
Une fois ces actions sont faites, la migration fait un Retry automatiquement.
Remarque:
"$WINDOWS~BT" est un dossier caché
Dans un projet de migration de Windows 10 vers une nouvelle version en utilisant les mises à jour de fonctionnalités de Microsoft Endpoint Configuration Manager, on peut citer quelques problèmes connus et comment les corriger ou contourner.
- Problèmes de compatibilité
- La version de Trend Micro n’est pas à jour (les versions inférieures à 6.7.x bloquent) > Migration bloquée
> Solution: désinstaller Trend Micro ou mettre à jour la version
- Client VMWare Workstation installé (les versions VMWare v12.5.7 et v12.1 ou inférieures bloquent) > Migration bloquée
> Solution: Désinstaller VMWare Workstation Client ou mettre à jour la version installée
- Le pilote Bluetooth Realtek n’est pas prêt pour la migration vers Windows 10 > Migration bloquée
> Solution: Mettre à jour le pilote Bluetooth vers la version 1.5.1012 ou ultérieure
Source : <https://support.microsoft.com/en-us/help/4529832/updating-to-windows-10-version-1903-on-devices-with-some-driver-versio>
Impact sur l’utilisateur : aucun impact
- Le client est considéré comme conforme sans avoir vraiment installé la mise à niveau vers Windows 10
- Vérifiez si l’ordinateur voit la mise à jour des fonctionnalités de Windows 10 comme requise dans SCCM
> Si la mise à jour n’est pas requise, vérifiez si la langue du système d’exploitation est dans le scope de la migration ou si la version actuelle du système d’exploitation est trop vieille pour la version de mise à niveau cible
Impact sur l’utilisateur : aucun impact
- L’installation est « In progress » avec l’état "successfully installed update(s)"
- Il s’agit d’un bug connu avec la version SCCM 1906 où les clients Configuration Manager détectent incorrectement l’état de cogestion
> Solution: Installez le correctif SCCM KB4529827 (https://www.prajwaldesai.com/configuration-manager-1906-hotfix-kb4529827/)
Impact sur l’utilisateur : aucun impact
- Problèmes de corruption de mise à niveau
- Erreur de délai d’expiration (l’ordinateur est trop lent ou trop utilisé pour dépasser le temps autorisé pour l’installation)
- Erreur de travail annulée en raison de la déconnexion de l’utilisateur, du redémarrage de l’ordinateur ou de la mise en mode veille de l’ordinateur
> Solution: attendez que le client réessaye automatiquement la tâche de mise à niveau
Impact sur l’utilisateur : aucun impact
- Problème de Rollback
- Ordinateur bloqué après le redémarrage pour finaliser la mise à niveau de Windows avec les options suivantes :
- Windows Rollback
- Windows 10 (avec numéro de volume spécifié)
- Windows 10 (avec numéro de volume spécifié)
> Solution: choisissez l’option Windows Rollback
Impact sur l’utilisateur : faible impact
- Cliquez sur Windows Rollback et attendez environ 10 à 15 minutes pour récupérer l’écran de connexion Windows
Remarques :
- L’impact sur l’utilisateur indique si l’utilisateur est bloqué pour travailler. S'il n'y a aucun impact c'est que l'utilisateur ne s'est même pas rendu compte du problème et que tout s'est passé en arrière plan.
- Les fichiers log à analyser pour détecter le problème rencontré :
- C:\Windows\CCM\Logs\UpdatesDeployment.log
- C:\$WINDOWS.~BT\Sources\Panther\setupact.log
- C:\$WINDOWS~BT\Sources\Panther\CompatData*.xml (le fichier le plus récemment modifié)
N.B: "$WINDOWS~BT" est un dossier caché
Comme certain d'entre vous j'en ai eu marre de ne plus avoir de place sur mon disque mais surtout de devoir re-déployer Windows Server à chaque nouvelle VM pour un Lab; voici donc comment créer un disque de différenciation sous Hyper-V.
1. Créer la VM de référence
1- Dans un premier temps, sur votre poste de travail définissez un répertoire dans lequel sera stocké le disque de référence.
Dans mon cas je vais créer le serveur de référence dans mon disque "D" dans un répertoire "Template" et placer son disque dans un sous répertoire "Virtual Hard Disk".
2- Ensuite lancez "Hyper-V Manager"
3- Puis sélectionnez le serveur Hyper-V et faites un clic droit « New » puis « Virtual Machine ».
Dans la fenêtre « Before you Begin » faites « Next »
4- Dans la fenêtre « Specify Name and Location » donnez un nom à votre machine de référence et sélectionnez « Store the virtual machine in a different location » et cliquez sur « Browse… »
5- Sélectionnez le répertoire dans lequel seront stocké les éléments de configuration de la VM puis « Select Folder »
6- Faites « Next »
7- Sélectionnez le type de génération de la VM (dans mon cas une VM de génération 2) et faites « Next »
8- Assignez une quantité de RAM à la VM (au moins le prérequis système) et faites « Next ».
9- Il n’est pas obligatoire d’assigner une carte réseau pour la machine de référence, faites « Next ».
10- Dans la configuration du disque dur choisissez une taille suffisante pour l’OS (et éventuellement les mises à jour), puis faites « Next ».
11- Sélectionnez l’ISO du Système d’exploitation et faites « Next »
12- Relisez le résumé de la configuration et faites « Finish »
13- Une fois la VM créée dans Hyper-V Manager sélectionnez la et faites « Settings »
14- Naviguez jusque « Checkpoint » et désélectionnez « Enable Checkpoints » puis faites « OK »
La VM est maintenant prête, nous allons donc pouvoir déployer l'image, rendez vous donc dans la partie 2.
Les messages d'erreur sont parfois frustrant par exemple celui ci-dessous:
En plus de ne pas être des plus explicit, une multitude de cas sont exposé sur internet avec des code erreur divers et variés.
Sans l'accès au log tout devient plus dificile, dans le cas de figure ici présent j'ai voulu déployer une VM de génération 2 sous Hyper-V via un média de boot (clés USB), je pensais que j'allais y passer des heures, mais en fait non 10 minutes tout au plus.
1 - Les causes
Les VM de génération 2 sous Hyper-V, ont par défaut le Secure boot activé.
Le secure boot est une fonctionnalité qui vérifie que le "Boot Loader" est signé par une autorité de confiance de la base UEFI pour empêcher l'exécution non authorisé d'un "Firmware", "OS" ou "Driver" au démarrage.
Sauf que dans notre cas cela nous empêche de créer la partition pour le "Staging" du WinPe.
2 - Les solutions
désactivez le secure boot.
- Lancez Hyper-V management.
- Sélectionnez votre VM.
- Faites un clic droit "Properties".
- Dans "Settings for xxxxxx on xxxxxx" sélectionnez "Security".
- décochez la case "Enable Secure boot".
- Validez.
Créez une partition UEFI.
En cherchant dans les logs on pourrait trouver l'erreur suivante "Unable to find the partition that contains the OS boot loaders. Please ensure the hard disks have been properly partitioned".
- Après avoir désativer le sécure boot, démarrez votre VM et faites "F8" durant le démarrage.
- Dans l'invite de commande exécutez les commandes suivantes:
- Diskpart (lancez l'utilitaire Diskpart)
- List Disk (Listez les disque)
- Select disk 0 (sélectionnez le disque 0 qui représente le disque système de la VM)
- Clean (permet d'effacer les données)
- Convert gpt (permet de convertir le disque)
- Create partition efi size=200 (création d'une partition Efi)
- Assign letter=s (Assignez un lettre disponible à la partition)
- Format quick fs=FAT32 (Formatez la partition)
- Create partition msr size=128 (création d'une partition msr)
- Create partition primary (création d'une partition Windows)
- Assign letter=c (Assignez la lettre C)
- Format quick fs=NTFS (Formatez en NTFS)
- Exit (quittez Diskpart)
- Normalement vous devriez maintenant pouvoir lancer la séquencce de tâche sans encombre.
Contexte
Depuis la mise à jour de Windows 10 Fall Creator Update (Windows 10 - 1709), lorsque vous éteignez votre machine, au redémarrage l’ensemble des applications qui étaient ouvertes s’ouvrent à nouveau automatiquement.
Pas très pratique si l’on est du genre à éteindre son poste alors que de nombreux programmes sont encore ouverts.
Solution
Pour le moment Microsoft ne propose pas d’option pour activer / désactiver cette (nouvelle) fonctionnalité.
Les solutions possibles pour ne pas avoir ce comportement :
- Passer par ALT + F4 pour éteindre Windows : on remarque alors que Microsoft à ajouter la ligne Ferme toutes les applications et éteint le PC (cf. image)
- Utiliser la ligne de commande shutdown /r /t 0
