Mitarbeiter-Onboarding in Microsoft 365 automatisieren: Konto, Lizenz, Gerät und Zugänge per PowerShell und Power Automate

Eine neue Kollegin fängt am Montag an. Bis dahin braucht sie ein Konto, eine Lizenz, ein Postfach, die richtigen Gruppen, Zugriff auf das Teampostfach, einen Laptop und einen Weg, sich beim ersten Mal anzumelden, ohne dass jemand ein Passwort auf einen Zettel schreibt. In vielen Unternehmen sind das sechs Tickets, drei Zuständige und ein Freitagnachmittag. Dabei ist jeder dieser Schritte in Microsoft 365 eine einzelne Operation gegen dieselbe Schnittstelle, die sich skripten, per Formular auslösen und sauber dokumentieren lässt.

Ein automatisiertes Onboarding macht daraus einen Ablauf: Die Personalabteilung meldet den Eintritt, und Konto, Lizenz, Gruppen, Gerät und Erstanmeldung entstehen ohne Klickarbeit. Dieser Leitfaden zeigt das komplette IT-Onboarding auf dem Stand von September 2026: zuerst die Voraussetzungen, dann Baustein für Baustein per Microsoft Graph PowerShell bis zum fertigen Skript, danach der Weg ohne Code über Power Automate und zum Schluss die Governance-Variante mit Lifecycle Workflows. Er ist der Nachfolger unseres Leitfadens zu Windows Autopilot: Autopilot liefert das Gerät, dieser Artikel liefert die Identität, die sich darauf anmeldet — und verbindet beides, indem das Gerät dem neuen Nutzer schon vor dem ersten Einschalten zugewiesen wird.

Was ein automatisiertes Onboarding umfasst

Bevor es an Befehle geht, lohnt ein Blick auf das Zielbild. Ein vollständiges Onboarding besteht aus acht Schritten, die in einer festen Reihenfolge voneinander abhängen:

Schritt	Was passiert	Womit
Konto	Benutzer in Microsoft Entra ID mit Anzeigename, UPN, Abteilung und Eintrittsdatum	New-MgUser
Nutzungsstandort	UsageLocation setzen, sonst scheitert die Lizenzzuweisung	Parameter beim Anlegen
Lizenz	Mitgliedschaft in einer Lizenzgruppe, die Lizenz folgt automatisch	New-MgGroupMember
Vorgesetzter	Manager-Attribut, Grundlage für Genehmigungen und Lifecycle Workflows	Set-MgUserManagerByRef
Erste Anmeldung	Temporary Access Pass statt Startpasswort	New-MgUserAuthenticationTemporaryAccessPassMethod
Gerät	Autopilot-Gerät dem Nutzer zuweisen, UPN wird auf dem Gerät vorbelegt	Graph-Aktion assignUserToDevice
Postfach und Teams	Freigaben auf gemeinsame Postfächer, Mitgliedschaft im Team	Exchange Online und Teams PowerShell
Information	Zugangsdaten an den Vorgesetzten, Nachricht an die IT	Power Automate oder Lifecycle Workflow

Zwei Dinge gehören ausdrücklich nicht dazu: ein Passwort, das ein Mensch liest, und ein Secret, das im Klartext im Skript steht. Beides löst dieser Leitfaden anders — mit einem Temporary Access Pass für den Nutzer und mit Zertifikat oder Managed Identity für die Automatisierung.

Drei Wege, ein Ziel: Skript, Power Automate, Lifecycle Workflows

Microsoft bietet drei Werkzeuge an, die sich in Lizenz, Reichweite und Zielgruppe deutlich unterscheiden:

	Graph PowerShell	Power Automate	Lifecycle Workflows
Lizenz	Modul aus der PowerShell Gallery, Rechte über Entra-Rollen	Standard-Connectoren wie Entra ID, Forms, SharePoint, Approvals, Outlook, Teams; HTTP-Aktion ist Premium	Microsoft Entra ID Governance oder Entra Suite
Kann	Alles: Konto, Lizenz, TAP, Autopilot-Zuweisung, Exchange, Teams	Konto, Gruppe, Vorgesetzter, Genehmigung, E-Mail, Teams-Nachricht	Zeitgesteuerte Aufgaben an bestehenden Konten: TAP-Mail, Konto aktivieren, Gruppen, Teams, Willkommensmail
Kann nicht	Nur, was die Rolle nicht erlaubt	Lizenz direkt, Nutzungsstandort, TAP, Autopilot (ohne Premium-HTTP)	Konten anlegen
Passt für	IT mit PowerShell-Erfahrung, versionierbar, wiederholbar	Auslösung aus der Personalabteilung mit Genehmigung, ohne Code	Unternehmen mit Governance-Lizenz und gepflegtem Eintrittsdatum

Unsere Empfehlung für den Mittelstand: Das Skript ist das Rückgrat, weil es als einziges alle Schritte beherrscht. Power Automate setzen Sie davor, wenn die Personalabteilung das Onboarding auslösen und der Vorgesetzte es freigeben soll. Lifecycle Workflows lohnen sich, wenn die Governance-Lizenz ohnehin vorhanden ist und das Eintrittsdatum verlässlich gepflegt wird.

Voraussetzungen: Lizenzen, Rollen und zwei einmalige Einstellungen

Lizenzen

Die gute Nachricht zuerst: Für die Lizenzzuweisung über Gruppen nennt die aktuelle Microsoft-Dokumentation keine Lizenzvoraussetzung mehr, sondern nur noch Rollen. Anders sieht es bei dynamischen Gruppen aus, die Mitglieder nach Regeln aufnehmen: Sie erfordern Microsoft Entra ID P1 für jeden Nutzer, der Mitglied mindestens einer dynamischen Gruppe ist. Die Lizenzen müssen im Tenant vorhanden, aber nicht einzeln zugewiesen sein; Geräte in dynamischen Gerätegruppen brauchen keine. P1 ist in Microsoft 365 Business Premium, E3, E5, F1 und F3 enthalten — welcher Plan zu Ihrer Größe passt, steht im Microsoft-365-Lizenzvergleich.

