Sektion 15: First-Day Checklist — Tenant Health Check im Microsoft Intune

## Einleitung

Wenn du einen neuen Intune-Tenant übernimmst — sei es durch Kundenakquise, internes Re-Design oder Migration von einem Legacy-System — ist der erste Tag entscheidend. Ein ungeprüfter Tenant ist wie ein Auto mit unbekannter Wartungshistorie: Du weißt nicht, ob die Bremsen funktionieren, bis du sie im Ernstfall brauchst.

Diese Sektion liefert dir eine vollständige, technisch fundierte Checkliste für den ersten Tag. Kein Marketing-Geschwafel, keine „5-Minuten-Tipps“. Stattdessen: Konkrete PowerShell-Befehle, Graph-API-Endpoints und reale Szenarien aus der Praxis.

—

## Phase 1: Tenant-Basisvalidierung (0-30 Minuten)

### 1.1 Tenant-Status und Lizenzierung prüfen

Bevor du irgendetwas konfigurierst, musst du wissen, mit was du arbeitest. Viele Admins überspringen diesen Schritt und wundern sich später, warum bestimmte Features nicht verfügbar sind.

**Graph API Call:**
„`http
GET https://graph.microsoft.com/v1.0/organization
„`

**PowerShell (Microsoft.Graph.Module):**
„`powershell
Connect-MgGraph -Scopes „Organization.Read.All“
Get-MgOrganization | Select-Object DisplayName, VerifiedDomains, MarketingNotificationEmails
„`

**Was du prüfen musst:**
– **Tenant-ID** dokumentieren (für alle zukünftigen Skripte)
– **Verifizierte Domains** — welche Domains sind aktiv? Welche ist default?
– **Lizenz-SKUs** — welche Intune-Lizenzen sind vorhanden? (Intune Plan 1 vs. Plan 2 vs. EMS E3/E5)

**Lizenz-Check:**
„`powershell
Connect-MgGraph -Scopes „Directory.Read.All“
Get-MgSubscribedSku | Select-Object SkuPartNumber, PrepaidUnits, ConsumedUnits
„`

**Reale Fallstricke:**
– Kunde hat nur **Intune Plan 1** → Autopilot Self-Deploying nicht verfügbar
– Kunde hat **EMS E3** aber keine **Intune-Lizenz** explizit zugewiesen → Geräte können nicht enrolled werden
– **Trial-Tenant** mit 25 Usern → Plötzlich blockiert Enrollment nach 30 Tagen

—

### 1.2 RBAC-Struktur analysieren

Die RBAC-Konfiguration (Role-Based Access Control) ist einer der häufigsten Schwachpunkte in Intune-Tenants.

**PowerShell:**
„`powershell
Connect-MgGraph -Scopes „DeviceManagementRBAC.Read.All“
Get-MgDeviceManagementRoleDefinition | Select-Object DisplayName, Description, IsBuiltIn, RolePermissions
„`

**Was du suchst:**
1. **Custom Roles** — Gibt es selbst erstellte Rollen? Warum?
2. **Scope Tags** — Sind diese korrekt konfiguriert für Multi-Site-Umgebungen?
3. **Admin-Zuweisungen** — Wer hat Global Admin? Wer hat Intune Admin?

**Best Practice:**
– Global Admin sollte maximal 2-3 Personen haben
– Intune Administrator für tägliche Operationen
– Helpdesk Operator mit eingeschränkten Rechten (nur Reset PIN, View Devices)
– **Scope Tags** für Mandantenfähigkeit nutzen (z.B. „Germany“, „Austria“, „Switzerland“)

**Red Flags:**
– Mehr als 5 Global Admins → Sofort aufräumen
– Custom Role mit allen Berechtigungen → Warum nicht Built-in nutzen?
– Keine Scope Tags in Multi-National-Umgebung → Risk of cross-border data access

—

## Phase 2: Device Compliance & Configuration (30-90 Minuten)

### 2.1 Compliance Policies Bestandsaufnahme

Compliance Policies sind das Herzstück von Conditional Access. Wenn diese falsch konfiguriert sind, blockierst du entweder alle User oder du hast ein Sicherheitsloch.

