L’un des défis auxquels je suis confronté est de savoir comment bien servir les professionnels TI francophones. Heureusement pour nous, nous avons une grande communauté de MVP et d’autres personnes toujours disposées à aider. Michael Niehaus est l’une de ces personnes qui s’est portée volontaire pour fournir une série d’articles liés à Microsoft 365 traduits en français. Ceci est le premier d’une série de publications sur Windows Autopilot provenant de lui et qui sont également publiées sur son propre blog – Out of Office Hours.
Supposons que vous enregistrez une nouvelle machine virtuelle ou un périphérique existant que vous souhaitez utiliser pour valider Windows Autopilot. (Les nouveaux périphériques doivent être enregistrés par le fabricant OEM, le distributeur ou le revendeur auprès duquel vous achetez le périphérique – plus d’informations à ce sujet ultérieurement.) Dans ce scénario, vous devez débuter avec le hachage matériel et le numéro de série du périphérique. Il existe différentes manières de rassembler cette information, mais en supposant qu’elle n’a jamais été inscrite dans Intune ou ConfigMgr, la méthode la plus simple consiste à exécuter un script PowerShell pour collecter les éléments nécessaires. Une fois ces informations rassemblées dans un fichier CSV, vous pouvez les importer dans Windows Autopilot via Intune ou Microsoft Store for Business (bien que je recommande fortement d’utiliser Intune). Cette procédure est décrite dans la documentation relative à Windows Autopilot.
Mais nous voulons nous concentrer sur ce qui se passe en arrière-plan. Lorsqu’Intune tente d’ajouter le périphérique au service de déploiement de Windows Autopilot. Toute une série de vérifications est effectuée et, en cas d’erreur, une erreur est renvoyée à Intune et rapportée à l’administrateur. Les erreurs possibles incluent :
| Erreur | Description | Notes |
| 801 | InvalidZtdRequestBody. The request was malformed or it didn’t include a tenantId. | Vous ne devriezs jamais voir ça. Si cela se produit, cela indique probablement un problème avec les services. |
| 802 | InvalidZtdHardwareHash. The hardware hash provided is invalid. | Le hachage matériel doit comporter exactement 4 096 caractères (4 Ko). Assurez-vous d’utiliser la valeur exactement telle qu’elle est renvoyée par le script PowerShell. |
| 803 | MissingZtdSerialNumberAndProductKey. The serial number and Windows Product ID values were null or invalid. | Vous ne devriez jamais voir cela depuis Intune ou Microsoft Store for Business, car vous devez utiliser le hachage matériel pour enregistrer le périphérique. (Vous devez toujours spécifier le numéro de série afin de pouvoir facilement retrouver le périphérique.) |
| 806 | ZtdDeviceAlreadyAssigned. The device is already registered to the specified tenant. | Celui-ci est de votre faute: n’essayez pas d’enregistrer le même appareil deux fois, il échouera. |
| 807 | ZtdDeviceIsNotRegistered. The device being deleted or configured does not exist in the service. | En règle générale, cela ne se produit que si Intune et le service de déploiement Windows Autopilot ne sont pas synchronisés (par exemple, vous avez supprimé un périphérique de Microsoft Store for Business, puis essayé de le supprimer via Intune avant qu’Intune ne l’ait remarqué). |
| 808 | ZtdDeviceAssignedToOtherTenant. The device is already registered to a different tenant. | Nous ne vous dirons pas sur quel tenant l’appareil est enregistré – espérons que vous pourrez le découvrir vous-même. Sinon, ouvrez un dossier de support via le nœud Aide et support Intune. |
| 809 | ZtdProfileIsNotRegistered. The profile being assigned to the device does not exist. | Il s’agit d’un autre problème «désynchronisé» (par exemple, un profil Windows Autopilot a été supprimé via Microsoft Store for Business, mais Intune a ensuite tenté de l’appliquer à un appareil avant qu’il ne remarque sa disparition). |
| 810 | ZtdProfileAssignedToOtherTenant. The profile being assigned belongs to a different tenant. | Vous ne devriez jamais le voir. Il n’ya aucun moyen de faire en sorte que Intune ou Microsoft Store for Business attribue un profil Windows Autopilot à un périphérique d’un autre tenant. |
| 811 | ZtdDeviceRegisteredByOtherTenant. The device being deleted exists in a different tenant. | Une autre que vous ne devriez jamais voir – cela ne se produirait que si vous essayez de supprimer un périphérique qui n’existe pas dans ce tenant mais dans un autre. (Un périphérique se voit attribuer un identifiant unique lorsqu’il est enregistré, vous aurez donc besoin de cet identifiant unique pour essayer de le faire.) |
| 812 | ZtdDeviceNotFound. The device being registered could not be found. | Cela ne peut pas se produire via Intune ou Microsoft Store for Business. Cela se produit lors de l’enregistrement d’un périphérique à l’aide de l’ID de produit Windows, du fabricant ou du modèle. (Plus sur cela plus tard.) |
| 813 | ZtdDeviceIsNotUnique. The MSA service could not uniquely identify the device given the hardware hash. | Ceci est très peu probable. Si vous voyez cela, ouvrez un dossier de support via le nœud Aide et support Intune. |
| 640 | StorageError. An error occurred while adding te device to the service or to Azure AD. | Il s’agit généralement d’une erreur temporaire. Essayez d’importer à nouveau le périphérique pour voir s’il se reproduit. (Si le périphérique a été ajouté, le message d’erreur 806 risque de s’afficher. Cela vous convient.) Si cela se produit fréquemment, ouvrez un dossier d’assistance via le nœud Aide et support Intune. |
Quelques notes rapides sur ces points:
- Les erreurs 806 et 810 devraient être les erreurs les plus courantes observées.
- Vous pouvez provoquer davantage d’erreurs si vous effectuez des tâches via Intune et Microsoft Store for Business.
- Portez une attention particulière aux différences entre l’erreur 806 (le périphérique est déjà dans votre client) et l’erreur 810 (le périphérique est déjà dans un autre client).
- Les hachages matériels changent chaque fois qu’ils sont générés, car ils contiennent des dates / horodatages, des informations sur la version du système d’exploitation et d’autres informations susceptibles de changer. C’est bien, car l’algorithme de correspondance tiendra compte de cela. Seules des modifications majeures du matériel (une nouvelle carte mère, par exemple) permettraient de détecter un périphérique existant comme étant nouveau.
- Si vous essayez de supprimer un périphérique et que les délais d’attente ou les délais sont longs, ouvrez un dossier de support via le nœud Aide et support Intune.
- Si vous ajoutez ou supprimez un périphérique Windows Autopilot via Intune et que vous ne le voyez pas dans la liste, vous pouvez lancer une «Sync» à partir du nœud périphérique Windows Autopilot. (Intune se synchronise automatiquement toutes les 12 heures.)
En supposant que le périphérique ait été enregistré avec succès, il se passe plusieurs choses :
- Le périphérique est ajouté au service de déploiement Windows Autopilot.
- Un objet de périphérique Azure AD est créé pour le périphérique, nommé en fonction du numéro de série du périphérique. Si par hasard il existait un objet pour le périphérique dans Azure AD, ce périphérique existant sera utilisé. Dans les deux cas, l’objet périphérique est «marqué» pour indiquer qu’il est associé au périphérique Windows Autopilot.
Voici un exemple de périphérique que je viens d’inscrire:
Vous pouvez voir le numéro de série (004524654257), le fabricant et le modèle sur la première ligne, ainsi que le nom du périphérique Azure AD associé (nommé avec le numéro de série) en bas à droite). Si vous cliquez sur le lien de périphérique associé Azure AD (texte en bleu), vous pouvez voir l’objet de périphérique réel Azure AD:
Comme vous pouvez le constater, ce périphérique Azure AD est désactivé, ce qui indique que le périphérique n’a pas encore été rejoint. Mais il existe quelques détails supplémentaires utiles pour voir ce qui ne figure pas dans le portail de gestion des appareils. Pour voir tout cela, nous devons utiliser l’explorateur graphique pour voir les détails. Voici les résultats de cette requête:
https://graph.microsoft.com/v1.0/devices?$filter=displayName eq ‘004524654257’
Ainsi, vous pouvez voir que le nom d’affichage est actuellement le numéro de série de l’appareil. Mais il existe également une autre valeur importante: la valeur physicalIds contient une valeur [ZTDID] qui marque ce périphérique en tant que périphérique Windows Autopilot – ce même identifiant existe dans le service de déploiement Windows Autopilot. (N’oubliez pas où cette valeur a été utilisée? Consultez ce blog pour plus de détails sur l’utilisation de cette valeur dans les requêtes dynamiques. Pendant que vous y êtes, assurez-vous de lire comment attribuer des profils aux périphériques.)
Voyons un peu plus loin:
- Si vous attribuez et déployez un profil Windows Autopilot user-driven Azure AD Join à ce périphérique, l’objet Azure AD existant sera activé et un objet de périphérique Intune sera créé.
- Si vous attribuez et déployez un profil Windows Autopilot user-driven Azure AD Join à ce périphérique, l’objet Azure AD existant sera activé et un objet de périphérique Intune sera créé. Plus tard, une fois le périphérique connecté à Active Directory, un deuxième objet sera synchronisé d’AD vers Azure AD pour le périphérique. Si vous utilisez White Glove, le périphérique est initialement lié à Azure AD, puis ultérieurement, dans le processus, supprimé d’Azure AD et associé à Active Directory.
- Si vous attribuez et déployez un profil Windows Autopilot à ce périphérique, l’objet Azure AD existant sera activé et un objet de périphérique Intune sera créé.
Souvenez-vous de l’état de ces objets de périphérique Azure AD lors de leur création initiale? Ils sont désactivés. Supposons que vous êtes un «mania de la propreté» et que vous supprimez ces objets de périphérique Azure AD. Qu’est-ce qui va arriver? Cela dépend du scénario:
- Avec les déploiements Windows Autopilot user-driven sans utiliser White Glove, un nouveau périphérique Azure AD sera créé, mais il ne sera pas avec le tag ZTDID.
- Avec les déploiements Windows Autopilot Self-deploying mode, ils échoueront, car un périphérique Azure AD associé est introuvable. (Il s’agit d’un mécanisme de sécurité permettant de s’assurer qu’aucun périphérique «imposteur» ne tente de se connecter à Azure AD sans informations d’identification.) L’échec indiquera une non-concordance ZTDID.
- Avec Windows Autopilot white glove, ils échoueront, car un périphérique Azure AD associé est introuvable. (En coulisse, les déploiements avec gants blancs utilisent le même processus en mode de déploiement automatique, de sorte qu’ils appliquent les mêmes mécanismes de sécurité.)
Par conséquent, ne supprimez pas l’objet de périphérique Azure AD pour un périphérique Windows Autopilot enregistré. Vous le regretterez plus tard.
De plus, notez que vous allez généralement vous retrouver avec deux objets de périphérique dans Azure AD pour les périphériques joints Azure AD hybride (un créé lorsque vous enregistrez le périphérique avec Windows Autopilot, un autre synchronisé d’AD avec Azure AD via AADConnect). Ceci est actuellement inévitable (ne supprimez pas non plus). Nous cherchons des moyens de simplifier cela à l’avenir.
