Teams-Client wird schneller – neuer Anrufprozess erfordert IT-Anpassung

Consulting Briefing: Teams bekommt einen „Beifahrer-Prozess“ fürs Telefonieren (und das ist gut so)

Im heutigen Consulting Briefing geht es um eine Änderung, die man als Anwender kaum bemerkt – und die in der IT trotzdem für erstaunlich viele „Warum geht das Meeting nicht?!“-Tickets sorgen kann, wenn man sie ignoriert. Microsoft trennt im neuen Teams-Client unter Windows die Calling- und Meeting-Engine vom Hauptprozess. Klingt nach Nerdkram. Ist es auch. Aber es ist Nerdkram mit echtem Nutzwert: schnellerer Start, weniger Hänger, mehr Stabilität.

Was ändert sich konkret?

Bisher lief im Wesentlichen alles unter dem Teams-Hauptprozess. Mit der Änderung führt Microsoft unter Windows einen zusätzlichen Kindprozess ein: ms-teams_modulehost.exe. Der Hauptprozess bleibt ms-teams.exe. Der neue Kindprozess übernimmt die Calling- und Meeting-„Calling Stack“-Anteile, also grob gesagt Audio, Video und Echtzeit-Medienpipeline.

Das ist laut Microsoft eine Performance- und Stabilitätsmaßnahme, die „unter der Haube“ passiert: Oberfläche und Bedienung bleiben gleich. Nur eben… flotter.
Rollout-Zeitraum: Microsoft kommunizierte die Einführung ab Januar 2026 (Windows-Client).

Warum lagert Microsoft den Aufruf- und Calling-Prozess aus?

Zwei große Gründe: Ressourcen entkoppeln und Fehler isolieren.

1. Weniger Konkurrenz um CPU und Speicher
   Teams macht gleichzeitig Chat/UI (Fenster, Listen, Emojis, Dateien) und Echtzeit-Medien (Audio/Video/Screen Sharing). Das sind sehr unterschiedliche Workloads. Wenn beides im selben Prozess um Threads, Speicher und Prioritäten kämpft, gewinnt oft das Chaos. Mit einem separaten Prozess kann Windows diese Lasten sauberer planen, und Teams kann die Medienpipeline gezielter priorisieren. Ergebnis: weniger „Teams denkt nach“-Momente beim Meeting-Start.

2. Stabilität: Crash nicht gleich Totalschaden
   Wenn ein Modul in der Calling-Engine aus dem Tritt kommt, soll nicht gleich der ganze Client mit Chat, Kalender und Kontext sterben. Ein separater Prozess ist wie ein Airbag: Wenn es knallt, knallt es lokaler. Das ist klassische Software-Architektur: „Fault isolation“ statt Dominoeffekt.

3. Modularität als Strategie
   Microsoft baut den Teams-Client seit dem „neuen Teams“ ohnehin modularer. Ein dedizierter Module-Host ist ein weiterer Schritt: weniger monolithischer Block, mehr austauschbare Bausteine. Das macht Updates kleiner, zielgerichteter und im Idealfall weniger riskant. (Und ja: Es macht auch das Debugging für Microsoft leichter.)

Wie funktioniert das technisch?

Aus Sicht von Windows passiert Folgendes:

• ms-teams.exe bleibt der „Chef“: UI, Anmeldung, Chat, Kalender, Benachrichtigungen.

• Sobald du einem Anruf/Meeting beitrittst oder etwas im Calling-Kontext initialisiert werden muss, startet Teams einen Kindprozess: ms-teams_modulehost.exe.

• In diesem Kindprozess laufen die Komponenten, die für Echtzeit-Kommunikation zuständig sind (Audio/Video, Gerätezugriffe, Medienverarbeitung). Das reduziert Blockaden im UI-Prozess und verbessert die Startzeit.

Wichtig: Das ist kein „zweites Teams“, sondern ein gezielter Host für ein Teilmodul. In der Taskleiste bleibt alles wie gehabt. Im Task-Manager sieht man nur mehr „Leben“.

Was bringt das den Nutzern?

Kurz: Meetings starten schneller, fühlen sich stabiler an.

• Schnelleres Join-Erlebnis: Weniger Initialisierungsballast im Hauptprozess, weniger Startverzögerung. 

• Weniger Hänger beim Umschalten: Kamera an/aus, Gerät wechseln, Bildschirm teilen – alles Dinge, die gern mal genau dann zicken, wenn der Vorstand zuschaut.

• Robustere Sessions: Wenn die Calling-Komponente Probleme hat, muss nicht automatisch das ganze Teams neu starten (oder sich wie ein beleidigter Toaster verhalten).

Unterm Strich: Für den Anwender bleibt alles gleich – nur mit weniger Wartezeit und weniger „Teams hat sich aufgehängt“-Folklore. Genau so sollten Plattformverbesserungen schmecken.

Und jetzt kommt die IT ins Spiel: Was müsst ihr tun?

