Användarmappning och huvudmigrering user-mapping-and-principal-migration
Introduktion introduction
Som en del av övergångsresan till Adobe Experience Manager (AEM) as a Cloud Service måste användare och grupper (eller Principal) migreras från befintliga AEM till AEM as a Cloud Service. Den här åtgärden utförs av verktyget Innehållsöverföring.
En stor förändring i AEM as a Cloud Service är den helintegrerade användningen av Adobe ID:n för att komma åt författarnivån. Den här processen kräver att Adobe Admin Console används för att hantera användare och användargrupper. Användarprofilinformationen är centraliserad i Adobe Identity Management System (IMS) som gör att du kan logga in på alla molnprogram i Adobe. Mer information finns i Identity Management. På grund av den här ändringen måste befintliga användare mappas till sina IMS-ID:n så att de kan komma åt AEMaaCS med sina IMS-profiler. Eftersom grupper i traditionella AEM i grunden skiljer sig från grupper i IMS, mappas inte grupper, men de två uppsättningarna grupper måste förenas när migreringen är klar.
Information om huvudmigrering principal-migration-detail
Verktyget Innehållsöverföring och Cloud Acceleration Manager migrerar alla objekt som är kopplade till det innehåll som migreras till molnsystemet. Verktyget Innehållsöverföring gör detta genom att kopiera alla objekt från AEM under extraheringsprocessen. CAM Ingestion väljer och migrerar sedan endast de objekt som är associerade med innehållet som ska importeras. Om ett huvudnamn finns i en ACL- eller CUG-princip för migrerat innehåll, migreras det huvudkontot och alla grupper det finns i och deras överordnade (överordnade) grupper migreras. Om ett huvudnamn i innehållet är en grupp migreras även alla dess underordnade (underordnade) grupper och användare.
Information om användarmappning user-mapping-detail
AEM användare kan mappas till motsvarande Adobe IMS-användare med samma e-postadress. Denna mappning kan göras automatiskt i CTT (under extraheringssteget) och oavsett om den är klar eller inte kan styras med en växlingsknapp innan extraheringen startas. Växlingens standardinställning kan åsidosättas av användaren när extraheringen startas.
- Om källsystemet är en författarinstans är standardalternativet att utföra mappningen på, eftersom det är den rekommenderade processen.
- Om källsystemet är en publiceringsinstans är standardvalet för mappning av eftersom användare normalt inte migreras eller används på publiceringsinstanser. Om de används används ett annat autentiseringssystem (dvs. inte IMS).
Oavsett om användare mappas under extraheringen migreras de, tillsammans med grupperna, till molnsystemet under importen om de är kopplade till innehåll som migreras.
Viktigt att tänka på vid mappning och migrering av användare important-considerations
Exceptionella ärenden exceptional-cases
Följande specialfall loggas:
- Om en användare inte har någon e-postadress i fältet
profile/emaili noden jcr kan användaren migreras, men den är inte mappad. Detta gäller även om e-postadressen används som användarnamn för inloggning. - Om användaren är inaktiverad behandlas den på samma sätt som andra användare. Den mappas och migreras som vanligt och inaktiveras fortfarande i molninstansen.
- Om det finns ett huvudkonto med någon av samma unika data (rep:palName, rep:authzableId, jcr:uid eller rep:externalId) på både källinstansen AEM och målinstansen av AEM Cloud Service, migreras inte huvudkontot och det tidigare befintliga huvudkontot på molnsystemet ändras inte. Detta loggas i huvudmigreringsrapporten.
- Om en användare inte mappas till IMS via användarmappning kommer IMS inte att känna igen användarprofilen i molnet AEM system. Om användaren loggar in via IMS kommer en ny (dubblettprofil) att skapas på AEM, men den kommer inte att innehålla den tidigare profilinformationen. Den ursprungliga användarprofilen kommer att finnas i molnet AEM system, men de kommer inte att kunna logga in via IMS, utan bara med den traditionella AEM metoden (lokal inloggning). Därför bör du mappa alla användare för alla författarmigreringar.
Ytterligare överväganden additional-considerations
- Om inställningen Rensa befintligt innehåll i molninstansen innan har angetts, tas tidigare överförda objekt till Cloud Servicen bort tillsammans med hela den befintliga databasen. En ny databas skapas i vilken innehåll importeras. Den här processen återställer även alla inställningar inklusive behörigheter för målanvändarinstansen och är true för en Cloud Service som lagts till i gruppen administratörer. Administratörsanvändaren måste läggas till på nytt i gruppen administratörer för att hämta åtkomsttoken för CTT/CAM Ingesses.
- När icke-rensningsinmatningar utförs (Rensa befintligt innehåll har tagits bort), och om innehållet inte överförs eftersom det inte har ändrats sedan den tidigare överföringen, överförs inte heller användare och grupper som är kopplade till det innehållet. Den här regeln gäller även om användare och grupper har ändrats i källsystemet. Detta beror på att användare och grupper endast migreras tillsammans med det innehåll de är kopplade till. På grund av detta migreras inga huvudkonton som är nya för en grupp i källsystemet, såvida de inte tillhör en annan grupp som migreras eller i åtkomstkontrollistan för ett annat innehåll som migreras. Om du vill migrera dessa huvuden i efterhand kan du använda paket eller ta bort huvudobjekt från målet och migrera det relevanta innehållet igen (Extrahera med överskrivning och Ingest med svepning).
- Dubblerade e-postadresser tillåts inte i IMS, men de tillåts i AEM (både lokalt och i molnet). En användare kan logga in på AEM via IMS med sin e-postadress och loggas in i den användarprofil som IMS refererar till.
- Se Migrera stängda användargrupper om du vill ha mer information om principer som används i en CUG-princip (Closed User Group).
Slutlig sammanfattning och rapport final-report
När extraheringen och intaget har slutförts genereras en rapport med information om huvudmigreringen. Mer information finns i Validera huvudmigreringen.