**PowerShell:**
„`powershell
Connect-MgGraph -Scopes „DeviceManagementConfiguration.Read.All“
Get-MgDeviceManagementDeviceCompliancePolicy | Select-Object DisplayName, Description, CreatedDateTime, LastModifiedDateTime
„`

**Checkliste pro Policy:**
– **BitLocker-Verschlüsselung** — Required oder Optional? (Required für Finance/HR)
– **Mindest-Build-Version** — Realistisch für den Kunden? (Windows 10 21H2 vs. 22H2)
– **Antivirus-Status** — Defender required? Third-Party erlaubt?
– **Passwort-Anforderungen** — Komplexität, Länge, Biometrie
– **Jailbreak/Root-Erkennung** — Aktiv für iOS/Android?

**Reales Szenario:**
Ein Kunde hatte eine Compliance Policy mit „BitLocker Required“. Problem: 300 Geräte hatten TPM 1.2 und konnten kein modernes BitLocker. Ergebnis: 300 Geräte non-compliant, User konnten nicht auf Outlook zugreifen (Conditional Access Block).

**Lösung:**
„`powershell
# Compliance Policy für BitLocker mit TPM 2.0 Ausnahme
$complianceParams = @(
„@OData.Type“ = „#microsoft.graph.deviceCompliancePolicySettingStateSummary“
SettingInstance = @(
@{
„@OData.Type“ = „#microsoft.graph.deviceComplianceScriptSettingStateSummary“
SettingDefinitionId = „require_bitlocker“
SettingInstance = @{
„@OData.Type“ = „#microsoft.graph.deviceComplianceScriptSettingStateSummary“
RequireBitLocker = $true
AllowTPM12 = $true # Ausnahme für ältere Hardware
}
}
)
)
„`

—

### 2.2 Configuration Profiles auditieren

Configuration Profiles sind mächtig, aber gefährlich. Ein falscher Wert und du hast 500 Geräte im Boot-Loop.

**PowerShell:**
„`powershell
Connect-MgGraph -Scopes „DeviceManagementConfiguration.Read.All“
Get-MgDeviceManagementDeviceConfiguration | Select-Object DisplayName, Description, Platforms, CreatedDateTime
„`

**Kritische Profile die du prüfen musst:**

**1. Windows Update for Business (WUfB)**
„`powershell
Get-MgDeviceManagementDeviceConfiguration | Where-Object { $_.DisplayName -like „*Update*“ } | Select-Object DisplayName, Description
„`
– **Deferral-Periods** — Maximal 30 Tage für Feature Updates
– **Active Hours** — 08:00-18:00 oder dynamisch?
– **Restart-Warnung** — Mindestens 4 Stunden Vorlauf

**2. BitLocker-Profil**
„`powershell
Get-MgDeviceManagementDeviceConfiguration | Where-Object { $_.DisplayName -like „*BitLocker*“ }
„`
– **Encryption Method** — XTS-AES-128 oder 256? (256 für Hochsicherheit)
– **Recovery Key Storage** — Nur Azure AD oder auch AD DS?
– **TPM-Requirement** — TPM 2.0 required? Was mit TPM 1.2 Geräten?

**3. Endpoint Protection (Defender)**
„`powershell
Get-MgDeviceManagementDeviceConfiguration | Where-Object { $_.DisplayName -like „*Defender*“ }
„`
– **Real-Time Protection** — Muss ON sein
– **Cloud Protection** — Enabled für schnelle Signatures
– **Scan-Schedule** — Täglich oder wöchentlich?
– **Exclusions** — Gibt es zu viele? (jede Exclusion ist ein Risiko)

**Red Flag Check:**
„`powershell
# Suche nach Profiles ohne Beschreibung
Get-MgDeviceManagementDeviceConfiguration | Where-Object { [string]::IsNullOrWhiteSpace($_.Description) } | Select-Object DisplayName, CreatedDateTime
„`
Profiles ohne Beschreibung sind ein Zeichen für schlechte Dokumentation. Sofort nachtragen oder löschen.

—

## Phase 3: Application Management (90-120 Minuten)

### 3.1 App-Inventory erstellen

Du musst wissen, welche Apps deployed sind, bevor du neue hinzufügst.

**PowerShell:**
„`powershell
Connect-MgGraph -Scopes „DeviceManagementApps.Read.All“
Get-MgDeviceAppManagementMobileApp | Select-Object DisplayName, Publisher, Category, IsAssigned, CreatedDateTime
„`

