← Alle Beiträge

Mitarbeiter-Onboarding automatisieren mit Azure Automation und Microsoft 365

02. Juni 2026
EN

Mitarbeiter-Onboarding Automatisierung - Prozessablauf

Ein neuer Mitarbeiter startet am Montag. HR hat den Antrag am Mittwoch geschickt. Die IT muss ein Active Directory Konto erstellen, ein Postfach einrichten, Microsoft 365 Lizenzen zuweisen, die Person zu den richtigen Sicherheitsgruppen und Verteilerlisten hinzufügen, Teams-Zugang konfigurieren und eine Willkommens-Mail mit temporären Zugangsdaten verschicken.

Auf dem Papier dauert das 30 Minuten. In der Praxis sind es 2-4 Stunden. Nicht weil die einzelnen Schritte schwer sind, sondern weil sie über mehrere Systeme verteilt sind, von verschiedenen Leuten bearbeitet werden und ständig von allem anderen unterbrochen werden, was die IT gerade zu tun hat.

Das Ganze mal 20 neue Mitarbeiter pro Monat. Das sind 40-80 Stunden manuelle Provisionierung. Jeden Monat. Für einen Prozess, der jedes einzelne Mal demselben Muster folgt.

Genau dafür ist Automatisierung gemacht.

Das Problem mit manuellem Onboarding

Wir haben Onboarding-Prozesse bei Dutzenden Organisationen analysiert. Der Ablauf ist überall erstaunlich ähnlich. Die Probleme auch.

Schritt-Wildwuchs. Einen einzelnen Benutzer anzulegen berührt Active Directory, Entra ID, Exchange Online, Microsoft 365 Lizenzierung, Teams, SharePoint und potenziell ein Dutzend weitere Systeme. Jeder Schritt hat sein eigenes Interface und seine eigenen Besonderheiten.

Inkonsistenz. Admin A fügt neue User zu 8 Sicherheitsgruppen hinzu. Admin B fügt sie zu 6 hinzu, weil er die anderen zwei nicht kennt. Admin C folgt der Dokumentation von 2022, die Gruppen auflistet, die es nicht mehr gibt. Drei Mitarbeiter starten in derselben Rolle mit unterschiedlichen Zugriffsrechten.

Verzögerungen. HR reicht den Antrag am Mittwoch ein. Die IT nimmt ihn Donnerstag Nachmittag auf. Es gibt eine Rückfrage zum Abteilungscode. HR antwortet Freitag Vormittag. Die IT schließt die Provisionierung Freitag Nachmittag ab. Der Mitarbeiter erscheint Montag zu einem halb konfigurierten Laptop ohne E-Mail-Zugang.

Kein Audit Trail. Wer hat diesen User provisioniert? Wann? Wurden alle Schritte abgeschlossen? Wenn drei Monate später etwas schiefgeht: Viel Erfolg dabei zu rekonstruieren, was beim Onboarding passiert ist.

Fehlerbehandlung. Schritt 5 von 7 schlägt fehl. Der User existiert im AD, hat aber keine Lizenz und kein Postfach. Jemand muss herausfinden, wo es aufgehört hat, und dort weitermachen. Oder von vorne anfangen und hoffen.

Die automatisierte Lösung

Der automatisierte Onboarding-Flow ersetzt manuelle Schritte durch ein einziges Azure Automation Runbook, das alles übernimmt. Der Auslöser kann ein ServiceNow-Request sein, eine Formular-Eingabe, ein Genehmigungsworkflow oder sogar ein geplanter Abruf aus dem HR-System.

Der grobe Ablauf:

HR stellt Antrag → Vorgesetzter genehmigt → Runbook führt aus → User ist vollständig provisioniert → Willkommens-Mail versendet → IT-Ticket aktualisiert

Der gesamte Prozess dauert unter 5 Minuten. Kein manueller Eingriff, solange die Genehmigung nicht aussteht.

Die Architektur

Zwei Komponenten machen das möglich:

Hybrid Runbook Worker übernimmt On-Premises Active Directory Operationen. AD-User anlegen, Attribute setzen, zu On-Prem-Sicherheitsgruppen hinzufügen und Entra ID Connect Sync auslösen. Der Hybrid Worker sitzt im Unternehmensnetzwerk mit Zugriff auf die Domain Controller.

Azure Automation Sandbox (oder derselbe Hybrid Worker) übernimmt Cloud-Operationen. Microsoft 365 Lizenzierung, Exchange Online Konfiguration, Teams-Provisionierung und Versand der Willkommens-Mail via Microsoft Graph.

