Migrera Sophos-enheter mellan Central-tenants

Vid företagsförvärv, tenantkonsolidering eller felaktig kundtilldelning flyttas hanterade datorer med Device Migration från ett sändande till ett mottagande Sophos Fusion-konto. Det ordinarie arbetsflödet använder Endpoint API: Först skapas ett Receiving Job i målet och därefter startas tillhörande Sending Job i källkontot.

Omfattning: Den aktuella Sophos-hjälpen beskriver detta arbetsflöde för ”computers”. Vilka operativsystem, enhetstyper, agentversioner och installerade produkter som tillåts i den aktuella tenanten måste bekräftas före utrullningen med hjälp av den aktuella Endpoint API-dokumentationen, svaret från live-tenanten eller Sophos Support. De allmänna Endpoint API-typerna är ingen lista över enheter som är godkända för migrering. Access Points och Switches har egna arbetsflöden och ingår inte i detta API-arbetsflöde.

Vad Device Migration gör – och vad som förbereds separat

Device Migration ändrar datorns registrering och vilket konto som hanterar den. Efter en lyckad migrering hanteras den av det mottagande kontot. Om migreringen misslyckas fortsätter den enligt Sophos att hanteras av det sändande kontot.

Den offentliga dokumentationen beskriver inte någon överföring av policyer, grupper, globala undantag, webbplatslistor, licenser, produkttilldelningar, varningar, utredningar eller revisionshistorik. Av detta går det varken att dra slutsatsen att dessa data överförs automatiskt eller att de blir kvar i sin helhet i källkontot. Därför förbereds målkonfigurationen och det faktiska tillståndet verifieras efter migreringen.

Planera förutsättningar och pilot

Före det första jobbet inventeras källa och mål, och en liten, representativ pilot fastställs. Kritiska servrar, VDI-system, hemarbetsenheter, isolerade datorer och bärbara datorer som sällan är anslutna hanteras i separata vågor.

Följande förutsättningar måste vara uppfyllda:

• Den person som utför migreringen har Sophos-rollen Admin i båda kontona.
• Det finns separata API Credentials med autentiseringsrollen Service Principal Super Admin för båda kontona. En mänsklig Super Admin måste skapa och hantera dessa autentiseringsuppgifter; rollen Admin räcker inte för detta.
• Tenant-ID och regional API-värd är kända för båda kontona. De fastställs via den ordinarie Sophos API-konfigurationen och ska inte gissas.
• De Endpoint-ID:n som ska migreras kommer från det sändande kontot, och varje pilotenhets lämplighet har bekräftats i live-tenanten eller med Sophos Support.
• Lämpliga licenser, policyer, grupper, undantag och webbplatslistor har förberetts i målet.
• Målkontots Update Caches, Message Relays och proxyservrar kan nås från respektive enhets plats.
• Isoleringar, öppna varningar och pågående utredningar har dokumenterats; nödvändiga incident- och revisionsunderlag har sparats före bytet.

API Client Secret och den Bearer Token som hämtas med den hör till ett visst konto. Den Migration Job Access Token som senare returneras av Receiving Job är en annan hemlighet. Client Secrets, Bearer Tokens och Migration Job Access Tokens hör inte hemma i skärmbilder, ärenden, shellhistorik eller driftloggar.

Aktivera Device Migration i båda kontona

Logga först in på det sändande och sedan på det mottagande kontot och öppna Global Settings > Platform > Device Migration i respektive konto:

1. Aktivera Allow device migration.
2. Ange en så kort tidsgräns som möjligt men som räcker för piloten eller vågen.
3. Kontrollera på nytt före jobbstarten att fönstret är aktivt i båda kontona.

Om alternativet är låst kommer inställningen från partnerns eller Enterprise-administratörens globala inställningar. Man ska då inte kringgå detta för jobbet med provisoriska lösningar; ansvarig överordnad administration måste ge sitt godkännande.

Utför migreringen med Receiving Job och Sending Job

Den aktuella Sophos-hjälpen om Device Migration beskriver jobbens ordningsföljd. Endpoint Migration API Guide leder till den aktuella API-referensen. Exakt request-struktur, fältanvändning och aktuell mängdbegränsning kontrolleras i den aktuella Endpoint API-definitionen omedelbart före körningen. Historiska payloads eller gränser används inte utan kontroll. Följande ordningsföljd gäller:

1. Skapa Receiving Job i målet

Operationsmönstret är POST /endpoint/v1/migrations. Anropet använder den regionala API-värden och autentiseringsuppgifterna för det mottagande kontot. Det skickar Bearer Token i headern Authorization, det mottagande kontots ID i headern X-Tenant-ID och, om en JSON-body används, headern Content-Type: application/json.

Bodyn anger det sändande kontot och de bekräftade enheterna i pilotfasen eller vågen. I det historiska schemat heter dessa fält fromTenant och endpoints; före körningen måste det bekräftas om de fortfarande heter exakt så i live-schemat och om båda krävs i detta steg.

