Entra Passkey sous Windows

Microsoft a enfin fait passer les Microsoft Entra passkeys on Windows en General Availability fin avril 2026. Concrètement, ça veut dire qu’on peut maintenant enregistrer des passkeys FIDO2 directement dans le conteneur Windows Hello et s’authentifier à Entra ID en passwordless. Cela fonctionne que le PC soit Entra-joined, registered, ou rien !

Personnel, partagé, BYOD, peu importe. Avec le rollout en cours jusqu’à mi-juin 2026, c’est le bon moment pour tester en lab avant que la migration auto vers les passkey profiles ne tombe sur votre tenant.

Dans cet article, on va voir comment configurer ça côté tenant (avec un focus sur la distinction entre l’ancienne UI Passkey (FIDO2) settings et la nouvelle expérience Passkey profiles), comment l’utilisateur enregistre sa passkey côté poste.

Au programme

Un peu d’histoire …
Entra passkey on Windows : c’est quoi exactement ?
Pré-requis tenant, poste et utilisateur
Ancienne UI : configuration via « Passkey (FIDO2) settings »
Nouvelle UI : configuration via « Passkey profiles »
Côté utilisateur : enregistrer sa première passkey Windows Hello
Le piège du Enforce attestation
Retex : les erreurs qu’on a croisées en lab

0. Un peu d’histoire …

Au début, l’authentification sur les environnements Microsoft reposait presque exclusivement sur le mot de passe. Un simple login + password suffisait pour accéder aux ressources d’entreprise, aussi bien on-premises que cloud.

Rapidement, les limites de ce modèle sont devenues évidentes :

mots de passe faibles
réutilisation entre services
phishing
fuites de credentials
attaques par bruteforce

Pour renforcer la sécurité, le MFA est alors devenu la norme. La première vague de MFA a surtout reposé sur les SMS, les appels téléphoniques ou les codes OTP. Cela améliorait clairement la sécurité, mais avec plusieurs problèmes :

fatigue utilisateur
dépendance au réseau mobile
vulnérabilités SIM swap
expérience parfois lourde

Ensuite sont arrivées les applications d’authentification comme Microsoft Authenticator, avec les notifications push, le number matching ou les OTP locaux.

L’expérience devenait plus fluide, mais on restait encore dans un modèle “mot de passe + validation secondaire”. Puis Microsoft a commencé à pousser fortement le passwordless avec :

Windows Hello for Business
les clés FIDO2 comme YubiKey

Cette fois, l’objectif était clair : supprimer complètement le mot de passe. Le problème, c’est que ces solutions restaient souvent liées à un device d’entreprise, à un PC Entra joined, ou à une clé hardware dédiée.

Les environnements BYOD, postes partagés ou machines temporaires restaient donc compliqués à gérer proprement en passwordless. Puis sont arrivées les passkeys synchronisées sur mobile :

iPhone via iCloud Keychain
Android via Google Password Manager
Microsoft Authenticator

Et c’est là qu’apparaît aujourd’hui “Entra passkey on Windows”. Le principe change beaucoup de choses : le PC Windows peut désormais héberger lui-même une passkey FIDO2 sans avoir à être joint au tenant.

1. Entra passkey on Windows : c’est quoi exactement ?

Pour rappel, jusqu’ici, si vous vouliez du passwordless FIDO2 sur Entra ID, il fallait soit une clé hardware type YubiKey, soit Windows Hello for Business (qui exige un device Entra-joined ou registered).

Les PC perso ou partagés étaient alors condamnés au mot de passe + MFA classique.

Avec Entra passkey on Windows, Microsoft permet désormais de créer une passkey FIDO2 directement dans le conteneur Windows Hello local, sans que le device soit joint au tenant. La passkey est device-bound (elle ne quitte jamais le poste), stockée dans le TPM, et débloquée par PIN, empreinte ou reconnaissance faciale.

Plusieurs passkeys peuvent cohabiter pour plusieurs comptes Entra sur le même PC.

Attention, le piège classique : ne confondez pas Entra passkey on Windows avec Windows Hello for Business.

Les deux utilisent Windows Hello, mais ce sont deux mécanismes distincts. Voici le tableau qui devrait vous éviter de mélanger les deux en réunion :

Critère	Entra passkey on Windows	Windows Hello for Business
Standard	FIDO2	Protocole 1P Microsoft (pas FIDO2)
Device join requis	Non	Oui (Entra-joined ou registered)
Sign-in OS Windows	Non	Oui
SSO Entra après login	Non	Oui
Provisionnement	User-initiated	Auto au device registration
Plusieurs comptes / device	Oui	Non (1 device = 1 compte)
Pilotage	Authentication Methods + passkey profiles	Intune / GPO

En clair : sur un device managé Entra-joined, gardez Windows Hello for Business. Sur un poste non-joined, perso ou partagé, Entra passkey on Windows est ce qu’il vous faut.

2. Pré-requis tenant, poste et utilisateur

Avant de vous lancer dans la conf, vérifiez que vous cochez tout ça :

Périmètre	Pré-requis
Tenant	Microsoft Entra ID (toute édition). Authentication Policy Admin ou Global Admin pour configurer.
Tenant	Méthode Passkey (FIDO2) activée dans Authentication methods.
Tenant	Conditional Access qui n’exige pas un device compliant ou Entra-joined sur le flux d’enregistrement.
Poste	Windows 11 24H2 minimum (build 26100+). Le provider passkey natif n’existe pas sur 23H2 ou Windows 10.
Poste	Edge ou Chrome à jour (≥ version 124).
Poste	TPM 2.0 opérationnel (`tpm.msc` doit afficher « prêt »).
Poste	Windows Hello configuré : PIN obligatoire, biométrie recommandée.
User	Une MFA réussie dans les 5 dernières minutes avant de cliquer « Add » sur la passkey.

Attention : sans Windows 11 24H2, le flux WebAuthn ne propose pas Windows Hello comme provider de passkey, et vous retombez sur l’ancien flux « Security key » qui demande un device externe (YubiKey, smartphone). C’est la cause numéro 1 d’enregistrements qui échouent.

3. Ancienne UI : configuration via « Passkey (FIDO2) settings »

Si vous n’avez pas encore migré vers la nouvelle expérience, vous êtes encore sur la vue legacy Passkey (FIDO2) settings. Vous la reconnaissez à un bandeau bleu en haut : « Synced passkeys and passkey profiles are now available. Upgrade to the new experience » :

