Copilot in AVD und Windows 365: ungeplante Rollouts vermeiden

Montagmorgen, neuer Session Host, ungefragter Copilot

Ein Kunde ruft mich Ende Juni an, leicht genervt. Sein Team hatte gerade ein neues Golden Image für den AVD-Pool ausgerollt, nichts Ungewöhnliches, ein reguläres Patch-Update. Am Montag danach melden sich die ersten Anwender: Auf dem Desktop und in der Taskleiste prangt plötzlich ein Copilot-Icon, das vorher nicht da war. Niemand hat es beauftragt, niemand hat eine Lizenz dafür freigegeben, und der Helpdesk bekommt prompt die ersten Tickets mit der Frage, ob das jetzt ein Sicherheitsproblem sei.

Es ist keins, zumindest nicht im klassischen Sinn. Es ist etwas anderes, denn Microsoft installiert die Microsoft 365 Copilot App inzwischen automatisch auf Windows-Geräten im Unternehmensumfeld, wenn nicht vorher aktiv gegengesteuert wird. Für physische PCs ist das ärgerlich, aber überschaubar. Für Azure Virtual Desktop und Windows 365, wo ein einziges Image unter Umständen gleich hunderte Sitzungen betrifft, ist es ein Governance-Thema, das eine bewusste Entscheidung verdient, keine stillschweigende Duldung durch die Hintertür.

Was Microsoft ab Juli 2026 tatsächlich macht

Microsoft rollt die Copilot-App zwischen Mitte Juni und Mitte Juli 2026 automatisch auf berechtigte Windows-Geräte im Unternehmensumfeld aus, sofern Administratoren nicht vorher eine entsprechende Blockierungsrichtlinie konfiguriert haben. Das betrifft grundsätzlich jedes Windows-Gerät, das über Microsoft-365-Update-Kanäle versorgt wird, physische Clients ebenso wie AVD-Session-Hosts und Windows-365-Cloud-PCs, die auf denselben Images basieren.

Um das zu unterbinden, gibt es zwei Wege:

1. Group Policy / Intune: Seit den im Juni 2026 aktualisierten Administrative Templates (.admx) für Microsoft 365 Apps gibt es die Richtlinie "Prevent automatic installation of Microsoft 365 Copilot" unter Computer Configuration \ Administrative Templates \ Microsoft 365 Copilot. Aktiviert, verhindert sie die Verteilung über die M365-Update-Kanäle.

2. Registrey-Key: Für unverwaltete Geräte oder als Alternative zur GPO lässt sich der DWORD-Wert PreventCopilotInstallation = 1 unter HKLM\SOFTWARE\Policies\Microsoft\Office\16.0\Common\ExperimentConfigs\ExternalFeatureOverrides\copilot setzen.
    

   Powershell:
   # Copilot-Autoinstallation verhindern (unverwaltete Geräte / Referenzimage)
   $regPath = "HKLM:\SOFTWARE\Policies\Microsoft\Office\16.0\Common\ExperimentConfigs\ExternalFeatureOverrides\copilot"

   if (-not (Test-Path -LiteralPath $regPath)) {
      New-Item -Path $regPath -Force | Out-Null
   }

   New-ItemProperty -Path $regPath -Name "PreventCopilotInstallation" -PropertyType DWord -Value 1 -Force | Out-Null
    

Wichtig für die Terminplanung: Eine nach dem 15.06.2026 gesetzte Richtlinie entfernt die App nicht rückwirkend von Geräten, die sie bereits erhalten haben. Sie verhindert nur künftige Neuinstallationen. Wer jetzt liest und noch nichts konfiguriert hat, sollte davon ausgehen, dass zumindest ein Teil der Images die Copilot App schon installiert hat, und entsprechend mit Deinstallation statt reiner Prävention planen.

Parallel dazu hat Microsoft im selben Zeitraum weitere Copilot-Änderungen ausgerollt, die für die Einordnung relevant sind. Seit Ende Februar 2026 können Admins per Cloud-Policy ein Wasserzeichen für KI-generierte oder -veränderte Video- und Audioinhalte aktivieren, um Transparenz zu schaffen. Die Richtlinie ist opt-in, ohne sie bettet Microsoft aber weiterhin Metadaten in die Inhalte ein [Microsoft Support]. Seit Mai 2026 rollt Microsoft zudem GPT-5.5 Instant (im Modellauswahl-Menü als "GPT-5.5 Quick response" gelistet) als schnelleres Modell für alltägliche Arbeitsfragen aus, zunächst mit Priority Access für lizenzierte Copilot-Nutzer [Microsoft Tech Community]. Mittlerweile ist mit GPT-5.6 bereits ein Nachfolger als bevorzugtes Modell im Einsatz, das Tempo bei den Modellwechseln ist selbst ein Beleg für die Ökosystem-Dynamik. Das alles zeigt, dass Copilot längst kein isoliertes Feature mehr ist, sondern ein wachsendes Ökosystem, das sich in bestehende Images und Prozesse einschleicht, ob man es nun geplant hat oder nicht.