Spara följande från svaret:

• ID för Receiving Job;
• Migration Job Access Token för tillhörande Sending Job;
• ett utgångsdatum som returneras av det aktuella API:t, om ett sådant finns.

Jobb-ID:t får anges i ändringsloggen. Migration Job Access Token överlämnas endast via en skyddad hemlighetskanal till den person eller automation som skapar Sending Job och loggas inte permanent.

2. Starta Sending Job i källan

Autentisera därefter separat mot det sändande kontot. Operationsmönstret är PUT /endpoint/v1/migrations/{receivingMigrationJobId}. Sökvägen innehåller Receiving Job-ID:t. Anropet skickar Bearer Token i headern Authorization och det sändande kontots ID i headern X-Tenant-ID; om en JSON-body används tillkommer Content-Type: application/json.

Sending Job använder:

• den bekräftade listan med Endpoint-ID:n från källkontot;
• ID:t för det Receiving Job som skapades tidigare;
• dess Migration Job Access Token.

Det historiska schemat kallar body-fälten token och endpoints. Även dessa namn och den aktuella svarsstrukturen bekräftas i live-definitionen före körningen.

Migreringen startar med Sending Job. Innan det skickas kontrolleras tenantkontext, endpointlista och vågens omfattning på nytt. En token eller ett jobb-ID från en annan körning får inte återanvändas. Det Sending Job-ID som returneras av det aktuella API:t registreras tillsammans med Receiving Job-ID:t; ett utgångsdatum registreras endast om live-svaret innehåller ett sådant.

3. Övervaka status och kö

Förloppet hämtas med GET /endpoint/v1/migrations/{migrationJobId}/endpoints. Anropet görs för respektive relevant Sending Job och Receiving Job i kontexten för det sändande respektive mottagande kontot, varje gång med kontots egen Bearer Token och X-Tenant-ID. Om resultatet omfattar flera sidor hämtas alla sidor och stäms av mot varje begärt Endpoint-ID. Som tillval visar GET /endpoint/v1/settings/migration om migrering är aktiverad i respektive konto.

Den aktuella live-definitionen avgör statusvärdena och detaljfälten. Det historiska API-schemat använde pending, succeeded och failed; beroende på resultatet innehöll det bland annat ett nytt Endpoint-ID, tidsuppgifter och en felorsak. Dessa namn är vägledning, inte en utfästelse om det aktuella schemat. De värden och fält som faktiskt returneras ska sparas.

Datorer ligger kvar i migreringskön i upp till 14 dagar. En offline-dator måste ansluta inom denna period. Ett kortare konfigurerat migreringsfönster kan ytterligare begränsa den tillgängliga tiden. Om enheten förblir offline längre och migreringen löper ut misslyckas den, och en administratör måste manuellt lägga tillbaka enheten i migreringskön.

En väntande offline-enhet ska inte avinstalleras i förebyggande syfte eller ändras genom lokala Tenant-ID-justeringar. Återställ först anslutningen inom det giltiga fönstret. Om ett försök misslyckas fortsätter enheten att hanteras av källkontot.

Verifiera resultatet i källa, mål och på enheten

En API-status är inte i sig ett fullständigt godkännandebevis. Före nästa våg stäms resultaten av mellan båda kontona och datorn.

Officiella migreringsbevis

1. Händelsen Send endpoints to another tenant finns i det sändande kontots Audit Log.
2. Händelsen för en dator som har migrerats visar Device registered with new account . It’s now managed by that account.
3. För en dator där migreringen har misslyckats visas i stället Device failed to register with new account . It continues to be managed by this account.
4. Allow endpoints to migrate to this tenant finns i det mottagande kontots Audit Log.
5. Under My Environment > Computers & Servers i målet är datorn registrerad, tilldelad en användare och aktuell.
6. Alla begärda Endpoint-ID:n har kopplats till API-resultaten; om ett nytt Endpoint-ID returneras dokumenteras även detta.

Driftsgodkännande

Kontrollera därefter att datorn i målet faktiskt skyddas och drivs enligt plan:

• Enhetstyp, licens och installerade produkter motsvarar den avsedda målkonfigurationen.
• Målgrupp, effektiva policyer, globala undantag och webbplatslistor är korrekta.
• Agentuppdateringar, ett godkänt skyddstest och de avsedda Response-funktionerna fungerar.
• Beteendet för Update Cache, Message Relay och proxy motsvarar målkontot.
• Den gamla posten i källkontot förväxlas inte med den aktiva målregistreringen.

Nästa lilla våg påbörjas först när API-resultat, Audit- och Endpoint-händelser samt driftsgodkännandet stämmer överens.

Avgränsa fel på ett säkert sätt

Jobbet förblir öppet