Authentifizierung nutzt Managed Identity für Azure und Microsoft Graph Ressourcen. Für On-Premises AD läuft der Hybrid Worker unter einem Service Account mit delegierten OU-Berechtigungen.

→ Details zur sicheren Architektur: Sichere Azure Automation Architektur

Was das Runbook tut: Schritt für Schritt

Schritt 1: Active Directory / Entra ID User anlegen

Das Runbook erhält Eingangsparameter: Vorname, Nachname, Abteilung, Jobtitel, Bürostandort, Vorgesetzter und Startdatum.

Es generiert den Account anhand von Namenskonventionen:

# Benutzername generieren: vorname.nachname (Duplikate behandeln)
$samAccount = "$($Vorname.ToLower()).$($Nachname.ToLower())"
$upn = "$samAccount@contoso.com"

# Auf Duplikate prüfen
$existing = Get-ADUser -Filter "SamAccountName -eq '$samAccount'" -ErrorAction SilentlyContinue
if ($existing) {
    $samAccount = "$($Vorname.ToLower()).$($Nachname.ToLower())$counter"
    $upn = "$samAccount@contoso.com"
}

# AD-User in der richtigen OU anlegen basierend auf Abteilung
$ou = Get-DepartmentOU -Department $Abteilung
New-ADUser -Name "$Vorname $Nachname" `
    -GivenName $Vorname `
    -Surname $Nachname `
    -SamAccountName $samAccount `
    -UserPrincipalName $upn `
    -Path $ou `
    -Department $Abteilung `
    -Title $Jobtitel `
    -Office $Standort `
    -Manager (Get-ADUser -Filter "UserPrincipalName -eq '$VorgesetzterUPN'") `
    -AccountPassword (ConvertTo-SecureString $tempPassword -AsPlainText -Force) `
    -ChangePasswordAtLogon $true `
    -Enabled $true

Die OU-Platzierung ist wichtig. Viele Organisationen strukturieren ihr AD nach Abteilung oder Standort. Wenn das stimmt, greifen Gruppenrichtlinien ab dem ersten Tag korrekt.

Nach dem Anlegen des On-Prem Users löst das Runbook einen Entra ID Connect Delta Sync aus:

# Delta Sync auf dem Entra ID Connect Server auslösen
Invoke-Command -ComputerName "AADConnectServer" -ScriptBlock {
    Start-ADSyncSyncCycle -PolicyType Delta
}
# Auf Sync-Abschluss warten
Start-Sleep -Seconds 60

Schritt 2: Microsoft 365 Lizenz zuweisen

Sobald der User in Entra ID existiert, weist das Runbook die passende Lizenz basierend auf Abteilung und Rolle zu:

# Mit Microsoft Graph verbinden
Connect-MgGraph -Identity

# Lizenz-SKU basierend auf Abteilung bestimmen
$licenseSku = switch ($Abteilung) {
    "Engineering"  { "ENTERPRISEPACK" }      # E3
    "Management"   { "SPE_E5" }              # E5
    "Vertrieb"     { "SPB" }                 # Business Premium
    default        { "ENTERPRISEPACK" }      # E3 als Standard
}

# Lizenz zuweisen
$skuId = (Get-MgSubscribedSku | Where-Object SkuPartNumber -eq $licenseSku).SkuId
Set-MgUserLicense -UserId $upn -AddLicenses @(@{SkuId = $skuId}) -RemoveLicenses @()

Die Lizenzzuweisung löst automatisch die Exchange Online Postfach-Provisionierung aus. Das dauert aber ein paar Minuten. Das Runbook enthält eine Warte-und-Prüf-Schleife.

Schritt 3: Exchange Online Postfach konfigurieren

Sobald das Postfach existiert, konfiguriert es das Runbook:

# Auf Postfach-Provisionierung warten
$versuche = 0
do {
    $mailbox = Get-EXOMailbox -Identity $upn -ErrorAction SilentlyContinue
    if (-not $mailbox) {
        Start-Sleep -Seconds 30
        $versuche++
    }
} while (-not $mailbox -and $versuche -lt 10)

# Postfach-Eigenschaften setzen
Set-Mailbox -Identity $upn -RetentionPolicy "Standard Retention" -AuditEnabled $true