Warum das bei AVD und Windows 365 anders wiegt

Bei einem einzelnen physischen Notebook ist ein ungewolltes App-Icon ein Ärgernis. Bei einer Multi-Session-Umgebung mit FSLogix-Profilcontainern und einer zentralen Image-Pipeline potenziert sich das Problem gleich in mehrere Richtungen:

Ein Image, viele Nutzer.

Ein einziges Golden-Image-Update trägt die Änderung sofort in jede Session, die davon abstammt. Es gibt keine "einzelne Ausnahme", die man später korrigiert, die Entscheidung wird für den gesamten Pool auf einmal getroffen, gewollt oder nicht.

Lizenz und Sichtbarkeit fallen auseinander.

Die App erscheint unabhängig davon, ob der jeweilige Benutzer überhaupt eine Microsoft-365-Copilot-Lizenz besitzt. Das Ergebnis in der Praxis: Anwender ohne Lizenz sehen ein Icon, klicken darauf, landen bei einer Fehlermeldung, und der Helpdesk bekommt Tickets für ein Problem, das eigentlich keins ist, aber wie eines aussieht.
 

FSLogix und Profilkonsistenz.

Die App selbst wird beim automatischen Rollout system-weit installiert, nicht pro Nutzer dupliziert. Der reale FSLogix-Risikopunkt liegt woanders. MSIX-Apps wie Copilot schreiben Nutzungsdaten nach %LocalAppData%\Packages, von denen FSLogix seit Version 2210 zwar die größten Cache-Ordner beim Sign-out automatisch verwirft, aber inkonsistente Installationswege (system-weit vs. versehentlich pro Nutzer) können dazu führen, dass die App auf einzelnen Session-Hosts für den Nutzer scheinbar verschwindet. Übrigens ein bekanntes FSLogix/MSIX-Verhalten, das auch beim neuen Teams-Client auftritt.

Governance- und Souveränitätsfrage.

Copilot verarbeitet Eingaben in der Regel über Microsoft-Cloud-Dienste. Wer sich gerade erst Gedanken über Betriebs- und Software-Souveränität macht, sollte nicht gleichzeitig eine KI-Komponente unkontrolliert in jede Sitzung einschleusen lassen. Das ist derselbe Gedanke, den ich bereits in Identitäten für KI-Agenten beschrieben habe: Jede neue KI-Komponente braucht eine eigene, bewusste Identitäts- und Zugriffsentscheidung, kein Trittbrettfahren über ein Windows-Update.

Praktische Schritte für die Image- und Rollout-Planung

Ein Detail, das in der Praxis oft übersehen wird: Wenn Sie Copilot für einen Teil Ihrer Nutzer tatsächlich wollen, ist ein separates Image oder eine App-Attach-Zuweisung meist die sauberere Lösung als ein einheitliches Basis-Image mit nachträglicher Blockierung für alle anderen. Entscheidend ist, dass Sie selbst festlegen, was wann und für welche Nutzer bereitgestellt wird, statt Änderungen automatisch auf die gesamte Umgebung auszurollen.

Praxistipp: Prüfen Sie vor der nächsten Image-Wartung explizit, ob die Juni-2026-ADMX-Vorlagen bereits importiert sind. Ohne aktualisierte Administrative Templates taucht die Richtlinie in der GPO-Konsole gar nicht erst auf, und Sie verlassen sich unwissentlich auf den Registry-Weg allein. Darüber hinaus gibt es auch den Schalter „Enable automatic installation of Microsoft 365 Copilot app“ im Microsoft 365 Apps Admin Center, der ebenfalls deaktiviert werden sollte.

Bewertung

Ich bin kein Copilot-Skeptiker, ich arbeite selbst täglich damit. Aber "automatisch für alle" ist in einer Multi-Session-Umgebung kein guter Rollout-Mechanismus, egal wie gut das zugrunde liegende Produkt ist. Der Punkt ist nicht, ob Copilot sinnvoll ist, sondern wer diese Entscheidung trifft. Microsoft über einen Update-Kanal oder Sie über eine bewusste Image- und Lizenzstrategie.

Für AVD- und Windows-365-Umgebungen heißt das konkret: Die Blockierrichtlinie gehört in jede Image-Baseline, unabhängig davon, ob Sie Copilot grundsätzlich einsetzen wollen. Wer es einsetzen will, tut das anschließend gezielt, über ein eigenes Image oder App-Attach, mit Lizenzabgleich, nicht als Nebeneffekt eines Windows-Updates.

Wenn Sie Ihre Image-Pipeline oder Ihre Copilot-Rollout-Strategie für AVD oder Windows 365 durchsprechen möchten, melden Sie sich gerne.