Om det aktuella API:t visar en status som ännu inte är slutförd kontrollerar du först om datorn är online, kan nå Sophos och om båda migreringsfönstren fortfarande är giltiga. Så länge migrering är aktiverad får en offline-enhet ligga kvar i kön. Efter ett misslyckande eller när tiden har löpt ut läggs endpointen manuellt tillbaka i kön med ett nytt, giltigt migreringsfönster.

Migreringen misslyckas

Först jämförs en felorsak som returneras av det aktuella API:t med datorns händelse och Audit Logs för båda kontona. Kontrollera därefter tenantkontext, Endpoint-ID, jobbtilldelning, aktuellt migreringsgodkännande och den lämplighet som bekräftats för den aktuella datorn. Vid ett oklart fel sparas båda jobb-ID:na, Endpoint-ID, tidsstämpel, API-korrelationsdata och ett SDU-arkiv och överlämnas till Sophos Support – utan hemligheter eller tokens.

Vid ett misslyckande har hanteringen inte överförts; enheten blir kvar i källkontot. För en redan lyckad migrering finns det inget belagt automatiskt Cancel-, Undo- eller Rollback-arbetsflöde i det dokumenterade API:t. En flytt tillbaka planeras som en ny, separat bekräftad migrering eller omregistrering.

API-anropet avvisas

Kontrollera att Bearer Token, X-Tenant-ID och regional API-värd hör till samma konto och att API Credentials där har rollen Service Principal Super Admin. Bearer Token får inte förväxlas med den Migration Job Access Token som hör till Receiving Job. Dessutom måste Allow device migration fortfarande vara aktivt i båda kontona.

Windows-alternativ: registrera om med --registeronly

--registeronly ingår inte i arbetsflödet med Receiving Job och Sending Job och ersätter inte API-migreringen. Växeln används för separat Windows-omregistrering av en redan skyddad enhet när Device Migration inte är lämplig eller tillgänglig för det aktuella fallet och denna metod har bekräftats med hjälp av den aktuella dokumentationen för Windows-installationsprogrammet eller av Sophos Support.

Följande separata förutsättningar gäller:

• Det finns en fungerande Sophos Protection-installation på Windows-enheten.
• Ett aktuellt, oförändrat installationsprogram, SophosSetup.exe, kommer från målkontot under My Environment > Installers.
• Enligt det dokumenterade kravet för --registeronly är Tamper Protection avstängt på enheten.
• Kommandot körs lokalt eller via programvarudistribution med administratörsbehörighet; enheten måste kunna nå Sophos.

Öppna Kommandotolken eller PowerShell som administratör på Windows-enheten och starta målets installationsprogram:

.\SophosSetup.exe --registeronly

Filnamnet och sökvägen kan skilja sig åt. Ett paket från källkontot skulle inte uppnå målet. Efter kommandot gäller samma operativa målverifieringar som ovan; en avslutad installationsprocess är inte i sig ett bevis på att åtgärden lyckades.

Windows-växeln får inte överföras till macOS eller Linux. För omregistrering på andra plattformar används det aktuella plattformsarbetsflöde som Sophos dokumenterar eller Sophos Support. Om den befintliga Windows-agenten är skadad eller redan har tagits bort går det inte att använda --registeronly. Följ då det reparations- eller avinstallationsförfarande som stöds och installera därefter på nytt med målets installationsprogram. För Windows beskriver Avinstallera Sophos Endpoint med manipuleringsskydd aktiverat återställningsförfarandet som stöds.

Registerändringar, Safe Mode-knep, manipulering av MCS-filer och manuellt angivna Tenant-ID:n är inte metoder som stöds för migrering eller återgång till källkontot. Om --registeronly misslyckas kontrolleras installationsprogrammets ursprung och aktualitet, administratörsbehörighet, internet-/proxyåtkomst och agentens tillstånd. Installationsloggar och vid behov ett SDU-arkiv sparas innan Sophos Support kontaktas.

Slutför vågen och spara underlag

Efter varje våg jämförs mållistan med resultaten. Följande dokumenteras:

• Receiving Job-ID och Sending Job-ID samt den jobbtilldelning som visas i API-resultatet;
• gammalt och, om det returneras, nytt Endpoint-ID;
• de status-, tids- och feluppgifter som returneras av det aktuella API:t;
• godkänt migreringsfönster, vågens omfattning och ansvarig person;
• tekniskt godkännande och driftsgodkännande;
• ägare till de API Credentials som har använts, men inga Secrets, Bearer Tokens eller Migration Job Access Tokens.

Efter den sista vågen stängs Allow device migration eller de tidsbegränsade godkännandena, tillfälliga undantag rensas bort och alla skyddskontroller återställs till avsett tillstånd. Gamla källobjekt ska inte tas bort generellt: Kontrollera först API-resultat, ägarstatus och lagringskrav. Incident- och revisionsunderlag förblir separat arkiverade enligt interna krav.

Vanliga frågor