Tant que vous n’avez pas cliqué sur ce lien, vous restez sur l’ancien modèle, et il fonctionne très bien pour Entra passkey on Windows, à condition de bien renseigner manuellement les AAGUIDs :

Authentificateur Windows Hello	AAGUID	Description
Authentificateur matériel Windows Hello	08987058-cadc-4b81-b6e1-30de50dcbe96	Clé privée stockée dans un module TPM basé sur le matériel.
Authentificateur matériel Windows Hello VBS	9ddd1817-af5a-4672-a2b9-3e3dd95000a9	La sécurité basée sur la virtualisation (VBS) utilise la virtualisation matérielle et l’hyperviseur Windows pour stocker des clés privées dans le module TPM de l’ordinateur hôte.
Authentificateur logiciel Windows Hello	6028b017-b1d4-4c02-b4b3-afcdafc96bb2	Clé privée stockée dans un module TPM basé sur logiciel.

Étape 0 : Connectez-vous au Microsoft Entra admin center, allez dans Protection → Authentication methods → Policies → Passkey (FIDO2) :

Étape 1 : Onglet Enable and Target : activez la méthode et scopez les utilisateurs concernés (un groupe pilote pour démarrer, c’est plus sain).

Étape 2 : Onglet Configure, dans la section General :

Allow self-service set up : Yes
Enforce attestation : No (j’insiste, on en reparle plus bas)

Étape 3 : Section Key Restriction Policy :

Enforce key restrictions : Yes
Restrict specific keys : Allow

Cliquez sur Add AAGUID et ajoutez les 3 AAGUIDs Windows Hello :

AAGUID	Authenticator
`08987058-cadc-4b81-b6e1-30de50dcbe96`	Windows Hello Hardware Authenticator (TPM matériel)
`9ddd1817-af5a-4672-a2b9-3e3dd95000a9`	Windows Hello VBS Hardware Authenticator (VBS + TPM)
`6028b017-b1d4-4c02-b4b3-afcdafc96bb2`	Windows Hello Software Authenticator (TPM logiciel)

Vous pouvez aussi ajouter les AAGUIDs Microsoft Authenticator si vous voulez autoriser les passkeys via l’app mobile :

90a3ccdf-635c-4729-a248-9b709135078f : Microsoft Authenticator Android
de1e552d-db1d-4423-a619-566b625cdc84 : Microsoft Authenticator Apple

Étape 4 : Cliquez sur Save en bas. Et c’est tout pour l’ancienne UI.

4. Nouvelle UI : configuration via « Passkey profiles »

Microsoft a introduit en mars 2026 le modèle des passkey profiles, qui remplace progressivement l’ancienne config FIDO2. L’idée : pouvoir définir plusieurs profils (jusqu’à 3 par tenant) avec des règles différentes selon les groupes :

Par exemple un profil avec attestation enforced pour les admins (YubiKey obligatoire), et un autre sans pour les utilisateurs standards (Windows Hello autorisé).

L’auto-enablement de la nouvelle UI court d’avril à fin mai 2026 sur les tenants. Donc même si vous ne faites rien, Microsoft va finir par migrer votre tenant. Mon conseil : faites la bascule volontairement, comme ça vous maitrisez le moment et ce qui change.

Étape 0 : Toujours dans Authentication methods → Passkey (FIDO2), cliquez sur le lien « Upgrade to the new experience » dans le bandeau bleu.

Étape 1 : Microsoft migre votre conf existante dans un Default passkey profile. Vos AAGUIDs et restrictions actuels sont préservés. Le passkeyType du profil est déterminé par votre réglage d’attestation :

Enforce attestation	Types autorisés par défaut
Enabled	Device-bound uniquement
Disabled	Device-bound + Synced (configurable)

Attention : si vous aviez Enforce attestation = No, l’upgrade activera aussi les synced passkeys par défaut (iCloud Keychain, Google Password Manager). Si vous ne voulez pas ça pour des raisons de gouvernance (clés hors du périmètre maitrisé), repassez le profil sur « Device-bound only » juste après l’upgrade.

Étape 2 : Cliquez sur le Default passkey profile pour l’éditer. Le panneau latéral s’ouvre avec :

Name : Default passkey profile (verrouillé, on ne peut pas le supprimer ni le renommer)
Enforce attestation : décoché
Passkey types : Device-bound, Synced (ajustez si besoin)
Target specific AAGUIDs : à cocher si vous voulez forcer une allow-list explicite

Étape 3 : En théorie, depuis la GA de fin avril 2026, Microsoft a supprimé l’obligation d’allow-lister les AAGUIDs Windows Hello. Donc si votre tenant a bien reçu la bascule, vous n’avez rien d’autre à faire.

En pratique pendant le rollout (qui finit mi-juin 2026), le tenant peut ne pas encore avoir basculé. Si l’enregistrement échoue côté utilisateur sans raison apparente, cochez Target specific et ajoutez les 3 AAGUIDs Windows Hello. C’est le contournement que j’ai dû appliquer en lab en mai 2026 :

Authentificateur Windows Hello	AAGUID	Description
Authentificateur matériel Windows Hello	08987058-cadc-4b81-b6e1-30de50dcbe96	Clé privée stockée dans un module TPM basé sur le matériel.
Authentificateur matériel Windows Hello VBS	9ddd1817-af5a-4672-a2b9-3e3dd95000a9	La sécurité basée sur la virtualisation (VBS) utilise la virtualisation matérielle et l’hyperviseur Windows pour stocker des clés privées dans le module TPM de l’ordinateur hôte.
Authentificateur logiciel Windows Hello	6028b017-b1d4-4c02-b4b3-afcdafc96bb2	Clé privée stockée dans un module TPM basé sur logiciel.

Étape 4 : Save. Vous pouvez créer jusqu’à 3 profils différents et les assigner à des groupes différents via l’onglet Enable and target.

5. Côté utilisateur : enregistrer sa première passkey Windows Hello

Maintenant qu’on est bon côté tenant, voyons l’expérience utilisateur. Le poste doit être en Windows 11 24H2, avec PIN Hello configuré et Edge à jour. C’est important.

Étape 0 : L’utilisateur ouvre Edge en session normale, et fait une MFA fraîche sur My Sign-Ins | Security Info | Microsoft.com → Add sign-in method → choisissez Passkey dans la liste :