**Kategorisierung:**
– **Required Apps** — Müssen auf jedem Gerät sein (Office, Defender, Browser)
– **Available Apps** — User kann im Company Portal installieren (7-Zip, VLC, etc.)
– **Uninstall Apps** — Apps die entfernt werden sollen (Adobe Reader, Java 8)

**Reales Problem:**
Ein Kunde hatte 47 Versionen von „Microsoft Office“ im Tenant. Warum? Jede Migration, jeder Test hat neue Einträge erstellt. Ergebnis: Conflicted Apps, User wussten nicht welche Version sie installieren sollen.

**Cleanup-Skript:**
„`powershell
# Finde duplizierte Apps
$apps = Get-MgDeviceAppManagementMobileApp
$duplicates = $apps | Group-Object DisplayName | Where-Object { $_.Count -gt 1 }

$duplicates | ForEach-Object {
Write-Host „Duplicate found: $($_.Name)“ -ForegroundColor Yellow
$_.Group | Select-Object DisplayName, Id, CreatedDateTime
}
„`

—

### 3.2 App-Assignments prüfen

Eine App zu deployen ist einfach. Die richtige App zur richtigen Zeit am richtigen Gerät zu deployen ist Kunst.

**PowerShell:**
„`powershell
# Alle Assignments für eine App
$appId = „“
Get-MgDeviceAppManagementMobileAppAssignment -MobileAppId $appId | Select-Object Target, Intent, CreatedDateTime
„`

**Assignment-Typen:**
– **Required** — App wird automatisch installiert (nur für kritische Apps)
– **Available** — User sieht sie im Company Portal
– **Uninstall** — App wird entfernt

**Best Practice:**
– **Required** nur für Security-Apps (Defender, ZScaler, etc.)
– **Available** für Productivity-Apps (Office, Teams, etc.)
– **Groups** dynamisch nutzen (z.B. „All-Windows-11-Devices“)
– **Exclusions** dokumentieren (warum ist Gruppe X ausgeschlossen?)

**Conditional Access Check:**
„`powershell
Connect-MgGraph -Scopes „Policy.Read.All“
Get-MgIdentityConditionalAccessPolicy | Where-Object { $_.State -eq „Enabled“ } | Select-Object DisplayName, State, Conditions
„`
– Gibt es eine Policy die „Approved App“ erfordert?
– Welche Apps sind als „Approved“ markiert?
– Blockiert die Policy Legacy Authentication?

—

## Phase 4: Security & Compliance Deep-Dive (120-150 Minuten)

### 4.1 Conditional Access Policies analysieren

Conditional Access (CA) ist deine letzte Verteidigungslinie. Fehler hier bedeuten entweder Security-Gap oder Total-Ausfall.

**PowerShell:**
„`powershell
Connect-MgGraph -Scopes „Policy.Read.All“
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State, Conditions, GrantControls
„`

**Kritische Policies die existieren MÜSSEN:**

**1. MFA für alle User**
„`json
{
„displayName“: „Require MFA for all users“,
„state“: „enabled“,
„conditions“: {
„users“: { „includeUsers“: [„All“] },
„applications“: { „includeApplications“: [„All“] }
},
„grantControls“: {
„operator“: „OR“,
„builtInControls“: [„mfa“]
}
}
„`

**2. Block Legacy Authentication**
„`json
{
„displayName“: „Block Legacy Authentication“,
„state“: „enabled“,
„conditions“: {
„clientAppTypes“: [„exchangeActiveSync“, „other“],
„applications“: { „includeApplications“: [„All“] }
},
„grantControls“: {
„operator“: „OR“,
„builtInControls“: [„block“]
}
}
„`

**3. Require Compliant Device**
„`json
{
„displayName“: „Require Intune Compliant Device“,
„state“: „enabled“,
„conditions“: {
„users“: { „includeUsers“: [„All“] },
„applications“: { „includeApplications“: [„Office365“] }
},
„grantControls“: {
„operator“: „OR“,
„builtInControls“: [„compliantDevice“]
}
}
„`