Hier wird es praktisch. Der neue Prozess ist eine neue ausführbare Datei – und damit interessiert er sofort:

• Endpoint Protection (AV/EDR)

• Application Control (AppLocker, WDAC, Drittprodukte)

• Monitoring/Telemetry

• QoS-Regeln (falls exe-basiert)

• Helpdesk-Runbooks

Microsoft empfiehlt explizit, ms-teams_modulehost.exe zu allowlisten (zusätzlich zu ms-teams.exe). Sonst kann es passieren, dass Calling-Funktionen blockiert werden oder Alarm auslösen.

1) Allowlisting und Application Control

• Prüfe Richtlinien, die auf Prozessnamen/Hashes/Signaturen basieren.

• In vielen Umgebungen ist nicht „Teams“ das Problem, sondern der Reflex: „Neue EXE? Erstmal sperren.“
  Das ist grundsätzlich vernünftig, nur bitte mit Plan: Signaturprüfung, Pfadprüfung (Teams-Installationspfad), Hersteller-Validierung, dann gezielt freigeben.

2) EDR/AV: Regeln und Ausnahmen sauber setzen

• Stelle sicher, dass der neue Prozess nicht als „unbekanntes Verhalten“ bewertet wird (insbesondere, wenn ihr strenge Verhaltensregeln für Child-Processes habt).

• Beobachte in der Einführungsphase eure Alerts: False Positives sind hier der Klassiker.

3) QoS und Netzwerkpolicies

Wenn eure QoS-Policies an die ausführbare Datei gebunden sind, müssen sie für beide Prozesse gelten. Microsoft nennt das Thema QoS explizit in den Admin-Hinweisen, und die generellen QoS-Leitlinien für Teams bleiben natürlich bestehen.

4) Monitoring, Logs, Dashboards

• Prozessname taucht in Telemetrie auf.

• Event-basierte Erkennung („Teams calling started“) könnte plötzlich einen anderen Prozessbezug haben.

• SIEM-Regeln, die auf ms-teams.exe filtern, sollten geprüft werden.

5) Helpdesk vorbereiten

Das ist der unterschätzte Teil: Der neue Prozess wird im Task-Manager sichtbar. Spätestens wenn ein Screenshot im Ticket hängt („Was ist das denn?!“), sollte der First-Level nicht antworten: „Deinstallieren Sie das bitte mal.“
Kurze interne Notiz reicht: „Neu ab Januar 2026: ms-teams_modulehost.exe = Calling/Meetings, ist ok.“

Architektur, Governance, Betrieb: Was ändert sich im großen Bild?

• Architektur: Teams wird modularer. Das ist ein Signal: Microsoft trennt Funktionen stärker in Komponenten, die unabhängig aktualisiert und abgesichert werden können.

• Governance/Security: Security-Tools müssen nicht „Teams“ neu lernen, aber sie müssen den zusätzlichen Prozess korrekt einordnen. Alles, was exe-basiert ist (Allowlisting, QoS, Monitoring), braucht ein Update.

• Betrieb: Change-Kommunikation ohne Drama. Für Anwender ist das kein Feature, sondern ein „läuft einfach besser“-Moment. Für den Betrieb ist es ein kleines, aber wichtiges Stück Hygiene.

Konkrete Empfehlungen für euren Rollout

1. Jetzt Allowlisting vorbereiten
   ms-teams_modulehost.exe in AV/EDR und Application Control freigeben (sauber über Signatur/Hersteller, nicht per Wildcard-Orgie).

2. Interne Doku/FAQ aktualisieren
   Ein Absatz reicht: neuer Prozess, Zweck, was bei Problemen zu prüfen ist.

3. Helpdesk-Briefing
   Mini-Schulung: „Neuer Prozessname, gleiche Funktion, kein Grund zur Panik.“

4. Nach dem Rollout messen
   Vorher/Nachher-Vergleich: Meeting-Startzeiten, Crashrate, CPU-Spitzen beim Join, Ticketvolumen „Audio/Video geht nicht“. Wenn es besser wird, habt ihr einen schönen Beleg, dass Technikpflege echte Lebensqualität bringt.

Strategische Einordnung (ohne Panikmodus)

Im Consulting Briefing sagen wir es gern so: Wenn Microsoft im Backend aufräumt, kann das die User Experience spürbar verbessern – aber nur, wenn die IT nicht überrascht in die Hecke springt. Diese Änderung ist kein Risiko-Feuerwerk, sondern eher eine Wartung am Motor: Von außen sieht man nichts, aber plötzlich startet der Wagen im Winter ohne Fluchen.

Für Anwender bleibt alles wie gehabt. Nur eben mit höherer Chance, dass das Meeting beim Klick auf „Teilnehmen“ tatsächlich… teilnimmt. Und das ist, Hand aufs Herz, schon ein kleines Wunder der Moderne.

(Und ja: Consulting Briefing kommt natürlich wieder. Die nächste „unsichtbare Änderung mit sichtbaren Tickets“ lauert bestimmt schon hinter der nächsten Ecke.)