Lors des premiers déploiements de Windows 365 Link, un problème revient systématiquement, y compris dans des tenants Intune pourtant bien maîtrisé : l’échec de l’enrôlement Intune pendant l’OOBE. Ce blocage n’est généralement pas lié à Windows 365, ni à une erreur utilisateur, ni à un problème réseau. Dans la majorité des cas, il est provoqué par une politique de restriction d’enrôlement Intune parfaitement légitime, mais inadaptée au comportement spécifique de Windows 365 Link.
Un premier article a déjà été écrit sur Windows 365 Link afin de répondre aux questions suivantes :
Dans ce second article, je vous propose de passer en revue les trois méthodes possible pour intégrer votre Windows 365 Link à votre tenant tout en évitant les restrictions mise en place sur Intune. Nous prendrons le temps de comparer leurs avantages, leurs limites et les scénarios dans lesquels elles font réellement sens.
Pourquoi Windows 365 Link pose problème avec les restrictions d’enrôlement ?
Lors du tout premier démarrage, Windows 365 Link démarre en Out of Box Experience, l’utilisateur s’authentifie avec son compte Microsoft Entra ID, le poste est alors joint à Microsoft Entra, puis l’enrôlement MDM automatique Intune est déclenché.
Jusque-là, rien d’inhabituel… du moins en apparence :
Mais c’est précisément au moment où Intune évalue les restrictions d’enrôlement que les choses se compliquent. Windows 365 Link :
est vu comme Unknown
n’est pas encore identifié comme corporate
n’est donc pas encore classifié
Ce n’est qu’après la jonction Entra ID complète que le Windows 365 Link bascule en poste d’entreprise :
La conséquence directe de ce comportement est simple : l’enrôlement peut se retrouver bloqué si une restriction d’enrôlement Intune bloquant les postes personnelles est mise en place :
Cette restriction d’enrôlement bloque de façon logique, les postes personnels, inconnus, et donc bloque aussi Windows 365 Link, même s’il s’agit d’un poste Microsoft, managé et destiné à Windows 365 :
Pour y remédier, Microsoft documente trois approches officielles. Elles sont toutes valides, mais ne répondent pas aux mêmes contraintes opérationnelles. Et je souhaitais en rajouter une de plus :
C’est l’approche la plus stricte et aussi la plus propre d’un point de vue sécurité :
Sécurité maximale
Aucun contournement des restrictions existantes
Comportement parfaitement déterministe
Les Corporate Device Identifiers permettent de dire à Intune que si un poste correspond à ces caractéristiques, il doit le considérer comme corporate dès le début de l’enrôlement.
Ainsi le device n’est jamais vu comme Unknown et les politiques bloquantes ne s’appliquent pas. Mais le seul souci reste la gestion et la manipulation de numéros de série des Windows 365 Link.
Pour cela, commencez par créer un fichier au format CSV contenant les champs suivants :
Manufacturer,Model,SerialNumber
Cela peut donner le fichier suivant :
Rendez-vous dans le menu d’Intune suivant :
Choisissez le type suivant, puis charger le fichier CSV précédemment créé :
Cliquez sur Ajouter :
Constatez l’apparition de votre poste dans les Corporate Device Identifiers :
Retournez sur votre Windows 365 Link afin de terminer la phase d’enrôlement :
Sur la console Intune, constatez le changement de statut de votre Windows 365 Link :
Cette fois, la phase d’enrôlement a pu aller jusqu’au bout, l’utilisateur peut maintenant se connecter à son Cloud PC :
Passons maintenant à une approche plus souple, mais tout aussi maîtrisable.
Méthode II – Autoriser Windows 365 Link via un filtre Intune :
Au lieu d’identifier chaque Windows 365 Link individuellement via des numéros de série, il est possible de définir une restriction d’enrôlement particulière à Windows 365 Link, avec une priorité plus haute, et ciblée uniquement sur Windows 365 Link via un filtre Intune.
Cette restriction d’enrôlement autorise l’enrôlement des Windows 365 Link, sans remettre en cause les restrictions pour les autres Windows.
Depuis le portail Intune, créez un filtre d’assignation pour les Windows 365 Link via le menu suivant :
Spécifie la règle de filtrage selon la propriété suivante afin de ne prendre en compte que les appareils Windows 365 Link :
Retournez ensuite dans la liste des restrictions d’enrôlement Windows afin d’en ajouter une nouvelle :
Nommez cette restriction, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Assignez cette restriction à tous les utilisateurs, puis cliquez ici pour ajouter un filtre :
Reprenez le filtre créé spécialement pour les Windows 365 Link :
Cliquez sur Suivant :
Cliquez sur Créer :
Attendez quelques secondes la fin de la nouvelle restriction d’enrôlement :
La règle doit être au-dessus de toute restriction d’enrôlement bloquante, pour cela, effectuez un glisser-déposer afin de changer la priorité de la restriction d’enrôlement dédiée au Windows 365 Link :
Avec cette deuxième méthode, la phase d’enrôlement a pu aller jusqu’au bout, l’utilisateur peut maintenant se connecter à son Cloud PC :
Passons maintenant à la troisième méthode.
Méthode III – Device Enrollment Manager (DEM) :
En utilisant un compte disposant du rôle DEM, il est également possible de contourner ces restrictions dans certains scénarios :
Un gestionnaire d’inscription d’appareil (DEM) est un utilisateur non administrateur qui peut inscrire des appareils dans Intune.
Les gestionnaires d’inscriptions des appareils sont utiles lorsque vous devez inscrire et préparer de nombreux appareils pour la distribution. Un compte DEM peut inscrire et gérer jusqu’à 1 000 appareils, tandis qu’un compte non administrateur standard ne peut en inscrire que 15.
Un DEM peut donc enrôler des devices même s’ils sont bloqués par des restrictions et aussi dépasser les limites de devices par utilisateur.
Configurez un ou plusieurs DEM sur le compte suivant :
Avec cette troisième méthode, la phase d’enrôlement a pu aller jusqu’au bout, le DEM a pu enrôler le Windows 365 Link et maintenant tous les utilisateurs peuvent se connecter à leur Cloud PC :
À noter que le DEM se retrouve en tant qu’utilisateur principal, et qu’il peut être remplacé :
Méthode IV – Windows Autopilot devices :
Lorsqu’on parle d’enrôlement Intune et de Windows 365 Link, une question revient très rapidement : Peut-on utiliser Windows Autopilot avec Windows 365 Link ?
Contrairement à un PC Windows classique, Windows 365 Link ne prend tout simplement pas en charge Windows Autopilot, quelle que soit la variante utilisée :
Autopilot : Windows 365 Link ne prend pas en charge autopilot ou la préparation des appareils Autopilot, notamment :
Inscription Autopilot
Configurations d’intégration
Actions d’appareil spécifiques à Autopilot, telles que la réinitialisation Autopilot.
Étant curieux, j’ai quand même voulu tester Autopilot pour le Windows 365 Link :
Mais le résultat a été l’effet attendu, puisque je n’ai pas été contraint lors de l’enrôlement du Windows 365 Link sur un autre tenant différent de celui configuré pour Autopilot :
Autrement dit, aucun scénario Autopilot n’est supporté, même partiellement, pour Windows 365 Link. Cette limitation n’est pas un oubli ou une restriction arbitraire : elle est directement liée à la nature même du Windows 365 Link :
Pas un Windows client classique
Aucune application locale
OS dédié extrêmement verrouillé
Politique stricte de contrôle d’exécution (intégrité du code)
Conclusion
Les restrictions d’enrôlement Intune sont l’un des premiers pièges rencontrés lors des déploiements de Windows 365 Link. Ce n’est ni un bug, ni un comportement anormal, mais la conséquence directe :
du cycle d’enrôlement Intune,
et du positionnement très spécifique de Windows 365 Link.
Une fois ce cadre bien compris, la solution devient finalement assez simple :
choisir la méthode d’enrôlement adaptée (Corporate Identifiers, filtre dédié ou DEM),
ne pas chercher à appliquer des logiques PC classiques (Autopilot, apps, scripts),
et traiter Windows 365 Link comme ce qu’il est réellement : un point d’accès sécurisé, minimaliste et contrôlé vers Windows 365.
C’est à cette condition que l’enrôlement devient fiable, reproductible, et cohérent avec une stratégie Cloud-first autour de Windows 365.
Depuis plusieurs mois, je souhaitais pouvoir Windows 365 Link dans des conditions réelles d’utilisation. Cette opportunité m’a enfin permis de prendre le temps d’analyser la solution de manière concrète, au-delà des annonces marketing et des fiches techniques. L’objectif de cet article est de décortiquer Windows 365 Link sous différents angles : technique, licences, intégration à l’écosystème Microsoft, mais aussi usage quotidien.
Au fil des tests, j’ai cherché à comprendre dans quels scénarios ce type d’appareil apporte une réelle valeur, et dans quels cas d’usage il montre ses limites.
Cet article se veut à la fois factuel et basé sur un retour d’expérience, afin d’apporter une vision pragmatique de Windows 365 Link et de son positionnement dans une stratégie de poste de travail cloud.
Pour vous guider plus facilement dans cet article très long, voici des liens rapides :
Commençons par le tout début. Il était une fois… Windows 365 Link.
Qu’est-ce que Windows 365 Link ?
En quelques mots, Windows 365 Link est un thin client qui permet de se connecter directement à un Cloud PC Windows 365, vous offrant ainsi un moyen sécurisé et simple d’accéder à votre environnement cloud.
Windows 365 Link est le premier appareil matériel pc cloud qui permet aux utilisateurs de se connecter directement à leur machine virtuelle Cloud PC. Il s’agit d’une solution de pile complète et spécialement conçue par Microsoft.
Lorsque les utilisateurs se connectent à leur Windows 365 Link, ils sont connectés à leur machine virtuelle PC Windows 365 Cloud via le service Windows 365.
Nerdio illustre, à l’aide d’un schéma simple, la manière dont Windows 365 Link s’intègre à l’écosystème cloud de Microsoft
Quelles sont ses caractéristiques techniques ?
Windows 365 Link mesure 120 × 120 × 30 mm pour un poids de 418 grammes, et est compatible VESA 100 et verrous Kensington. De plus, il dispose des connectivités suivantes :
Sans fil :
Wi-Fi 6E
Bluetooth 5.3
Face avant :
USB-A (USB 3.2)
Prise audio jack
Face arrière :
USB-C (USB 3.2)
DisplayPort (1.4a, jusqu’à 4k 60 Hz)
HDMI (2.0b, jusqu’à 4k60)
Ethernet (1.0 Gbit/s)
Alimentation électrique (65 watts)
Unified Extensible Firmware Interface (UEFI) pour la réinitialisation
Côté matériel et logiciel, on retrouve les éléments suivants :
Windows 365 Link est conçu pour offrir un accès direct, sécurisé et dédié à un PC Cloud Windows 365, sans exécuter de système Windows local complet. L’objectif n’est pas de remplacer un PC traditionnel, mais de proposer un point d’accès matériel minimaliste, fortement intégré aux services Microsoft Entra ID, Intune et Windows 365.
En quoi est-il différent d’un PC pour accéder à Windows 365 ?
Contrairement à un PC Windows traditionnel, Windows 365 Link ne stocke pas de données utilisateur localement et ne permet pas d’exécuter d’applications hors du PC Cloud. Toute l’expérience utilisateur est déportée dans le Cloud PC, ce qui contribue à réduire la surface d’attaque locale et simplifie considérablement l’administration du poste.
Windows 365 Link peut-il remplacer un thin client tiers ?
Windows 365 Link se rapproche fonctionnellement d’un thin client, mais avec une intégration native et exclusive à Windows 365.
Il ne vise pas la polyvalence fonctionnelle (VDI multiples, accès Linux ou AVD générique), mais une expérience optimisée et contrôlée pour Windows 365 uniquement. Cela en fait un choix pertinent dans des environnements standardisés, mais plus restrictif que certaines solutions tierces.
Attention, ce point a déjà été mentionné à plusieurs reprises, mais mérite d’être rappelé : Windows 365 Link ne prend pas en charge Azure Virtual Desktop ni Microsoft Dev Box.
Dans quels scénarios est-il le plus pertinent ?
Windows 365 Link est particulièrement adapté aux environnements à postes partagés, aux scénarios Frontline, aux centres de contact, aux environnements industriels ou aux sites distants où la simplicité de déploiement, la sécurité et la rapidité de remplacement du matériel sont prioritaires.
Voici quelques exemples de cas d’usage :
Postes partagés
Permettre aux collaborateurs en mode hybride de retrouver instantanément leur environnement de travail
Accès rapide et sécurisé à leur Cloud PC Windows 365, sans dépendance au poste physique
Idéal pour les environnements à forte rotation d’utilisateurs ou à postes non attribués
Centres d’appels
Démarrage en quelques secondes vers un Cloud PC Windows 365
Expérience utilisateur fluide et réactive, adaptée aux usages intensifs (voix, CRM, applications métiers)
Aucune donnée stockée localement sur le terminal, réduisant les risques de fuite d’informations
Authentification sans mot de passe via Microsoft Entra ID
Espaces spécialisés
Accès sécurisé aux outils et aux données dans des environnements contrôlés
Utilisation dans des lieux spécifiques tels que :
laboratoires
zones logistiques ou arrière-boutiques
centres de formation
accueils et réceptions
Frontline et métiers spécifiques
Mise à disposition d’un poste de travail Cloud sécurisé pour :
travailleurs de première ligne en milieu industriel
agents d’accueil
personnels en environnement scientifique ou de recherche
Réduction des contraintes matérielles locales et simplification du support
Métiers à forte sensibilité des données
Accès distant sécurisé pour des profils tels que :
analystes financiers
consultants
chargés de clientèle bancaire
agents de support client
téléconseillers / télévendeurs
Centralisation des données dans le Cloud PC, limitant les risques de fuite ou de perte
Dans quels cas n’est-il pas recommandé ?
Windows 365 Link est peu adapté aux utilisateurs nomades, aux scénarios nécessitant un fonctionnement hors ligne, ou aux usages impliquant des applications locales spécifiques ou des périphériques avancés non pris en charge. Il n’est pas non plus destiné à remplacer un poste de travail puissant pour des usages lourds locaux.
De ce fait, la comparaison entre Windows 365 Link + Cloud PC et un ordinateur portable moyen de gamme peut soulever des questions économiques :
Critère
Laptop moyen de gamme
Windows 365 Link + Windows 365
Coût matériel initial
~800 € (laptop)
365 € (Windows 365 Link)
Durée de vie
3–4 ans
4–5 ans (device statique)
Coût licence Windows 365
0 €
60 €/mois → 2 160 € sur 3 ans
Déploiement initial
Imaging, drivers, apps
Provisioning automatique
Support & maintenance (3 ans)
30 h × 60 €/h = 1 800 €
30 h × 30 €/h = 900 €
Données locales
Oui
Non
Exposition en cas de perte/vol
Élevée
Très faible (données Cloud)
Continuité de service
Dépend du matériel
Reconnexion immédiate
Coût total estimé sur 3 ans
~2 600 €
~3 425 €
Lecture du ROI
Référence
Surcoût ~825 € / poste sur 3 ans
Windows 365 n’est donc pas nécessairement moins coûteux par défaut, le ROI devient positif si :
Postes partagés / Frontline / hot desk
Réduction forte du support de proximité
Exigences sécurité élevées
Besoin de remplacement immédiat du poste
Sinon, sur poste dédié standard, l’ordinateur portable reste économiquement plus avantageux.
Permet-il de réduire les coûts IT et le provisioning ?
Dans les usages recommandés listés plus haut, Windows 365 Link peut contribuer à une réduction des coûts liés au support, au renouvellement matériel et à la gestion des images système. En revanche, il renforce la dépendance au modèle de licences Windows 365, qui doit être évalué globalement dans la stratégie poste de travail.
Windows 365 Link simplifie le provisioning, le remplacement des appareils et l’exploitation quotidienne grâce à l’enrôlement automatique Entra ID et Intune. L’administration est centralisée, avec moins d’interventions locales, ce qui facilite la standardisation et la gouvernance du poste de travail.
Quels sont ses bénéfices de sécurité ?
L’absence de données persistantes locales, l’authentification systématique via Microsoft Entra ID et l’intégration native avec les stratégies d’accès conditionnel renforcent la posture de sécurité globale. En cas de perte ou de vol du matériel, aucune donnée utilisateur n’est exposée localement.
En centralisant l’exécution et les données dans le Cloud PC, Windows 365 Link limite les impacts d’incidents matériels, de compromission locale ou de mauvaise configuration utilisateur. La gestion centralisée via Intune permet également d’appliquer des politiques de sécurité homogènes et cohérentes.
Quels sont les licences nécessaires pour l’utiliser ?
Voici les exigences connues pour pouvoir utiliser Windows 365 Link :
Exigences de licence Windows 365
Exigences Microsoft Entra ID
Exigences Microsoft Intune
Prenons le temps de comprendre en détail toutes ces exigences.
Exigences de licence Windows 365 :
Windows 365 Link n’introduit aucune nouveauté du côté des licences. On reste strictement dans le périmètre Windows 365.
Sans licence Windows 365 valide assignée à l’utilisateur, votre Windows 365 Link n’est pas utilisable : la connexion à un autre PC est tout simplement impossible, même à un environnement Azure Virtual Desktop.
À noter que Windows 365 Link accepte tous les types de licences Windows 365 :
Windows 365 Entreprise
Windows 365 Business
Windows 365 Frontline
Exigences Microsoft Entra ID :
Avec Windows 365 Link, un point apparaît rapidement comme non négociable : Windows 365 Link doit être Microsoft Entra joined ou Entra hybrid joined.
L’utilisateur qui effectue cette jonction doit bien évidemment avoir les droits pour joindre des appareils au tenant :
Lors de la jonction à Entra ID, le device s’enrôle automatiquement dans Intune. Et là, point important : l’utilisateur qui joint le device doit disposer d’une licence Microsoft Entra ID Premium, sinon l’enrôlement automatique échoue.
L’enrôlement automatique dans Intune dépend du paramétrage suivant :
Exigences Microsoft Intune :
L’enrôlement Intune des Windows 365 Link se fait pendant l’OOBE, sans action manuelle supplémentaire grâce aux mécanismes d’Entra.
Là encore, l’utilisateur qui joint le Windows 365 Link doit :
Disposer d’une licence Microsoft Intune
Avoir le droit d’enrôlement
Ne pas être bloqué par des restrictions d’enrôlement Intune :
Concrètement, voici ce que la donne lors du premier démarrage du Windows 365 Link :
L’utilisateur démarre et s’authentifie pour la toute première fois :
Le Windows 365 Link s’enrôle automatiquement dans Entra :
Puis l’enrôlement automatique MDM prend le relais pour l’ajouter dans Intune :
Avant d’arriver à cela avec votre Windows 365 Link, prenons le temps de passer en revue toutes les étapes.
Où peut-on l’acheter ?
Sa disponibilité dépend des pays et des vagues de lancement définies par Microsoft. L’appareil est proposé via des partenaires et revendeurs agréés Microsoft, comme TD SYNNEX selon les régions concernées.
À ce jour, la disponibilité semble s’élargir progressivement avec les vagues successives de déploiement, parfois désignées comme Wave 1 ou Wave 2. Windows 365 Link est actuellement disponible pour les pays suivants :
États-Unis
Australie
Canada
Danemark
France
Allemagne
Inde
Japon
Pays-Bas
Nouvelle-Zélande
Suède
Suisse
Royaume-Uni
Dans les prochains mois, Il devrait l’être par la suite aussi disponible dans :
Belgique
Finlande
Irlande
Italie
Pologne
Singapour
Espagne
Pour connaître les options d’achat exactes, il est recommandé de se rapprocher d’un partenaire Microsoft local ou de consulter les annonces officielles de Microsoft pour votre zone géographique.
Maintenant que les principaux aspects fonctionnels, techniques et de licences autour de Windows 365 Link ont été abordés, il est temps de passer à la partie plus concrète.
La section suivante détaille pas à pas les différentes étapes de configuration et de prise en main de Windows 365 Link, depuis la préparation de l’environnement jusqu’aux premiers tests en conditions réelles :
Dans mon environnement de test, j’ai déjà configuré plusieurs polices de provisionnement afin de créer mes Cloud PCs qui vont me servir durant mes tests :
Les Cloud PCs étant correctement déployés, une exigence particulière concerne toutefois le SSO avec Entra. Pour être plus clair, je vais maintenant repasser en détail sur toutes les étapes pour correctement configurer le SSO.
Etape I – Configuration du Single Sign-On :
Windows 365 Link repose entièrement sur le mécanisme Single Sign-On via Microsoft Entra ID. Autrement dit : si le SSO n’est pas activé sur le Cloud PC, la connexion de votre utilisateur risque d’échouer :
Pour activer le SSO, il sera nécessaire de vérifier, et de modifier si nécessaire, la police de provisionnement de vos Cloud PC, puis de recréer au besoin de nouveaux Cloud PCs si ces derniers ont été créés avant cette modification :
Voici l’option SSO dans la police de provisionnement des Cloud PCs qui doit être cochée :
L’étape suivante consiste à supprimer la demande de consentement SSO côté Microsoft Entra ID, dont la configuration repose sur des principaux de service :
Commençons par autoriser Microsoft Entra dans l’authentification pour Windows sur le tenant. Pour cela, j’utilise la console PowerShell d’Azure Cloud Shell, accessible depuis le portail Azure :
J’importe les deux modules Microsoft Graph suivants, puis je me connecte avec le compte aux permissions appropriées :
Je modifie la propriété isRemoteDesktopProtocolEnabledtruesur True, puis je vérifie que la propriété isRemoteDesktopProtocolEnabledest correctement définie :
Depuis le portail Intune, je crée ensuite un groupe contenant les Cloud PCs :
J’utilise une requête dynamique pour ajouter automatiquement mes prochains Cloud PCs au groupe :
Enfin, toujours dans la même session d’Azure Cloud Shell, j’ajoute l’ID de groupe à une propriété sur le principal du service SSO Windows Cloud Login :
Tout est maintenant en place pour tester la première authentification sur votre Windows 365 Link.
Etape II – Test de la première connexion Windows 365 Link :
La vidéo suivante correspond à la première connexion avec succès de mon utilisateur de test à son Windows 365 Link :
J’ai réalisé ensuite une seconde vidéo montrant plusieurs scénarios de connexion et de bascule d’utilisateurs avec Windows 365 Link :
Le premier test illustre la connexion d’un utilisateur unique à différents Cloud PC Windows 365 qui lui sont attribués. L’objectif est d’observer le temps de connexion, la fluidité du changement de Cloud PC, ainsi que l’efficacité globale du processus d’authentification.
Le second test se concentre sur un scénario de type pool partagé, comparable à un usage Windows 365 Frontline, où plusieurs utilisateurs se connectent successivement au sein d’un même pool de Cloud PC. Ce scénario permet d’analyser le comportement de l’authentification, la gestion des sessions et la rapidité de bascule entre utilisateurs.
Ces démonstrations offrent un retour concret sur les performances et l’expérience utilisateur, avant d’aborder les aspects de configuration et d’administration via Intune.
Travis nous a d’ailleurs fait une excellente vidéo sur ce sujet disponible juste ici :
Une fois ces premiers tests de connexion réalisés, on peut imaginer d’autres tâches ou configurations que l’on peut faire autour de son Windows 365 Link.
Mais avant cela, je vous conseille de commencer par créer un filtre d’assignation Intune pour cibler uniquement les Windows 365 Link dans vos futures polices de configuration.
Etape III – Création d’un filtre d’assignation Intune :
Depuis le portail Intune, je commence par créer un filtre d’assignation, qui me sera très utile pour configurer les Windows 365 Link par la suite :
Je nomme ce filtre avec comme plateforme Windows 10 et +, puis je clique sur Suivant :
Je spécifie la règle de filtrage selon la propriété suivante afin de ne prendre en compte que les appareils Windows 365 Link, puis je clique sur Prévisualiser :
Si des Windows 365 Link sont déjà présents, je devrais voir ces derniers apparaître :
Enfin je confirme la création du filtre :
Mon filtre est maintenant en place, je vais pouvoir commencer à effectuer quelques réglages, comme la détection automatique du fuseau horaire.
Etape IV – Configuration automatique du fuseau horaire :
Au démarrage de votre Windows 365 Link, l’heure qui s’affiche n’est peut-être pas la bonne :
Les appareils Windows 365 Link peuvent rencontrer des problèmes de fuseau horaire si la détection automatique n’est pas autorisée. Il est possible de forcer l’utilisation du fuseau horaire local en autorisant l’accès à la localisation via Microsoft Intune.
Pour cela, connectez-vous au portail Intune, puis dirigez-vous vers le menu suivant :
Sélectionnez le type de profil suivant :
Renseignez les informations suivantes, puis cliquez sur Suivant :
Nom : Windows 365 Link – Time Zone Detection
Description : Autorise l’accès à la localisation afin de permettre la détection automatique du fuseau horaire sur les appareils Windows 365 Link.
Recherchez Access location, puis sélectionnez la catégorie Privacy, configurez comme ceci, puis cliquez sur Suivant :
Ajoutez les Scope tags nécessaires selon votre organisation, puis cliquez sur Suivant :
Dans Assignments, ciblez les appareils Windows 365 Link selon la méthode suivante, puis cliquez sur Suivant :
Par exemple, en utilisant All devices
En appliquant un Include filter basé sur un filtre de type Windows 365 Link
Vérifiez la configuration, puis cliquez ici pour déployer la stratégie :
Quelques minutes plus tard, l’accès à la localisation est autorisé, Windows 365 Link peut détecter automatiquement le fuseau horaire local, et affiche l’heure correcte selon la localisation de l’utilisateur :
Etape V – Modification du délai d’extinction de l’écran :
Par défaut, les appareils Windows 365 Link éteignent l’écran après environ cinq minutes d’inactivité. Ce comportement est assimilé à un verrouillage local : lorsque l’utilisateur réactive l’appareil, l’écran de connexion s’affiche.
Comme pour l’heure, la configuration se fait via une police de configuration Intune. Dans mon cas je configure l’extinction de l’écran après 9 minutes d’inactivité :
Travis nous a encore fait une excellente seconde vidéo sur ce sujet :
Etape VI – Modification des délais de déconnexion des sessions :
Comme Microsoft le recommande, est-il possible de raccourcir (mais pas de rallonger ?) les temps définis par défaut dans le cas de sessions Windows 365 inactives ou déconnectées :
Par défaut, Windows 365 PC Frontline conservent la session utilisateur active jusqu’à ce que :
En mode dédié : Le PC cloud est inactif pendant 30 minutes.
En mode partagé : Le PC cloud est inactif pendant 15 minutes.
Deux minutes avant la limite de temps d’inactivité, l’utilisateur reçoit une notification avec une boîte de dialogue.
Cette stratégie force la fermeture (log off) des sessions Windows 365 afin d’éviter :
Les sessions laissées ouvertes sans activité
Les sessions bloquées après une coupure réseau
La consommation inutile de capacité (critique en Frontline partagé)
Elle remplace alors entièrement le comportement par défaut des services Windows 365 expliqués plus haut, à la condition que les temps indiqués ne soient pas supérieurs :
Par contre, à la différence des configurations précédemment appliquées sur les Windows 365 Link, j’ai appliqué cette nouvelle police sur filtre comprenant uniquement les Cloud PCs Frontline comme ceci :
Le tableau ci-dessous résume les différents événements observés et les mécanismes impliqués dans ma configuration :
Étape
Heure
Événement
Mécanisme responsable
Login utilisateur
08h47
Connexion au Cloud PC Frontline
Session RDS active
Idle atteint
08h52
Message “You will be signed out in 2 minutes”
Idle session RDS (5 min)
Log off
08h54
Déconnexion automatique (sign out)
End session when time limits are reached
Écran noir
09h03
Extinction automatique de l’écran
Policy Display Windows 365 Link (9 min)
Etape VII – Connexion automatique sur un Cloud PC :
Windows 365 Link permet également d’activer des mécanismes de connexion automatique et d’authentification sans mot de passe (passwordless), afin de simplifier encore davantage l’accès au Cloud PC pour l’utilisateur final.
Dans ce scénario, l’utilisateur n’a pas besoin de saisir manuellement son identifiant, ce qui rend l’expérience de connexion particulièrement fluide :
Pour cela, je suis passé par la création d’une police de configuration personnalisé avec les paramètres OMA-URI suivants :
Nom : Activer les clés de sécurité FIDO pour la connexion à Windows
OMA-URI : ./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
Type de données : Integer
Valeur : 1
Il est également possible de configurer Windows 365 Link pour qu’il se connecte automatiquement à un Cloud PC Windows 365 spécifique :
Cette option est particulièrement adaptée aux environnements à poste dédié ou aux usages standardisés. On y retrouve les fonctionnalités habituelles, comme la restauration ou la réinitialisation de la connexion.
Enfin, un bouton Annuler permet d’annuler la connexion automatique à ce Cloud PC. Cette action redirige l’utilisateur vers l’écran de sélection afin de lui permettre de choisir un autre Cloud PC Windows 365 auquel se connecter :
Ces options permettent d’adapter finement l’expérience de connexion selon que l’on se trouve dans un scénario à poste dédié ou à usage partagé.
Etape VIII – Restauration de mode usine :
Si nécessaire, Microsoft propose une restauration en mode usine des Windows 365 Link depuis le portail Intune. Comme beaucoup de postes gérés en MDM sous Intune, cette fonction très utile permet de réinitialiser complètement l’appareil à distance, en supprimant toute configuration et toute association utilisateur, afin de le reprovisionner proprement.
Voici d’ailleurs une vidéo qui montre le processus en entier, d’environ 30 minutes (accéléré), sur un Windows 365 Link :
Etape IX – Test de Microsoft Teams :
J’ai réalisé un test Microsoft Teams avec Windows 365 Link et j’ai été très satisfait de l’expérience globale, tant sur la qualité du rendu que sur la fluidité du partage d’écran et des flux audio/vidéo.
Un tour dans les paramètres de Teams confirme que le mode Media Optimized (SlimCore) est bien actif avec Windows 365 Link :
Pour plus de détails sur SlimCore et son fonctionnement côté AVD / Windows 365, voir cet article dédié sur mon blog.
Ce test rapide illustre le rendu réel de Microsoft Teams en conditions d’usage, du partage d’écran et des flux caméra, en mettant en évidence que le traitement (CPU) est effectué localement sur le Windows 365 Link et non sur le Cloud PC :
Et voici encore une autre vidéo faite cette fois avec une vidéo YouTube :
Après ces différents tests et configurations, il est possible de tirer plusieurs enseignements concrets sur l’usage de Windows 365 Link.
Conclusion
En conclusion, et après plusieurs jours d’utilisation et de tests dans des scénarios réels, Windows 365 Link s’est montré convaincant à l’usage quotidien.
Les performances observées, la simplicité d’accès au Cloud PC et la stabilité globale de l’expérience m’ont laissé une impression très positive au quotidien. Dans certains cas, j’ai pu avoir des doutes quant à la pertinence de l’appareil, notamment pour des scénarios où ses limites fonctionnelles peuvent apparaître.
Néanmoins, pour les cas d’usage évoqués plus haut (postes partagés, environnements Frontline, centres de contact ou contextes à forte exigence de sécurité), Windows 365 Link apporte une réelle valeur.
C’est un produit cohérent, bien positionné dans la stratégie Cloud-first de Microsoft, et je suis personnellement très satisfait d’avoir pu le tester dans des conditions concrètes et représentatives.
Alors, Windows 365 Link est-il un produit de niche ou le début d’une nouvelle norme ?
Windows 365 Link s’inscrit dans la stratégie Cloud-first de Microsoft et cible des usages bien définis. Il ne remplace pas tous les postes de travail, mais propose une alternative cohérente dans les environnements où la simplicité, la sécurité et la centralisation priment sur la flexibilité locale.
Enfin, retrouvez-moi et Arnaud et Arnaud dans un futur AzuReX prévu le 29 janvier prochain à 13 heures, dont l’inscription se passe juste ici 😎
Vous commencez enfin à maîtriser le service Autopilot de Microsoft et vous vous en servez déjà pour déployer vos postes ? Cela tombe très bien ! Microsoft vient justement de sortir il y a quelques mois la Préparation de l’appareil Windows Autopilot. Peut-on parler de cette nouvelle fonctionnalité comme d’un Autopilot en version 2 ? Oui et non, mais cela va encore plus démocratiser Intune auprès des services IT.
Quelles sont les différences entre Autopilot v1 et Autopilot v2 ?
Le fait de les appeler v1 et v2 un choix personnel afin de gagner en clarté, ce qui ne veut pas dire que la seconde est un remplacement complet de la première. Voici d’ailleurs une comparaison v1/v2 rédigée par Microsoft :
Fonctionnalité
Windows Autopilot préparation de l’appareil (Autopilot v2)
Windows Autopilot (Autopilot v1)
Fonctionnalités
Prise en charge des environnements Government Community Cloud High (GCCH) et ministère de la Défense (DoD). Expérience d’approvisionnement plus rapide et plus cohérente. Informations de surveillance et de résolution des problèmes en quasi-temps réel.
Prise en charge de plusieurs types d’appareils (HoloLens, Salle de réunion Teams). De nombreuses options de personnalisation pour l’expérience d’approvisionnement.
Rejoindre Microsoft Entra. Jointure hybride Microsoft Entra.
Inscription de l’appareil requise ?
Non.
Oui.
Que doivent configurer les administrateurs ?
Stratégie de préparation des appareils Windows Autopilot. Groupe de sécurité de l’appareil avec le client d’approvisionnement Intune en tant que propriétaire.
Profil de déploiement Windows Autopilot. Page d’état d’inscription (ESP).
Quelles configurations peuvent être fournies lors de l’approvisionnement ?
Basé sur l’appareil uniquement pendant l’expérience out-of-box (OOBE).Jusqu’à 10 applications essentielles (métier), Win32, Microsoft Store, Microsoft 365). Jusqu’à 10 scripts PowerShell essentiels.
Basé sur l’appareil pendant l’ESP de l’appareil. Basé sur l’utilisateur pendant l’ESP utilisateur. N’importe quel nombre d’applications.
Résolution des problèmes de création de rapports &
Rapport de déploiement de la préparation de l’appareil Windows Autopilot : Affiche tous les déploiements de préparation des appareils Windows Autopilot. Davantage de données disponibles. Quasiment en temps réel.
Rapport de déploiement Windows Autopilot : Affiche uniquement les appareils inscrits sur Windows Autopilot. Pas en temps réel.
Prend en charge les applications métier et Win32 dans le même déploiement ?
Oui.
Non.
Versions prises en charge de Windows
Windows 11, version 23H2 avec KB5035942 ou version ultérieure. Windows 11, version 22H2 avec KB5035942 ou version ultérieure.
Comme le rappel l’excellent billet écrit sur le site de Synapsys, Microsoft a souhaité faire évoluer son service Autopilot créé en 2017 afin de pouvoir supporter un plus grand nombre d’appareils. Cela va permettre de gérer le provisionnement des Cloud PC Windows 365 ou pour des clients dont le tenant est sur une instance Gov du Cloud Microsoft :
Windows Autopilot Device Preparation vise à simplifier encore plus le déploiement des périphériques, en optimisant le temps global de préparation de celui-ci et en améliorant notamment la résolution des problématiques qui peuvent survenir pendant le déploiement ainsi que le reporting.
La grosse nouveauté comparée à Windows Autopilot est qu’il n’est plus nécessaire d’importer le hash matériel pour pouvoir bénéficier du service. Autre nouveauté, le profil de déploiement sera à déployer sur un profil utilisateur et non machine.
Ai-je besoin de licences spécifiques pour Autopilot v2 ?
Comme il est rappelé dans la documentation Microsoft, Autopilot v2 a besoin des mêmes licences que pour Autopilot v1. Voici une liste non exhaustive de licences ou combinaison de licences possibles :
Licence Microsoft 365 Business Premium
Licence Microsoft 365 F1 ou F3
Licence Microsoft 365 Academic A1, A3 ou A5
Licence Microsoft 365 Entreprise E3 ou E5
Licence Enterprise Mobility + Security E3 ou E5
Licence Intune pour l’éducation
Licence ID Microsoft Entra P1 ou P2 + Licence Microsoft Intune
Afin de se faire une meilleure idée sur Autopilot v2, je vous propose un petit exercice à réaliser sur une souscription Azure.
Dans cet exercice, nous allons effectuer les étapes suivantes :
Microsoft a même mis à disposition un très bon tutoriel pour Autopilot v2 juste ici :
Etape 0 – Rappel des prérequis :
Afin de tester la fonctionnalité d’intégration proposée via Autopilot v2, nous allons avoir besoin de :
Un tenant Microsoft
Une souscription Azure valide
Une ou des licences contenant Intune et Azure AD Premium P1
Une Image OS de Windows 11, version 22H2 ou 23H2 générée après avril 2024 ou avec le KB5035942
Etape I – Configurer l’inscription automatique Windows à Intune :
Commençons par la configuration sur Entra ID.
Pour que la préparation des appareils Windows Autopilot (Autopilot v2) fonctionne, les appareils doivent être en mesure de s’inscrire automatiquement dans Intune. L’inscription automatique des appareils dans Intune peut être configurée automatiquement dans le portail Azure
La méthode d’inscription à Intune avec Autopilot v2 ne diffère pas de la première : il est nécessaire de configurer une inscription automatique à Intune depuis le portail Entra ID.
Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis cliquez sur cela :
Définissez le périmètre de l’inscription automatique MDM à Intune, puis cliquez sur Sauvegarder :
Restons sur le portail d’Entra ID afin d’autoriser les utilisateurs à joindre des machines à Intune.
Etape II – Autoriser les utilisateurs à joindre des appareils :
Pour rappel, il existe plusieurs types de jointures possibles à Entra ID, dont voici un lien vers un précédent article. Avec Autopilot v2, les utilisateurs ont toujours besoin d’être autorisé à joindre des postes à Entra ID.
Pour que la préparation des appareils Windows Autopilot fonctionne, les utilisateurs doivent être autorisés à joindre des appareils à l’ID Microsoft Entra.
Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis activez cette option :
Continuons avec la création d’un premier groupe Entra ID dédié aux postes Intune.
Etape III – Créer un groupe d’appareils Entra ID :
La préparation des appareils Windows Autopilot utilise un groupe d’appareils dans le cadre de la stratégie de préparation des appareils Windows Autopilot. Le groupe d’appareils spécifié dans la stratégie de préparation des appareils Windows Autopilot est le groupe d’appareils dans lequel les appareils sont ajoutés automatiquement pendant le déploiement de la préparation de l’appareil Windows Autopilot
Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis créer un groupe dédié aux appareils automatiquement inscrits par Autopilot v2 :
Ajoutez le propriétaire Intune Provisioning Client ou avec son principal de service dont l’ID est le suivant : f1346770-5b25-470b-88bd-d5744ab7952c :
N’ajoutez aucun membre manuellement, puis cliquez sur Créer :
Continuons avec la création d’un second groupe Entra ID dédié aux utilisateurs Intune.
Etape IV – Créer un groupe d’utilisateurs Entra ID :
La préparation de l’appareil Windows Autopilot utilise un groupe d’utilisateurs dans le cadre de la stratégie de préparation des appareils Windows Autopilot. Les utilisateurs membres du groupe d’utilisateurs spécifié dans la stratégie de préparation de l’appareil Windows Autopilot sont les utilisateurs qui reçoivent le déploiement de la préparation de l’appareil Windows Autopilot.
Pour cela, restez sur le même menu qui précédemment d’Entra ID, puis créer un second groupe cette fois dédié aux utilisateurs concernés par le processus Autopilot v2 :
Ajoutez des membres manuellement ou dynamiquement en correspondance avec vos utilisateurs Autopilot v2, puis cliquez sur Créer :
Continuons avec la configuration de postes sous Intune.
Etape V – Affectation de la configuration Intune :
Pendant l’expérience OOBE (out-of-box experience) avant que l’utilisateur final ne soit connecté pour la première fois, la préparation de l’appareil Windows Autopilot permet de déployer jusqu’à :
10 applications managées
10 scripts PowerShell
Pour que les applications s’installent et que les scripts PowerShell fonctionnent correctement, ils doivent être affectés au groupe d’appareils créé pour la préparation des appareils Windows Autopilot.
J’ai souhaité dans mon cas créer différents scénarios d’installation d’applications :
Applications intégrées au processus Autopilot v2 :
Microsoft Company Portal (Windows Store)
Global Secure Access (EXE)
Applications obligatoires pour les postes Intune :
Google Chrome (MSI)
Microsoft 365 Apps (Microsoft 365 Apps)
Applications disponibles pour les utilisateurs Intune :
Adobe Acrobat Reader DC (Windows Store)
Mozilla Firefox (Windows Store)
Notepad X (Windows Store)
Pour cela, rendez-vous dans le menu suivant d’Intune, puis rajoutez vos applications concernées :
J’ai également rajouté un script PowerShell, mais que je ne souhaite pas intégrer dans le processus Autopilot v2 car les applications installées ou les scripts PowerShell qui s’exécuteront systématiquement dans un contexte système.
Il ne nous reste maintenant qu’à créer la stratégie de préparation des appareils Windows Autopilot.
Etape VI – Création de la stratégie de préparation des appareils Windows Autopilot :
La stratégie Autopilot spécifie la façon dont l’appareil est configuré pendant l’installation de Windows et ce qui est affiché pendant l’expérience OOBE (out-of-box experience).
Pour cela, rendez-vous dans le menu suivant d’Intune, puis cliquez sur le menu suivant :
Cliquez sur Créer :
Cliquez sur Suivant :
Nommez votre profil, puis cliquez sur Suivant :
Ajoutez le groupe dédié aux postes Intune via Autopilot v2, puis cliquez sur Suivant :
Définissez les paramètres de configuration Autopilot v2 :
Personnalisez l’expérience OOBE :
Ajoutez les applications intégrées dans le processus Autopilot v2 :
Ajoutez si besoin les scripts intégrés dans le processus Autopilot v2, puis cliquez sur Suivant :
Modifiez les tags au besoin, puis cliquez sur Suivant :
Ajoutez le groupe dédié aux utilisateurs Intune via Autopilot v2, puis cliquez sur Suivant :
Cliquez sur Sauvegarder :
La configuration Autopilot v2 est maintenant terminée, il ne nous reste qu’à créer une machine virtuelle Hyper-V sur Azure pour ensuite créer des machines sous Windows 11.
Etape VII – 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ésente dans la famille Dsv3, puis cliquez sur Suivant :
Rajoutez un second disque pour stocker la machine virtuelle Windows 11,créée plus tard dans notre machine virtuelle hôte (Hyper-V) :
Conservez les options par défaut, puis cliquez sur OK :
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 Hyper-V :
Ensuite, cliquez-ici pour déployer le service Azure Bastion :
Nous allons utiliser Bastion pour nous connecter de façon sécurisée à notre VM hôte (Hyper-V).
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 via la notification Azure suivante :
Renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :
Autorisez le fonctionnement du presse-papier pour Azure Bastion :
Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :
Exécutez la commande suivante pour installer les 2 rôles suivants :
Depuis la console Server Manager, ouvrez Hyper-V Manager :
Ouvrez le menu suivant :
Contrôlez la présence de votre switch virtuel créé précédemment :
Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM Hyper-V :
Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :
Sur celui-ci, créez un nouveau volume :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
L’environnement Hyper-V est maintenant en place. Nous allons pouvoir créer ensemble la machine virtuelle Windows 11.
Etape VIII – Création de la machine virtuelle Windows 11 :
Pour cela, il est nécessaire de récupérer une image au format ISO de Windows 11 afin d’y installer l’OS.
Toujours sur la machine virtuelle Hyper-V, ouvrez le navigateur internet Microsoft Edge.
Rendez-vous sur la page suivante pour télécharger l’ISO de Windows 11, puis effectuez les actions suivantes :
Choisissez la langue désirée, puis cliquez sur Confirmer :
Cliquez sur la version 64 bits pour lancer le téléchargement :
Attendez quelques minutes pour que le téléchargement de l’ISO se termine :
Depuis votre VM Hyper-V, rouvrez votre console Hyper-V Manager, puis cliquez-ici pour créer votre machine virtuelle Windows 11 :
Cliquez sur Suivant :
Modifiez les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM Hyper-V, puis cliquez sur Suivant :
Pensez à bien sélectionner Génération 2 :
Comme indiqué, cette option ne sera plus modifiable par la suite.
Modifiez la taille de la mémoire vive allouée à la VM Windows 11, puis cliquez sur Suivant :
Utilisez le switch créé précédemment, puis cliquez sur Suivant :
Cliquez sur Suivant :
Utilisez le fichier ISO de Windows 11 téléchargé précédemment, puis cliquez sur Suivant :
Cliquez sur Terminer pour finaliser la création de votre machine virtuelle Windows 11 :
Une fois la machine virtuelle Windows 11 créée, modifiez sa configuration comme ceci :
Dans la section Sécurité, cochez la case suivante pour activer TPM :
Modifiez le nombre de processeurs virtuels afin d’accélérer l’installation de Windows 11, puis cliquez sur OK :
Double-cliquez sur votre machine virtuelle Windows 11 :
Cliquez-ici pour lancer le démarrage de la VM Windows 11 :
Appuyez sur n’importe quelle touche du clavier pour démarrer sur l’image ISO de Windows 11 :
Attendez que le chargement se termine :
La machine virtuelle est maintenant prête à recevoir l’OS Windows 11. Suivez toutes les étapes de l’installation pour le configurer et l’installer.
Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :
Lancez l’installation de Windows 11 :
Choisissez une version de Windows 11, puis cliquez sur Suivant :
Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :
Sélectionnez l’installation personnalisée de Windows 11 :
Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :
Attendez maintenant que l’installation de Windows 11 commence :
Lancez le redémarrage de la machine virtuelle Windows 11 :
Tout est bon, il ne nous reste plus qu’à voir si nouvelle méthode d’Autopilot v2 prend bien la suite de la configuration une fois l’utilisateur 365 authentifié.
Etape IX – Test Autopilot v2 :
Attendez quelques minutes que le redémarrage se termine :
Une fois l’interface Windows 11 affichée, sélectionnez le pays adapté, puis cliquez sur Oui :
Choisissez le clavier correspondant au vôtre, puis cliquez sur Oui :
Ajoutez si besoin un second clavier :
Attendez que l’installation de Windows 11 vérifie si de nouvelles mises à jour sont disponibles :
Le traitement peut être plus ou moins long :
Un redémarrage est même possible :
Afin que le processus Autopilot v2 fonctionne, configurez votre Windows 11 avec un des utilisateurs appartenant au groupe créé pour les utilisateurs Intune via Autopilot v2, puis cliquez sur Suivant :
Windows 11 se connecte alors au compte 365 pour en comprendre la configuration Autopilot v2 :
Le processus de préparation des appareils Windows Autopilot démarre alors :
Une fois le traitement terminé, cliquez sur Accepter :
Si besoin, déverrouillez la session Windows pour continuer :
Attendez la fin de configuration Windows :
Vous voilà enfin sur le bureau Windows 11 !
Attendez quelques minutes afin de voir le Company Portal s’installer automatiquement :
Le client Global Secure Access, est lui aussi installé automatiquement, ouvrant une fenêtre authentification avec possibilité SSO :
Environ 20 minutes plus tard, d’autres applications comme ceux liés à la suite Office, s’installent également de façon automatique :
Prenons en exemple l’installation manuelle de Mozilla Firefox :
L’installation manuelle via le Company Portal ne prend que quelques secondes :
Et l’application Firefox s’ajoute bien dans menu Démarrer de Windows :
Le script configuré en dehors de la Préparation de l’appareil Windows Autopilot (Autopilot v2) s’exécute bien dans le contexte utilisateur :
Enfin côté portail Intune, Microsoft propose également un nouveau rapport afin de surveiller l’état des déploiements Autopilot v2 :
Conclusion
J’espère que cet article vous aura permis de percevoir les avantages et l’intérêt possible de cette nouvelle méthode Autopilot v2. Bien entendu, et comme le rappelle Microsoft, ce nouveau type de déploiement ne pourra pas encore prendre en compte tous les scénarios ou toutes les configurations.
La gestion des mots de passe est une tâche critique, mais ô combien barbante, que cela concerne les comptes personnels ou professionnels. L’apparition des gestionnaires de mots de passes et des méthodes d’authentifications renforcées (2FA / MFA) ont permis d’accroîte la sécurité sur les identités.
Windows fonctionne de la même manière et dispose-lui aussi de comptes aux droits variés. Microsoft propose justement d’en gérer une partie pour vous via Entra ID (Azure AD).
Microsoft a annoncé en mai 2023, la prise en charge des mots de passe Windows LAPS (Windows Local Administrator Password Solution) par Entra ID (Azure AD).
En quelques mots, Entra ID est capable de stocker de façon sécurisé le mot de passe de l’administrateur local de chacun des postes Windows. Mais il y a mieux, Entra ID se chargera aussi de la rotation de ces derniers selon vos propres règles !
Qu’est-ce Windows LAPS ?
Chaque machine Windows dispose d’un compte d’administrateur local intégré qui ne peut pas être supprimé et qui dispose d’autorisations complètes sur l’appareil. La sécurisation de ce compte est une étape importante dans la sécurisation de votre organization. Les appareils Windows incluent la solution de mot de passe de l’administrateur local Windows (LAPS), une solution intégrée permettant de gérer les comptes d’administrateur local.
La configuration de Windows LAPS via Azure AD se fait via Microsoft Intune. Il faudra donc joindre en MDM les machines à ce dernier de afin de pouvoir leur appliquer la police de configuration.
Pour cela les jointures suivantes sont possibles :
Jointure à Azure AD
Jointure Hybride (Azure AD + Active Directory)
Intune prend en charge les fonctionnalités suivantes de Windows LAPS :
Définition des exigences de mot de passe
Rotation automatique et périodique du mot de passe
Choix du lieu de sauvegarde du mot de passe
Actions après utilisation du mot de passe
Avons-nous besoin de licence particulière ?
Pour profiter de la fonctionnalité Windows LAPS au travers d’Entra ID / Intune, il est nécessaire de disposer ces licences suivantes :
Microsoft Intune Plan 1
Microsoft Entra ID Free, anciennement Azure Active Directory Free
Existe-t-il des rôles RBAC dédiés à Windows LAPS ?
Windows LAPS est encore en préversion à l’heure où ces lignes sont écrites. Les rôles et permissions dédiés seront introduit par la suite. Pour l’instant, il est nécessaire d’utiliser l’un des deux rôles Azure AD suivants :
Global Administrator
Cloud Device Administrator
Enfin, Microsoft a commencé à mettre une FAQ sur Windows LAPS juste ici.
Afin de bien comprendre Windows LAPS, nous nous allons prendre de tester cette nouvelle fonctionnalité dans cet article :
Pour réaliser cet exercice sur Windows LAPS, il vous faudra disposer des ressources suivantes :
Une souscription Azure valide
Une Licence Intune Plan 1
Dans notre exercice, nous allons créer plusieurs machines virtuelles via Azure Virtual Desktop afin de servir de machines utilisateurs de test. Ces machines seront automatiquement jointes à Entra ID et Intune pour la suite de notre configuration.
Etape I – Préparation d’Azure Virtual Desktop :
Commençons par créer nos machines virtuelles AVD de test.
Pour cela, rendez-vous dans le portail d’Azure afin créer un réseau virtuel en utilisant la barre de recherche en haut de l’écran :
Cliquez ici pour créer votre réseau virtuel pour les VMs d’AVD :
Renseignez les différents champs, puis lancez validation du template par Azure :
Une fois la validation réussie, lancez la création de la ressource :
Attendez environ une minute que le réseau virtuel Azure soit créé, puis cliquez-ici :
Rendez-vous dans la section suivante afin de créer un futur accès aux VMs via le service Azure Bastion :
Le service Azure Bastion se créé en tâche de fond comme le montre les deux notifications suivantes :
N’attendez par la fin d’Azure Bastion et continuez la création des ressources AVD en utilisant la barre de recherche Azure :
Cliquez-ici pour créer un nouvel environnement Azure Virtual Desktop :
Renseignez les champs du premier onglet, puis cliquez sur Suivant :
Inutile de modifier l’accès réseau AVD sur le second onglet, cliquez sur Suivant :
Renseignez les informations liées aux machines virtuelles AVD en prenant soin de choisir une image présente dans la liste de celles compatibles avec Windows LAPS :
Définissez le nombre de VMs voulues, puis renseignez le réseau virtuel créé précédemment :
Joignez vos VMs AVD à Azure AD et en gestion MDM avec Intune, puis renseignez un mot de passe administrateur local qui sera géré par Windows LAPS par la suite :
Créez un espace de travail AVD, puis lancez la validation Azure :
Une fois la validation Azure passée, lancez la création des ressource AVD :
Le traitement Azure devrait durer une dizaine de minutes environ :
Pendant ce temps, recherchez Azure AD afin de créer les groupes et utilisateurs :
Créez si besoin les utilisateurs nécessaires à AVD :
Créez si besoin le groupe d’utilisateurs nécessaire à AVD :
Retournez sur le portail Azure afin d’ajouter des rôles RBAC Azure sur le groupe de ressources AVD :
Ajoutez les rôles suivants sur le groupe d’utilisateurs AVD :
Quelques minutes plus tard, les ressources Azure créées pour AVD sont bien disponibles, cliquez-ici pour consulter le pool d’hôtes :
Rafraichissez plusieurs fois afin que toutes les machines AVD soient prêtent et disponibles :
Quelques rafraichissements plus tard, toutes les machines virtuelles sont bien disponibles :
Activez la fonction suivante pour profiter du SSO dans les propriétés RDP, puis sauvegardez :
Votre environnement Azure Virtual Desktop est maintenant prêt. Nous allons pouvoir maintenant configurer Windows LAPS.
Etape II – Préparation de Windows LAPS sur Entra ID :
Afin de pouvoir utiliser Windows LAPS sur nos machines virtuelles d’Azure Virtual Desktop, il est nécessaire de l’activer sur notre tenant.
Pour cela, rendez-vous sur le portail Entra afin d’activer l’option suivante, puis sauvegardez :
Profitez-en pour vérifier les présences des VMs AVD et la bonne gestion MDM par Intune :
Créez un nouveau groupe Azure AD dédié aux machines virtuelles AVD :
Ajoutez les VMs AVD à ce groupe, puis lancez la création :
Le travail sur Entra ID est maintenant terminé, il ne nous reste qu’à créer notre police de configuration dédiée à Windows LAPS sur Intune.
Etape III – Configuration de Windows LAPS sur Intune :
Pour cela, rendez vous sur le portail Intune sur l’adresse suivante.
Créer une nouvelle police de configuration comme ceci :
Choisissez le type de profile ci-dessous, puis cliquez sur Créer :
Nommez votre nouvelle police de profil, puis cliquez sur Suivant :
Définissez les règles de configuration, puis cliquez sur Suivant :
Dans mon exemple, après chaque authentification réussie de mon administrateur local JLO, un nouveau mot de passe sera redéfini 1 heure après.
Sinon, ce dernier est systématiquement changé tous les 7 jours.
Cliquez sur Suivant :
Ajoutez le groupe de VMs créé précédemment, puis cliquez sur Suivant :
Lancez la création de votre police Windows LAPS :
Toujours sur Intune, allez voir sur une des VMs AVD afin de voir la liste des configurations appliquées :
Attendez quelques minutes puis rafraichissez afin de constater la présence de votre nouvelle police Windows LAPS :
Notre configuration est enfin terminée, nous allons pouvoir tester Windows LAPS et son impact en nous connectant sur une des machines virtuelles AVD de test.
Etape IV – Test de Windows LAPS
Avant de vous connecter, retournez sur la liste des VMs AVD depuis le portail Azure AD :
Sur une des machines AVD, cliquez sur le menu suivant pour constater l’absence de mot de passe de l’administrateur local :
Sur le portail Azure, retournez sur la liste des machines virtuelles afin de vous y connecter à l’une d’entre-elles via Azure Bastion en utilisant le compte administrateur AVD renseigné :
Vérifiez la présence des droits administrateurs sur votre session :
Déconnectez-vous de la session Azure Bastion :
Attendez un peu, puis recommencez une connexion Azure Bastion avec les mêmes identifiants :
Constatez l’apparition du message d’erreur suivant :
Retournez sur la VM AVD utilisée depuis le portail d’Azure AD :
Retentez une nouvelle connexion Azure Bastion avec le mot de passe récupéré sur Windows LAPS :
Déconnectez-vous encore une fois de la session Azure Bastion :
Attendez environ une heure, puis recommencez une connexion Azure Bastion avec les mêmes nouveaux identifiants :
Constatez encore une fois l’apparition du message d’erreur suivant :
Retournez encore une fois sur la VM AVD utilisée depuis le portail d’Azure AD :
Retentez une 3ème connexion Azure Bastion avec le mot de passe récupéré sur Windows LAPS :
Déconnectez-vous une fois 3ème de la session Azure Bastion :
Une heure plus tard, le mot de passe aura encore tourné ✌️:
Petite anecdote :
Sur mon portail Intune, je ne vois pas le menu Local admin password 🥲🥲
Cela ne m’a pas empêché de retrouver l’info sur le portail d’Azure AD.
Conclusion
Très facile à mettre en oeuvre et fonctionnant aussi bien dans une architecture 100% Cloud ou Hybride, cette solution apporte une sécurité supplémentaire sur les postes physiques ou virtuels. Nul doute que la gestion de mots de passe administrateur Windows dans Azure va également faciliter le travail de fournis de certains administrateurs IT 😎
La mise en place d’un processus de provisionnement des postes utilisateurs peut, par moment, virer au casse-tête ! Entre le spécifique nécessaire à certains utilisateurs, les besoins complexes, ou encore les contraintes géographiques pour la réception des matériels, les équipes IT doivent pouvoir se reposer sur des outils modernes, efficaces et facilement adaptables.
Le but n’étant pas de leur retirer tout travail, mais bien de leur faciliter la vie ! Après un premier article sur les GPOs poussées via Intune, je trouvais intéressant d’écrire un second article, dédié à la fonction d’Autopilot de celui-ci.
Intune, ou Microsoft Endpoint Manager, simplifie le processus de préparation des postes utilisateurs. Comme les services du Cloud Microsoft, Intune a la faculté de pousser des configurations de poste et des applications au travers d’une connexion internet.
Cette approche de connexion simplifie grandement le management des postes, que ces derniers soient sur le réseau d’entreprise ou en situation de mobilité.
Qu’est-ce qu’Autopilot ?
Windows Autopilot est un ensemble de technologies utilisées pour configurer et préconfigurer de nouveaux appareils de manière à les préparer à une utilisation productive. Windows Autopilot peut être utilisé pour déployer des PC Windows
Le bénéfice premier d’Autopilot est donc de combler la phase initiale, afin que le poste de l’utilisateur, à peine déballé par ce dernier, soit directement rattaché au tenant, et donc de fait « guidé » dans un processus de mise en route.
Cette méthode permet de retirer, dans certains cas, des étapes préparatoires réalisées par les équipes IT, ou des actions réalisées par l’utilisateur final pour la finalisation du processus de configuration du poste.
De quoi avons-nous besoin pour qu’un poste intègre le processus Autopilot ?
Dans la plupart des cas, l’importation des postes à un tenant 365 via Autopilot repose sur l’utilisation du Hash de l’appareil.
Un hachage d’appareil ou de matériel est une chaîne de chiffres et de lettres … qui contient des informations sur l’appareil et son utilisateur. Ces informations s’apparentent à l’identité de l’appareil.
Il est aussi possible de travailler avec le numéro de série du fabricant. Une fois la liste de hashs à disposition, il suffit de :
Importer celle-ci sur le tenant 365, via le portail Intune
Configurer un profil Autopilot associé aux machines importées
Ai-je besoin de licences spécifiques pour Autopilot ?
Comme il est rappelé dans la documentation Microsoft, Autopilot a besoin de plus que la licence Intune. Il est en effet nécessaire de disposer d’une licence Azure Active Directory Premium P1 ou P2.
Afin de se faire une meilleure idée sur le processus Autopilot, je vous propose un petit exercice à réaliser sur une souscription Azure. Dans cet exercice, nous allons effectuer les étapes suivantes :
Pour réaliser cet exercice sur Autopilot, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Une licence contenant Intune
Une licence contenant Azure AD Premium P1
Afin de tester la fonctionnalité Autopilot, nous allons avoir besoin d’intégrer une machine dans notre tenant 365. Plus exactement, il va être nécessaire de précharger son hash dans la console Intune sur le tenant 365 de test.
Pour cela, je vous propose de simuler un poste sous Windows 11 grâce à un environnement virtualisé de type Hyper-V.
Dans Azure, il est en effet possible 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 jaunes suivantes :
Choisissez une taille de machine virtuelle présent dans la famille Dsv3, puis cliquez sur Suivant :
Rajoutez un second disque pour stocker la machine virtuelle invitée (Windows 11),créée plus tard dans notre machine virtuelle hôte (Hyper-V) :
Conservez les options par défaut, puis cliquez sur OK :
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 :
Nous allons utiliser Bastion pour nous connecter de façon sécurisée à notre VM hôte (Hyper-V).
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 via la notification Azure suivante :
Renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :
Autorisez le fonctionnement du presse-papier pour Azure Bastion :
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 :
Depuis la console Server Manager, ouvrez Hyper-V Manager :
Ouvrez le menu suivant :
Contrôlez la présence de votre switch virtuel créé précédemment :
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 :
Sur celui-ci, créez un nouveau volume :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
L’environnement Hyper-V est maintenant en place. Nous allons pouvoir créer ensemble la machine virtuelle invitée (Windows 11).
Etape II – Création de la machine virtuelle invitée (Windows 11) :
Pour cela, il est nécessaire de récupérer une image au format ISO de Windows 11 afin de créer la machine virtuelle invitée (Windows 11), puis d’y installer l’OS.
Toujours sur la machine virtuelle hôte (Hyper-V), ouvrez le navigateur internet Microsoft Edge.
Rendez-vous sur la page suivante pour télécharger l’ISO de Windows 11, puis effectuez les actions suivantes :
Choisissez la langue désirée, puis cliquez sur Confirmer :
Cliquez sur la version 64 bits pour lancer le téléchargement :
Attendez quelques minutes pour que le téléchargement de l’ISO se termine :
Depuis votre VM hôte (Hyper-V), rouvrez votre console Hyper-V Manager, puis cliquez-ici pour créer votre première machine virtuelle invitée (Windows 11) :
Cliquez sur Suivant :
Modifier les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM hôte (Hyper-V), puis cliquez sur Suivant :
Pensez à bien choisir Génération 2 :
Comme indiqué, cette option ne sera plus modifiable par la suite.
Modifier la taille de la mémoire vive allouée à la VM invitée (Windows 11), puis cliquez sur Suivant :
Utilisez le switch créé précédemment, puis cliquez sur Suivant :
Cliquez sur Suivant :
Utilisez le fichier ISO de Windows 11 téléchargée précédemment, puis cliquez sur Suivant :
Cliquez sur Terminer pour finaliser la création de votre machine virtuelle invitée (Windows 11) :
Une fois la machine virtuelle créée, modifiez sa configuration comme ceci :
Dans la section Sécurité, cochez la case suivante pour activer TPM :
Modifiez le nombre de processeurs virtuels afin d’accélérer l’installation de Windows 11, puis cliquez sur OK :
Double-cliquez sur votre machine virtuelle invitée (Windows 11) :
Cliquez-ici pour lancer le démarrage de la VM invitée (Windows 11) :
Appuyez sur n’importe quelle touche du clavier pour démarrer sur l’image ISO de Windows 11 :
Attendez que le chargement se termine :
La machine virtuelle est maintenant prête à recevoir l’OS Windows 11. Suivez toutes les étapes de l’installation pour le configurer et l’installer.
Etape III – Installation de Windows 11 sur la VM invitée (Windows 11) :
Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :
Lancez l’installation de Windows 11 :
Attendez que le démarrage de l’installation se lance, puis cliquez-ici pour ne pas renseigner de clef de licence Windows 11 :
Choisissez une version de Windows 11, puis cliquez sur Suivant :
Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :
Sélectionnez l’installation personnalisée de Windows 11 :
Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :
Attendez maintenant que l’installation de Windows 11 commence :
Lancez le redémarrage de la machine virtuelle invitée (Windows 11) :
Attendez quelques minutes que le redémarrage se poursuivre :
Sélectionnez le pays adapté, puis cliquez sur Oui :
Choisissez le clavier correspondant au vôtre, puis cliquez sur Oui :
Ajoutez, si besoin, un second clavier :
Attendez que l’installation de Windows 11 vérifie si de nouvelles mises à jour sont disponibles :
Nommez votre machine virtuelle invitée (Windows 11) selon vos souhaits, puis cliquez sur Suivant :
Attendez que la configuration finale se termine :
Afin de récupérer le hash de notre machine virtuelle invitée (Windows 11), nous avons besoin d’un compte local.
Pour cela, configurer votre VM invitée (Windows 11) comme ceci, puis cliquez sur Suivant :
Donnez à nom à votre compte local Windows, puis cliquez sur Suivant :
Définissez un mot de passe à votre compte local Windows 11, puis cliquez sur Suivant :
Confirmez votre nouveau mot de passe une seconde fois, puis cliquez sur Suivant :
Adaptez la configuration des paramètres de confidentialité, puis cliquez sur Accepter :
Attendez quelques minutes durant la seconde vérification de mise à jour :
Attendez enfin la dernière finalisation de la configuration de Windows 11 :
Vous voilà enfin sur le bureau Windows de votre machine virtuelle invitée (Windows 11) :
Retournez sur la console Hyper-V de votre VM hôte (Hyper-V) afin de créer un snapshot de votre VM invitée (Windows 11) :
Attendez quelques secondes, puis cliquez sur OK sur le message de notification suivant :
La machine virtuelle invitée est maintenant en place avec un OS Windows 11. Nous allons maintenant récupérer son hash, l’intégrer dans notre tenant de test, puis réinitialiser celle-ci pour tester Autopilot.
Etape IV – Récupération et intégration du hash de la VM invitée (Windows 11)
Retournez sur le bureau de la machine virtuelle invitée (Windows 11), puis ouvrez PowerShell en mode administrateur :
Cliquez sur Oui pour confirmer votre choix :
Saisissez le script suivant dans la fenêtre PowerShell. Celui-ci a pour but de générer un fichier CSV contenant le Hash de notre machine virtuelle invitée (Windows 11) :
Pour cela, utilisez la fonction suivante dans la connexion Hyper-V afin de faciliter le copier // coller entre la VM hôte (Hyper-V) et la VM invitée (Windows 11) :
Au besoin, utilisez Notepad pour vérifier le bon fonctionnement du copier // coller :
La commande du script créée le fichier AutopilotHWID.csv, contenant le hash de notre machine virtuelle invitée (Windows 11) :
Retrouvez ce fichier dans l’explorateur de votre machine virtuelle invitée (Windows 11) :
Vérifiez que le contenu du fichier présente bien des informations similaires à l’exemple ci-dessous :
Pour plus de facilité, utilisez la fonction de partage Windows afin de reprendre le contenu du fichier hash vers la machine virtuelle hôte (Hyper-V).
Pour cela, depuis la VM invitée (Windows 11), activez le partage du dossier racine comme ceci :
Cliquez sur le menu suivant :
Activez le partage du dossier :
Copiez le chemin réseau du partage nouvellement activé :
Depuis la machine virtuelle hôte (Hyper-V), coller le chemin réseau dans l’explorateur, puis utilisez les identifiants renseignés lors de la configuration du compte local de la VM invitée (Windows 11) :
Ouvrez le fichier CSV avec Notepad :
Copiez le contenu du fichier puis collez-le sur votre poste local, afin de pouvoir charger le fichier sur le portail Intune :
Enregistrer ce fichier nouvellement créé au format CSV :
De retour sur la machine virtuelle invitée (Windows 11), recherchez dans le menu Démarrer le programme de réinitialisation Windows :
Lancez le programme de réinitialisation de Windows 11 :
Confirmez la suppression de toutes les données personnelles :
Attendez que le traitement prépare l’opération de réinitialisation :
Choisissez la réinstallation depuis une source locale :
Cliquez sur Suivant pour préparer le traitement :
Attendez une seconde fois que le traitement prépare l’opération de réinitialisation :
Cliquez sur Réinitialiser pour lancer le traitement :
Vérifiez que le traitement de réinitialisation s’enclenche bien :
Depuis le portail Intune, accessible à cette adresse, rendez-vous dans la section dédiée à l’import Autopilot de machines Windows :
Cliquez-ici pour importer le fichier CSV contenant le hash de notre machine virtuelle invitée (Windows 11) :
Sélectionnez le fichier CSV, puis cliquer sur Importer :
Une notification de travail en cours doit apparaître :
Environ 30 secondes plus tard, l’importation est terminée avec succès :
Attendez quelques secondes, puis rafraichissez la page afin de retrouver votre machine virtuelle invitée (Windows 11) dans la liste :
Assignez si besoin un utilisateur Azure AD à votre machine de test afin d’améliorer le test de l’expérience Autopilot :
Sur la page d’Azure AD, créez ou utilisez un groupe Azure AD existant, puis ajoutez-y la machine virtuelle importée via Autopilot :
De retour sur le portail Intune, rendez-vous dans le menu suivant pour configurer un profil de déploiement Autopilot :
Configurez à votre guise votre profil de configuration Autopilot, puis assignez ce dernier au groupe Azure AD contenant votre machine virtuelle invitée (Windows 11) :
Quelques minutes plus tard, vérifiez bien la présence de ladite machine dans la section ci-dessous de votre profil Autopilot :
Etape V – Test de la fonction Autopilot
Retournez sur la machine virtuelle invitée (Windows 11) afin de constater l’avancement de la préparation à la réinitialisation de Windows 11 :
Environ 20 minutes plus tard, le processus de préparation à la réinitialisation est maintenant terminé :
La machine va ensuite redémarrer :
Des mises à jour automatiques sont prises en compte :
Le processus de réinitialisation commence enfin :
Celui-ci se poursuit avec la réinstallation de Windows 11 :
Une fois la réinstallation terminée, Windows 11 s’ouvre et affiche une fenêtre vous invitant à vous authentifier avec un compte 365 du tenant concerné.
Veuillez saisir le mot de passe de l’utilisateur :
Attendez quelques instants que Windows 11 récupère les éléments de configuration liés au poste :
Attendez encore afin que les éléments récupérés soit installés sur le poste :
Ce processus peut durer une vingtaine de minutes environ :
Différentes étapes sont alors réalisées, dont le détail est visualisable si besoin :
Après cela, Windows 11 s’ouvre et l’utilisateur peut déjà percevoir les éléments installés par la configuration :
Conclusion
J’espère que cet article vous aura permis de percevoir les avantages et l’intérêt possible grâce à Autopilot. Bien entendu, ce type de déploiement ne pourra pas prendre en compte tous les scénarios et toutes les configurations.
C’est pour cela que, bien souvent, plusieurs méthodes de déploiement sont à envisager afin de couvrir un spectre toujours plus grand sur les besoins des utilisateurs et les exigences de configuration IT.
Intune, ou aussi appelé Microsoft Endpoint Manager, continue son bonhomme de chemin. Microsoft vient d’annoncer il y a peu la possibilité de créer des profils de configuration basés via l’intégration simple et rapide de fichiers ADMX/ADML directement depuis la console Intune.
Est-ce vraiment nouveau ?
Alors non, cela ne l’est pas vraiment, car il était déjà possible sur Intune depuis 2020. Mais de gros progrès ont été fait sur l’interface des GPOs, qui a grandement évolué depuis.
Voici anciennement ce qu’il était possible de faire avant cette évolution :
Comme vous le voyez, l’interface n’était pas encore très adaptée et le travail restait très manuel, voir laborieux.
Dans cet article, nous allons justement tester la nouvelle méthode pour les GPOs et les différentes options possibles grâce à celle-ci.
Pourquoi refaire ce qu’un domaine Active Directory sait déjà très bien faire ?
Microsoft continue sa voie dans la création d’une architecture IT 100% Cloud « allégée » de certains composants historiques, comme les Contrôleurs de domaine.
Prenons l’exemple d’Azure Virtual Desktop et ses machines virtuelles jointes à Azure AD et gérées sous Intune. Microsoft proposera bientôt une solution sans contrôleur de domaine, une fois qu’Azure AD sera en mesure de gérer certains protocoles d’authentification.
Comment fonctionne Intune pour créer des GPOs ?
Intune a la même base qu’un domaine Active Directory pour créer des configurations GPOs. La configuration de GPOs repose toujours sur le couple de fichiers (ADMX / ADML).
Ces fichiers doivent donc être importés dans la console Intune, pour créer par la suite un profil de configuration de type Modèle administratif.
Afin d’en savoir un peu plus, je vous propose ce petit exercice, basé sur une GPO dédiée à Mozilla Firefox.
Rappel des prérequis :
Pour réaliser cet exercice Intune, il vous faudra disposer de :
Un tenant Microsoft
Une ou des licences Intune
Un ou des postes Windows 10/11 de test :
Comme je ne dispose pas de postes de test, j’ai décidé de créer plusieurs machines virtuelles sur Azure, via le service Azure Virtual Desktop. Ces machines AVD sont de type individuel et sont attribuées à plusieurs utilisateurs Cloud provenant d’un tenant CDX.
Lors de la création de cet environnement AVD, j’ai spécifié que les machines virtuelles soit gérées via Intune. Je retrouve d’ailleurs cette information dans Azure AD :
Mais également dans la console Intune de mon tenant :
Etape I – Déployer Mozilla Firefox sur les machines de test :
Avant de pouvoir configurer une GPO depuis la console Intune, il est nécessaire d’installer une application en relations avec celle-ci. J’ai donc choisi Mozilla Firefox pour servir d’application de test.
Comme mes machines virtuelles AVD proviennent d’une image Windows 11 provisionnée par Microsoft, Mozilla Firefox n’y est pas installé par défaut.
Pour l’installer, rendez vous dans la console Intune, puis cliquez sur le menu Applications :
Cliquez ici pour ajouter votre nouvelle application Firefox :
Sélectionnez le type Nouvel Microsoft Store, puis continuez :
Recherchez l’application Firefox, puis continuez :
Cochez l’option ci-dessous, puis passez sur l’onglet Suivant :
Choisissez l’assignation qui vous convient, puis continuez :
Lancez la création de l’application :
Attendez une bonne dizaine de minutes, puis constatez, toujours dans le menu Applications, la bonne installation de Mozilla Firefox sur une ou plusieurs machines de test :
Connectez-vous sur une machine de test avec un utilisateur du tenant pour constater la bonne apparition de l’application Mozilla Firefox dans le menu Démarrer :
Ouvrez l’application Firefox, terminez sa configuration, puis constatez l’absence de configuration particulière :
Etape II – Importez la configuration ADMX :
Avant de pouvoir configurer des polices Firefox depuis la console Intune, il est nécessaire d’importer dans celle-ci le modèle ADMX. Ce dernier est accompagné du fichier ADML, utilisé pour la traduction dans une langue locale.
Mozilla met à disposition les fichiers ADMX/ADML sur leur page GitHub, disponible juste ici.
Téléchargez le fichier ZIP disponible sur cette page, ou via ce lien direct juste là :
Lancez l’extraction des fichiers sur votre poste :
Dans le dossier issu de l’extraction de l’archive ZIP, constatez la présence pour Firefox du fichier ADMX :
Mais également du fichier ADML dans le sous-dossier de langue :
Vous noterez la présence deux autres fichiers, appelés aussi dépendances :
mozilla.admx
mozilla.adml
Ces deux dépendances sont nécessaires pour la configuration de Firefox. L’importation de fichiers Firefox avant ceux de Mozilla provoqueront une erreur Intune :
Retournez sur votre console Intune pour importer les deux fichiers Mozilla :
Cliquez sur Importer :
Sélectionnez les deux fichiers Mozilla, puis cliquez sur Suivant :
Cliquez ici pour démarrer l’importation :
Environ deux minutes et un rafraichissement plus tard, l’importation est réussie :
Recommencez la même opération avec les fichiers de configuration Firefox :
Environ deux minutes et un rafraichissement plus tard, la seconde importation est elle aussi réussie :
Etape II – Création du profil de configuration pour Firefox :
Intune est maintenant prêt pour la configuration de Firefox sur les postes de test. Il ne nous reste qu’à créer le profil de configuration, de type profil administratif, pour Firefox.
Pour cela, créez un nouveau profil comme ceci :
Donnez-lui un nom, puis cliquez sur Suivant :
Dans la section Configuration de l’ordinateur, recherchez le mot home, puis cliquez sur le résultat suivant :
Configurez la police avec une URL de votre choix, puis cliquez sur OK :
Cliquez sur Suivant :
Cliquez encore sur Suivant :
Choisissez l’assignation qui vous convient, puis continuez :
Lancez la création de la police :
Rafraichissez la page pour voir apparaître la nouvelle police dédiée à Mozilla Firefox :
Cliquez dessus et attendez son déploiement sur les machines de test :
Quelques minutes plus tard, les machines virtuelles reçoivent la police de configuration :
Etape III – Test de la GPO Firefox créée via Intune :
Retournez sur une machine de test, puis lancez Mozilla Firefox :
Constatez l’ouverture immédiate de la page de démarrage configurée dans votre GPO Intune :
Conclusion
Cette avancée ne semble pas extraordinaire, et pourtant, elle l’est ! Cet exercice montre avant tout la simplification du processus de création de GPOs via la console Intune, plébiscitée dans un grand nombre d’environnements Cloud. Nul doute que d’autres avancées sont encore dans les cartons de Microsoft pour Intune.
Attendu depuis plusieurs mois, il est maintenant possible de mettre en place un MDM via l’outil Intune pour des machines virtuelles partagées Azure Virtual Desktop. Il s’agit toujours d’une nouvelle feature en Preview, mais qui va à terme simplifier le maintien opérationnel de ce service de Remote Desktop proposé par Azure.
Pour vous re-situer dans le sujet, voici deux vidéos sélectionnées par mes soins sur qu’est ce qu’Intune et les différences et les synergies possibles avec Configuration Manager :
Points clefs d’Intune.
Merci à Jean-Sébastien 🙂
L’objectif de cet article est donc de vous parcourir avec vous toutes les étapes nécessaires à la mise en place de cette association.
Rappel :
Comme indiqué dans son article sur les machines virtuelles partagées, Microsoft nous explique que la prise en charge actuelle d’Intune est uniquement orientée sur la configuration des VMs. De ce fait et pour que l’application se fasse correctement, il sera donc nécessaire de cibler les polices sur des groupes de machines et non des groupes d’utilisateurs.
Etape 0 : Prérequis
Certaines conditions sont donc obligatoires pour profiter d’Intune sur un environnement Azure Virtual Desktop :
Windows 10 multisessions, version 1903 ou ultérieure
Azure Virtual Desktop host pool configuré en version partagé
Version de l’agent Azure Virtual Desktop égale ou supérieure à 2944.1400
L’une des exigences pour gérer votre environnement Windows 10 AVD avec Endpoint Manager est l’utilisation de la jointure hybride avec Azure AD. Lorsque vous configurez vos périphériques pour qu’ils rejoignent Azure AD, ces périphériques seront visibles et gérables à la fois dans votre AD sur site et dans Azure AD.
Etape I : Mise en place d’un serveur Active Directory sur une machine virtuelle
Comme rappelé plus haut, il est donc nécessaire de disposer d’un serveur Active Directory, géré sur une machine virtuelle et non pas via le service managé par Azure Active Directory Domain Services (AADDS). Vous devrez donc créer une machine virtuelle sous Windows Server et y installer le rôle Active Directory.
Vous pouvez mettre en place très facilement cet ensemble VM + DC via le template proposé par Microsoft juste ici.
Champs à renseigner pour déployer le custom template de domain (Microsoft)
Le déploiement complet de la machine virtuelle et du domain prend environ 20 minutes.
Le template modifie même le serveur DNS du réseau virtuel sur lequel il est déployé, la vie est belle !
Pensez également à créer dans votre AD un ou plusieurs utilisateurs de test pour la solution Azure Virtual Desktop.
Création d’une première OU pour les machines virtuelles AVD et d’une seconde OU pour les utilisateurs AVD.
Etape II : Installation d’AD Connect
Une fois déployé, nous allons mettre en place la liaison entre le serveur Active Directory et Azure AD. Pour cela, nous allons utiliser l’outil Azure AD Connect, téléchargeable directement ici. Idéalement installé sur une machine dédiée et jointe au domaine, vous pouvez l’installer directement sur votre contrôleur de domaine pour environnement de test.
Si vous souhaitez en savoir plus sur cet utilitaire et son installation, voici une vidéo proposée par l’Azure Academy :
Merci à Dean Cefola ????
Synchronisation des 2 OUs précédemment créés sur le serveur Active Directory.
L’installation est terminée et la synchronisation se lance à l’issue de cette dernière. J’en ai profité pour activer le SSO, fonctionnel au sein de AVD.
Une fois déployé, vous devriez retrouver votre groupe et vos utilisateurs AVD créés sur l’AD directement sur Azure AD :
La mention DIRECTORY SYNCED vous indique que ces utilisateurs ne sont pas à l’origine créé par Azure AD.
Etape III : Mise en place de l’Hybrid Join via Azure AD Connect
Cet étape demande à retourner sur la configuration d’Azure AD Connect. En effet, il faut activer cette option dans un second temps :
Lancez Azure AD Connect et cliquez sur le bouton Configurer
Cliquez sur Configurer les options du dispositif dans la liste des tâches supplémentaires
Passez en revue la page et cliquez sur Suivant
Saisissez les informations d’identification d’un compte d’administrateur global Azure AD, puis cliquez sur Suivant
Sélectionnez Configure Hybrid Azure AD join et cliquez sur Next
Sélectionnez la configuration du système d’exploitation de l’appareil (Windows 10 actuel ou systèmes d’exploitation plus anciens de « niveau inférieur ») qui sera prise en charge et cliquez sur Suivant
Cliquez sur le bouton Modifier et saisissez vos informations d’identification d’administrateur d’entreprise, puis cliquez sur Suivant
Cliquez sur Configurer pour commencer le processus
Lorsque le message Configuration terminée s’affiche, vous pouvez quitter l’assistant
Etape IV : Activation de l’enrôlement automatique vers Intune
Pour que l’inscription soit automatique sur Intune et qu’ils soient managés par ce dernier, il est nécessaire de faire quelques vérifications de configuration sur Azure AD. Rendez-vous donc sur la page d’Azure AD :
Certains tenants peuvent avoir à la fois Microsoft Intune et Microsoft Intune Enrollment. Assurez-vous que vos paramètres d’inscription automatique sont configurés sous Microsoft Intune (et non Microsoft Intune Enrollment).
Vérifier l’URL de découverte MDM pour l’inscription automatique et assurez-vous que l’inscription automatique est activée pour les utilisateurs désirés.
Etape V : Création d’une GPO d’auto-enrôlement
À partir de Windows 10, version 1607, une fois que l’entreprise a enregistré un appareil Windows à son Active Directory local, cet appareil sera automatiquement enregistré dans Azure AD.
Une fois la stratégie de groupe créée et activée sur l’Active Directory local, une tâche est créée en arrière-plan pour lancer l’inscription à l’aide de la configuration existante du service MDM à partir des informations Azure AD de l’utilisateur, et sans son interaction. Effectuez les étapes ci-dessous pour configurer une stratégie de groupe afin d’inscrire un groupe d’appareils dans Intune :
Naviguer vers le dossier C:\Program Files (x86)\Microsoft Group Policy\Windows 10 May 2020 Update (2004) et copiez le dossier PolicyDefinitions dans F:\SYSVOL\domain\Policies.
Redémarrez le contrôleur de domaine pour rendre la police disponible.
Créez un objet de stratégie de groupe (GPO) et activez la stratégie de groupe Configuration de l’ordinateur > Stratégies > Modèles d’administration > Composants Windows > MDM > Activer l’inscription automatique au MDM en utilisant les informations d’identification Azure AD par device.
Dans le cadre d’un environnement AVD partagé, il est nécessaire de sélectionner « Device Credential ».
Important
Sur tous les Windows 10, versions 2004, 20H2 et 21H1, il y a actuellement un problème qui fait que les actions à distance dans Microsoft Endpoint Manager, comme la synchronisation à distance, ne fonctionnent pas correctement. En conséquence, l’application de toute politique en attente affectée à des périphériques peut prendre jusqu’à 8 heures. Pour résoudre ce problème, veuillez effectuer les étapes suivantes sur vos machines virtuelles avant de les inscrire dans Microsoft Endpoint Manager en utilisant dans votre GPO la clé de registre suivante :
Une fois la GPO terminée, il ne vous reste qu’à rattacher celle-ci au groupe de machines virtuelles AVD.
Etape VI : Création de l’environnement AzureVirtual Desktop
Dans tous les cas, la création d’une environnement Azure Virtual Desktop nécessite une jointure à un domaine existant. Il peut être géré sur une machine virtuelle Windows Server, ou managé par Microsoft via le service AADDS. L’étape de création de AVD va s’occuper de générer les ressources Azure suivantes :
Host Pool AVD
Session hosts (machine virtuelles AVD)
Workspace
Application groupe
J’ai donc procédé à la création suivante pour Azure Virtual Desktop :
La première étape consiste à créer le host pool et à définir si ce dernier est partagé avec la règle de load balancing désirée.
Le second onglet se concentre sur les machines virtuelles créées et rattachées au Host Pool AVD.
La partie basse de l’onglet des machines virtuelles est dédiée à la jointure avec le domain existant et les comptes d’administration.
Une fois la création du workspace et les tags renseignés, comptez une dizaine de minutes pour retrouver l’environnement AVD entièrement déployé.
Une fois le déploiement AVD terminé, il vous faut retourner sur le service pour assigner à l’application group créé un groupe d’utilisateurs AVD :
Affecter ici le groupe d’utilisateurs créé dans Active Directory et synchronisé sur Azure AD via Azure AD Connect.
Etape VII : Affecter les VMs AVD au groupe de machines AD et forcer les GPO
Les machines virtuelles créées par le service Azure Virtual Desktop se trouvent dans la bonne OU mais doivent être encore affectées au groupe de machines AVD pour recevoir la GPO créée précédemment.
Un redémarrage des machines virtuelles AVD actualisera sur ces dernières les groupes et les GPO à appliquer. Vous pouvez vérifier que tout s’est bien passé avec un compte administrateur :
La commande GPRESULT /R /SCOPE COMPUTER vous permettra de vous assurer que la machine virtuelle applique ce qu’il faut.
La commande RSoP.msc vous permettra de vous assurer que la machine virtuelle applique ce qu’il faut.
Un tour dans le registre Windows vous montre également que la clef de registre a bien été correctement déployée grâce à la GPO.
Etape VIII : Synchronisation AD > Azure AD grâce à AD Connect
Azure AD Connect est configuré par défaut pour synchroniser les objets toutes les 30 minutes. Un tour dans le programme Synchronization Service Manager nous permet de voir la prochaine synchronisation :
Il est possible de forcer une synchronisation plus tôt, si cela est nécessaire.
Une fois la synchronisation effectuée vers Azure AD, vous devriez retrouver les machines virtuelles AVD dans la section Device votre Azure AD :
Il est possible que la colonne REGISTERED indique encore Pending pendant un certain temps.15 minutes plus tard et sans rien faire, elles retrouvent bien un statut REGISTERED.
Dans certains cas, le statut peut perdurer en Pending. Voici un bon article qui explique comment s’en sortir. Quelques minutes plus tard, les choses comment aussi à bouger pour la colonne MDM :
Cette copie d’écran démontre que la machine virtuelle vm-2 est routée vers System Center Configuration Manager, ce qui n’est évidemment pas le cas.
Note :
Il sera possible que les choses changent quand un utilisateur se connecte aux machines virtuelles AVD. La copie d’écran ci-dessous montre que le tir est rectifié, comme vous pouvez le voir dans la colonne MDM : Intune.
OUF ????
La seconde arrive !
All good.
Si cela ne se passe pas comment attendu dans votre environnement, vous pouvez consulter les messages d’erreur directement dans les logs d’Event Viewer ou consulter cette page de troubleshoot.
Pour vérifier cette erreur, recherchez l’ID d’événement 76 (message d’événement : Inscription automatique À la gestion des données de la gestion des données : Échec (code d’erreur Win32 inconnu : 0x8018002b)). Cet événement indique un échec d’inscription automatique.
Etape IX : Configuration des VMs AVD sur Intune :
Pour rappel, Intune est l’ancien nom pour Microsoft Endpoint Manager, vous pouvez vous connecter à l’admin center par ce lien. Si toutes les étapes précédentes se sont bien passées, vous devriez retrouver les machines virtuelles AVD dans la section Windows Devices :
Vous allez pouvoir configurer différents types de police. Vous devez créer une nouvelle stratégie de conformité et la cibler sur le groupe de périphériques contenant vos VM multisessions. Les configurations de conformité ciblées sur l’utilisateur ne sont pas prises en charge.
Polices de conformité et accès conditionnel
Vous pouvez sécuriser vos VM multisessions Windows 10 Enterprise en configurant des politiques de conformité et des politiques d’accès conditionnel dans le centre d’administration Endpoint Manager. Les politiques de conformité suivantes sont prises en charge sur les VM multisessions de Windows 10 Enterprise :
Version minimale du système d’exploitation
Version maximale du système d’exploitation
Constructions de système d’exploitation valides
Mots de passe simples
Type de mot de passe
Longueur minimale du mot de passe
Complexité du mot de passe
Expiration du mot de passe (jours)
Nombre de mots de passe précédents pour empêcher la réutilisation
Microsoft Defender Antimalware
Intelligence de sécurité Microsoft Defender Antimalware à jour
Pare-feu
Antivirus
Antispyware
Protection en temps réel
Version minimale de Microsoft Defender Antimalware
Score de risque Defender ATP
Toutes les autres politiques sont signalées comme non applicables.
Les politiques d’accès conditionnel prennent en charge les configurations basées sur les utilisateurs et les périphériques pour Windows 10 Enterprise multisession.
Déploiement d’applications
Toutes les applications Windows 10 peuvent être déployées sur Windows 10 Enterprise multisessions avec les restrictions suivantes :
Toutes les applications doivent être configurées pour s’installer dans le contexte système/appareil et être ciblées sur les appareils. Les applications Web sont toujours appliquées dans le contexte utilisateur par défaut, elles ne s’appliqueront donc pas aux VM multisessions
Toutes les applications doivent être configurées avec l’intention d’affectation Required ou Uninstall app. L’intention de déploiement Available apps n’est pas prise en charge sur les VM multisession
Si une application Win32 configurée pour être installée dans le contexte du système a des dépendances ou des relations de substitution avec toute application configurée pour être installée dans le contexte de l’utilisateur, l’application ne sera pas installée. Pour s’appliquer à une VM multisession Windows 10 Enterprise, créez une instance distincte de l’application du contexte système ou assurez-vous que toutes les dépendances de l’application sont configurées pour être installées dans le contexte système
Azure Virtual Desktop RemoteApp et l’attachement d’applications MSIX ne sont pas actuellement pris en charge par Microsoft Endpoint Manager
Déploiement de scripts
Les scripts configurés pour s’exécuter dans le contexte système sont pris en charge sur Windows 10 Enterprise multisessions. Cela peut être configuré sous Paramètres de script en définissant Exécuter ce script en utilisant les informations d’identification connectées sur Non
Mise à jour de Windows pour les entreprises
Les politiques de Windows Update for Business ne sont pas actuellement prises en charge pour Windows 10 Enterprise multisessions.
Actions à distance
Les actions à distance suivantes des périphériques de bureau Windows 10 ne sont pas prises en charge et seront grisées dans l’interface utilisateur et désactivées dans Graphique pour les VM multisessions Windows 10 Enterprise :
Réinitialisation du pilote automatique
Rotation des clés BitLocker
Nouveau départ
Verrouillage à distance
Réinitialisation du mot de passe
Effacer
Fin de vie
La suppression des VM d’Azure laissera des enregistrements de périphériques orphelins dans Microsoft Endpoint Manager. Ils seront automatiquement nettoyés selon les règles de nettoyage configurées pour le locataire.
Configurations supplémentaires qui ne sont pas prises en charge sur les VM multisessions de Windows 10 Enterprise.
L’inscription à Out of Box Experience (OOBE) n’est pas prise en charge pour Windows 10 Enterprise multisessions. Cette restriction signifie que :
Windows Autopilot et Commercial OOBE ne sont pas pris en charge.
La page d’état des inscriptions n’est pas prise en charge.
Conclusion
C’était un plaisir de tester cette nouvelle feature pour Azure Virtual Desktop. J’attends avec impatience que plus de polices soient disponibles pour les machines virtuelles en Windows 10 multisessions. Pensez à partager dans les commentaires vos autres sources d’apprentissage ! ????