**What-If Tool nutzen:**
Bevor du Policies änderst, nutze das CA What-If Tool:
„`
https://portal.azure.com/#blade/Microsoft_AAD_IAM/ConditionalAccessBlade/Policies
„`
Teste mit einem Test-User bevor du die Policy auf „All“ setzt.

—

### 4.2 Intune Protect (Endpoint Security) Status

Endpoint Security ist der moderne Weg in Intune. Viele Tenants haben noch alte Configuration Profiles die migriert werden müssen.

**PowerShell:**
„`powershell
Connect-MgGraph -Scopes „DeviceManagementConfiguration.Read.All“

# Antivirus Policies
Get-MgDeviceManagementIntent | Where-Object { $_.DisplayName -like „*Antivirus*“ }

# Attack Surface Reduction
Get-MgDeviceManagementIntent | Where-Object { $_.DisplayName -like „*ASR*“ }

# Disk Encryption
Get-MgDeviceManagementIntent | Where-Object { $_.DisplayName -like „*Encryption*“ }

# Firewall
Get-MgDeviceManagementIntent | Where-Object { $_.DisplayName -like „*Firewall*“ }
„`

**Migration von Config Profiles zu Intents:**
„`powershell
# Check welche alten Profiles noch existieren
$oldProfiles = Get-MgDeviceManagementDeviceConfiguration | Where-Object {
$_.AdditionalProperties[„@odata.type“] -like „*endpointProtection*“
}

if ($oldProfiles.Count -gt 0) {
Write-Warning „Found $($oldProfiles.Count) legacy Endpoint Protection profiles“
Write-Host „Consider migrating to Intune Intents for better management“
}
„`

—

## Phase 5: Reporting & Monitoring Setup (150-180 Minuten)

### 5.1 Intune Reporting Baseline

Ohne Reporting fliegst du blind. Richte am ersten Tag die grundlegenden Reports ein.

**Wichtige Report-Kategorien:**
1. **Device Compliance** — Wie viele Geräte sind compliant?
2. **App Protection** — Welche Apps sind wo installiert?
3. **Security Baselines** — Welche Baselines sind deployed?
4. **Tenant Health** — Gibt es kritische Alerts?

**PowerShell für Compliance-Report:**
„`powershell
Connect-MgGraph -Scopes „DeviceManagementConfiguration.Read.All“

# Compliance Status pro Policy
$policies = Get-MgDeviceManagementDeviceCompliancePolicy
foreach ($policy in $policies) {
$settings = Get-MgDeviceManagementDeviceCompliancePolicySettingStateSummary -DeviceCompliancePolicyId $policy.Id
Write-Host „Policy: $($policy.DisplayName)“
Write-Host “ Compliant: $($settings.DeviceCount)“
Write-Host “ Non-Compliant: $($settings.NonCompliantDeviceCount)“
Write-Host “ Error: $($settings.ErrorDeviceCount)“
}
„`

**Graph API für Device Status:**
„`http
GET https://graph.microsoft.com/v1.0/deviceManagement/managedDevices?$select=deviceName,complianceState,lastSyncDateTime,operatingSystem
„`

—

### 5.2 Alerting konfigurieren

Intune kann Alerts senden, aber die Standard-Konfiguration ist oft unzureichend.

**Graph API für Alert Settings:**
„`http
GET https://graph.microsoft.com/v1.0/deviceManagement/monitoringSettings
„`

**Empfohlene Alerts:**
– **Device Compliance Drop** — Wenn Compliance unter 90% fällt
– **App Deployment Failure** — Wenn mehr als 10% der Deployments fehlschlagen
– **Certificate Expiry** — 30 Tage vor Ablauf
– **Enrollment Failure** — Wenn Enrollment-Rate unter 95% fällt

**PowerShell für Alert-Setup:**
„`powershell
# Monitoring Settings prüfen
$monitoring = Get-MgDeviceManagementMonitoringSetting
if ($monitoring.SendEmailNotificationForDeviceCompliancePolicy -eq $false) {
Write-Warning „Email Notifications für Compliance sind deaktiviert“
}
„`

—

## Phase 6: Dokumentation & Handover (180-200 Minuten)

### 6.1 Tenant-Dokumentation erstellen

Was du nicht dokumentierst, existiert nicht. Erstelle am ersten Tag ein Basis-Dokument.

