Migrer des appareils Sophos entre des tenants Central

En cas d’acquisition d’une entreprise, de consolidation de tenants ou d’affectation incorrecte à un client, les ordinateurs gérés sont déplacés d’un compte Sophos Fusion émetteur vers un compte destinataire à l’aide de Device Migration. La procédure habituelle utilise l’Endpoint API : un Receiving Job est d’abord créé dans la cible, puis le Sending Job associé est lancé dans le compte source.

Périmètre : l’aide Sophos actuelle décrit cette procédure pour les « computers ». Les systèmes d’exploitation, types d’appareils, versions d’agent et produits installés autorisés dans le tenant concerné doivent être confirmés avant le déploiement à l’aide de la documentation actuelle de l’Endpoint API, de la réponse du tenant en production ou de Sophos Support. Les types généraux de l’Endpoint API ne constituent pas une liste d’autorisation pour la migration. Les Access Points et Switches suivent leurs propres procédures et ne font pas partie de ce workflow API.

Ce que fait Device Migration, et ce qui doit être préparé séparément

Device Migration modifie l’enregistrement et le compte qui gère l’ordinateur. Après une migration réussie, celui-ci est géré par le compte destinataire. Si la migration échoue, Sophos indique qu’il reste géré par le compte émetteur.

La documentation publique ne décrit pas le transfert des Policies, groupes, exclusions globales, listes de sites web, licences, affectations de produits, Alerts, investigations ou de l’historique d’audit. Il est donc impossible d’en conclure que ces données sont transférées automatiquement ou qu’elles restent intégralement dans le compte source. Il faut par conséquent préparer la configuration cible et vérifier l’état effectif après la migration.

Planifier les prérequis et le pilote

Avant le premier Job, la source et la cible sont inventoriées et un petit pilote représentatif est défini. Les serveurs critiques, systèmes VDI, appareils en télétravail, ordinateurs isolés et ordinateurs portables rarement connectés sont répartis dans des vagues distinctes.

Les conditions suivantes doivent être remplies :

• La personne qui effectue l’opération possède le rôle Sophos Admin dans les deux comptes.
• Des API Credentials distincts auxquels le rôle Service Principal Super Admin est attribué existent pour les deux comptes. Un Super Admin humain doit créer et gérer ces Credentials ; le rôle Admin seul ne suffit pas.
• Le Tenant-ID et l’hôte API régional sont connus pour les deux comptes. Ils sont déterminés à l’aide de la procédure normale de configuration de l’API Sophos et ne doivent pas être devinés.
• Les Endpoint-IDs à migrer proviennent du compte émetteur, et l’éligibilité de chaque appareil pilote est confirmée dans le tenant en production ou auprès de Sophos Support.
• Les licences, Policies, groupes, exclusions et listes de sites web appropriés sont préparés dans la cible.
• Les Update Caches, Message Relays et Proxies du compte cible sont accessibles depuis l’emplacement de chaque appareil.
• Les isolements, Alerts ouverts et investigations en cours sont documentés ; les preuves d’incident et d’audit requises sont sauvegardées avant le changement.

L’API Client Secret et le Bearer Token obtenu à partir de celui-ci appartiennent chacun à un compte. Le Migration Job Access Token émis ultérieurement par le Receiving Job est un secret différent. Les Client Secrets, Bearer Tokens et Migration Job Access Tokens ne doivent figurer ni dans les captures d’écran, ni dans les tickets, ni dans l’historique du shell, ni dans les journaux d’exploitation.

Autoriser Device Migration dans les deux comptes

Connectez-vous d’abord au compte émetteur, puis au compte destinataire, et ouvrez dans chacun Global Settings > Platform > Device Migration :

1. Activez Allow device migration.
2. Définissez une durée aussi courte que possible, mais suffisante pour le pilote ou la vague.
3. Juste avant de lancer le Job, vérifiez à nouveau que la fenêtre est active dans les deux comptes.