Eine Conditional-Access-Richtlinie, die die Registrierung der Sicherheitsinformationen schützt, setzt ebenfalls P1 voraus. Lifecycle Workflows brauchen Microsoft Entra ID Governance oder die Microsoft Entra Suite; Entra ID P2 allein enthält sie nicht. In Power Automate sind die Connectoren für Entra ID, Forms, SharePoint, Genehmigungen, Outlook und Teams Standard, die generische HTTP-Aktion ist Premium.

Rollen nach dem Prinzip der geringsten Rechte

Globale Administratorrechte braucht das Onboarding nicht. Microsoft dokumentiert für jede Aufgabe die schwächste ausreichende Rolle:

Aufgabe	Rolle
Benutzer anlegen, Gruppen zuweisen, Eigenschaften ändern	User Administrator
Lizenz einer Gruppe zuweisen	User Administrator
Lizenz einem Nutzer direkt zuweisen	License Administrator
Gruppe anlegen	Groups Administrator
TAP-Richtlinie aktivieren	Authentication Policy Administrator
TAP für einen Nutzer erstellen	Authentication Administrator
Lifecycle Workflow erstellen	Lifecycle Workflows Administrator

Die alten Module sind abgeschaltet

Wer Anleitungen mit New-MsolUser oder New-AzureADUser findet, kann sie schließen. Microsoft hat beide Module zum 30. März 2024 abgekündigt und die Abschaltung für MSOnline zwischen Anfang April und Ende Mai 2025, für AzureAD Anfang Juli 2025 angekündigt. Beide Termine sind verstrichen. Der Ersatz ist das Microsoft Graph PowerShell SDK — Microsoft empfiehlt für Skripte ausdrücklich die v1.0-Module, weil sich die Beta-Module ohne Ankündigung ändern können. Dazu kommen die Module für Exchange Online und Teams:

Install-Module Microsoft.Graph -Scope CurrentUser -Repository PSGallery -Force
Install-Module ExchangeOnlineManagement
Install-Module -Name MicrosoftTeams -Force -AllowClobber

Das Hauptmodul installiert über 47 Untermodule; wer schlank bleiben will, installiert nur die benötigten, Microsoft.Graph.Authentication ist immer dabei. Als Alternative existiert Microsoft Entra PowerShell mit New-EntraUser, dieser Leitfaden bleibt beim Graph-SDK.

Einmalig: TAP-Richtlinie aktivieren

Ein Temporary Access Pass lässt sich zwar für jeden Nutzer erzeugen, aber nur Nutzer im Geltungsbereich der Richtlinie können sich damit anmelden. Die Richtlinie aktivieren Sie einmal im Entra admin center unter Authentication methods → Policies → Temporary Access Pass, mit der Rolle Authentication Policy Administrator. Die Standardwerte lohnen einen bewussten Blick:

Einstellung	Standard	Erlaubter Bereich
Minimale Gültigkeit	1 Stunde	ab 10 Minuten
Maximale Gültigkeit	8 Stunden	bis 43.200 Minuten (30 Tage)
Standardgültigkeit	1 Stunde
Einmalnutzung	Nein
Länge	8 Zeichen	8 bis 48 Zeichen

Weil die Gültigkeit ab der Startzeit zählt, lässt sich der Pass schon am Vortag erzeugen: Mit startDateTime am Eintrittstag um 8 Uhr und 480 Minuten gilt er bis 16 Uhr. Nur wer ohne Startzeit arbeitet oder mehr als einen Arbeitstag abdecken will, muss das Maximum der Richtlinie anheben, denn ein Wert über dem Maximum wird abgelehnt.

Einmalig: Lizenzgruppe anlegen

Lizenzen weisen Sie nicht dem Nutzer zu, sondern einer Sicherheitsgruppe. Jeder, der Mitglied wird, bekommt die Lizenz automatisch, und beim Ausscheiden verschwindet sie mit der Mitgliedschaft. Welche Lizenz im Tenant welchen technischen Namen trägt, zeigt Get-MgSubscribedSku; die Zahl freier Lizenzen ergibt sich laut Microsoft aus aktiven Einheiten minus Warnungseinheiten minus verbrauchten Einheiten:

Connect-MgGraph -Scopes "Organization.Read.All","Group.ReadWrite.All","LicenseAssignment.ReadWrite.All"

# Alle Lizenzen des Tenants mit technischem Namen und Verbrauch
Get-MgSubscribedSku -All | Select-Object SkuPartNumber, SkuId, ConsumedUnits,
  @{ n = 'Aktiv'; e = { $_.PrepaidUnits.Enabled } }, @{ n = 'Warnung'; e = { $_.PrepaidUnits.Warning } }

# Lizenz einer Sicherheitsgruppe zuweisen (Beispiel: Microsoft 365 E5 = SPE_E5)
$sku = Get-MgSubscribedSku -All | Where-Object SkuPartNumber -eq 'SPE_E5'
$grp = Get-MgGroup -Filter "displayName eq 'LIC-M365-E5'"
Set-MgGroupLicense -GroupId $grp.Id -AddLicenses @(@{ SkuId = $sku.SkuId }) -RemoveLicenses @()

Drei Regeln aus der Dokumentation: Verschachtelte Gruppen unterstützt die Gruppenlizenzierung nicht. Nutzer ohne Nutzungsstandort erben den Standort des Tenants — Microsoft empfiehlt trotzdem, den Standort beim Anlegen immer zu setzen. Und wer einen Nutzer zwischen zwei Lizenzgruppen verschiebt, fügt ihn erst der Zielgruppe hinzu, prüft die Lizenz und entfernt ihn dann aus der Quellgruppe, sonst verliert er zwischendurch den Zugriff.