Attention : ne sélectionnez pas « Security key » ou « USB security key » si vous avez ces options. C’est l’ancien flux FIDO2 qui ne déclenche pas le provider Windows Hello. Le bon choix est « Passkey », qui appelle le picker WebAuthn de l’OS et propose Windows Hello comme provider.

Étape 1 : Windows ouvre une fenêtre qui demande où enregistrer la passkey. Choisissez « This Windows device » (ou « Windows Hello » selon la version d’Edge).

Étape 2 : Le prompt Windows Hello apparaît. Authentifiez-vous avec visage, empreinte ou PIN Hello.

Étape 3 : Donnez un nom à la passkey (ex : « Laptop perso », « PC bureau »). Validez.

C’est bien enregistré sur votre compte :

Mais aussi sur votre poste :

Concrètement, ça donne quoi à la prochaine connexion ? L’utilisateur tape son email sur la page de login Microsoft, le navigateur propose la passkey du device, Windows Hello se déclenche (visage / PIN) et il est connecté. Plus de mot de passe, plus de SMS, plus de prompt MFA séparé. Le rêve.

6. Le piège du Enforce attestation

C’est LE piège qui m’a fait perdre du temps en lab et que vous allez forcément rencontrer si vous avez le réflexe sécu de tout durcir :

Le réglage Enforce attestation dans le profil passkey demande à l’authentificateur de fournir une preuve cryptographique signée par le constructeur, garantissant qu’il s’agit bien d’un device authentique (typiquement une YubiKey certifiée FIDO). Sur le papier, c’est une bonne pratique sécu.

Le problème : Windows Hello ne fournit pas encore d’attestation reconnue par Entra. Microsoft le dit explicitement dans la doc :

À noter : la doc MS Learn parle encore de public preview à la date de rédaction, mais la limite est confirmée post-GA :

Attestation isn’t supported for Microsoft Entra passkey on Windows during public preview. As a result, if Enforce attestation is enabled in a passkey profile that allows Windows Hello AAGUIDs, passkey registration attempts to Windows Hello will fail.

In the Authentication methods policy in the Microsoft Entra admin center, ensure that Enforce attestation is set to No for any passkey profile that includes Windows Hello AAGUIDs during public preview.
Enable Microsoft Entra passkey on Windows — Microsoft Learn

Concrètement, si vous cochez Enforce attestation = Yes sur un profil qui scope des utilisateurs sur Windows Hello, l’enregistrement échoue à la dernière étape (juste au moment où l’utilisateur nomme la passkey).

Côté serveur Entra, la requête est rejetée parce que la « preuve » attendue n’arrive pas :

Le piège classique : vous activez Enforce attestation en pensant durcir la conf, et vous cassez tout l’enregistrement Windows Hello sans message d’erreur clair. Vos utilisateurs vous appellent en disant « ça marche pas », et vous galérez à comprendre pourquoi parce que la conf semble propre.

La solution propre : deux profils séparés

Profil « YubiKey / clés certifiées » : Enforce attestation = Yes, scopé aux admins / users à fort privilège. AAGUIDs des modèles YubiKey autorisés en allow-list.
Profil « Windows Hello » : Enforce attestation = No, scopé aux utilisateurs standards. Allow-list avec les 3 AAGUIDs Windows Hello.

C’est exactement ce que la nouvelle UI passkey profiles permet de faire (jusqu’à 3 profils par tenant). Sur l’ancienne UI, vous étiez obligé de choisir un seul réglage tenant-wide, d’où l’intérêt de migrer si vous avez des cas d’usage mixtes.

Mon retour terrain : pour le moment, sur les Windows Hello passkeys, on accepte de se passer d’attestation. Le risque est limité parce que les credentials sont stockés dans le TPM et device-bound. Le jour où Microsoft livrera l’attestation Windows Hello, on rebascule. Pour les YubiKeys, l’attestation reste obligatoire.

7. Retex : les erreurs qu’on a croisées en lab

Pour finir, le vrai retour de tests, parce que la doc Microsoft ne couvre pas les cas où ça part en sucette. Voici les deux erreurs principales rencontrées en lab et comment les diagnostiquer.

Erreur 1 : « We’re sorry, we ran into a problem »

Message qui apparait juste à l’étape Name your security key, après que la clé ait été reconnue. Avec un Correlation ID dans les détails. Frustrant parce que tout semble fonctionner jusqu’à la dernière seconde.

Cause la plus fréquente : vous êtes sur le mauvais flux. Vous avez cliqué sur « Security key » au lieu de « Passkey » dans Add sign-in method. Le flux Security key n’utilise pas Windows Hello comme provider et tente de s’enregistrer comme une clé externe, d’où le crash final.

Erreur 2 : « Passkey not registered »

Message qui apparait sur le bon flux (Passkey, pas Security key), avec le texte « This might be due to a timeout, a canceled request or a private browsing window ». Le message officiel suggère timeout / cancel / private mode, mais en pratique la cause est ailleurs.

De mon côté, je n’ai eu aucun souci en navigation privée :

Cause #1 : Windows Hello pas configuré. Vérifiez Paramètres → Comptes → Options de connexion → Code PIN (Windows Hello). Sans PIN Hello, le provider n’a rien à appeler.

Cause #2 : rollout GA pas encore activé sur votre tenant. C’est la cause que j’ai rencontrée. Microsoft a annoncé que la GA enlève l’obligation d’allow-lister les AAGUIDs Windows Hello, mais cette bascule se déploie progressivement jusqu’à mi-juin 2026. Si votre tenant n’a pas encore reçu la modification, l’enregistrement échoue silencieusement.

Fix : dans le passkey profile, cochez Target specific AAGUIDs et ajoutez explicitement les 3 AAGUIDs Windows Hello. Save, retentez. Ça contourne le délai de rollout.

Cause #3 : Windows trop vieux. Sur 23H2 ou Windows 10, le picker n’affiche pas « This Windows device » dans la liste des providers. Vous voyez seulement « iPhone/Android » et « Security key ». Pas de chemin valide pour Windows Hello passkey.

Fix : passez en 24H2.

Cause #4 : Enforce attestation = Yes sur un profil scopant Windows Hello (cf. section précédente).

Fix : vérifiez que Enforce attestation est bien à No.

Conclusion

Entra passkey on Windows comble enfin un trou dans la stratégie passwordless de Microsoft : les PC non-managés peuvent désormais s’authentifier en FIDO2 sans avoir à sortir une YubiKey ni à passer par le téléphone. Pour les contractors, les postes partagés, les BYOD, c’est une vraie avancée.