Si l’option est verrouillée, le paramètre provient des paramètres globaux du partenaire ou de l’administrateur Enterprise. Il ne faut pas contourner cette restriction ; l’administration supérieure compétente doit accorder l’autorisation.

Effectuer la migration avec un Receiving Job et un Sending Job

L’aide Sophos actuelle sur Device Migration décrit l’ordre des Jobs. L’Endpoint Migration API Guide renvoie à la référence actuelle de l’API. La structure exacte de la Request, les champs à renseigner et la limite quantitative actuelle sont vérifiés dans la définition actuelle de l’Endpoint API juste avant l’exécution. Les anciens Payloads ou anciennes limites ne doivent pas être repris sans vérification. Procédez dans l’ordre suivant :

1. Créer le Receiving Job dans la cible

Le modèle d’opération est POST /endpoint/v1/migrations. L’appel utilise l’hôte API régional et les Credentials du compte destinataire. Il transmet le Bearer Token dans l’en-tête Authorization, l’ID du compte destinataire dans l’en-tête X-Tenant-ID et, en présence d’un Body JSON, l’en-tête Content-Type: application/json.

Le Body indique le compte émetteur et les appareils confirmés pour le pilote ou la vague. Dans l’ancien schéma, ces champs s’appelaient fromTenant et endpoints ; il faut vérifier avant l’exécution si le schéma en production utilise toujours exactement ces noms et exige bien les deux champs à cette étape.

Conservez les éléments suivants de la réponse :

• l’ID du Receiving Job ;
• le Migration Job Access Token destiné au Sending Job associé ;
• une date d’expiration émise par l’API actuelle, le cas échéant.

L’ID du Job peut être inscrit dans le journal des modifications. Le Migration Job Access Token est transmis uniquement par un canal sécurisé dédié aux secrets à la personne ou à l’automatisation qui crée le Sending Job, et il n’est pas consigné durablement.

2. Lancer le Sending Job dans la source

Authentifiez-vous ensuite séparément dans le compte émetteur. Le modèle d’opération est PUT /endpoint/v1/migrations/{receivingMigrationJobId}. Le chemin contient l’ID du Receiving Job. L’appel transmet le Bearer Token dans l’en-tête Authorization et l’ID du compte émetteur dans l’en-tête X-Tenant-ID ; en présence d’un Body JSON, ajoutez Content-Type: application/json.

Le Sending Job utilise :

• la liste confirmée des Endpoint-IDs du compte source ;
• l’ID du Receiving Job créé précédemment ;
• son Migration Job Access Token.

L’ancien schéma nomme les champs du Body token et endpoints. Ces noms ainsi que la structure actuelle de la réponse doivent également être confirmés dans la définition en production avant l’exécution.

Le Sending Job lance la migration. Avant l’envoi, vérifiez à nouveau le contexte du tenant, la liste des Endpoints et le périmètre de la vague. Un Token ou un ID de Job provenant d’une autre exécution ne doit pas être réutilisé. L’ID du Sending Job renvoyé par l’API actuelle est consigné avec l’ID du Receiving Job ; une date d’expiration n’est enregistrée que si la réponse en production en fournit une.

3. Surveiller l’état et la file d’attente

La progression est consultée avec GET /endpoint/v1/migrations/{migrationJobId}/endpoints. L’appel est effectué pour chaque Sending Job et Receiving Job concerné dans le contexte du compte émetteur ou destinataire respectif, avec son Bearer Token et son X-Tenant-ID. Si les résultats comprennent plusieurs pages, toutes sont consultées et rapprochées de chaque Endpoint-ID demandé. Facultativement, GET /endpoint/v1/settings/migration indique si la migration est autorisée dans le compte concerné.

La définition en production actuelle détermine les valeurs d’état et les champs détaillés. L’ancien schéma API utilisait pending, succeeded et failed ; selon le résultat, il fournissait notamment un nouvel Endpoint-ID, des informations temporelles et le motif de l’échec. Ces noms sont donnés à titre indicatif et ne garantissent pas le schéma actuel. Enregistrez les valeurs et champs réellement émis.