Der Weg per PowerShell: Baustein für Baustein

1. Verbinden mit den richtigen Scopes

Graph PowerShell verlangt für jede Operation eine passende Berechtigung, die Sie beim Verbinden anfordern. Für das komplette Onboarding reichen fünf:

Connect-MgGraph -Scopes "User.ReadWrite.All",
                        "Group.ReadWrite.All",
                        "Organization.Read.All",
                        "UserAuthenticationMethod.ReadWrite.All",
                        "DeviceManagementServiceConfig.ReadWrite.All"

Beim ersten Mal muss ein Administrator der Anwendung zustimmen. Welche Berechtigung ein bestimmtes Cmdlet braucht, verrät Find-MgGraphCommand -Command New-MgUser | Select-Object -First 1 -ExpandProperty Permissions — die verlässlichste Antwort auf den Fehler Authorization_RequestDenied.

2. Konto anlegen

Fünf Felder sind Pflicht: accountEnabled, displayName, mailNickname, passwordProfile und userPrincipalName. Die Domain im UPN muss zu den verifizierten Domains des Tenants gehören, und der UPN darf laut Microsoft keine Akzentzeichen enthalten: Erlaubt sind A bis Z, a bis z, 0 bis 9 sowie Apostroph, Punkt, Bindestrich, Unterstrich, Ausrufezeichen, Raute, Zirkumflex und Tilde. Wir verwenden dieselbe Regel für den Alias. Aus „Müller” wird deshalb mueller, und diese Umschrift gehört fest ins Skript, nicht in den Kopf des Administrators.

$PasswordProfile = @{
  Password                      = $startPassword   # zur Laufzeit erzeugt, nie geloggt
  ForceChangePasswordNextSignIn = $true
}
$user = New-MgUser -DisplayName "Erika Mustermann" `
  -GivenName "Erika" -Surname "Mustermann" `
  -MailNickname "erika.mustermann" `
  -UserPrincipalName "erika.mustermann@contoso.com" `
  -PasswordProfile $PasswordProfile `
  -AccountEnabled `
  -UsageLocation "DE" `
  -Department "Vertrieb" -JobTitle "Account Manager" `
  -EmployeeHireDate (Get-Date "2026-10-01T08:00:00")

Zwei Parameter sind wichtiger, als sie aussehen. -UsageLocation ist ein Ländercode nach ISO 3166-1 alpha-2, ohne ihn lässt sich keine Lizenz direkt zuweisen. Und -EmployeeHireDate nimmt eine Uhrzeit auf: Lifecycle Workflows verwenden genau diesen Zeitpunkt als Startzeit für den Temporary Access Pass.

3. Lizenz über die Gruppe, Vorgesetzter, Abteilungsgruppe

Mit der Lizenzgruppe aus den Voraussetzungen wird die Lizenzzuweisung eine Gruppenmitgliedschaft. Dieselbe Operation setzt den Nutzer in seine Abteilungsgruppe, und ein zweiter Aufruf trägt den Vorgesetzten ein:

# Lizenz: Mitglied der Lizenzgruppe werden, die Lizenz folgt automatisch
New-MgGroupMember -GroupId $licGroup.Id -DirectoryObjectId $user.Id

# Abteilungs- oder Teams-Gruppe
New-MgGroupMember -GroupId $deptGroup.Id -DirectoryObjectId $user.Id

# Vorgesetzten setzen
$manager = Get-MgUser -UserId "max.mustermann@contoso.com"
Set-MgUserManagerByRef -UserId $user.Id -BodyParameter @{
  "@odata.id" = "https://graph.microsoft.com/v1.0/users/$($manager.Id)"
}

Wer ohne Gruppe arbeiten will, weist die Lizenz direkt zu — die Microsoft-Dokumentation nutzt dafür das Beispiel Microsoft 365 E5:

$sku = Get-MgSubscribedSku -All | Where-Object SkuPartNumber -eq 'SPE_E5'
Set-MgUserLicense -UserId $user.Id -AddLicenses @{ SkuId = $sku.SkuId } -RemoveLicenses @()

Ein Fehler, der in beiden Varianten auftritt: MutuallyExclusiveViolation. Er bedeutet, dass zwei Lizenzen Servicepläne enthalten, die sich gegenseitig ausschließen, etwa Exchange Online Plan 1 und Plan 2. Dann bleibt nur eine der beiden Lizenzen, oder der doppelte Plan wird über DisabledPlans abgeschaltet.

4. Temporary Access Pass statt Startpasswort

Der Temporary Access Pass ist ein zeitlich begrenzter Code, mit dem sich der neue Nutzer beim ersten Mal anmeldet, seine Authentifizierungsmethoden unter Security info registriert und — bei einem noch nicht eingerichteten Windows-Gerät — den Entra-Join und Windows Hello for Business ohne Passwort abschließt. Er ersetzt das Passwort nicht, das bleibt Pflichtfeld; aber niemand muss es kennen.

$tapBody = @{
  isUsableOnce      = $true
  lifetimeInMinutes = 480
  startDateTime     = (Get-Date "2026-10-01T07:30:00").ToUniversalTime()
}
$tap = New-MgUserAuthenticationTemporaryAccessPassMethod -UserId $user.Id -BodyParameter $tapBody
$tap.TemporaryAccessPass   # nur jetzt lesbar, später null

Der Wert des Passes ist ausschließlich in der Antwort auf die Erstellung enthalten, jede spätere Abfrage liefert null. Pro Nutzer existiert nur ein Pass, ein neuer ersetzt den alten. Nach dem Anlegen kann es einige Minuten dauern, bis die Anmeldung ihn anbietet. Und eine Falle für das Zusammenspiel mit Autopilot: Bei einem Einmal-Pass muss die passwortlose Registrierung innerhalb von zehn Minuten nach der Anmeldung erfolgen. Dauert die Geräteeinrichtung länger, braucht der Nutzer einen zweiten Pass — oder Sie erzeugen für die Geräteeinrichtung von vornherein einen mehrfach nutzbaren.