Les pièges principaux à retenir :

Windows 11 24H2 minimum côté poste, sinon vous restez bloqué sur l’ancien flux Security key
Choisir « Passkey » et pas « Security key » dans Add sign-in method
Ne pas cocher Enforce attestation sur le profil qui scope Windows Hello
Pendant le rollout GA (avril → mi-juin 2026), allow-lister explicitement les 3 AAGUIDs Windows Hello si l’enregistrement échoue
Migrer volontairement vers les passkey profiles avant l’auto-enablement de fin mai 2026

Foncez tester en lab avec un compte de test, validez le flux, puis pilotez le déploiement sur un groupe pilote avant d’ouvrir vanne large. Et surtout, anticipez la migration auto vers les passkey profiles qui tombe entre maintenant et fin mai — autant maitriser le moment plutôt que le subir.

Enfin, pour aller plus loin :

À tester d’urgence en lab !

Migrez un vieux PC de 10 à 11 !

Windows 10 verra son support étendu s’achever le 14 octobre 2025, poussant beaucoup à envisager Windows 11. Comment vérifier la compatibilité de votre poste et quelles sont les solutions officielles ou détournées pour migrer même si votre matériel ne remplit pas tous les critères ? C’est ce que nous allons voir ensemble dans cet article consacré à la migration d’un poste, pleinement fonctionnel, mais qui ne satisfait pas toutes les conditions.

Il est parfois frustrant de constater l’« air du tout jetable » qui règne dans le monde de l’informatique : des machines parfaitement fonctionnelles se retrouvent considérées comme obsolètes dès qu’un détail matériel (TPM, Secure Boot ou CPU non listé) n’est pas validé.

Pourtant, nombre de ces postes ont encore de belles années devant eux et peuvent très bien faire le boulot sous Windows 11, si l’on savait simplement contourner ce petit verrou.

C’est d’ailleurs grâce à un message de Marjorie SIEGLER sur LinkedIn que j’ai découvert la méthode la plus simple pour faire sauter ce contrôle et donner une seconde vie à ces PC « délaissés ». Un grand merci à elle pour ce partage éclairé !

Quand Microsoft arrêtera-t-il le support de Windows 10 ?

Le support grand public (« Mainstream Support ») de Windows 10 a pris fin le 13 octobre 2020. Microsoft assure toutefois un support étendu (« Extended Support ») jusqu’au 14 octobre 2025, date à laquelle toutes les mises à jour de sécurité et correctifs pour Windows 10 cesseront d’être publiés.

Qu’est-ce que Windows 11 ?

Windows 11 est la version suivante de Windows après Windows 10. Publié officiellement par Microsoft en octobre 2021, il apporte un certain nombre de changements tant au niveau de l’interface utilisateur que des fonctionnalités sous-jacentes par rapport à Windows 10.

Quels sont les prérequis pour passer de Windows 10 à Windows 11 ?

Voici les conditions minimales à respecter pour passer de Windows 10 à Windows 11. Ces prérequis sont inchangés depuis leur publication initiale et doivent tous être satisfaits simultanément pour que l’upgrade in-place soit autorisée :

Catégorie	Prérequis minimaux
Processeur (CPU)	Processeur 64 bits cadencé à ≥ 1 GHz avec au moins 2 cœurs, figurant dans la liste officielle des CPU compatibles Windows 11 et prenant en charge les instructions SSE 4.1/4.2, AVX.
Mémoire vive (RAM)	4 Go ou plus.
Stockage	Disque (physique ou partition) d’au moins 64 Go d’espace disponible pour l’installation.
Firmware système	Démarrage en mode UEFI avec Secure Boot activé.
TPM (Trusted Platform Module)	Module TPM version 2.0 activé.
Carte graphique	Compatible DirectX 12 ou version ultérieure avec pilote WDDM 2.0.
Écran	Écran HD (720p) de plus de 9″ en diagonale, 8 bits par canal de couleur.
Connexion Internet et compte	Pour Windows 11 Home, un compte Microsoft et une connexion Internet sont nécessaires pour la configuration initiale.

Peut-on vérifier la compatibilité de son poste pour passer à Windows 11 ?

Microsoft propose une application gratuite, PC Health Check, qui analyse automatiquement votre machine et vous indique si elle remplit les conditions minimales pour Windows 11 :

Quid des extended security updates (ESU) pour Windows 10 ?

Les Extended Security Updates (ESU) pour Windows 10 sont un programme payant permettant aux utilisateurs de continuer à recevoir uniquement les correctifs de sécurité (critique et important) après la date de fin de support officielle de Windows 10 (14 octobre 2025).

Le support standard de Windows 10 s’achève le 14 octobre 2025. Les ESU Windows 10 débutent alors, et s’étendent jusqu’au 14 octobre 2028 (trois années au total).

Pour les acheter, vous pourrez passer via le Volume Licensing (Microsoft 365, Microsoft 365 FPP, etc.) ou auprès d’un partenaire Microsoft avec un contrat EA unqiuement (pour l’instant).

Pour information, vous aurez la possibilité d’enrôlement gratuit pour les ESU quand les machines Windows 10 sont hébergées sur :

Azure Virtual Desktop
Azure VM
Windows 365

Voici d’ailleurs un tableau Microsoft montrant les autres ESU actuellement en vigueur :

Peut-on malgré tout migrer sur Windows 11 sans valider tous les prérequis ?

Il n’existe pas de voie « officielle » pour forcer l’installation de Windows 11 sur un matériel qui ne respecte pas tous les prérequis. Microsoft bloque volontairement l’upgrade in-place (et parfois même la clean install) dès qu’un des critères essentiels (TPM 2.0, Secure Boot, CPU compatible, etc.) n’est pas rempli.

Cependant, plusieurs utilisateurs avancés ont découvert des contournements (workarounds) pour installer Windows 11 sur du matériel non pris en charge. Voici les principales méthodes, ainsi que leurs risques et limitations.

Méthode 1 : modification du registre avant l’upgrade in-place :

Méthode 2 : clean install depuis un ISO modifié (offline) :

Méthode 3 : utilisation d’un script tiers (par exemple Flyby11) :

Méthode 4 : utilisation d’un argument d’installation :

Afin de voir si cela marche vraiment, voici les différentes étapes que nous allons suivre afin de tester la méthode 4 sur un environnement de test :

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice de mise à jour d’un poste Windows 10 non compatible vers Windows 11, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