**Template:**
„`markdown
# Intune Tenant Dokumentation

## Tenant Info
– Tenant ID: [ID]
– Tenant Name: [Name]
– Primary Domain: [Domain]
– Lizenz-SKUs: [SKUs]

## RBAC Struktur
– Global Admins: [Liste]
– Intune Admins: [Liste]
– Helpdesk: [Liste]

## Compliance Policies
1. [Policy Name] — [Beschreibung] — [Zielgruppe]
2. [Policy Name] — [Beschreibung] — [Zielgruppe]

## Configuration Profiles
1. [Profil Name] — [Beschreibung] — [Plattform]

## Applications
– Required: [Liste]
– Available: [Liste]
– Uninstall: [Liste]

## Conditional Access Policies
1. [Policy Name] — [Status] — [Zielgruppe]

## Bekannte Issues
– [Issue 1] — [Workaround]
– [Issue 2] — [Geplant für]

## Nächste Schritte
– [Task 1] — [Priorität] — [Fällig]
– [Task 2] — [Priorität] — [Fällig]
„`

—

### 6.2 Automation Scripts bereitstellen

Stelle sicher, dass du die wichtigsten Skripte für den täglichen Betrieb hast.

**Essential Scripts:**
1. **Device-Compliance-Check.ps1** — Täglicher Compliance-Report
2. **App-Deployment-Monitor.ps1** — Überwacht App-Installationen
3. **Certificate-Expiry-Check.ps1** — Warnt vor Ablauf
4. **Enrollment-Failure-Analyzer.ps1** — Analysiert Enrollment-Fehler

**Beispiel: Daily Compliance Check**
„`powershell
# Daily-Compliance-Check.ps1
Connect-MgGraph -Identity

$reportDate = Get-Date -Format „yyyy-MM-dd“
$complianceData = Get-MgDeviceManagementDeviceCompliancePolicySettingStateSummary

$report = [PSCustomObject]@{
Date = $reportDate
TotalDevices = $complianceData.DeviceCount
Compliant = $complianceData.CompliantDeviceCount
NonCompliant = $complianceData.NonCompliantDeviceCount
ComplianceRate = [math]::Round(($complianceData.CompliantDeviceCount / $complianceData.DeviceCount) * 100, 2)
}

$report | Export-Csv -Path „C:\Reports\Compliance-$reportDate.csv“ -NoTypeInformation

if ($report.ComplianceRate -lt 90) {
Send-MailMessage -To „admin@company.com“ -Subject „ALERT: Compliance unter 90%“ -Body „Aktuelle Compliance: $($report.ComplianceRate)%“
}
„`

—

## Zusammenfassung

Ein Intune Tenant Health Check am ersten Tag ist wie eine Generaluntersuchung beim Arzt: Unangenehm, aber notwendig. Hier die kritischen Punkte im Überblick:

**Phase 1 (0-30 min):** Tenant-Basis
– [ ] Tenant-ID und Domains dokumentiert
– [ ] Lizenzen geprüft und verstanden
– [ ] RBAC-Struktur analysiert

**Phase 2 (30-90 min):** Devices
– [ ] Compliance Policies validiert
– [ ] Configuration Profiles geprüft
– [ ] BitLocker-Status verifiziert

**Phase 3 (90-120 min):** Apps
– [ ] App-Inventory erstellt
– [ ] Duplikate bereinigt
– [ ] Assignments dokumentiert

**Phase 4 (120-150 min):** Security
– [ ] Conditional Access Policies getestet
– [ ] MFA für alle aktiv
– [ ] Legacy Auth geblockt

**Phase 5 (150-180 min):** Reporting
– [ ] Baseline Reports eingerichtet
– [ ] Alerting konfiguriert
– [ ] Monitoring aktiv

**Phase 6 (180-200 min):** Dokumentation
– [ ] Tenant-Dokumentation erstellt
– [ ] Automation Scripts bereitgestellt
– [ ] Nächste Schritte definiert

**Goldene Regel:** Wenn du es nicht dokumentieren kannst, war es keine professionelle Arbeit. Nimm dir die Zeit für Phase 6 — sie wird dich in 6 Monaten vor Verzweiflung bewahren.

—

*Ende Sektion 15. Nächste Sektion: „Autopilot Deployment — Zero-Touch Provisioning in der Praxis“*