Wer die Registrierung der Sicherheitsinformationen zusätzlich per Conditional Access absichert, ist auf den Pass angewiesen: Microsoft dokumentiert ausdrücklich, dass Administratoren neuen Nutzern dann einen Temporary Access Pass ausstellen müssen, damit diese die MFA-Anforderung bei der Registrierung erfüllen können.

5. Autopilot-Gerät dem neuen Nutzer zuweisen

Hier schließt sich der Kreis zum Autopilot-Leitfaden. Ein registriertes Autopilot-Gerät lässt sich einem Nutzer zuweisen; bei unterstützten Herstellern erscheint sein UPN dann bereits auf der Anmeldeseite, und seine Richtlinien und Apps werden schon während der Einrichtung angewendet. Der Nutzer muss dafür Intune-lizenziert sein, und mit AD FS funktioniert die Zuweisung nicht.

Import-Module Microsoft.Graph.DeviceManagement.Enrollment
$device = Get-MgDeviceManagementWindowsAutopilotDeviceIdentity -All |
          Where-Object SerialNumber -eq $SerialNumber
if (-not $device) { throw "Autopilot-Gerät mit Seriennummer $SerialNumber nicht registriert." }

Set-MgDeviceManagementWindowsAutopilotDeviceIdentityUserToDevice `
  -WindowsAutopilotDeviceIdentityId $device.Id `
  -BodyParameter @{
    userPrincipalName   = $user.UserPrincipalName
    addressableUserName = $user.DisplayName
  }

Dahinter steht die Graph-Aktion assignUserToDevice in der stabilen v1.0-API mit der Berechtigung DeviceManagementServiceConfig.ReadWrite.All; das Gegenstück heißt unassignUserFromDevice. Weil die Intune-Lizenz in diesem Ablauf über die Gruppe kommt und die Verarbeitung je nach Tenant dauert, gehört die Zuweisung ans Ende des Skripts, mit Wiederholung bei Fehlschlag. Wer Geräte ohnehin per CSV importiert, kann den Nutzer alternativ direkt in der Spalte „Assigned User” hinterlegen — nur im Texteditor, nie mit Excel.

6. Postfach und Teams: der zweite Lauf

Das Postfach entsteht automatisch, sobald die Exchange-Online-Lizenz greift. Die Bereitstellung dauert laut Microsoft typischerweise unter 30 Minuten, in Einzelfällen bis zu 24 Stunden. Freigaben auf gemeinsame Postfächer und die Team-Mitgliedschaft gehören deshalb in einen zweiten Lauf, nicht unmittelbar hinter das Anlegen:

Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com

# Vollzugriff auf ein gemeinsames Postfach (mit Automapping in Outlook)
Add-MailboxPermission -Identity "vertrieb@contoso.com" -User $user.UserPrincipalName `
  -AccessRights FullAccess -InheritanceType All
# Senden als
Add-RecipientPermission -Identity "vertrieb@contoso.com" -Trustee $user.UserPrincipalName `
  -AccessRights SendAs

Disconnect-ExchangeOnline -Confirm:$false

Connect-MicrosoftTeams
Add-TeamUser -GroupId $teamGroupId -User $user.UserPrincipalName -Role Member

Add-TeamUser fügt den Nutzer dem Team und der dahinterliegenden Microsoft-365-Gruppe hinzu, kehrt aber sofort zurück; im Teams-Client kann die Änderung 24 bis 48 Stunden brauchen. Eine Wiederholungsschleife, die auf Sichtbarkeit wartet, ist deshalb sinnlos. Für Postfächer mit sehr vielen Berechtigten, Microsoft nennt mehr als 500 Einträge, empfiehlt Microsoft Sicherheitsgruppen statt Einzelnutzer; das Automapping in Outlook wirkt allerdings nur für einzeln berechtigte Nutzer.

Alles zusammen: New-Employee.ps1

Die Bausteine ergeben ein Skript, das mit vier Pflichtparametern auskommt und optional das Autopilot-Gerät zuweist. Drei Entwurfsentscheidungen darin sind Konventionen von uns, keine Microsoft-Vorgaben: Vorgesetzter und Lizenzgruppe werden vor dem Anlegen aufgelöst, damit kein halbfertiges Konto entsteht, wenn ein Name falsch geschrieben ist. Schlägt ein späterer Schritt fehl, deaktiviert das Skript das Konto wieder, statt es aktiv liegen zu lassen — und zwar bevor es den Fehler weiterreicht, denn bei $ErrorActionPreference = 'Stop' würde ein vorangestelltes Write-Error den Rollback überspringen. Und das Startpasswort wird aus dem Zufallszahlengenerator des Betriebssystems erzeugt und nie ausgegeben — die Anmeldung läuft über den Temporary Access Pass.

<#
.SYNOPSIS  Legt einen neuen Mitarbeiter in Microsoft 365 an:
           Konto, Lizenzgruppe, Vorgesetzter, Temporary Access Pass, optional Autopilot-Gerät.
.NOTES     Keine Secrets im Skript: Anmeldung interaktiv (delegiert) oder per Zertifikat (App-only).
           Exchange- und Teams-Schritte laufen als zweiter Lauf, sobald das Postfach existiert.