Les ordinateurs restent jusqu’à 14 jours dans la file d’attente de migration. Un ordinateur hors ligne doit se connecter pendant cette période. Une fenêtre de migration configurée pour une durée plus courte peut réduire davantage le délai disponible. Si l’appareil reste hors ligne plus longtemps et que la migration expire, celle-ci échoue et un administrateur doit manuellement remettre l’appareil en file d’attente pour la migration.

Un appareil hors ligne en attente ne doit pas être désinstallé par précaution ni faire l’objet de modifications locales du Tenant-ID. Rétablissez d’abord la connexion pendant la fenêtre de validité. En cas d’échec de la tentative, l’appareil reste géré par le compte source.

Vérifier la réussite dans la source, la cible et sur l’appareil

Un état API ne constitue pas à lui seul une preuve de recette complète. Avant la vague suivante, rapprochez les résultats dans les deux comptes et sur l’ordinateur.

Preuves officielles de migration

1. L’événement Send endpoints to another tenant est présent dans l’Audit Log du compte émetteur.
2. L’événement de l’ordinateur migré avec succès contient Device registered with new account . It’s now managed by that account.
3. Pour un ordinateur dont la migration a échoué, il contient à la place Device failed to register with new account . It continues to be managed by this account.
4. L’événement Allow endpoints to migrate to this tenant est présent dans l’Audit Log du compte destinataire.
5. Sous My Environment > Computers & Servers dans la cible, l’ordinateur est enregistré, affecté à un utilisateur et à jour.
6. Tous les Endpoint-IDs demandés correspondent sans lacune aux résultats de l’API ; si un nouvel Endpoint-ID est fourni, il est également documenté.

Recette opérationnelle

Vérifiez ensuite que l’ordinateur bénéficie effectivement de la protection et du fonctionnement prévus dans la cible :

• Le type d’appareil, la licence et les produits installés correspondent à la configuration cible prévue.
• Le groupe cible, les Policies effectives, les exclusions globales et les listes de sites web sont corrects.
• Les mises à jour de l’Agent, un test de protection approuvé et les fonctions Response prévues fonctionnent.
• Le comportement de l’Update Cache, du Message Relay et du Proxy correspond au compte cible.
• L’ancien enregistrement du compte source n’est pas confondu avec l’enregistrement cible actif.

La petite vague suivante ne commence que lorsque le résultat de l’API, les événements d’audit et d’Endpoint ainsi que la recette opérationnelle concordent.

Cerner les erreurs en toute sécurité

Le Job reste ouvert

Si l’API actuelle indique un état encore inachevé, vérifiez d’abord que l’ordinateur est en ligne, qu’il peut joindre Sophos et que les deux fenêtres de migration sont toujours valides. Tant que la migration est autorisée, un appareil hors ligne peut rester dans la file d’attente. Après un échec ou une expiration, l’Endpoint est manuellement remis en file d’attente avec une nouvelle fenêtre de migration valide.

La migration échoue

Commencez par comparer tout motif d’échec fourni par l’API actuelle à l’événement de l’ordinateur et aux Audit Logs des deux comptes. Vérifiez ensuite le contexte du tenant, l’Endpoint-ID, l’association au Job, l’autorisation de migration actuelle et l’éligibilité confirmée de cet ordinateur. Si l’erreur reste inexpliquée, sauvegardez les deux IDs de Job, l’Endpoint-ID, l’horodatage, les données de corrélation API et une archive SDU, puis transmettez-les à Sophos Support, sans Secrets ni Tokens.

En cas d’échec, la gestion n’a pas été transférée correctement ; l’appareil reste dans le compte source. Pour une migration déjà réussie, l’API documentée ne prévoit aucune procédure automatique Cancel, Undo ou Rollback. Un retour est planifié comme une nouvelle migration ou un nouveau réenregistrement confirmé séparément.