N’ayant pas d’anciens postes physiques à disposition (à part celui de mon fils 🤣), j’ai choisi de le simuler grâce à un environnement virtualisé Hyper-V recréé sous Azure.

Il est en effet possible dans Azure d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.

Etape I – Préparation de la machine virtuelle hôte (Hyper-V) :

Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :

Cliquez-ici pour créer votre machine virtuelle hôte (Hyper-V) :

Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :

Choisissez une taille de machine virtuelle présent dans la famille Dsv3, puis cliquez sur Suivant :

Rajoutez un second disque pour stocker la ou les futures machines virtuelles invitées, puis cliquez ensuite sur Suivant :

Retirez l’adresse IP publique pour des questions de sécurité, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création des ressources Azure :

Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle hôte (Hyper-V) :

Ensuite, cliquez-ici pour déployer le service Azure Bastion :

Attendez quelques minutes la fin du déploiement d’Azure Bastion, indispensable pour continuer les prochaines opérations :

Peu après, constatez le déploiement réussi d’Azure Bastion, puis renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :

Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :

Exécutez la commande suivante pour installer les deux rôles suivants :

Rôle DHCP
Rôle Hyper-V

Install-WindowsFeature -Name DHCP,Hyper-V –IncludeManagementTools

Attendez environ une minute que l’installation des 2 rôles se termine :

Lancez la commande suivante pour lancer un redémarrage immédiat de votre VM hôte (Hyper-V) :

Shutdown -R

Attendez environ 30 secondes que le redémarrage se termine pour vous reconnecter à celle-ci, toujours via le service Azure Bastion :

Une fois la session Bastion rouverte, ouvrez PowerShell en mode ISE :

Lancez le script suivant afin de créer un switch virtuel dans Hyper-V de type interne :

$switchName = "InternalNAT"
New-VMSwitch -Name $switchName -SwitchType Internal
New-NetNat –Name $switchName –InternalIPInterfaceAddressPrefix “192.168.0.0/24”
$ifIndex = (Get-NetAdapter | ? {$_.name -like "*$switchName)"}).ifIndex
New-NetIPAddress -IPAddress 192.168.0.1 -InterfaceIndex $ifIndex -PrefixLength 24

Lancez le script suivant afin de configurer un périmètre DHCP avec une règle de routage, couplé au serveur DNS d’Azure :

Add-DhcpServerV4Scope -Name "DHCP-$switchName" -StartRange 192.168.0.50 -EndRange 192.168.0.100 -SubnetMask 255.255.255.0
Set-DhcpServerV4OptionValue -Router 192.168.0.1 -DnsServer 168.63.129.16
Restart-service dhcpserver

Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM hôte (Hyper-V) :

Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :

Créez un nouveau volume NTFS :

L’environnement Hyper-V est maintenant en place. Nous allons maintenant pouvoir créer ensemble une ou plusieurs machines virtuelles invitées.

Etape II – Création de la machine virtuelle Windows 10 :

Pour cela, il est nécessaire de récupérer l’image au format ISO afin de créer la machine virtuelle invitée, puis d’y installer l’OS. Pour ma part, je suis passé par mon abonnement Visual Studio :

Attendez la fin du téléchargement pour continuer :

Depuis votre VM hôte (Hyper-V), ouvrez votre console Hyper-V Manager :

Cliquez-ici pour créer votre machine virtuelle invitée :

Modifiez les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM hôte (Hyper-V), puis cliquez sur Suivant :

Choisissez Génération 1 :

Modifiez la taille de la mémoire vive allouée à la VM invitée, puis cliquez sur Suivant :

Utilisez le switch créé précédemment, puis cliquez sur Suivant :

Cliquez sur Suivant :

Utilisez le fichier ISO téléchargé précédemment, puis cliquez sur Suivant :

Cliquez sur Terminer pour finaliser la création de votre machine virtuelle Windows 10 :

Une fois la machine virtuelle Windows 10 créée, modifiez sa configuration comme ceci :

Double-cliquez sur votre machine virtuelle, puis cliquez-ici pour lancer le démarrage de la VM :

Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :

Lancez l’installation de Windows :

Une fois Windows 10 correctement installé, installez PC Health Check afin de constater l’impossibilité en l’état actuel de basculer sur Windows 11 :

Nous allons maintenant pouvoir tester la méthode alternative pour installer malgré tout Windows 11 sur cette machine virtuelle

Etape III – Mise à jour vers Windows 11

Avant de mettre à jour vers Windows 11, commencez par ouvrir Windows Update afin de mettre à jour tous les patchs existants :

Une fois tous les patchs installés, vérifiez à nouveau Windows Update :

Téléchargez cette fois l’image ISO de Windows 11 :

Une fois téléchargée, extrayez le contenu de l’ISO dans un dossier :

Puis créez un fichier texte avec le contenu suivant :

setup.exe /product server

Sauvegardez ce fichier texte avec une terminaison BAT :

Ouvrez en mode administrateur l’exécuteur de commande Windows, puis lancez l’application setup.bat :

Autorisez l’action en cliquant sur Oui :

Attendez plusieurs minutes que l’installation se prépare :

Cliquez sur Suivant :

Attendez la vérification de mises à jour Windows :

Attendez encore quelques minutes :

Acceptez les termes et conditions de Microsoft Windows :

Cliquez-ici pour conserver les informations en place sur votre poste :

Attendez quelques minutes :

Attendez la seconde vérification des mises à jour Windows :

Cliquez-ici pour démarrer l’installation de Windows 11 :

Attendez plusieurs minutes que l’installation se termine :

Attendez encore plusieurs redémarrages de votre poste :

Authentifiez-vous avec votre compte sur Windows 11 :

Retournez dans les paramètres Windows afin de vérifier le bon changement de version de votre OS :

Retournez à nouveau dans Windows Update pour vérifier, puis lancez les nouvelles mises à jour disponibles :

Conclusion

En définitive, si vous êtes dans la situation où votre poste Windows 10 parfaitement fonctionnel ne remplit pas tous les critères officiels de Windows 11, sachez qu’il existe plusieurs moyens de contourner ces contrôles et d’offrir une seconde vie à votre machine.

Gardez toutefois à l’esprit que ces contournements ne sont pas supportés officiellement par Microsoft : vous prenez le risque de ne plus recevoir certaines mises à jour futures, voire de rencontrer des limitations sur les fonctionnalités de sécurité (Windows Hello, BitLocker, etc.)