#>
[CmdletBinding(SupportsShouldProcess)]
param(
  [Parameter(Mandatory)] [string] $GivenName,
  [Parameter(Mandatory)] [string] $Surname,
  [Parameter(Mandatory)] [string] $Department,
  [Parameter(Mandatory)] [string] $ManagerUpn,
  [string] $JobTitle,
  [datetime] $HireDate = (Get-Date).Date.AddHours(8),
  [string] $SerialNumber,                              # optional: Autopilot-Gerät
  [string] $Domain = "contoso.com",
  [string] $UsageLocation = "DE",
  [string] $LicenseGroupName = "LIC-M365-E5",
  [int]    $TapLifetimeMinutes = 480,
  [switch] $MultiUseTap,                               # mehrfach nutzbarer Pass, z. B. für die Geräteeinrichtung
  # App-only statt interaktiv: Zertifikat im Zertifikatspeicher, kein Secret im Skript
  [string] $ClientId, [string] $TenantId, [string] $CertificateThumbprint
)

$ErrorActionPreference = 'Stop'

# --- 1. Verbinden: delegiert (interaktiv) oder App-only per Zertifikat ---
$scopes = "User.ReadWrite.All","Group.ReadWrite.All","Organization.Read.All",
          "UserAuthenticationMethod.ReadWrite.All","DeviceManagementServiceConfig.ReadWrite.All"
if ($ClientId -and $TenantId -and $CertificateThumbprint) {
  Connect-MgGraph -ClientId $ClientId -TenantId $TenantId -CertificateThumbprint $CertificateThumbprint
} else {
  Connect-MgGraph -Scopes $scopes
}

# --- 2. Alias und UPN bilden (Konvention: vorname.nachname, nur erlaubte Zeichen), Kollision prüfen ---
$map = @{ 'ä' = 'ae'; 'ö' = 'oe'; 'ü' = 'ue'; 'ß' = 'ss' }
$raw = ("{0}.{1}" -f $GivenName, $Surname).ToLower()
foreach ($k in $map.Keys) { $raw = $raw.Replace($k, $map[$k]) }
$alias = $raw -replace '\s+', '-' -replace '[^a-z0-9.\-_]', ''
$upn   = "$alias@$Domain"
if (Get-MgUser -Filter "userPrincipalName eq '$upn'") {
  throw "UPN $upn existiert bereits."
}

# --- 3. Vorgesetzten und Lizenzgruppe auflösen, BEVOR etwas angelegt wird ---
$manager  = Get-MgUser -UserId $ManagerUpn
$licGroup = Get-MgGroup -Filter "displayName eq '$LicenseGroupName'"
if (@($licGroup).Count -ne 1) { throw "Lizenzgruppe '$LicenseGroupName' nicht gefunden oder nicht eindeutig." }

# --- 4. Startpasswort erzeugen: Pflichtfeld, wird nie ausgegeben, der TAP ersetzt es beim ersten Login ---
$bytes = New-Object byte[] 24
$rng = [System.Security.Cryptography.RandomNumberGenerator]::Create()   # läuft unter Windows PowerShell 5.1 und PowerShell 7
$rng.GetBytes($bytes); $rng.Dispose()
$startPassword = [Convert]::ToBase64String($bytes) + 'aA1!'             # alle Zeichenklassen sicher enthalten

$user = $null
try {
  # --- 5. Konto anlegen ---
  $newUser = @{
    DisplayName = "$GivenName $Surname"; GivenName = $GivenName; Surname = $Surname
    MailNickname = $alias; UserPrincipalName = $upn
    PasswordProfile = @{ Password = $startPassword; ForceChangePasswordNextSignIn = $true }
    AccountEnabled = $true; UsageLocation = $UsageLocation
    Department = $Department; EmployeeHireDate = $HireDate
  }
  if ($JobTitle) { $newUser.JobTitle = $JobTitle }       # leere Werte gar nicht erst übergeben
  if ($PSCmdlet.ShouldProcess($upn, "New-MgUser")) {
    $user = New-MgUser @newUser
  }
  if (-not $user) {
    # -WhatIf: Vorprüfungen sind gelaufen, angelegt wurde nichts
    Write-Host "WhatIf: Konto $upn würde angelegt, Lizenzgruppe '$($licGroup.DisplayName)', Vorgesetzter $($manager.UserPrincipalName), TAP ab $HireDate für $TapLifetimeMinutes Minuten."
    return
  }

  # --- 6. Lizenz über die Gruppe, Vorgesetzter ---
  New-MgGroupMember -GroupId $licGroup.Id -DirectoryObjectId $user.Id
  Set-MgUserManagerByRef -UserId $user.Id -BodyParameter @{
    "@odata.id" = "https://graph.microsoft.com/v1.0/users/$($manager.Id)"
  }

  # --- 7. Temporary Access Pass (Richtlinie muss aktiv sein, Lebensdauer innerhalb des Maximums) ---
  $tap = New-MgUserAuthenticationTemporaryAccessPassMethod -UserId $user.Id -BodyParameter @{
    isUsableOnce      = -not ($MultiUseTap -or $SerialNumber)   # mit Gerät: mehrfach nutzbar (10-Minuten-Regel)
    lifetimeInMinutes = $TapLifetimeMinutes
    startDateTime     = $HireDate.ToUniversalTime()
  }

  # --- 8. Optional: Autopilot-Gerät zuweisen ---
  if ($SerialNumber) {
    Import-Module Microsoft.Graph.DeviceManagement.Enrollment
    $device = Get-MgDeviceManagementWindowsAutopilotDeviceIdentity -All |
              Where-Object SerialNumber -eq $SerialNumber
    if ($device) {
      Set-MgDeviceManagementWindowsAutopilotDeviceIdentityUserToDevice `
        -WindowsAutopilotDeviceIdentityId $device.Id `
        -BodyParameter @{ userPrincipalName = $upn; addressableUserName = "$GivenName $Surname" }
    } else {
      Write-Warning "Kein Autopilot-Gerät mit Seriennummer $SerialNumber registriert. Zuweisung übersprungen."
    }
  }

  # --- 9. Ergebnis: der TAP geht nur an den Vorgesetzten, nie ins Log ---
  [pscustomobject]@{
    UserPrincipalName   = $upn
    Manager             = $manager.UserPrincipalName
    LicenseGroup        = $licGroup.DisplayName
    TapValidFrom        = $tap.StartDateTime
    TapLifetimeMin      = $tap.LifetimeInMinutes
    TemporaryAccessPass = $tap.TemporaryAccessPass
  }
}
catch {
  $msg = $_.Exception.Message
  if ($user) {
    # Erst deaktivieren, dann abbrechen: Write-Error würde bei ErrorActionPreference 'Stop' den Block sofort verlassen
    try {
      Update-MgUser -UserId $user.Id -AccountEnabled:$false
      Write-Warning "Konto $upn wurde deaktiviert. Bitte manuell prüfen."
    } catch {
      Write-Warning "Konto $upn konnte NICHT deaktiviert werden: $($_.Exception.Message)"
    }
  }
  throw "Onboarding für $upn fehlgeschlagen: $msg"
}
finally {
  Disconnect-MgGraph | Out-Null
}

