För att automatisera avregistrering i Microsoft 365 bygger du avgångsflöden i Microsoft Entra ID Lifecycle Workflows som utlöses av ett datumattribut på användarobjektet i stället för av ett ärende som någon måste komma ihåg att skapa. Du sätter employeeLeaveDateTime på kontot, och Entra kör ett flöde före avgången innan sista dagen, ett avregistreringsflöde på själva dagen, och ett flöde efter avgången därefter, vart och ett med inbyggda uppgifter som Disable User Account, Remove user from all groups, Remove all licenses for user och Delete User Account. Utlösaren är ett datum, omfattningen är en regel, och körningen lämnar en historik du kan visa för en revisor. Den här guiden går igenom hela bygget, anger ärligt vilken licens som krävs, och täcker de fyra saker den inte gör åt dig.
Medarbetaren som behöll en licens i fyra månader
Börja med felet som detta ska åtgärda, för det är nästan aldrig ett tekniskt fel. Någon slutar. Supportfunktionen blockerar inloggning på sista dagen, blir bortkallad till något brådskande, och resten av sekvensen händer aldrig. Fyra månader senare är kontot fortfarande aktiverat i tre säkerhetsgrupper, håller fortfarande en full plats, och räknas fortfarande på fakturan.
Räknestycket är värt att göra med dina egna siffror snarare än någon annans jämförelsetal. En organisation med 250 användare och normal personalomsättning förlorar kanske 30 personer om året. Om varje avregistrering slutförs i genomsnitt sex veckor för sent är det ungefär 3,5 platsmånader i slöseri per avgång, alltså omkring 105 platsmånader om året. Vid £22 per plats är det drygt £2,300; vid £35 ligger det närmare £3,700. Ändra någon indata och svaret rör sig, vilket är hela poängen: din ekonomiansvarige kan kontrollera den summan i huvudet.
Kostnaden är det som ger ett budgetsamtal. Risken är det som ger ett styrelsesamtal. En avgången medarbetare med aktiva gruppmedlemskap har fortfarande allt de grupperna ger, och vid 50 till 600 användare håller samma person vanligtvis också delade autentiseringsuppgifter, ett Teams-medlemskap med kunddata i, och en postlåda som ingen har läst sedan de slutade. Automatisering spelar roll här inte för att de manuella stegen är svåra, utan för att en manuell process som körs 30 gånger om året kommer att hoppas över minst en gång, och du kommer inte att veta vilken gång.
Vad borttagningen i administrationscentret faktiskt täcker
Den manuella utgångspunkten är värd att vara exakt om. I administrationscentret för Microsoft 365 kör du, via Users then Active users, genom att välja en person och välja Delete user, ett helt paket: det kan ta bort licenserna, ge någon åtkomst till OneDrive och e-posten, och sedan ta bort kontot. Det är ett genuint användbart flöde för en enskild avgång och du behöver inte skämmas för att använda det.
Vad det inte är, är en process. Det gör ingenting förrän en människa öppnar det, det behandlar varje avgång identiskt oavsett roll eller avdelning, det ger inget underlag utöver granskningsloggen som någon skulle känna igen som bevis, och det kan inte köras en vecka före sista dagen eller trettio dagar efter den. Att få ordningsföljden rätt spelar också större roll än folk väntar sig, eftersom att ta bort en licens innan du har hanterat postlådan innebär att data går förlorade. Checklistan för avregistrering i Microsoft 365 beskriver den sekvensen steg för steg, och den är fortfarande rätt referens för hur bra ser ut. Den här artikeln handlar om att få sekvensen att köra av sig själv.
Licensfrågan, besvarad innan du planerar något
Var tydlig med detta innan du designar något alls, för det avgör om resten av artikeln är relevant för dig.
Lifecycle Workflows kräver licenser för Microsoft Entra ID Governance eller Microsoft Entra Suite. Det ingår inte i Microsoft Entra ID P1, det ingår inte i Microsoft Entra ID P2, och det ingår därför inte i Microsoft 365 E3 eller E5 genom det Entra-abonnemang de innehåller. Microsoft Entra ID Governance är en separat prenumeration som ligger ovanpå ett kvalificerande abonnemang, och Microsoft har varit tydliga med att inga nya funktioner för identitetsstyrning kommer att läggas till i SKU:n Entra ID P2.
Du behöver också tillräckligt många licenser för att täcka varje medlemsanvändare inom flödets omfattning, plus den som konfigurerar det, snarare än en enda administratörsplats. Microsofts eget räkneexempel är ett flöde före avgången med 50 användare i omfattningen, vilket kräver 51 licenser. För en organisation med 300 användare som avregistrerar 30 personer om året förändrar det affärsfallets form: du licensierar inte 30 avgångar, du licensierar hela den population som flödets omfattning täcker.
Det finns en provperiod. En Global Administrator i en kommersiell tenant som redan har en kvalificerande produkt som Microsoft Entra ID P1, och som inte har provat den tidigare, kan starta en från administrationscentret för Microsoft 365 under Billing then Purchase services, genom att söka efter Microsoft Entra ID Governance och välja Details then Start free trial. Det är det ärliga sättet att testa flödena nedan mot din egen tenant innan någon skriver på något.
Bygg flödet för avgångar
Att skapa ett flöde i administrationscentret för Microsoft Entra börjar alltid från en mall, och det finns 14 inbyggda. Fyra spelar roll för avgångar, och skälet till att de är fyra är att avregistrering inte är ett enda ögonblick.
Pre-Offboarding of an employee körs som standard sju dagar före employeeLeaveDateTime, med Remove user from selected groups och Remove user from selected Teams. Det här är den folk hoppar över och sedan ångrar: det är här du plockar ut någon ur lönegruppen och ekonomiavdelningens Team medan de fortfarande är kvar för att lämna över.
Offboard an employee körs på själva avgångsdatumet, med Disable User Account, Remove user from all groups och Remove user from all Teams. Det är flödet som stänger dörren.
Post-Offboarding of an employee körs efter avgångsdatumet, med Remove all licenses for user, Remove user from all Teams och Delete User Account. Det är flödet som stoppar faktureringen av platsen, och förskjutningen du väljer här är det enskilt dyraste talet i hela designen.
Real-time employee termination har inget körningsvillkor alls. Det körs enbart på begäran, med Remove user from all groups, Delete User Account och Remove user from all Teams, och det finns för fallet där någon lämnar byggnaden samma dag.
Den bredare uppgiftskatalogen är där du finjusterar var och en. Vid sidan av uppgifterna ovan innehåller den Revoke all refresh tokens for user, Remove all access package assignments for user, Send email to manager before user's last day, Send email on user's last day och Send email to user's manager after their last day. Att återkallande av sessioner är en inbyggd uppgift är värt att notera, eftersom gott om guider för avregistrering fortfarande presenterar det som något du måste skripta själv.
Två mallar till förtjänar att nämnas även om de inte strikt drivs av avgångar: Pre-Offboard inactive users och Offboard inactive users utlöses av inloggningsinaktivitet snarare än av ett avgångsdatum, med 90 respektive 120 dagar som standard. De är den automatiserade kusinen till rapporten i vår guide om att hitta inaktiva Microsoft 365-användare, och de fångar kontona som aldrig fick ett avgångsdatum för att ingen någonsin berättade för någon att personen hade slutat.
Schemaläggning, omfattning och attributet som allt hänger på
Tre konfigurationsdetaljer avgör om detta fungerar i praktiken.
Attributet är inte gratis. employeeLeaveDateTime fylls inte i åt dig. Det kommer från HR-driven etablering, från Microsoft Entra Connect, eller från ett skript som skriver det via Microsoft Graph. Att skriva det i en delegerad kontext kräver rollen Global Administrator tillsammans med behörigheterna User.Read.All och User-LifeCycleInfo.ReadWrite.All, vilket är en högre ribba än för de flesta rapporteringsuppgifter och värt att ta upp tidigt med den som äger din HR-integration. Om ingen sätter datumet körs ingenting, och flödet kommer att se trasigt ut när det bara står stilla.
Schemaläggning måste du slå på själv. Nya flöden är aktiverade som standard, men schemaläggning är det inte, så ett flöde kan stå där och se korrekt ut och ändå aldrig utlösas. När det väl är schemalagt utvärderas flöden på ett tenantomfattande intervall som är var tredje timme som standard och kan sättas var som helst från 1 till 24 timmar, under ID Governance then Lifecycle workflows then Workflow settings i administrationscentret för Microsoft Entra. Du behöver minst rollen Lifecycle Workflows Administrator för att ändra det.
Körningar på begäran ignorerar dina körningsvillkor. Att köra ett flöde på begäran tillämpar dess uppgifter på användaren oavsett om de uppfyller omfattningen och utlösaren eller inte. Det är exakt vad du vill ha vid en uppsägning samma dag och exakt vad du inte vill ha när du testar, så testa mot ett konto du är beredd att förlora.
En god nyhet om tidsaspekten: om avgångsdatumet sätts sent, säg för att HR-systemet uppdaterades i efterhand, kommer Lifecycle Workflows ändå att försöka behandla användaren förutsatt att uppsättningen slutförs inom tre dagar från den avsedda behandlingstidpunkten. Det ikappbeteendet gäller inte alternativet Time based attribute V2 som just nu är i public preview.
Fem drag. Entra automatiserar ett, två, tre och fem. Det fjärde är det som avgör om någon litar på de andra fyra.
De fyra saker den inte gör
Lifecycle Workflows styr identiteten. Avregistrering i Microsoft 365 är bredare än identiteten, och de här fyra luckorna förblir dina.
Postlådan. Det finns ingen uppgift för att konvertera en användarpostlåda till en delad postlåda, och ordningsfällan är verklig: postlådan måste fortfarande vara licensierad i det ögonblick du konverterar den, så det här måste ske innan flödet efter avgången tar bort licensen, inte efter.
Filerna. Att ge en chef åtkomst till den avgångnes OneDrive är ett jobb i administrationscentret för SharePoint. Ingenting i avgångsmallarna rör det.
Enheten. Retire och wipe finns i administrationscentret för Microsoft Intune, och ingen lifecycle-uppgift når dem. Schemalagda Intune-rapporter är det praktiska sättet att bevisa vilka av de avgångnas enheter som faktiskt checkade in och uppfyllde kraven.
Fakturan. Remove all licenses for user frigör tilldelningen. Den minskar inte ett förbetalt prenumerationsantal, så besparingen når din faktura först när någon agerar vid förnyelsen. Kom licensen från gruppbaserad licensiering är det gruppmedlemskapet som håller platsen, vilket är varför gruppuppgifterna och licensuppgiften hör hemma i samma flöde.
Här är skriptet för den första luckan, dimensionerat att köras en gång per avgång i fönstret mellan sista dagen och körningen efter avgången.
# Fills the gaps Lifecycle Workflows does not cover, before the licence is removed
Connect-ExchangeOnline
Connect-MgGraph -Scopes "User.RevokeSessions.All"
$Leaver = "leaver@contoso.com"
$Manager = "manager@contoso.com"
# Belt and braces: end every active session now rather than waiting for token expiry
Revoke-MgUserSignInSession -UserId $Leaver
# Convert while the mailbox is still licensed, or the conversion is not available
Set-Mailbox -Identity $Leaver -Type Shared
Add-MailboxPermission -Identity $Leaver -User $Manager -AccessRights FullAccess -InheritanceType All
Add-RecipientPermission -Identity $Leaver -Trustee $Manager -AccessRights SendAs -Confirm:$false
Write-Host "$Leaver converted to shared and delegated to $Manager"
Läs det innan du kör det. Revoke-MgUserSignInSession är överflödigt om ditt avregistreringsflöde redan bär återkallandeuppgiften, och harmlöst om det gör det. Konverteringen håller e-post och kalender nåbara upp till 50 GB utan en betald plats, vilket är det som gör det säkert att låta flödet ta bort licensen en dag senare. Ta inte bort kontot medan den delade postlådan används, eftersom kontot förankrar den.
Om den sekvensen ser ut som något du hellre ser köra kontinuerligt än kommer ihåg per avgång, visar en 14-dagars provperiod av EtherInsights samma kontroller mot din egen tenant.
Den ärliga gränsen för att automatisera detta
Lifecycle Workflows är bra. Det är också en mekanism, inte ett utfall, och tre saker skiljer de två.
Någon måste äga det. Ett flöde utan ägare driver iväg: omfattningsregeln slutar matcha en avdelning som bytt namn, en mall redigeras under en stressig vecka, och ingen märker det förrän en avregistrering tyst gör ingenting. Workflow history ger dig råmaterialet, som går att se per användare, körningar och uppgifter, men råmaterial är inte en genomgång.
Någon måste ta fram bevisen. Din revisor, din Cyber Essentials-bedömare och säkerhetsformuläret från din största kund ställer alla samma fråga med olika ord: visa mig att åtkomsten togs bort inom er angivna tidsram, för de här namngivna personerna, på de här datumen. Det är ett rapporteringsjobb ovanpå flödet, inte en biprodukt av det.
Och någon måste följa återtagningen hela vägen till fakturan. Platsen som flödet frigör är en besparing först när prenumerationsantalet sjunker. Mellan de två händelserna sitter ett förnyelsedatum och ett samtal med ekonomi, och det är där det mesta återtagningsarbetet tyst dör. Vår guide till att bevisa besparingar i molnet täcker varför det sista steget behöver ett före och efter snarare än ett påstående.
Inget av det är ett argument mot att bygga flödena. Bygg dem den här månaden. Det är ett argument för att vara tydlig med att automatiseringen löser genomförandeproblemet och lämnar ägarskapsproblemet exakt där det låg.
Var EtherInsights passar in
EtherInsights är konsolen som ligger ovanpå allt det här. Den kontrollerar avregistrering kontinuerligt snarare än per ärende, lyfter fram avgångna som fortfarande är aktiverade eller fortfarande licensierade som fynd med en namngiven ägare och en nästa åtgärd, och behåller före och efter så att en återtagning når din ekonomigenomgång som bevis snarare än som ett påstående. Där du har Lifecycle Workflows berättar den om flödena faktiskt gjorde det du designade dem för. Där du inte har det, för att licensen för styrning ännu inte är godkänd, ger den dig samma insyn utan en.
Licenshantering och avregistrering för Microsoft 365 kör loopen för nyanställda, rollbyten och avgångar som en process över tenanter, med arbetet kring vilande platser från att hitta oanvända licenser i samma vy. Det kostar £0.79 per aktiv användare med en provperiod på 14 dagar, så du kan mäta glappet mellan dina avgångsdatum och dina licensborttagningar innan du binder dig till något, vilket vanligtvis är talet som avgör diskussionen.
Sätt avgångsdatumet ordentligt, bygg de tre schemalagda flödena, skripta postlådan, och lägg in en månatlig genomgång i kalendern. Om den genomgången fortsätter att glida har du hittat den verkliga begränsningen, och det var aldrig verktygen.
Utforska licenshantering och avregistrering för Microsoft 365 för att se avgångskontroller, licensåtertagning och bevisspåret hanteras som en enda kontinuerlig process i stället för ett flöde som ingen bevakar.