En revanche, si votre objectif est de repousser l’obsolescence de machines qui tournent encore très bien, l’une de ces méthodes peut vous permettre de migrer vers Windows 11 sans changer de matériel immédiatement.

Clonez votre Windows 365

Windows 365 est un service de Cloud PC créé par Microsoft et disponible via un système licence mensuelle fixe. Le service Windows 365 est en évolution constante depuis sa sortie en 2021. Très proche d’Azure Virtual Desktop, Windows 365 se distingue principalement par l’absence de connaissances nécessaires sur Azure. Mais que se passe-t-il quand un utilisateur rencontre des difficultés sur son poste Windows 365 ?

J’ai écrit cet article à la suite d’un souci technique sur un poste Windows 365. Pour des questions de commodités, nous avons pris la décision de cloner ce Cloud PC afin de l’analyser et de le redéployer par la suite.

Avant d’aller plus loin, et si Windows 365 nous vous semble pas familier, voici quelques articles très intéressants et disponibles sur ce blog :

Voici ce que Microsoft en dit en quelques mots :

Windows 365 est un service cloud qui crée automatiquement un nouveau type de machine virtuelle Windows (PC cloud) pour vos utilisateurs finaux. Chaque PC cloud est attribué à un utilisateur et devient ainsi son appareil Windows dédié. Windows 365 offre les avantages de productivité, de sécurité et de collaboration de Microsoft 365.
Microsoft Learn

Saviez-vous que votre Cloud PC est accessible avec un simple smartphone comme ressource local ?

Disons-le franchement, la documentation Microsoft ne m’a pas vraiment aidé 😥. Je vous propose donc ici de suivre un exercice étape par étape concernant le clonage du poste Windows 365 déjà en place, dans le but de l’analyser en dehors de l’environnement de production.

Pour des questions de confidentialité, l’environnement présent ci-dessous sera une copie approchante de l’environnement réel du client concerné.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur Windows 365, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide
Une licence Windows 365

Commençons par recréer un environnement Windows 365 fonctionnel

Etape I – Environnement Windows 365 de départ :

Pour cela, commencez par créer un groupe Entra ID dans lequel votre utilisateur de test Windows 365 est présent :

Assignez à cet utilisateur une licence Windows 365 :

Depuis le portail Azure, recherchez le service des réseaux virtuels :

Créez un réseau virtuel Azure, ce dernier sera utilisé pour créer le poste Windows 365 :

Renseignez les champs de base de votre nouveau réseau virtuel, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre réseau virtuel :

Environ 30 secondes plus tard, votre réseau virtuel Azure est créé :

Retournez sur la page dédiée à Windows 365 sur le portail Intune, puis lancez la création d’une connexion vers Azure :

Renseignez les champs relatifs au réseau virtuel Azure créé précédemment, puis cliquez sur Suivant :

Démarrez la validation Intune, puis lancez la création de la connexion Azure :

La création de la connexion vers Azure apparaît alors, et les premiers contrôles de conformité démarrent automatiquement :

Attendez environ 5 minutes que les contrôles sur la connexion Azure soit terminés :

Cliquez-ici pour définir les paramètres utilisateurs :

Choisissez parmi les options suivantes :

Assignez les paramétrages utilisateurs au groupe Entra ID, puis lancez la création :

Afin de créer le premier poste Windows 365, cliquez sur le menu suivant afin d’assigner une police de provisionnement à votre utilisateur de test :

Renseignez les informations de base de la police de provisionnement, puis cliquez sur Suivant :

Choisissez une image déjà présente dans la galerie Microsoft, puis cliquez sur Suivant :

Personnalisez au besoin la configuration, puis cliquez sur Suivant :

Assignez la police de provisionnement à votre groupe Entra ID, puis cliquez sur Suivant :

Lancez la création de votre police de provisionnement Windows 365 :

Vérifiez la bonne apparition de celle-ci :

Puis retournez sur l’onglet suivant afin de constater le provisionnement de votre Cloud PC assigné à votre utilisateur de test :

Environ 15 minutes plus tard, le provisionnement du poste Windows 365 est terminé :

Sur votre poste local, téléchargez l’application Remote Desktop depuis la page officielle Microsoft, installez-là, puis ouvrez une session avec votre utilisateur de test :

Acceptez en cliquant sur Oui :

Ouvrez une session Windows 365 afin de constater le bon fonctionnement du Cloud PC :

Téléchargez le logiciel Google Chrome depuis la page officielle suivante :

Choisissez la version MSI, puis démarrez le téléchargement :

Une fois téléchargé, ouvrez l’exécutable :

Lancez l’installation de Google Chrome :

Notre environnement de départ est en place et fonctionne correctement. Nous allons maintenant nous intéresser au clonage du poste Windows 365.

Etape II – Sauvegarde du poste Windows 365 :

Afin de stocker l’image de notre Cloud PC Windows 365, commençons par rechercher le service de compte de stockage sur le portail Azure :

Cliquez-ici pour créer le compte de stockage :

Renseignez les informations de base dont le nom unique de votre compte de stockage, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre ressource Azure :

Environ 30 secondes plus tard, cliquez-ici pour ouvrir la page de votre compte de stockage :

Ajoutez un role RBAC sur votre compte stockage par le menu suivant :

Recherchez le rôle Azure RBAC ci-dessous, puis cliquez sur Suivant :

Ajoutez l’application Windows 365, puis lancez la validation :

Lancez l’assignation RBAC par le bouton suivant :

Ajoutez également le rôle RBAC suivant sur la souscription Azure contenant le compte de stockage :

Depuis le portail Intune, retournez sur le Cloud PC afin de déclencher la création d’un point des restauration manuel par le menu suivant :

Confirmez votre choix en cliquant sur Oui :

Quelques minutes plus tard, votre point de restauration apparaît dans la liste ci-dessous. Cliquez-ici pour copier ce dernier sur votre compte de stockage :

Sélectionnez la souscription Azure et le compte de stockage correspondants, puis cliquez sur Partager :

L’ordre de copie est déclenché, attendez maintenant quelques minutes :

Le status du partage est consultable ici :

Depuis le portail Azure, retournez sur votre compte de stockage puis lancez plusieurs rafraichissements si besoin :

Constatez la création d’un nouveau conteneur blob, puis cliquez sur celui-ci :