Ein Aufruf mit -WhatIf prüft Vorgesetzten, Lizenzgruppe und UPN-Kollision und zeigt, welches Konto angelegt würde, ohne etwas zu ändern. Mit einer Seriennummer erzeugt das Skript einen mehrfach nutzbaren Pass, sofern die Richtlinie keine Einmalnutzung erzwingt, damit die Zehn-Minuten-Regel die Geräteeinrichtung nicht ausbremst. Das Skript läuft unter Windows PowerShell 5.1 und PowerShell 7. Der zweite Lauf mit den Exchange- und Teams-Bausteinen aus Schritt 6 lässt sich als Grant-EmployeeAccess.ps1 am nächsten Morgen ausführen, wenn das Postfach sicher existiert.

Der Weg mit Power Automate: vom HR-Formular zum Konto

Wenn nicht die IT, sondern die Personalabteilung ein Onboarding anstoßen soll, ist Power Automate das passende Frontend. Ein Flow, der ausschließlich Standard-Connectoren nutzt, sieht so aus:

1. Auslöser: Microsoft Forms mit dem Trigger „When a new response is submitted” und der Aktion „Get response details” — oder eine SharePoint-Liste mit „When an item is created”, die zugleich als Nachweis dient.
2. Vorgesetzten ermitteln: Das Formular fragt den Vorgesetzten der neuen Person ab; Office 365 Users liefert dazu Profil und Objekt-ID, die Schritt 3 und Schritt 6 brauchen. Die Aktion „Get manager (V2)” hilft nur, wenn der Vorgesetzte selbst das Formular ausfüllt.
3. Genehmigung: Approvals, Aktion „Start and wait for an approval”. Microsoft bietet die Typen „Everyone must approve”, „First to respond”, eigene Antworten und sequenzielle Genehmigungen. In der anschließenden Bedingung ist die Antwort Approve auf Groß- und Kleinschreibung zu prüfen.
4. Konto anlegen: Connector „Microsoft Entra ID”, Aktion „Create user” mit den Pflichtfeldern Account Enabled, Display Name, Mail Nickname, Password und User Principal Name; laut Microsoft muss der Nutzer das Passwort bei der nächsten Anmeldung ändern. Optional: Vorname, Nachname, Abteilung, Jobtitel.
5. Lizenz: Aktion „Add user to group” mit der Lizenzgruppe aus den Voraussetzungen — so bekommt der Nutzer seine Lizenz, obwohl der Connector selbst keine Lizenzaktion kennt.
6. Vorgesetzter: Aktion „Assign manager” mit der Objekt-ID des Vorgesetzten.
7. Information: Office 365 Outlook, „Send an email (V2)” an den Vorgesetzten, und Microsoft Teams, „Post message in a chat or channel” in den Kanal der IT.

Der Connector „Microsoft Entra ID” braucht eine Verbindung mit einem Konto, das die Berechtigungen User.ReadWrite.All, Group.ReadWrite.All und Directory.ReadWrite.All hat. Die Aktionsliste des Connectors zeigt seine Grenzen: keine Lizenzaktion, kein eigenes Feld für den Nutzungsstandort (der Nutzer erbt bei der Gruppenlizenz den Standort des Tenants), kein Temporary Access Pass, keine Autopilot-Zuweisung. Als bekannte Einschränkungen nennt Microsoft außerdem: Der Connector liefert keine benutzerdefinierten Attribute zurück und unterstützt weder E-Mail-aktivierte Sicherheitsgruppen noch rollenzuweisbare Gruppen. Und ein Satz, der im Mittelstand oft übersehen wird: Ist Conditional Access mit MFA aktiv, „funktioniert der Connector nicht wie erwartet” — das Verbindungskonto braucht eine passende Ausnahme oder ein anderes Verfahren.

Für alles, was der Connector nicht kann, gibt es die HTTP-Aktion gegen Microsoft Graph mit einer eigenen App-Registrierung. Sie ist ein Premium-Connector, ebenso „HTTP With Microsoft Entra ID”. Ohne passende Power-Automate-Lizenz bricht der Flow mit der Meldung ab, der Nutzer habe „keinen ausreichenden Serviceplan für die Nicht-Standard-Verbindung”; eine Microsoft-365-Lizenz allein genügt dafür nicht. Die pragmatische Aufteilung lautet deshalb: Power Automate übernimmt Formular, Genehmigung und Konto; ein Skript übernimmt Pass und Gerät. Wie sich Power Automate gegen n8n und Make schlägt, haben wir im Vergleich der Automatisierungsplattformen untersucht.

Lifecycle Workflows: Onboarding als Governance-Funktion

Microsoft Entra ID Governance bringt derzeit 14 fertige Vorlagen für den Lebenszyklus von Identitäten mit, drei davon für den Eintritt:

• Onboard pre-hire employee: läuft sieben Tage vor dem Eintrittsdatum (anpassbar) und erzeugt einen Temporary Access Pass, den es per E-Mail an den Vorgesetzten schickt.
• Onboard new hire employee: läuft am Tag des Eintritts, aktiviert das Konto, fügt es Gruppen hinzu und verschickt die Willkommensmail.
• Post-Onboarding of an employee: läuft sieben Tage danach und ergänzt Gruppen und Teams.

Auslöser ist das Attribut employeeHireDate, das Sie in Schritt 2 mit Uhrzeit gesetzt haben: Die TAP-Aufgabe verwendet genau diesen Zeitpunkt als Start des Passes, liegt er in der Vergangenheit, nimmt sie die aktuelle Zeit. Voraussetzung ist außerdem, dass Vorgesetzter und dessen E-Mail-Adresse am Konto gepflegt sind und die TAP-Richtlinie aktiv ist. Die E-Mail-Vorlagen kennen Platzhalter für Anzeigename, UPN, Eintrittsdatum, Vorgesetzten und den Pass selbst.

Und ohne Governance-Lizenz? Das Prinzip lässt sich mit Bordmitteln nachbauen: Das Eintrittsdatum steht ohnehin in der SharePoint-Liste, über die die Personalabteilung den Eintritt meldet. Ein geplanter Power-Automate-Flow prüft täglich, welche Eintritte in sieben Tagen anstehen, und erinnert IT und Vorgesetzten; am Eintrittstag stößt er das Skript an oder meldet, dass der Pass zu erzeugen ist. Das Attribut employeeHireDate pflegen Sie trotzdem, dann ist der spätere Umstieg auf Lifecycle Workflows eine Lizenzfrage und kein Umbau. Weil in dieser Liste Personaldaten stehen, gehören Zugriffsrechte und Löschfristen dazu, siehe unsere DSGVO-Checkliste für die IT. Wer statt der Liste direkt das HR-System anbinden will, braucht eine Schnittstelle zwischen Personalsoftware und Microsoft 365.

Zwei Grenzen: Lifecycle Workflows legen keine Konten an, sie ergänzen den HR-gesteuerten Sync oder ein Skript. Und sie erfordern Microsoft Entra ID Governance oder die Entra Suite — die Rolle für die Einrichtung heißt Lifecycle Workflows Administrator.

Wenn es klemmt: die häufigsten Fehler

Symptom	Ursache	Lösung
Lizenz lässt sich nicht zuweisen, Hinweis auf fehlenden Standort	UsageLocation fehlt	Update-MgUser -UserId <UPN> -UsageLocation DE, im Skript beim Anlegen setzen
Gruppenlizenz meldet „Errors & issues”	Keine freien Lizenzen, widersprüchliche Servicepläne oder ungültiger Standort	Ursache beheben, dann im Admin Center „Reprocess” (maximal 20 Nutzer gleichzeitig)
MutuallyExclusiveViolation	Zwei Lizenzen mit sich ausschließenden Plänen	Nur eine Lizenz zuweisen oder Plan per DisabledPlans abschalten
Anmeldung bietet keinen TAP an	Nutzer außerhalb der Richtlinie, Pass abgelaufen oder verbraucht, Replikation läuft noch	Geltungsbereich prüfen, neuen Pass erzeugen, einige Minuten warten
„Temporary Access Pass sign in was blocked due to User Credential Policy”	Mehrfach-Pass trotz Richtlinie mit Einmalnutzung, oder Pass bereits benutzt	Pass passend zur Richtlinie erzeugen
Passwortlose Registrierung nach dem Pass scheitert	Einmal-Pass, aber mehr als zehn Minuten seit der Anmeldung	Mehrfach-Pass für die Geräteeinrichtung oder zweiten Pass ausgeben
New-MgUser lehnt den UPN ab	Domain nicht verifiziert oder unzulässige Zeichen	Verifizierte Domain, Alias ohne Umlaute
Authorization_RequestDenied	Scope oder Rolle fehlt; bei App-only fehlt die Anwendungsberechtigung oder die Zustimmung	Find-MgGraphCommand, erneut verbinden, Berechtigung mit Admin-Zustimmung ergänzen
Postfach fehlt nach der Lizenz	Bereitstellung läuft, typischerweise unter 30 Minuten, bis zu 24 Stunden	Warten, Exchange-Schritte in den zweiten Lauf legen
Teams-Mitgliedschaft nicht sichtbar	Add-TeamUser wirkt im Client erst nach 24 bis 48 Stunden	Warten, keine Wiederholungsschleife
Hybrid: Konto erscheint verspätet in Entra	Entra Connect Sync läuft alle 30 Minuten	Start-ADSyncSyncCycle -PolicyType Delta
Autopilot-Zuweisung ohne Wirkung	Nutzer noch nicht Intune-lizenziert, oder AD FS im Einsatz	Lizenzverarbeitung abwarten; mit AD FS nicht unterstützt
Power Automate: „does not have a service plan adequate for the non-Standard connection”	Premium-Connector ohne Premium-Lizenz	Lizenz beschaffen oder Flow auf Standard-Connectoren umbauen
Entra-ID-Connector schlägt fehl	Conditional Access mit MFA auf dem Verbindungskonto	Laut Microsoft funktioniert der Connector dann „nicht wie erwartet”; Verbindungskonto gesondert behandeln
Managed Identity bekommt trotz Rolle 403	Token-Cache, Rollenänderungen greifen verzögert	Warten, Runbook neu starten

Sicherheit: Rollen, App-Registrierung, Managed Identity

Ein Onboarding-Skript besitzt zwangsläufig weitreichende Rechte, deshalb entscheidet der Betrieb über die Sicherheit. Drei Stufen, von einfach bis robust:

Delegiert, interaktiv. Der Administrator meldet sich beim Ausführen an, Rechte kommen aus seiner Rolle. Für das gelegentliche Onboarding völlig ausreichend, solange die Rolle nach der Tabelle oben zugeschnitten ist. Microsoft empfiehlt zusätzlich eine eigene App-Registrierung statt der Standard-App des SDK, bei der „Assignment required” aktiv ist, damit nur zugewiesene Personen sie nutzen können: Connect-MgGraph -ClientId <AppId> -TenantId <TenantId>.

App-only mit Zertifikat. Für Läufe ohne Anmeldedialog bekommt eine App-Registrierung Anwendungsberechtigungen mit Admin-Zustimmung, und das Skript verbindet sich mit Connect-MgGraph -ClientId <AppId> -TenantId <TenantId> -CertificateThumbprint <Thumbprint>; Get-MgContext zeigt dann AuthType : AppOnly. Ein selbstsigniertes Zertifikat genügt, ein Client Secret im Skript nicht — es gehört, wenn überhaupt, in Azure Key Vault und wird mit Get-AzKeyVaultSecret zur Laufzeit gelesen.

Managed Identity in Azure Automation. Die robusteste Variante verzichtet ganz auf Secrets und Zertifikate: Das Runbook läuft unter einer systemzugewiesenen verwalteten Identität und verbindet sich mit Connect-MgGraph -Identity. Die Graph-Berechtigungen bekommt die Identität per App-Rollen-Zuweisung an den Graph-Service-Principal (New-MgServicePrincipalAppRoleAssignment), wofür einmalig die hochprivilegierte Berechtigung AppRoleAssignment.ReadWrite.All nötig ist. Auch Exchange Online unterstützt diesen Weg mit Connect-ExchangeOnline -ManagedIdentity -Organization contoso.onmicrosoft.com, sofern der Identität die Berechtigung Exchange.ManageAsApp und eine passende Exchange-Rolle zugewiesen sind. Eine Eigenheit: Nach einer Rollenänderung liefert die Identität wegen des Token-Caches noch eine Weile 403, bis der Runbook-Neustart greift.

Offboarding als Spiegelbild

Wer das Onboarding automatisiert hat, bekommt das Offboarding fast geschenkt — mit umgekehrter Reihenfolge und zwei Besonderheiten. Die ersten drei Schritte dokumentiert Microsoft genau so; Postfach, Lizenz und Gerät haben wir in der Reihenfolge ergänzt, die sich aus den jeweiligen Microsoft-Seiten ergibt:

Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All","Group.ReadWrite.All"
$licGroup = Get-MgGroup -Filter "displayName eq 'LIC-M365-E5'"

$User = Get-MgUser -UserId "erika.mustermann@contoso.com"
Update-MgUser -UserId $User.Id -AccountEnabled:$false           # 1. Konto deaktivieren
Revoke-MgUserSignInSession -UserId $User.Id                      # 2. Sitzungen und Refresh-Tokens widerrufen
Get-MgUserRegisteredDevice -UserId $User.Id -All | ForEach-Object {
  Update-MgDevice -DeviceId $_.Id -AccountEnabled:$false         # 3. Geräte deaktivieren
}
# 4. Exchange (eigene Sitzung): Set-Mailbox -Identity $User.UserPrincipalName -Type Shared
# 5. Erst danach die Lizenz entziehen:
Remove-MgGroupMemberByRef -GroupId $licGroup.Id -DirectoryObjectId $User.Id
# 6. Intune: Retire oder Wipe, dann Autopilot-Registrierung entfernen

Die erste Besonderheit betrifft das Postfach: Vor der Umwandlung in ein gemeinsames Postfach muss das Konto noch lizenziert sein, erst danach darf die Lizenz weg; ohne Lizenz bleiben 50 GB Speicher, und das Konto darf nicht gelöscht werden, weil es das Postfach verankert. Die zweite betrifft das Gerät: Ein Intune-Retire entfernt Firmendaten und Verwaltung, widerruft aber keine Zugriffstokens — deshalb gehören Kontosperre und Revoke-MgUserSignInSession an den Anfang, vor Postfach, Lizenz und Gerät. Beim endgültigen Ausmustern folgt die Autopilot-Deregistrierung in der Reihenfolge aus dem Autopilot-Leitfaden: erst das Gerät in Intune löschen, dann die Autopilot-Registrierung, das Entra-Geräteobjekt nicht manuell anfassen. Hatte die Person eine Teams-Rufnummer, hebt der Entzug der Telefonie-Lizenz die Zuweisung auf, bei Direct Routing verschwindet die Nummer aus der Nummernverwaltung, Details im Leitfaden zur Teams-Telefonanlage. Wer die Hardware anschließend über den IT-Ankauf abgibt, hat damit alle Voraussetzungen für einen sauberen Übergang geschaffen.

Fazit

Ein automatisiertes Onboarding ist kein großes Projekt, sondern eine Kette kleiner, dokumentierter Schritte: Lizenzgruppe und TAP-Richtlinie einmal einrichten, ein Skript aus verifizierten Graph-Bausteinen, ein zweiter Lauf für Postfach und Teams, optional ein Formular mit Genehmigung davor. Das Ergebnis ist ein erster Arbeitstag, an dem die neue Kollegin ihren Laptop einschaltet, ihren Namen schon auf dem Anmeldebildschirm sieht und sich mit einem Pass anmeldet, den ihr Vorgesetzter ihr gibt — ohne Ticket, ohne Zettel, ohne Freitagnachmittag.

Lota Engineering richtet solche Abläufe für Unternehmen aus Düsseldorf und dem Rheinland ein: von der Microsoft-365-Umgebung über die Beschaffung ab Werk registrierter Geräte bis zum Helpdesk, der neue Mitarbeitende am ersten Tag begleitet. Wie sich dieser Ablauf in Ihre Prozesse einfügt, zeigt unser Anwendungsfall Onboarding automatisieren. Wenn Ihr nächster Eintritt ohne Ticket-Pingpong laufen soll: Sprechen Sie uns an.