# Zu Verteilerlisten basierend auf Abteilung hinzufügen
$vls = Get-DepartmentDistributionLists -Department $Abteilung
foreach ($vl in $vls) {
    Add-DistributionGroupMember -Identity $vl -Member $upn
}

Schritt 4: Zu Sicherheitsgruppen hinzufügen

Gruppenmitgliedschaft bestimmt, worauf der User zugreifen kann. Das Runbook mappt Abteilungen und Rollen auf Sicherheitsgruppen:

# Basisgruppen für alle Mitarbeiter
$basisGruppen = @("Alle-Mitarbeiter", "VPN-Users", "Intranet-Zugang")

# Abteilungsspezifische Gruppen
$abtGruppen = Get-DepartmentSecurityGroups -Department $Abteilung

# Rollenspezifische Gruppen
$rollenGruppen = Get-RoleSecurityGroups -JobTitle $Jobtitel

# Zu allen Gruppen hinzufügen
foreach ($gruppe in ($basisGruppen + $abtGruppen + $rollenGruppen)) {
    Add-ADGroupMember -Identity $gruppe -Members $samAccount
}

Hier zahlt sich eine Mapping-Tabelle aus. Wir implementieren das typischerweise als JSON- oder CSV-Datei, die Abteilungs-/Rollenkombinationen auf Gruppenlisten abbildet. Wenn eine neue Gruppe hinzukommen muss, wird die Mapping-Datei aktualisiert statt des Runbook-Codes.

Schritt 5: Teams-Zugang konfigurieren

Das Runbook fügt den User zu relevanten Teams basierend auf seiner Abteilung hinzu:

# Zum Abteilungs-Team hinzufügen
$teamId = Get-DepartmentTeamId -Department $Abteilung
Add-MgTeamMember -TeamId $teamId -Roles @() -AdditionalProperties @{
    "@odata.type" = "#microsoft.graph.aadUserConversationMember"
    "user@odata.bind" = "https://graph.microsoft.com/v1.0/users('$userId')"
}

# Zu unternehmensweiten Teams hinzufügen
$firmenTeams = @("Unternehmens-Ankuendigungen", "IT-Support")
foreach ($team in $firmenTeams) {
    $tId = (Get-MgGroup -Filter "displayName eq '$team'" -Property Id).Id
    Add-MgTeamMember -TeamId $tId -Roles @() -AdditionalProperties @{
        "@odata.type" = "#microsoft.graph.aadUserConversationMember"
        "user@odata.bind" = "https://graph.microsoft.com/v1.0/users('$userId')"
    }
}

Schritt 6: Willkommens-Mail versenden

Das Runbook sendet eine Willkommens-Mail mit dem temporären Passwort und Einstiegsinformationen. Diese geht an die private E-Mail des Mitarbeiters (von HR bereitgestellt), da das Firmen-Postfach brandneu ist:

$willkommensText = @"
<h2>Willkommen bei Contoso, $Vorname!</h2>
<p>Ihr Konto wurde eingerichtet. Hier ist alles was Sie für den Start brauchen:</p>
<ul>
    <li><strong>Benutzername:</strong> $upn</li>
    <li><strong>Temporäres Passwort:</strong> $tempPassword</li>
    <li><strong>Portal:</strong> https://portal.office.com</li>
</ul>
<p>Bei der ersten Anmeldung werden Sie aufgefordert, Ihr Passwort zu ändern.</p>
<p>Bei Fragen wenden Sie sich an den IT-Support: support@contoso.com</p>
"@

# Versand via Microsoft Graph
$params = @{
    Message = @{
        Subject = "Willkommen bei Contoso - Ihre Zugangsdaten"
        Body = @{ ContentType = "HTML"; Content = $willkommensText }
        ToRecipients = @(@{ EmailAddress = @{ Address = $PrivateEmail } })
    }
}
Send-MgUserMail -UserId "noreply@contoso.com" -BodyParameter $params

Schritt 7: Alles protokollieren

Jeder Schritt erzeugt einen strukturierten Log-Eintrag. Das Runbook trackt Erfolg, Fehler und Timing für jede Operation:

$log = @{
    Zeitstempel = Get-Date -Format "yyyy-MM-ddTHH:mm:ssZ"
    Mitarbeiter = "$Vorname $Nachname"
    UPN = $upn
    Schritte = @(
        @{ Schritt = "AD User erstellt"; Status = "Erfolg"; Dauer = "2,3s" }
        @{ Schritt = "Lizenz zugewiesen"; Status = "Erfolg"; Dauer = "1,1s" }
        @{ Schritt = "Postfach konfiguriert"; Status = "Erfolg"; Dauer = "45,2s" }
        @{ Schritt = "Gruppen hinzugefügt"; Status = "Erfolg"; Dauer = "3,7s" }
        @{ Schritt = "Teams konfiguriert"; Status = "Erfolg"; Dauer = "5,1s" }
        @{ Schritt = "Willkommens-Mail gesendet"; Status = "Erfolg"; Dauer = "0,8s" }
    )
    Gesamtdauer = "58,2s"
}

$log | ConvertTo-Json -Depth 3 | Write-Output

Dieses Log fließt in Log Analytics für Dashboards und Compliance-Reporting. Wenn ein Auditor fragt „zeigen Sie mir jedes Konto, das in Q1 erstellt wurde,“ sind die Daten da.

Integration mit Genehmigungsworkflows

Nicht jeder Onboarding-Antrag sollte automatisch ausgeführt werden. Die meisten Organisationen wollen einen Genehmigungsschritt durch den Vorgesetzten.

Option 1: ServiceNow oder ITSM-Integration. HR erstellt einen Request in ServiceNow. Der Vorgesetzte genehmigt. Ein ServiceNow-Workflow ruft das Azure Automation Runbook via Webhook oder REST API auf. Das Runbook-Ergebnis aktualisiert das ServiceNow-Ticket.

Option 2: Power Automate. HR füllt ein Microsoft Form aus. Power Automate sendet eine Genehmigungsanfrage an den Vorgesetzten. Nach Genehmigung wird das Azure Automation Runbook ausgelöst. Einfach, Low-Code, und nutzt Tools die bereits im Microsoft 365 Stack vorhanden sind.

Option 3: Custom Portal. Für Organisationen mit spezifischen Anforderungen: Ein eigenes Web-Portal (gehostet als Azure App Service oder Static Web App) sammelt die Onboarding-Daten, steuert Genehmigungen und löst das Runbook aus. Mehr Aufwand beim Bau, aber maximale Flexibilität.

Option 1 sehen wir am häufigsten in Unternehmen mit etablierten ITSM-Prozessen. Option 2 funktioniert gut für mittelständische Unternehmen, die bereits in Power Platform investiert haben.

→ ServiceNow-Daten sauber halten: ServiceNow Foundation Data automatisch synchronisieren

Die Zahlen

Hier ist, was sich durch Onboarding-Automatisierung ändert. Diese Zahlen stammen aus echten Implementierungen:

Vor der Automatisierung:

Nach der Automatisierung:

Das sind 36-76 Stunden pro Monat, die der IT zurückgegeben werden. Für ein IT-Team von fünf Personen entspricht das grob einer vollen Stelle, die für Arbeit frei wird, die tatsächlich menschliches Urteilsvermögen erfordert.

Die Fehlerreduktion wiegt schwerer als die Zeitersparnis. Jedes falsch provisionierte Konto ist ein Sicherheitsrisiko (zu viel Zugriff) oder ein Produktivitätshemmnis (zu wenig Zugriff). Beides erzeugt Support-Tickets. Beides untergräbt das Vertrauen in die IT.

Sonderfälle behandeln

Automatisierung deckt den 80%-Fall brillant ab. Die restlichen 20% brauchen konzeptionelle Überlegung.

Externe und temporäre Mitarbeiter. Andere Lizenzstufe, zeitlich begrenzte Konten, eingeschränkter Gruppenzugang. Das Runbook akzeptiert einen „Benutzertyp“-Parameter, der die Provisionierungslogik anpasst. Konten für Externe bekommen ein Ablaufdatum im AD und eine Kalender-Erinnerung zur Überprüfung.

Versetzungen und Rollenwechsel. Kein Neuzugang, aber Gruppen und Lizenzen müssen aktualisiert werden. Ein separates „Rollenwechsel“-Runbook passt Gruppenmitgliedschaften und Lizenzierung basierend auf der neuen Abteilung/Rolle an. Es entfernt alte Abteilungsgruppen und fügt neue hinzu.

Vorab-Einrichtung für zukünftige Starttermine. HR reicht den Antrag zwei Wochen vorher ein. Das Runbook erstellt den Account, lässt ihn aber deaktiviert bis zum Startdatum. Ein geplantes Runbook prüft täglich, ob Konten existieren, deren Startdatum erreicht ist, und aktiviert sie.