Constatez la création d’un nouveau blob au format VHD :

Une image de notre poste Windows 365 est maintenant présente dans Azure. La prochaine étape sera de créer une machine virtuelle reprenant ce VHD.

Etape III – Création d’une machine virtuelle Azure :

Avant de créer directement la machine virtuelle, commencez par créer un disque OS via le service Azure suivant :

Cliquez-ici pour créer le disque OS :

Renseignez les informations de base pour votre disque OS, dont l’URL de votre blob VHD :

Vérifiez les champs suivants, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre disque OS :

Environ 1 minute plus tard, cliquez-ici pour consulter la page de votre disque OS :

Cliquez-ici pour réutiliser votre disque OS dans la création d’une machine virtuelle Azure :

Renseignez les champs de base votre machine virtuelle, dont le disque OS :

Choisissez la taille de votre VM, puis cliquez sur Suivant :

Cliquez sur Suivant :

Retirez l’adresse IP publique de votre VM, puis cliquez sur Suivant :

Décochez la case d’extinction automatique, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre machine virtuelle :

Environ 2 minutes plus tard, votre VM est créée, cliquez-ici :

Vérifiez le bon démarrage de votre VM par le biais du menu suivant :

Déployez Azure Bastion de pouvoir vous y connecter en RDP de façon sécurisée :

Afin de vous connecter à votre VM en utilisant le compte Entra ID de votre utilisateur de test via Azure Bastion, passez la commande PowerShell suivante via le menu dédié :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -Value '0' # was before 2
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value '0' # was before 1

Attendez la confirmation de la bonne exécution de votre script PowerShell :

Ouvrez une connexion RDP à distance depuis Azure Bastion avec votre utilisateur de test, toujours précédé de la mention AzureAD\ :

Constatez la bonne ouverture de votre session Windows :

Constatez la présence de l’icône Google Chrome sur le bureau de la VM :

Notre machine virtuelle Azure est maintenant en place. Nous pourrions alors effectuer tous les tests ou des modifications nécessaires sur celle-ci. Afin de donner un exemple banal, nous allons installer Mozilla sur notre VM.

Etape IV – Modification de la VM :

Rendez-vous sur la page officielle de Mozilla pour y télécharger et installer une version MSI du navigateur :

Constatez la présence de l’icône Firefox sur le bureau de la VM :

Profitez-en pour installer toutes les dernières mises à jour de Windows 11 :

Redémarrez la machine virtuelle Azure si nécessaire :

Vérifiez que Windows Update ne vous propose plus d’autres mises à jour Windows :

Depuis le portail Azure, relancez le script en sens inverse :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -Value '2' # was before 0
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value '1' # was before 0

Depuis la session RDP déjà ouverte via Azure Bastion, lancez la commande sysprep suivante en mode administrateur :

Sysprep /generalize /oobe /mode:vm /shutdown

Attendez qu’Azure Bastion vous indique une fermeture de session inattendue :

Une fois la machine virtuelle arrêtée au niveau OS, lancez un arrêt depuis le portail afin de désallouer les ressources Azure :

Une fois la machine virtuelle arrêtée et désallouée, lancez une capture de celle-ci :

Renseignez les champs de base de votre image, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre image :

Environ 3 minutes plus tard, constatez la bonne création de votre image :

Nous allons maintenant pouvoir recréer un second Cloud PC Windows 365 à partir de cette nouvelle image modifiée.

Etape V – Nouvel environnement Windows 365 :

Pour plus de facilité, j’ai recréé un second groupe Entra ID avec un second utilisateur de test que celui utilisé précédemment :

J’ai réassigné la licence Windows 365 précédemment assignée à mon nouvel utilisateur de test :

A partir du portail Intune, cliquez sur le menu suivant pour importer votre propre image Windows 365 :

Renseignez les informations de votre nouvelle image Windows 365, dont la source de votre image présente sur votre environnement Azure :

Le téléversement de votre image depuis Azure et vers Intune commence alors :

Environ 30 minutes plus tard, votre image personnalisée est bien chargée et reconnue par Intune :

Cliquez-ici pour créer une seconde police de provisionnement Windows 365 :

Renseignez les informations de base de la police de provisionnement, puis cliquez sur Suivant :

Choisissez votre image personnalisée, puis cliquez sur Suivant :

Personnalisez au besoin la configuration, puis cliquez sur Suivant :

Assignez votre police de provisionnement à votre second groupe Entra ID, puis cliquez sur Suivant :

Lancez la création de votre police de provisionnement Windows 365 :

Vérifiez la bonne apparition de celle-ci :

Puis retournez sur l’onglet suivant afin de constater le provisionnement de votre nouveau Cloud PC, assigné cette fois à votre second utilisateur de test :

Environ 15 minutes plus tard, le provisionnement du nouveau poste Windows 365 est terminé :

Depuis l’application Remote Desktop, ouvrez une session avec votre second utilisateur de test :

Acceptez en cliquant sur Oui :

Constatez la bonne ouverture de votre session Windows :

Constatez la présence de deux icônes Chrome et Firefox sur le bureau Windows :

😎

Troubleshooting – Quelques erreurs possibles :

Voici quelques erreurs que j’ai pu rencontrer lors de cet exercice :

Erreur rencontrée lors du lancement de la commande sysprep car des mises à jour Windows étaient encore en attente :

Erreur rencontrée lors du téléversement de mon image créée directement depuis mon blob VHD, sans avoir créé de machine virtuelle Azure entre temps :

Erreur rencontrée lors de la création d’une VM depuis une image sans avoir créé le disque OS entre temps :

Conclusion :

Cette opération nous montre encore une fois les synergies fortes entre tous les outils Cloud de Microsoft. J’espère que ce petit exercice pourra en aider quelques-uns sur les interventions IT sur des postes Windows 365 🤘🙏

Windows Server 2025 🪟

Depuis seulement quelques jours, La nouvelle release de Windows Server s’appelle maintenant Windows Server 2025 ! Seulement disponible via le programme Windows Server Insider, la version Build v26040 de Windows Server 2025 promet de nouvelles fonctionnalités comme le Hotpatching pour tous ou encore Active Directory et SMB en version Next Gen, et sûrement encore plein d’autres à découvrir.

Cette annonce de Windows Server 2025 a été faite sur le site TechCommunity juste ici.

De précédentes annonces concernant Windows Server avaient été annoncées durant le dernier Ignite juste là :

