ahmido
cf5b0027e3
Zusammenfassung: Fügt im „Run Inventory Sync“-Modal einen include_dependencies-Toggle hinzu und persistiert die Auswahl in der InventorySyncRun.selection_payload. Tests, Quickstart und Tasks wurden entsprechend aktualisiert. Files: InventoryLanding.php, InventorySyncButtonTest.php, quickstart.md, tasks.md Motivation: Ermöglicht explizites Ein-/Ausschalten der Dependency-Extraktion pro Sync-Run (z. B. Assignments/Scope Tags/Foundations), statt starrer Defaults. Passt zur bestehenden selection_hash-Logik (InventorySelectionHasher) und zur deterministischen Selektionspersistenz. Verhalten: include_dependencies ist im Modal standardmäßig true. Wird die Option gesetzt, landet der Wert als bool im selection_payload und beeinflusst selection_hash über die Normalisierung. Tests: Neuer/angepasster Pest-Test stellt sicher, dass include_dependencies in selection_payload persistiert. Lokaler Testlauf: ./vendor/bin/sail artisan test tests/Feature/Inventory/InventorySyncButtonTest.php → alle Tests für diese Datei bestanden. ./vendor/bin/pint --dirty wurde ausgeführt (Formatting ok). How to test (quick): Start Sail + Queue: Im Admin → Inventory: „Run Inventory Sync“ öffnen, Include dependencies umschalten, ausführen. Prüfen: neu erstellter InventorySyncRun.selection_payload.include_dependencies ist der gesetzten Auswahl entsprechend. Oder laufen lassen: Notes / Next steps: Diese Änderung bereitet den Weg, später die Dependency-Extraction (042-inventory-dependencies-graph) optional tiefer zu integrieren. Working tree ist sauber; es gibt ein nicht eingebundenes Verzeichnis 0800-future-features (unrelated). Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local> Reviewed-on: #47
66 lines
3.2 KiB
Markdown
66 lines
3.2 KiB
Markdown
# Brainstorming: Was fehlt, damit TenantPilot als Suite ein „Must-have“ für Unternehmen & MSPs wird?
|
||
|
||
Ziel: Features, die Microsoft in Intune voraussichtlich **nicht** in dieser Qualität nachrüstet – und für die Mittelstand/MSPs **wirklich zahlen** (Portfolio, Governance, Standardisierung, Automation, Nachweisbarkeit).
|
||
|
||
---
|
||
|
||
## 1) MSP Portfolio & Operations (Multi-Tenant)
|
||
- **Multi-Tenant Health Dashboard**: pro Tenant „Backup ok?“, „Sync ok?“, „Drift Findings“, „High-risk Changes last 7d“
|
||
- **SLA-/Compliance-Reports** pro Kunde (PDF/Export): Coverage, letzter erfolgreicher Backup, Restore-Test-Status
|
||
- **Alerting** (Teams/Email/Webhook): failed runs, throttling, permissions drift, „kein erfolgreicher Backup seit X Tagen“
|
||
- **Troubleshooting Center**: Error Codes → konkrete Fix-Schritte (fehlende Permissions, 429, contract mismatch, mapping fehlt)
|
||
|
||
---
|
||
|
||
## 2) Drift & Change Governance (Zahlhebel #1)
|
||
- **Drift Findings mit Risikostufe** (high/medium/low) + „was hat sich geändert?“
|
||
- **Change Approval Workflow**: DEV→PROD Promotion nur mit Approval + Audit Pack
|
||
- **Guardrails / Policy Freeze Windows**: definierte Zeitfenster ohne High-Risk Changes
|
||
- **Tamper Detection**: Policy geändert außerhalb genehmigter Changes → Alert + Audit
|
||
|
||
---
|
||
|
||
## 3) Standardisierung & Policy Quality („Intune Linting“)
|
||
- **Policy Linter**: Naming, Scope Tag Pflicht, keine All-Users Assignments bei High Risk, Mindest-Settings
|
||
- **Company Standards als Templates**: eigene Standards („Company Standard 2026“) statt nur Microsoft Baselines
|
||
- **Policy Hygiene**: Duplicate Finder, Unassigned Policies, Orphaned filters/tags, stale/deleted policies
|
||
|
||
---
|
||
|
||
## 4) Tenant-to-Tenant / Staging→Prod Promotion
|
||
- **Compare/Diff zwischen Tenants** (DEV vs PROD) auf Policy-/Settings-Ebene
|
||
- **Mapping UI**: Gruppen, Scope Tags, Filters, Named Locations (CA), App-Refs
|
||
- **Promotion Plan**: Preview → Dry-run → Cutover → Verify (post-apply compare)
|
||
|
||
---
|
||
|
||
## 5) Security Suite Layer (ohne „Defender ersetzen“)
|
||
- **Security Posture Score** (aus euren Policies/Standards, nicht nur Microsoft Scores)
|
||
- **Blast Radius Anzeige**: welche Geräte/Benutzer/Groups wären betroffen, wenn X geändert wird
|
||
- **Opt-in High-Risk Enablement**: Baselines/CA als Module (create-new + verify, niemals blind update)
|
||
|
||
---
|
||
|
||
## 6) Recovery Confidence (Killer-Feature)
|
||
- **Automatisierte Restore-Tests** in Test-Tenants („Nightly restore rehearsal“)
|
||
- **Recovery Readiness Report**: „Wir können 92% der kritischen Config-Typen restoren“
|
||
- **Preflight Score**: Missing prereqs, permissions, mapping completeness → Score + konkrete ToDos
|
||
|
||
---
|
||
|
||
## 7) Script & Secrets Governance
|
||
- **Script Diff + Approval + Rollback** (PowerShell/macOS)
|
||
- **Secret Scanning** in Scripts (API keys/tokens) + block/alert
|
||
- **Allowlist/Signing Workflow** (Governance, Wer darf was ausrollen?)
|
||
|
||
---
|
||
|
||
# Was fehlt „heute“ im Vergleich zu eurem aktuellen Stand?
|
||
Ihr habt schon sehr stark: Backup/Restore, Versioning, Wizard, Bulk/Queue + Progress, Inventory, Scheduling (MVP), Dependencies (in Arbeit).
|
||
|
||
Was euch zum Must-have macht:
|
||
1. **MSP Portfolio + Alerting**
|
||
2. **Drift + Approvals/Governance**
|
||
3. **Standardisierung/Linting**
|
||
4. **Promotion DEV→PROD**
|
||
5. **Recovery Confidence (automatisierte Tests)** |