Cloud Workplace Foundation
Azure Virtual Desktop und Windows 365 in einer Architektur, einer Konfiguration und einem Betrieb. Ihr entscheidet je Nutzergruppe, welcher Desktop passt, wir bauen die Plattform darunter als Code und betreiben sie. Die zweite Nutzergruppe ist dann kein Projekt mehr, sondern ein Use Case.
Jeder dieser Desktops war eine gute Entscheidung
Der erste virtuelle Desktop ist meist ein Host Pool für das Callcenter, sauber gebaut, und die Nutzer sind zufrieden. Dann kommen die Engineers mit eigenen Maschinen, die Kolleginnen im Homeoffice mit Windows 365, die Schicht am Standort mit Frontline. Jede dieser Entscheidungen war richtig, und jede hat eine eigene Kette an Pflichten hinter sich hergezogen, die niemand bestellt hat.
- Neuer Desktop-TypEin weiteres Projekt und ein weiteres Team, das ihn kennt
- Eigenes ImageNoch ein Golden Image, das jemand von Hand pflegt
- Manuelles PatchenPatch-Wochenenden und Sessions, die jemand abmelden muss
- Apps doppelt paketiertDieselbe Anwendung, zweimal gebaut und zweimal getestet
- DriftNach einem Jahr gleicht keine Umgebung mehr der anderen
- Kosten und RisikoMehr Hände im Betrieb und mehr Fläche für Fehler
- Mit Cloud Workplace Foundation
- Ein Framework
- Ein Image-Prozess
- Eine Paketierung
- Keine Drift
Ohne Framework ist jeder Desktop ein Sonderfall
Das liegt nicht an den Teams, die die Umgebungen gebaut haben, sondern daran, dass jede als eigenes Produkt entstanden ist. Drei Folgen zeigen sich fast überall.
- KostenJeder Desktop-Typ hat seine eigenen Hosts, seine eigenen Images und sein eigenes Wissen im Team. Kapazität lässt sich deshalb nur je Umgebung planen, nicht je Nutzergruppe, und bezahlt wird für Reserve, die selten jemand abruft.
- RisikoSecurity Baselines, die von Hand gepflegt werden, laufen mit der Zeit auseinander. Was auf dem einen Host Pool gilt, fehlt auf dem anderen, und die Frage, welcher Stand gerade produktiv ist, beantwortet am Ende ein Audit.
- GeschwindigkeitEin neues Team bekommt ein neues Projekt: Design, Image, Policies, Paketierung, Abnahme. Wochen vergehen bis zum ersten sicheren Desktop, obwohl jeder Baustein dafür längst irgendwo im Haus existiert.
Vier Desktop-Typen, ein Framework
Jede Nutzergruppe bekommt den Desktop, der zu ihrer Arbeit passt, und alle vier laufen auf derselben Plattform. Applikationen und Client-Konfiguration sind überall gleich, nur die Infrastruktur darunter unterscheidet sich: Bei Azure Virtual Desktop bauen und betreiben wir sie als Code, bei Windows 365 betreibt Microsoft sie, und wir liefern die Azure Network Connection und die Konfiguration darüber. Die Wahl des Typs ist damit eine Frage der Arbeit, nicht der Architektur.
Azure Virtual DesktopAVD PooledMehrere Nutzer teilen sich einen Session Host. Die wirtschaftlichste Form, wenn viele Menschen ähnlich arbeiten. | Azure Virtual DesktopAVD PersonalJeder Nutzer hat seine eigene virtuelle Maschine, mit eigenem Zustand und voller Leistung. | Windows 365Windows 365 EnterpriseEin persönlicher Cloud PC je Nutzer, Infrastruktur bei Microsoft. Der Desktop für alle, die von überall arbeiten. | Windows 365Windows 365 FrontlineDedizierte Cloud PCs für Mitarbeitende, die in Schichten arbeiten und ihren Desktop nur während der Schicht brauchen. | |
|---|---|---|---|---|
| Eigener Desktop je User | nicht enthalten | enthalten | enthalten | enthalten |
| Geteilte Session Hosts mit Scaling Plans | enthalten | nicht enthalten | nicht enthalten | nicht enthalten |
| Monatlich neues Image aus der Image Factory | enthalten | nicht enthalten | nicht enthalten | nicht enthalten |
| Lizenz folgt der Schicht, nicht dem Kopf | nicht enthalten | nicht enthalten | nicht enthalten | enthalten |
| Infrastruktur als Code, betrieben von glueckkanja | enthalten | enthalten | nicht enthalten | nicht enthalten |
| Infrastruktur betreibt Microsoft, Azure Network Connection von glueckkanja | nicht enthalten | nicht enthalten | enthalten | enthalten |
| Intune Policy Blueprints und Defender for Endpoint | enthalten | enthalten | enthalten | enthalten |
| RealmJoin mit über 2.500 Applikationen | enthalten | enthalten | enthalten | enthalten |
| Typisch für | Callcenter, Externe, Saisonkräfte | Engineers, Power User | Remote Knowledge Worker | Frontline, Schichtarbeit |
- Eigener Desktop je User
- Geteilte Session Hosts mit Scaling Plans
- Monatlich neues Image aus der Image Factory
- Lizenz folgt der Schicht, nicht dem Kopf
- Infrastruktur als Code, betrieben von glueckkanja
- Infrastruktur betreibt Microsoft, Azure Network Connection von glueckkanja
- Intune Policy Blueprints und Defender for Endpoint
- RealmJoin mit über 2.500 Applikationen
Typisch für: Callcenter, Externe, Saisonkräfte
- Eigener Desktop je User
- Geteilte Session Hosts mit Scaling Plans
- Monatlich neues Image aus der Image Factory
- Lizenz folgt der Schicht, nicht dem Kopf
- Infrastruktur als Code, betrieben von glueckkanja
- Infrastruktur betreibt Microsoft, Azure Network Connection von glueckkanja
- Intune Policy Blueprints und Defender for Endpoint
- RealmJoin mit über 2.500 Applikationen
Typisch für: Engineers, Power User
- Eigener Desktop je User
- Geteilte Session Hosts mit Scaling Plans
- Monatlich neues Image aus der Image Factory
- Lizenz folgt der Schicht, nicht dem Kopf
- Infrastruktur als Code, betrieben von glueckkanja
- Infrastruktur betreibt Microsoft, Azure Network Connection von glueckkanja
- Intune Policy Blueprints und Defender for Endpoint
- RealmJoin mit über 2.500 Applikationen
Typisch für: Remote Knowledge Worker
- Eigener Desktop je User
- Geteilte Session Hosts mit Scaling Plans
- Monatlich neues Image aus der Image Factory
- Lizenz folgt der Schicht, nicht dem Kopf
- Infrastruktur als Code, betrieben von glueckkanja
- Infrastruktur betreibt Microsoft, Azure Network Connection von glueckkanja
- Intune Policy Blueprints und Defender for Endpoint
- RealmJoin mit über 2.500 Applikationen
Typisch für: Frontline, Schichtarbeit
Updates ohne Unterbrechung
Pooled Hosts patchen wir nicht im laufenden Betrieb, wir bauen sie jeden Monat aus einem neuen Image. Die Image Factory erzeugt es, ihr prüft es in Staging, danach rollt es als Green/Blue Deployment aus: Neue Hosts kommen in den Pool, Nutzer wechseln mit der nächsten Anmeldung, und die bisherigen Hosts bleiben stehen, bis niemand sie mehr braucht. Der Weg zurück ist jederzeit frei, und das Patch-Wochenende fällt aus, ersatzlos.
- 1Image bauenMonatlich aus Code, mit den aktuellen Updates und eurer Anwendungsbasis
- 2Staging bereitstellenDas neue Image steht in einer Staging-Umgebung bereit
- 3Image validierenIhr prüft es mit euren Anwendungen, Rückmeldung innerhalb von zwei Werktagen
- 4Hosts tauschenNeue Hosts aus dem Image kommen in den Pool, Nutzer wechseln beim nächsten Login
- 5Fallback behaltenDie bisherigen Hosts bleiben, bis alle gewechselt sind, Rollback jederzeit
- 2.500+fertige Applikationen in RealmJoin
- 100 %Infrastructure as Code, von der Landing Zone bis zur Policy
Zertifizierter BetriebCloud-native, als Code
Was den Unterschied macht
Cloud Workplace Foundation ist zu hundert Prozent Infrastructure as Code: OpenTofu, TerraProvider, Packer und GitHub, betrieben nach ISO 27001. Jede Umgebung lässt sich daraus neu erzeugen, jede Änderung hat einen Plan und eine Historie, und die Dokumentation wird nicht geschrieben, sondern jede Nacht aus dem Code erzeugt. Sie ist damit die einzige Dokumentation, die garantiert den Stand von heute beschreibt.
Alle Hosts sind Entra ID joined. In der VDI-Umgebung gibt es keine Domain Controller, und ältere Anwendungen, die Kerberos brauchen, bekommen es über Entra Kerberos und Cloud Kerberos Trust. Neue Microsoft-Funktionen fließen laufend in die Blueprints ein, ohne dass jemand die Umgebung neu baut. Die Plattform altert nicht, sie wird gepflegt.
- Entra ID nativeAlle Hosts Entra ID joined, keine Domain Controller in der VDI, Entra Kerberos und Cloud Kerberos Trust für ältere Applikationen
- EvergreenNeue Microsoft-Funktionen fließen laufend in die Blueprints ein, ohne Neubau der Umgebung
- Documentation AppDie Dokumentation eurer Umgebung entsteht jede Nacht neu aus dem Code
- 100 Prozent Infrastructure as CodeOpenTofu, TerraProvider, Packer, GitHub. Optional Azure Confidential VMs für regulierte Daten
Was sich für euer Unternehmen ändert
Eine Plattform statt mehrerer Produkte wirkt an vier Stellen gleichzeitig, und zwar für jede Nutzergruppe, die ihr heute habt, und für jede, die noch kommt.
GeschwindigkeitEine neue Nutzergruppe ist ein Use Case auf der bestehenden Plattform, kein Projekt mit Lenkungskreis. Definieren, parametrisieren, ausrollen, validieren, live.
KostenKapazität wird je Nutzergruppe geplant und skaliert mit dem Bedarf. Bezahlt wird, was gebraucht wird, nicht, was vor zwei Jahren einmal vorgesehen war.
SicherheitDieselbe Security Baseline auf jedem Desktop, ob Pooled, Personal oder Cloud PC, als Code geprüft und jeden Monat auf dem Stand von Microsoft. Ein Audit wird damit zu einer Frage, die der Code beantwortet.
KontinuitätMonatlicher Image-Lifecycle, Evergreen-Updates, Monitoring und Service Reviews laufen im Managed Service mit. Euer Team behält die Entscheidungen und gibt den Regelbetrieb ab.
Jede neue Nutzergruppe startet auf derselben Plattform
Ein Use Case ist bei uns eine Nutzergruppe mit ihrem Desktop-Typ, ihren Anwendungen und ihren Regeln. Er durchläuft fünf Schritte, parallel zum Foundation Setup oder später, gern auch mehrere gleichzeitig, und jede weitere Gruppe nimmt denselben Weg. Wer ihn einmal gegangen ist, kennt ihn beim zweiten Mal, und beim dritten Mal kennt ihn die Pipeline.
Vier typische Use Cases
- AVD PooledCallcenterViele gleiche Arbeitsplätze, die Kapazität folgt der Tageszeit
- AVD PersonalEngineersEigene Werkzeuge und volle Leistung auf der eigenen VM
- Windows 365 EnterpriseRemote Knowledge WorkerDerselbe persönliche Desktop, egal von wo
- Windows 365 FrontlineSchichtbetriebEin Cloud PC je Schicht, nicht je Kopf
Der Weg, den jede Gruppe nimmt
- 1DefineNutzergruppe, Desktop-Typ, Anwendungen, Anforderungen an Netzwerk und Sicherheit
- 2ParameterizeAus dem Blueprint wird euer Use Case: Parameter im Code, nicht im Portal
- 3DeployDie Pipeline rollt Infrastruktur, Policies und Applikationen aus
- 4ValidateIhr prüft mit Pilotnutzern und euren Fachanwendungen
- 5Go liveDie Nutzergruppe wechselt, der Managed Service übernimmt
Ihr entscheidet, wo welche Workload läuft, wir betreiben die Plattform
Oben bleibt, was nur ihr wissen könnt: welche Fachanwendungen eure Leute brauchen und ob ein neues Image mit ihnen funktioniert. Die Schichten darunter betreiben wir im Managed Service, bis hinunter zur Landing Zone, die wir mit der Azure Foundation übernehmen, wenn ihr sie noch nicht habt. Die Grenze ist klar gezogen, und sie verläuft dort, wo Wissen über eure Anwendungen gefragt ist, nicht über Azure.
- Eure Nutzer und ApplikationenFachanwendungen, Endanwender-Support, Freigabe des neuen Images in StagingIhr oder euer Partner*
- Use Cases je NutzergruppeDefine, Parameterize, Deploy, Validate, Go live, für jede weitere Gruppe auf derselben PlattformglueckkanjaCloud Workplace FoundationInfrastruktur als Code, monatlicher Image-Lifecycle, Intune Policies und Defender, RealmJoin, Monitoring und Alerting in eurem Tenant, monatliches Service ReviewCloud PCs: Microsoftglueckkanja
- Landing ZoneSubscriptions und Management Groups, Hub-Netzwerk, Governance als Code. Betreibt ihr oder euer Partner, mit der Azure Foundation übernehmen wir auch diese Schicht.Azure Foundation
Ohne Azure Foundation gehört euch die Landing Zone, alles darüber bis zu euren Fachanwendungen betreiben wir.
* Bei euch bleiben auch Funktionstests eurer Fachapplikationen, Microsoft-Lizenzen, Azure-Verbrauch und RealmJoin-Lizenzen.
Vom Ramp-up zu den ersten Nutzern
- Rahmen festlegenRahmen festlegenDas Ramp-up-Projekt: Design, Regeln, Berechtigungen und Prozesse. Wir legen mit euch fest, wie die Plattform in eurem Tenant aussieht und wer was darf.
- Foundation aufbauenFoundation aufbauenDas Foundation Setup: Infrastruktur, IaC-Pipelines, Intune Baselines, Netzwerk inklusive Azure Network Connection, Security und Tooling, alles als Code.
- Nutzergruppen ausrollenNutzergruppen ausrollenDie Use-Case-Deployments: je Nutzergruppe Define, Parameterize, Deploy, Validate, Go live. Parallel zum Foundation Setup oder später, auch mehrere gleichzeitig.
- Plattform betreibenPlattform betreibenManaged Operations: Monitoring, Image-Lifecycle, Evergreen, monatliches Service Review. Ab hier ist jede neue Nutzergruppe ein Use Case, kein Projekt.
Was davor und danach kommt
Ohne Folien, mit eurer Architektur
Das Briefing mit dem Azure-Team 60 Minuten
In 60 Minuten gehen wir eure Desktop-Landschaft durch: welche Nutzergruppen es gibt, welcher Desktop-Typ zu welcher passt und was Cloud Workplace Foundation davon übernimmt. Keine Folien, sondern eure Architektur auf dem Tisch, und am Ende ein Bild davon, wie eure Plattform aussähe. Ihr bekommt einen Terminvorschlag, keinen Vertriebsanruf.
NutzergruppenBestandWelche Gruppen heute auf welchen Desktops arbeiten und was als Nächstes ansteht
Desktop-TypenZuordnungPooled, Personal, Enterprise oder Frontline je Nutzergruppe, mit Begründung- BetriebsmodellZuständigkeitenWas glueckkanja übernimmt, was bei euch bleibt und was eure Landing Zone dafür braucht
Nächster SchrittRamp-upOb ein Ramp-up-Projekt der richtige Einstieg ist und was es von eurer Seite braucht
Fragen, die wir im ersten Gespräch hören
Kurz beantwortet. Wenn eure Frage fehlt, stellt sie uns unten.
Windows 365 wird doch von Microsoft gemanagt.
Ja, die Infrastruktur. Compute, Storage und die Bereitstellung der Cloud PCs liegen bei Microsoft, und genau deshalb braucht es dafür keine Image Factory. Netzwerk, Policies, Security Baselines und Applikationen liegen allerdings weiterhin bei euch, und dort setzt Cloud Workplace Foundation an: mit der Azure Network Connection, den Intune Blueprints, Defender for Endpoint und RealmJoin, auf dem Cloud PC genauso wie auf dem Session Host.
Wir haben schon Azure Virtual Desktop oder eine andere VDI.
Das passt. Cloud Workplace Foundation ist eine Plattform, keine Migration auf einen Schlag. Nutzergruppen ziehen als Use Cases nacheinander um, die bestehende Umgebung läuft so lange weiter, und am Ende betreibt ihr eine Welt statt zwei.
Unsere Apps brauchen Active Directory.
Meistens brauchen sie Kerberos, nicht den Domain Controller. Alle Hosts sind Entra ID joined, und über Entra Kerberos und Cloud Kerberos Trust bekommen ältere Anwendungen und Dateifreigaben ihr Kerberos-Ticket weiterhin. Einen klassischen AD Domain Join der Session Hosts unterstützt die Plattform bewusst nicht.
Wir wollen den Traffic der Session Hosts über Firewall oder Proxy filtern.
Zero Trust endet bei uns am Endpoint, nicht an der Firewall. Defender for Endpoint übernimmt Web- und Netzwerkschutz auf jedem Host, dadurch entfällt der zentrale Engpass im Pfad. Abweichende Designs mit Firewall oder Proxy sind möglich, allerdings ein Sonderaufwand außerhalb des Blueprints.
Brauchen wir dafür andere Managed Services von glueckkanja?
Nein. Cloud Workplace Foundation nutzt Entra ID, Intune, Defender und RealmJoin als Bausteine, setzt aber keinen anderen Managed Service voraus. Wer Managed Intune oder Managed Entra bereits hat, bekommt die virtuellen Desktops in denselben Blueprint. Wer nicht, bekommt die Plattform trotzdem komplett.
Welche Lizenzen brauchen wir?
Microsoft 365 E3 mit E5 Security und Intune Plan 1 als Basis. Für Windows 365 kommen die Enterprise- oder Frontline-Lizenzen je Nutzergruppe hinzu, für RealmJoin die RealmJoin-Lizenz. Die Lizenzen bleiben bei euch, Lizenzberatung ist nicht Teil des Service.
Wie lange dauert es bis zum ersten Desktop?
Das hängt an Landing Zone, Netzwerk und der ersten Nutzergruppe, deshalb nennen wir keine pauschale Zahl, die wir hinterher erklären müssten. Foundation Setup und erster Use Case laufen parallel, und im Briefing sagen wir euch für eure Landschaft, womit ihr rechnen könnt.
Wir sind reguliert und haben besondere Anforderungen an die Datenverarbeitung.
Dafür gibt es optional Azure Confidential VMs als Session Hosts, bei denen die Daten auch während der Verarbeitung verschlüsselt bleiben. Die Plattform selbst betreiben wir nach ISO 27001, und Monitoring sowie Log Analytics laufen in eurem eigenen Tenant.
Was ist nicht enthalten?
Die Landing Zone, die ihr entweder schon habt oder über die Azure Foundation bekommt, der Support für Endanwender, Funktionstests eurer Fachapplikationen, Windows Server oder andere Betriebssysteme als Session Host sowie Microsoft-Lizenzen, Azure-Verbrauch und RealmJoin-Lizenzen. Das Management physischer Geräte und MDM für iOS und Android sind nicht Teil der Plattform, als Erweiterung mit Managed Intune aber möglich.