Je ne vais pas rentrer tout de suite dans les détails de Windows Server 2025, que je ne connais pas encore car je ne l’ai pas testé. Mais je trouvais intéressant de partager avec vous une méthode de déploiement facile et rapide du dernier OS de Microsoft sur Azure.

En effet, et comme vous pouvez vous en doutez, ce dernier n’est pas encore directement accessible via le portail Azure lors de la création d’une machine virtuelle.

D’où mon petit exercice très rapide sur le sujet :

Commençons par un bref rappel des prérequis.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur Windows Server 2025, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

La suite se passera par l’inscription au programme Windows Insider.

Etape I – Programme Windows Insider :

Afin de récupérer l’image de la dernière version disponible de Windows Server 2025, il est donc nécessaire de s’inscrire au programme Windows Insider (de Windows Server).

La documentation officielle de Microsoft l’explique bien et est accessible via ce lien :

Vous pouvez vous inscrire directement Programme Windows Insider via cette page, en utilisant un compte Microsoft Entra ou même un compte personnel Microsoft :

Lisez les informations du programme, puis acceptez ses termes si vous êtes d’accord :

Cliquez-ici pour rejoindre la page dédiée à Windows Server :

Choisissez la version suivante de Windows Server afin de pouvoir l’installer sous Azure :

Sélectionnez la seule langue disponible actuellement, puis cliquez sur Confirmer :

Cliquez-ici pour commencer le téléchargement du fichier au format VHDX :

Attendez quelques minutes la fin du téléchargement sur votre poste :

Une fois téléchargé, le fichier VHDX doit être converti en VHD pour être exploité sous Azure.

Etape II – Préparation du fichier image VHD :

En effet Azure ne support que le format VHD. Nous allons donc devoir effectuer une conversion de format. Cela est possible facilement en PowerShell.

Note : Pour utiliser la commande Convert-VHD, les outils Hyper-V sont nécessaires.

Ouvrez PowerShell, puis lancez la commande suivante pour convertir le fichier téléchargé au format VHDX en fichier au format VHD :

Convert-VHD –Path c:\2025\Windows_InsiderPreview_ServerDatacenter_Azure_Edition_en-us_VHDX_26040.vhdx –DestinationPath c:\2025\Windows_InsiderPreview_ServerDatacenter_Azure_Edition_en-us_VHDX_26040.vhd -VHDType Fixed

Attendez environ 5 minutes que le traitement de conversion se termine :

Une fois le fichier image converti au format VHD, ouvrez le portail Azure, puis recherchez le Service de stockage :

Créez un nouveau compte de stockage Azure en cliquant ici :

Nommez votre compte de stockage, puis lancez la validation Azure :

Une fois la validation Azure réussie, démarrez la création de la ressource :

Environ 1 minute plus tard, cliquez-ici pour vous connecter au nouveau compte de stockage :

Créez un nouveau contenaire blob :

Nommez-le puis lancez sa création :

Dans ce contenaire blob, cliquez sur Téléverser :

Sélectionnez votre fichier VHD, choisissez le format Page Blob, puis cliquez sur Téléverser :

La notification Azure suivante doit apparaitre :

Suivez l’évolution de l’envoi vers Azure en bas à droite de l’écran :

Attendez environ 15 minutes que l’envoi vers Azure se termine :

Une fois l’envoi vers Azure terminé, cliquez sur votre blob pour en copier l’URL :

Votre source est enfin prête. Nous allons maintenant créer une galerie d’images de VM en faisant appel à notre fichier blob.

Etape III – Création de la galerie d’images :

Pour cela, commencez par rechercher le service Azure suivant :

Créez une nouvelle galerie d’images VM en cliquant ici :

Nommez votre galerie d’images VM, puis lancez la validation Azure :

Une fois la validation Azure réussie, cliquez-ici pour démarrer la création de la ressource :

Environ 1 minute plus tard, la galerie d’images VM est créée, puis cliquez ici :

Cliquez-ici pour créer une nouvelle définition d’image VM :

Renseignez tous les champs nécessaires, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la ressource :

Environ 2 minutes plus tard, cliquez-ici pour ajouter une nouvelle version :

Cliquez-ici pour ajouter une nouvelle version à votre définition d’images VM :

Renseignez les champs et reprenez pour le disque OS l’URL du blob copiée précédemment :

Lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la ressource :

Environ 10 minutes plus tard, cliquez-ici pour retourner sur votre version :

Notre environnement est enfin prêt, nous allons maintenant créer notre première machine virtuelle sous Windows Server 2025.

Etape IV – Création de la machine virtuelle :

Cliquez-ici pour créer une nouvelle machine virtuelle à partir de cette image :

Renseignez tous les champs de base :

Définissez un compte administrateur local, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Retirez l’IP publique de votre VM, puis cliquez sur Suivant :

Retirez l’extinction automatique, puis lancez la validation Azure :

Une fois la validation Azure réussie, cliquez-ici pour lancer la création de la ressource :

Environ 5 minutes plus tard, cliquez-ici pour consulter la machine virtuelle créée :

Dans la foulée, déployez le service Azure Bastion afin de pouvoir ouvrir une connexion RDP :

Attendez 5 minutes la création du service Azure Bastion :

Etape V – Test et connexion :

Une fois le service Azure Bastion déployé, ouvrez une session RDP par ce dernier :

Définissez la politique d’envoi de données à Microsoft :

Depuis Server Manager, vérifiez la bonne version de votre Windows Server :

Depuis Paramètres, vérifiez la bonne version de votre Windows Server :

De retour sur Azure, profitez-en pour installer Windows Admin Center :

Attendez environ 1 minute que l’extension Windows Admin Center soit installée :

Vérifiez sa bonne installation par cet écran :

Ajoutez votre utilisateur Entra ID le rôle RBAC suivant :

Ajoutez une IP publique et une règle entrante NSG pour pouvoir vous connecter à Windows Admin Center depuis le portail Azure :

Ouvrez une connexion à Windows Admin Center :

Vérifiez la bonne disponibilité des informations via Windows Admin Center :

Redémarrez par le portail Azure votre VM si Windows Admin Center reste trop longtemps sur cette page :

Conclusion

Microsoft continue de faire avancer Windows Server dans sa gamme de produit OS, et promet à coup sûr de belles choses à venir 😎. Quand j’aurais pris le temps de faire mes tests dessus🤣, comptez sur moi pour d’autres articles à suivre !