L’appel API est refusé

Vérifiez que le Bearer Token, le X-Tenant-ID et l’hôte API régional appartiennent au même compte et que les API Credentials de ce compte possèdent le rôle Service Principal Super Admin. Le Bearer Token ne doit pas être confondu avec le Migration Job Access Token du Receiving Job. Allow device migration doit également être toujours actif dans les deux comptes.

Alternative Windows : réenregistrer avec --registeronly

--registeronly ne fait pas partie de la procédure avec un Receiving Job et un Sending Job et ne remplace pas la migration par API. Cette option sert à réenregistrer séparément un appareil Windows déjà protégé lorsque Device Migration n’est pas adaptée ou disponible pour le cas concerné, et que cette méthode a été confirmée à l’aide de la documentation actuelle du programme d’installation Windows ou par Sophos Support.

Elle est soumise à ses propres conditions :

• Une installation Sophos Protection fonctionnelle est présente sur l’appareil Windows.
• Un programme d’installation SophosSetup.exe actuel et inchangé provient du compte cible, sous My Environment > Installers.
• Conformément au prérequis documenté pour --registeronly, Tamper Protection est désactivé sur l’appareil.
• La commande est exécutée localement ou via une distribution logicielle avec des droits d’administrateur ; l’appareil doit pouvoir joindre Sophos.

Sur l’appareil Windows, ouvrez une invite de commandes ou PowerShell en tant qu’administrateur, puis lancez le programme d’installation cible :

.\SophosSetup.exe --registeronly

Le nom du fichier et le chemin peuvent différer. Un package provenant du compte source ne permettrait pas d’atteindre la cible. Après la commande, effectuez les mêmes vérifications opérationnelles de la cible que ci-dessus ; la simple fin du processus d’installation ne prouve pas sa réussite.

L’option Windows ne doit pas être transposée à macOS ou Linux. Pour un réenregistrement sur d’autres plateformes, utilisez la procédure actuelle documentée par Sophos pour la plateforme concernée ou faites appel à Sophos Support. Si l’Agent Windows existant est endommagé ou a déjà été supprimé, --registeronly ne peut pas être utilisé. Suivez alors la procédure de réparation ou de désinstallation prise en charge, puis effectuez une nouvelle installation avec le programme d’installation cible. Pour Windows, Désinstaller Sophos Endpoint avec la protection antialtération activée décrit la procédure de récupération prise en charge.

Les modifications du registre, les astuces en mode sans échec, les manipulations des fichiers MCS et les Tenant-IDs définis manuellement ne sont pas des méthodes prises en charge pour une migration ou un retour au compte source. Si --registeronly échoue, vérifiez l’origine et l’actualité du programme d’installation, les droits d’administrateur, l’accès Internet/Proxy et l’état de l’Agent. Sauvegardez les journaux d’installation et, si nécessaire, une archive SDU avant de faire appel à Sophos Support.

Terminer la vague et sauvegarder les preuves

Après chaque vague, rapprochez la liste prévue et les résultats. Documentez :

• les IDs du Receiving Job et du Sending Job ainsi que l’association aux Jobs indiquée dans le résultat de l’API ;
• l’ancien Endpoint-ID et, s’il est fourni, le nouveau ;
• les informations d’état, de temps et d’erreur émises par l’API actuelle ;
• la fenêtre de migration autorisée, le périmètre de la vague et la personne responsable ;
• la recette technique et opérationnelle ;
• le propriétaire des API Credentials utilisés, mais aucun Secret, Bearer Token ou Migration Job Access Token.

Après la dernière vague, fermez Allow device migration ou les autorisations limitées dans le temps, supprimez les exclusions temporaires et rétablissez tous les contrôles de protection dans l’état prévu. Ne supprimez pas systématiquement les anciens objets source : vérifiez d’abord le résultat de l’API, l’état de propriété et les exigences de conservation. Les preuves d’incident et d’audit restent archivées séparément conformément aux règles internes.

Questions fréquentes