Internationale Standorte. Andere Namenskonventionen, andere Lizenzpools, andere Compliance-Anforderungen. Alles parametrisieren. Das Runbook liest standortspezifische Konfiguration aus einer Mapping-Datei, nicht aus hartcodierter Logik.

Sicherheitsüberlegungen

Onboarding-Automatisierung handhabt sensible Operationen. Security muss von Anfang an mitgedacht werden.

→ Alles zur sicheren Automation-Architektur: Azure Automation Security Best Practices

Schrittweiser Einstieg

Man muss nicht alles auf einmal automatisieren. Mit dem Teil starten, der das höchste Volumen hat und am stärksten standardisiert ist.

Phase 1 (Woche 1-2): AD-User-Erstellung, Lizenzzuweisung und Basis-Gruppenmitgliedschaft automatisieren. Das deckt die zeitaufwändigsten manuellen Schritte ab.

Phase 2 (Woche 3-4): Exchange-Konfiguration, Teams-Provisionierung und Willkommens-Mail ergänzen. Jetzt ist der User am ersten Tag voll arbeitsfähig.

Phase 3 (Woche 5-6): Mit dem Antrags-/Genehmigungssystem integrieren (ServiceNow, Power Automate oder Custom). Compliance-Logging und Dashboard hinzufügen.

Phase 4 (laufend): Sonderfälle behandeln. Externe, Versetzungen, Offboarding (der umgekehrte Prozess). Gruppen-Mapping verfeinern, wenn sich die Organisation weiterentwickelt.

Jede Phase liefert eigenständigen Mehrwert. Man braucht nicht die komplette Pipeline, bevor man Zeit spart.

FAQ

Was passiert wenn ein Schritt im Runbook fehlschlägt?

Das Runbook nutzt Try/Catch bei jedem Schritt. Wenn Schritt 3 von 7 fehlschlägt, wird der Fehler geloggt, bereits abgeschlossene Schritte wo möglich zurückgerollt (z.B. erstelltes Konto deaktiviert) und ein Alert an die IT gesendet mit genauer Angabe, was fehlgeschlagen ist und was bereits erledigt war. Keine halb provisionierten User, die unbemerkt bleiben.

Funktioniert das auch mit On-Premises Exchange statt Exchange Online?

Ja. Der Hybrid Runbook Worker kann Exchange Management Shell Befehle gegen On-Premises Exchange Server ausführen. Die Runbook-Logik ist ähnlich, nur andere Cmdlets. Wir haben hybride Szenarien implementiert, in denen manche Postfächer On-Prem und manche in Exchange Online liegen.

Wie handhabt man unterschiedliche Provisionierungsregeln pro Abteilung?

Eine Konfigurationsdatei (JSON oder CSV) mappt Abteilungen auf Lizenz-SKUs, Sicherheitsgruppen, Teams, Verteilerlisten und OU-Pfade. Wenn eine Abteilung ihre Anforderungen ändert: Config-Datei aktualisieren und in Source Control committen. Das Runbook liest die Config zur Laufzeit. Für die meisten Policy-Updates sind keine Code-Änderungen nötig.

Was ist mit Offboarding?

Offboarding ist das Spiegelbild. Ein separates Runbook deaktiviert das Konto, entfernt Lizenzen, wandelt das Postfach in ein Shared Mailbox um, entfernt Gruppenmitgliedschaften und archiviert Daten. Das ist tatsächlich einfacher zu automatisieren, weil weniger Entscheidungen zu treffen sind. Wir implementieren meist zuerst Onboarding und ergänzen Offboarding in der nächsten Phase.

Wie lässt sich das mit HR-Systemen wie SAP SuccessFactors oder Workday integrieren?

Beide Systeme stellen APIs bereit. Azure Automation Runbooks können diese APIs nach neuen Mitarbeiterdatensätzen abfragen, die relevanten Attribute extrahieren und den Onboarding-Flow auslösen. Das eliminiert sogar den manuellen Antragsschritt: HR erfasst den neuen Mitarbeiter im HR-System, und alles Weitere passiert automatisch.

Bereit, Stunden an manuellem Onboarding einzusparen? Wir konzipieren und implementieren automatisierte Onboarding-Lösungen mit Azure Automation und Microsoft 365. Von der initialen Architektur bis zum Go-Live übernehmen wir das gesamte Projekt.

Sprechen wir über Ihre Onboarding-Automatisierung.