# Eine Validierungsumgebung, die etwas aussagt
Typ: Checkliste
Herkunft: rds-avd-operations / host-pool-design / rds-avd-pool-validation-rollout
Version: rds-avd-pool-validation-rollout-2026-09-12
Geprüft: 2026-09-12

ACHTUNG: Dieses Dokument ist ein Lernartefakt aus einer Schulungssequenz. Es ist kein produktives Runbook. Vor jeder Anwendung in einer realen Umgebung müssen die Schritte gegen lokale Dokumentation, Runbooks und Freigabestatus geprüft werden.

## Szenario
Bisher erreichen Dienstaktualisierungen alle Pools gleichzeitig; zweimal im vergangenen Jahr fiel eine fehlerhafte Änderung erst in der Produktion auf. Eine Validierungsumgebung soll das ändern. Ein leerer Pool mit dem Kennzeichen reicht dafür nicht — er würde nichts bemerken.

## Schritte
1. Einen Pool mit demselben Abbild und denselben Anwendungen wie die Produktivpools aufbauen.
2. Eine echte Nutzergruppe zuweisen, die dort ihre tägliche Arbeit erledigt — nicht gelegentlich testet.
3. Den Pool als Validierungsumgebung kennzeichnen, damit Dienstaktualisierungen ihn zuerst erreichen.
4. Die vorhandenen automatisierten Tests der Host Pools auf diesen Pool ausweiten.
5. Nach jeder Dienstaktualisierung Befunde aus diesem Pool abwarten, bevor die Produktion folgt.

## Begründung
Warum: Eine Vorabumgebung ist nur so aussagekräftig wie ihre Ähnlichkeit und ihre Beanspruchung. Das Kennzeichen zuerst zu setzen ist die verbreitete Reihenfolge und die falsche: Ab diesem Moment kommen Änderungen zuerst dort an, und wenn niemand dort arbeitet, entsteht ein Ergebnis ohne Aussage, auf das sich trotzdem alle verlassen.
Folgen: **+** Ein Befund aus der Validierungsumgebung ist belastbar, und ihr Schweigen ebenfalls. **−** Sie kostet Hosts, Lizenzen und Pflege dauerhaft — und sie setzt eine echte Nutzergruppe bewusst dem ersten Kontakt mit jeder Dienstaktualisierung aus. Wer diese Gruppe nicht offen darüber informiert, verschiebt ein Betriebsrisiko still auf einzelne Kollegen.

## Quellen
1. https://learn.microsoft.com/en-us/azure/virtual-desktop/terminology