Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Richtlinien für das Onboarding von Bewerbungen
Bevor Sie eine Anwendung für Endbenutzer über WorkSpaces Anwendungen verfügbar machen, überprüfen Sie, ob die Anwendung in der WorkSpaces Applications Cloud-Umgebung ordnungsgemäß funktioniert, stellen Sie sicher, dass die Anwendung ohne Rendering-Artefakte gestreamt werden kann, und dimensionieren Sie Ihre Flotte entsprechend dem Ressourcenprofil der Anwendung. Diese Seite enthält eine strukturierte Onboarding-Checkliste, die Sie für jede Anwendung, die Sie streamen möchten, befolgen können. Wenn Sie mehrere Sitzungen verwenden möchten, müssen Sie besonders darauf achten, dass mehrere Versionen der Anwendung auf demselben Host ausgeführt werden können. Wenn Sie den systemeigenen Anwendungsmodus verwenden möchten, müssen Sie sicherstellen, dass die Anwendung keine Kompatibilitätsprobleme mit diesem Modus aufweist.
Diese Richtlinien gelten unabhängig davon, ob Sie eine neue Anwendung integrieren oder eine bestehende Anwendung aus einem anderen Bereitstellungsmodell migrieren.
Überblick über den Onboarding-Prozess
Das Onboarding einer Anwendung in WorkSpaces Applications erfolgt in zwei parallel Schritten:
-
Überprüfung der Anwendungskompatibilität: Stellen Sie sicher, dass sich die Anwendung in der Streaming-Umgebung in allen Funktionen, auf die sich Ihre Benutzer verlassen, korrekt verhält.
-
Instance-Größe und Kapazitätsplanung: Wählen Sie einen Instance-Typ und eine Flottenskalierungsrichtlinie, die dem CPU-, Arbeitsspeicher- und GPU-Profil der Anwendung und Ihrer erwarteten Anzahl gleichzeitiger Benutzer entsprechen.
Wir empfehlen, zuerst die Kompatibilitätsprüfung durchzuführen (für einen Image Builder und eine Pilotflotte) und dann die Messungen aus dieser Validierung zu verwenden, um Entscheidungen zur Instanzgröße zu treffen.
Teil 1: Validierung der Anwendungskompatibilität
Allgemeine Kompatibilität
WorkSpaces Applications richtet eine Streaming-Sitzung in dieser Reihenfolge ein:
Der Client des Benutzers stellt eine Verbindung zu einer Streaming-Instanz her.
Der Benutzer ist bei der Serverbetriebssystemsitzung auf der Instanz angemeldet.
Die Anwendung wird gestartet.
Die Streamingsitzung beginnt. Zu diesem Zeitpunkt werden Umgebungseinstellungen angewendet, die vom Client abhängen (z. B. Bildschirmauflösung des Clients, DPI, Zeitzone des Clients und vom Client umgeleitete Geräte wie Drucker).
Da clientabhängige Umgebungseinstellungen nach dem Start der Anwendung angewendet werden, reagiert eine Anwendung, die diese Werte beim Start nur einmal liest, nicht auf die tatsächliche Client-Konfiguration des Benutzers. Überprüfen Sie Folgendes:
Die Anwendung liest oder abonniert Änderungen der Bildschirmauflösung, DPI und Zeitzone nach dem Start, oder Sie konfigurieren die Streaming-Instance mit Standardwerten, die Ihrer Benutzerpopulation entsprechen, bevor der Client eine Verbindung herstellt.
Die Anwendung toleriert, dass sich die lokale Zeitzone des Benutzers von der Zeitzone der Streaming-Instanz unterscheidet.
Die Anwendung schlägt nicht fehl oder hängt nicht, wenn der Client während der Sitzung die Verbindung trennt und wieder herstellt.
Multi-session Kompatibilität
Wenn Sie die Anwendung auf einer Flotte mit mehreren Sitzungen ausführen möchten, überprüfen Sie Folgendes auf einem Image Builder und einer Pilotflotte mit zwei oder mehr gleichzeitigen Benutzern:
Die Lizenz der Anwendung ermöglicht gleichzeitige Mehrbenutzersitzungen auf einer einzelnen Serverinstanz. Die Geräte- oder Benutzerlizenzen einiger Anwendungen verbieten diese Konfiguration ausdrücklich.
Benutzerprofile, Anwendungseinstellungen und Benutzerdaten werden zwischen den Sitzungen isoliert. Testen Sie, ob eine Änderung, die ein Benutzer vornimmt, für einen anderen gleichzeitigen Benutzer nicht sichtbar ist.
User-specific Daten werden in benutzerspezifische Speicherorte wie
%APPDATA%und geschrieben%LOCALAPPDATA%, nicht in gemeinsam genutzte Verzeichnisse wieC:\Program Filesoder.C:\ProgramDataDie Anwendung ist nicht auf Systemdienste angewiesen, die von allen Sitzungen gemeinsam genutzt werden, oder solche Dienste können mehrere gleichzeitige Sitzungen korrekt verarbeiten.
Die Anwendung enthält keine fest codierten Pfade, die von einer Einzelbenutzerumgebung ausgehen.
In den Dialogen der Systemgeräte werden nur die vom aktuellen Benutzer umgeleiteten Geräte wie Scanner und Drucker aufgeführt, nicht alle Geräte, die für den Server sichtbar sind.
Beim Öffnen und Speichern von Dateien werden zugeordnete Clientlaufwerke und umgeleitete Ordner für den aktuellen Benutzer korrekt aufgelöst.
Für das Installationsprogramm, den Updater und alle Hintergrundprozesse der Anwendung ist kein interaktiver Administratorzugriff erforderlich, solange die Benutzer angemeldet sind.
Anmerkung
Multi-session Flotten unterstützen derzeit keine Webcam, kein Dynamic Application Framework und keine Smartcard-Authentifizierung. Wenn Sie eine dieser Funktionen benötigen, empfehlen wir Ihnen, Flotten mit einer einzigen Sitzung zu verwenden.
Kompatibilität mit dem systemeigenen Anwendungsmodus
Im systemeigenen Anwendungsmodus wird jede Remoteanwendung als separates Fenster auf dem lokalen Gerät des Benutzers mit einem eigenen Taskleistensymbol gestreamt. Anwendungen, die im klassischen Modus ordnungsgemäß funktionieren, können sich im nativen Anwendungsmodus anders verhalten, da Fensterverwaltung, Fokus und Rendern unterschiedlich gehandhabt werden. Einen Überblick über die Funktion finden Sie unter Nativer Anwendungsmodus.
Überprüfen Sie Folgendes im nativen Anwendungsmodus auf einem Image Builder und einer Pilotflotte:
Fensteranzeige: Alle Anwendungsfenster, einschließlich Dialoge, Begrüßungsbildschirme und modaler Eingabeaufforderungen, werden korrekt angezeigt und können interagiert werden. Achten Sie besonders auf Fenster, die manuell und nicht mit den standardmäßigen Windows-UI-Toolkits gezeichnet werden (z. B. individuell gerenderte Begrüßungsbildschirme oder Startdialoge, die vor dem Hauptfenster angezeigt werden). Bei diesen ist es wahrscheinlicher, dass Kompatibilitätsprobleme auftreten.
Transparente oder nicht rechteckige Fenster: Suchen Sie nach Fenstern mit transparenten Bereichen oder mit abgerundeten oder nicht rechteckigen Formen (z. B. Ballonspitzen, benutzerdefinierte QuickInfos oder Fenster mit Haut). Diese werden im nativen Anwendungsmodus möglicherweise nicht richtig gerendert.
Taskleiste: Anwendungen, die den Windows-Infobereich (Taskleiste) benötigen, werden derzeit im systemeigenen Anwendungsmodus nicht unterstützt. Wenn Ihre Anwendung ein Taskleistensymbol nur für sekundäre Funktionen verwendet, stellen Sie sicher, dass der Kernworkflow auch dann funktioniert, wenn die Taskleiste nicht verfügbar ist.
DPI-Erkennung: Streaming-Sitzungen können mit Auflösungen und DPI-Einstellungen ausgeführt werden, die sich von denen des lokalen Clients unterscheiden. Ist dies bei der Anwendung nicht der DPI-aware Fall, skaliert Windows selbst die Ausgabe, was zu unscharfem Rendern führt. Testen Sie auf mindestens einem Client mit einer anderen DPI-Skalierung als 100% (z. B. auf einem Laptop mit hohem DPI-Wert von 125% oder 150%).
Multi-window Workflows: Testen Sie Workflows, die sich über mehrere Anwendungsfenster erstrecken (z. B. das Wechseln zwischen einem Hauptfenster und einem modalen Dialog oder zwischen zwei Dokumenten, die in separaten Fenstern geöffnet werden). Vergewissern Sie sich, dass sich die Fokusübergänge und die Aktivierung durch Klicken auf die Taskleiste erwartungsgemäß verhalten.
Alt+Tab und Verhalten in der Taskleiste: Wechseln Sie zwischen der Anwendung und anderen lokalen Anwendungen, indem Sie Alt+Tab verwenden und auf das Taskleistensymbol klicken. Die Remoteanwendung sollte in den Vordergrund treten, ohne dass externe Fenster angezeigt werden, die nichts miteinander zu tun haben.
Modale Dialoge: Wenn ein modaler Dialog in der Remote-Anwendung geöffnet ist, sollte das darunter liegende Remote-Fenster korrekt anzeigen, dass er deaktiviert ist, und wenn Sie darauf klicken, sollte das Modal blinken oder aktiviert werden.
Druck-Workflows: Drucken Sie aus der Anwendung heraus und stellen Sie sicher, dass der Druckdialog sichtbar ist (nicht hinter dem Hauptfenster versteckt) und dass die umgeleiteten Drucker aufgelistet sind. Die von einigen Druckertreibern angezeigten Druckdialoge sind möglicherweise an das falsche Fenster angehängt. Wenn Sie dies beobachten, sollten Sie erwägen, den DCV PDF Printer anstelle von Microsoft Print to PDF zu verwenden.
Andocken von Browser-Tabs: Wenn Benutzer während einer Streaming-Sitzung im nativen Anwendungsmodus versuchen, Tabs in einem Browserfenster in separaten Fenstern anzudocken oder abzudocken, funktioniert der Remote-Streaming-Browser nicht auf die gleiche Weise wie ein lokaler Browser. Benutzer müssen die Alt-Taste drücken, bis die Tabs an separaten Browserfenstern angedockt sind. Wenn Ihre Benutzer häufig das Abdocken von Tabs bevorzugen, sollten Sie für dieses Verhalten eine Benutzerschulung einplanen.
Moduswechsel: Testen Sie, ob die Anwendung weiterhin funktioniert, wenn der Benutzer während einer Sitzung zwischen dem systemeigenen Anwendungsmodus und dem klassischen Modus wechselt.
Wir empfehlen, die Validierung des systemeigenen Anwendungsmodus mit einer Pilotbenutzergruppe zu beginnen und alle anwendungsspezifischen Einschränkungen vor der vollständigen Bereitstellung zu dokumentieren. Das Verhalten und die Leistung von Anwendungen können je nach Streaming-Modus variieren, sodass Tests im klassischen Modus kein Ersatz für Tests im nativen Anwendungsmodus sind.
Handhabung und Umleitung von Dateien
Öffnen und speichern Sie Dateien von und auf zugewiesenen Clientlaufwerken und umgeleiteten Ordnern.
Wenn die Anwendung temporäre Dateien verwendet, stellen Sie sicher, dass diese in temporäre Benutzerverzeichnisse geschrieben werden.
Testen Sie Operationen mit großen Dateien über den Dateiübertragungsmechanismus der Sitzung, wenn Ihre Benutzer mit Dateien arbeiten, die größer sind als die typische Größe der Streaming-Sitzung.
Testen Sie das Drucken auf jedem umgeleiteten Druckertyp, den Ihre Benutzer verwenden werden (Netzwerkdrucker, Microsoft Print to PDF, PDF-Druckertreiber wie der DCV-PDF-Drucker und umgeleitete Drucker von Drittanbietern).
Testen Sie das Drucken in jeder Anwendung, die über einen Druckworkflow verfügt, einschließlich Anwendungen, die Webinhalte (z. B. Chromium-based Ansichten) einbetten.
Überprüfen Sie das Verhalten des Druckdialogs im systemeigenen Anwendungsmodus (siehe voriger Abschnitt).
Interaktionen mit lokalen Geräten
Audioeingang und -ausgang (Mikrofon, Lautsprecher und Headsets).
Webcam, falls sie von der Anwendung verwendet wird.
USB-Geräteumleitung, falls von der Anwendung verwendet. Eine Liste der unterstützten Geräte finden Sie unter USB-Geräteumleitung.
Smartcard-Authentifizierung, falls von der Anwendung verlangt.
Netzwerkleistung
Messen Sie die Reaktionsfähigkeit der Anwendung über eine Netzwerkverbindung, die für Ihren Benutzer im schlimmsten Fall repräsentativ ist (z. B. ein Remote-Benutzer mit einer Breitbandverbindung für Privatanwender mit einer Hin- und Rücklaufzeit von 100 ms). Streaming-Sitzungen reagieren empfindlich auf Round-Trip-Zeit und Paketverlust.
Stellen Sie sicher, dass die Anwendung kurze Netzwerkunterbrechungen und Sitzungswiederverbindungen toleriert.
Multi-monitor Unterstützung
Testen Sie Workflows, die sich über mehrere Monitore auf der Clientseite erstrecken.
Wenn die Anwendung die Monitorgeometrie liest, vergewissern Sie sich, dass sie das Monitorlayout des Clients liest, nicht das Layout der Streaming-Instanz.
Audio- und Videofunktionen
Real-time Audio-Video-Szenarien (in die Anwendung eingebettete Tools für Sprach-, Videokonferenzen und Zusammenarbeit) erfordern höhere Bildraten und möglicherweise einen größeren Instance-Typ. Siehe Teil 2: Instanzgröße und Kapazitätsplanung.
Validierungsumgebung
Führen Sie die Prüfungen in diesem Abschnitt zunächst in einem Image Builder und dann in einer Pilotflotte mit einer kleinen Gruppe repräsentativer Benutzer durch, bevor Sie das Image für Ihre gesamte Benutzerbasis bereitstellen. Verlassen Sie sich nicht auf Tests im klassischen Modus als Ersatz für Tests im systemeigenen Anwendungsmodus.
Teil 2: Instanzgröße und Kapazitätsplanung
Wählen Sie eine Instance-Familie
Wählen Sie eine Instanzfamilie auf der Grundlage des Ressourcenprofils der Anwendung aus. Hardwarespezifikationen und Preise finden Sie unter WorkSpaces Instanzfamilien für WorkSpaces Anwendungen und Preise für Anwendungen
| Anwendungsprofil | Empfohlene Instanzfamilie |
|---|---|
| Office, Webbrowser, die meisten Branchenanwendungen | Allgemeine Zwecke |
| Compute-bound Anwendungen (umfangreiche clientseitige Berechnungen, lokale Analysen) | Für Datenverarbeitung optimiert |
| Memory-intensive Anwendungen (große Datensätze im Speicher, In-Memory-Datenbanken) | RAM-optimiert |
| Grafikanwendungen, die DirectX, OpenGL oder OpenCL verwenden | Grafiken der G4dn-, G5- oder G6-Familie |
| Real-time Audio-Video für Szenarien mit hoher Bildrate | Erhöhen Sie die Instance-Größe innerhalb der ausgewählten Familie. Ziehen Sie eine Instanz der Graphics-Produktreihe in Betracht, wenn die Anwendung auch GPU-Beschleunigung verwendet |
Jede WorkSpaces Anwendungsinstanz verfügt über ein Laufwerk C mit fester Größe von 200 GB, das nach jeder Benutzersitzung gelöscht wird. Verlassen Sie sich für Benutzerdaten nicht auf instanzlokalen Speicher, sondern verwenden Sie Basisordner, Dateifreigaben oder Profilverwaltung für die Persistenz.
Passen Sie die Größe einer Instanz für einen einzelnen Benutzer an
Bevor Sie die Größe für gleichzeitige Benutzer anpassen, messen Sie den Ressourcenverbrauch der Anwendung für eine einzelne Sitzung:
Stellen Sie einen Image Builder mit der kleinsten Instanzgröße in der ausgewählten Familie bereit, der die angegebenen Mindestanforderungen der Anwendung erfüllt.
Melden Sie sich als Einzelbenutzer an und führen Sie den repräsentativen Workload durchgängig aus. Schließen Sie alle Abhängigkeiten ein, die in der Streaming-Sitzung ausgeführt werden sollen (z. B. Hintergrundsynchronisierungsclients, Security Agents und Profilverwaltungsclients).
Messen Sie mit dem Windows Performance Monitor oder einem vergleichbaren Tool: Spitzenauslastung und andauernde CPU-Auslastung, Spitzenauslastung und Dauerauslastung des Arbeitsspeichers (private Byte), I/O Festplattenrate und, falls zutreffend, GPU-Auslastung und Videospeicher.
Wenn die CPU-Spitzenleistung bei normalen Workflows etwa 80% oder der maximale Arbeitsspeicher etwa 75% der Instance-Kapazität übersteigt, wechseln Sie zur nächsten Instance-Größe.
Lassen Sie Spielraum für das Windows Server-Betriebssystem, den WorkSpaces Applications Agent, Amazon DCV, Anti-Malware und alle anderen Management-Agenten. Als Faustregel gilt, dass auf einer Einzelsitzungsinstanz etwa 1 vCPU und 1 GB Arbeitsspeicher für den Basissystem-Overhead reserviert werden sollten.
Größe für Flotten mit mehreren Sitzungen
Multi-session Flotten führen mehrere Benutzer gleichzeitig auf einer einzigen Windows Server-Instanz aus. Die unterstützte maximale Anzahl von Benutzern pro Instanz hängt von der Instanzgröße und dem Ressourcenprofil der Anwendung ab.
Beginnen Sie mit Ihrer Einzelbenutzer-Messung (aus dem vorherigen Abschnitt).
Wenden Sie einen Parallelitätsmultiplikator an, der auf dem Verhalten der Anwendung basiert. Für Anwendungen, deren Ressourcenprofil überwiegend inaktiv ist (z. B. interaktiv genutzte Office-Anwendungen), sollten Sie die gesamte CPU- und Speicherauslastung so einplanen, dass sie ungefähr linear mit der Benutzerzahl skaliert, jedoch mit einer Reduzierung um 20-30% aufgrund des gemeinsam genutzten Betriebssystem-Overheads einhergeht. Für Anwendungen mit einem durchgängig aktiven Ressourcenprofil (z. B. Datenverarbeitungstools oder Browser, in denen umfangreiche Webanwendungen ausgeführt werden), sollten Sie eine nahezu lineare Skalierung ohne Reduzierung einplanen.
Berechnen Sie die maximale Anzahl von Benutzern pro Instanz als Kandidat wie folgt:
max_users_per_instance = min( (instance_vcpus - 1) / peak_single_user_vcpus_under_concurrency, (instance_memory_gb - 1) / peak_single_user_memory_gb_under_concurrency )
Überprüfen Sie den Kandidatenwert in einem echten Pilotprojekt mit mehreren Sitzungen. Führen Sie einen Test mit der Kandidatenanzahl gleichzeitiger Benutzer durch (z. B. mit einem Tool zur Lastgenerierung oder mit tatsächlichen Pilotbenutzern). Überwachen Sie die CPU-Auslastung (Ziel weniger als 80% zu Spitzenzeiten, weniger als 70% dauerhaft), den verfügbaren Arbeitsspeicher (Ziel mehr als 15% des Gesamtspeichers zu Spitzenzeiten), die Länge der Festplattenwarteschlange (Ziel weniger als 2 dauerhaft) und die Reaktionsfähigkeit von DCV-Sitzungen (subjektiv — fühlt sich die Sitzung interaktiv an?).
Wenn das Pilotprojekt eines dieser Ziele nicht erfüllt, reduzieren Sie die maximale Benutzeranzahl pro Instanz um eins und führen Sie den Test erneut durch. Wenn das Pilotprojekt problemlos bestanden wird, können Sie die maximale Anzahl von Benutzern pro Instanz um eins erhöhen und den Test erneut durchführen oder Spielraum für Workload-Spitzen lassen.
Konfigurieren Sie die Flottenskalierung
Nachdem Sie die maximale Anzahl an Benutzern pro Instanz ermittelt haben, konfigurieren Sie die Flottenskalierung auf der Grundlage Ihrer erwarteten Anzahl gleichzeitiger Benutzer im Laufe der Zeit. Die vollständigen Mechaniken finden Sie unter Fleet Auto Scaling for WorkSpaces Applications. In diesem Abschnitt werden die Entscheidungen zusammengefasst, die Sie im Rahmen des Onboardings treffen sollten.
Mindestkapazität. Dieser Wert basiert auf der niedrigsten zu erwartenden Anzahl gleichzeitiger Benutzer während der Geschäftszeiten, geteilt durch die Benutzer pro Instanz. Die Bereitstellung dauert mehrere Minuten pro Instanz. Eine Mindestkapazität von Null oder ein zu niedriger Wert kann also dazu führen, dass Benutzer zu Beginn des Arbeitstages auf den Start einer Instanz warten. Für vorhersehbare Anlaufzeiten am Morgen sollten Sie eine geplante Skalierungsrichtlinie verwenden, um die Mindestkapazität vor Beginn des Arbeitstages zu erhöhen und vor dem Ende des Arbeitstages zu verringern.
Maximale Kapazität. Legen Sie eine Obergrenze fest, die maximale Anzahl gleichzeitiger Benutzer zuzüglich einer Sicherheitsmarge berücksichtigt. Der Spitzenwert beträgt in der Regel das 1,2- bis 1,5-fache des Durchschnitts während der Geschäftszeiten. Messen Sie jedoch Ihren eigenen Traffic, um diesen Wert genau festzulegen.
Zielauslastung. Verwenden Sie für Flotten mit unvorhersehbarer Nachfrage eine Skalierungsrichtlinie für die Zielverfolgung. Wählen Sie eine Zielauslastung, die Ihre erwartete Benutzerfluktuationsrate (Kundenabwanderung) innerhalb eines Zeitfensters von 15 Minuten
100% - target utilizationübersteigt. Wenn beispielsweise 10% der Benutzer Sitzungen innerhalb eines beliebigen Zeitfensters von 15 Minuten beginnen und beenden, legen Sie das Ziel auf 90% oder weniger fest. Weitere Informationen finden Sie im Whitepaper unter Best Practices for Scaling Policy Design.InsufficientCapacityError Alarm. Erstellen Sie einen CloudWatch Amazon-Alarm für die
InsufficientCapacityErrorMetrik für jede Flotte, sodass Administratoren benachrichtigt werden, wenn die automatische Skalierung nicht mit der Nachfrage Schritt halten kann.
Führen Sie eine umfassende Validierung mit einem Pilotprojekt durch
Bevor Sie eine Anwendung für alle Benutzer bereitstellen, führen Sie ein Pilotprojekt mit 10—50 Benutzern für mindestens eine volle Geschäftswoche durch. Während des Pilotprojekts:
Vergewissern Sie sich, dass die Ergebnisse der Anwendungskompatibilitätsprüfung aus Teil 1 auch für reale Benutzerarbeitslasten gelten.
Vergewissern Sie sich, dass die gewählte Instance-Größe die beobachtete maximale Anzahl gleichzeitiger Benutzer pro Instanz unterstützt.
Vergewissern Sie sich, dass die Richtlinie zur Flottenskalierung den Start des Tages und den Rampdown am Tagesende ohne Ereignisse berücksichtigt.
InsufficientCapacityErrorSammeln Sie Feedback von Pilotbenutzern zur Reaktionsfähigkeit der Sitzung und zum Anwendungsverhalten.
Checkliste für das Onboarding
Verwenden Sie diese Checkliste, um den Status jeder Anwendung zu verfolgen, die Sie aufnehmen.
Anwendungskompatibilität
Die Anwendungslizenz ermöglicht die vorgesehene Bereitstellung (Einzelsitzung oder Mehrfachsitzung, gleichzeitige Benutzer).
Allgemeine Kompatibilitätsprüfungen bestehen (clientabhängige Einstellungen werden nach dem Start der Anwendung angewendet).
Multi-session Die Kompatibilitätsprüfungen wurden bestanden (wenn Flotten mit mehreren Sitzungen ausgewählt wurden).
Die Prüfungen im systemeigenen Anwendungsmodus bestehen (Fenster, Dialoge, Tray, DPI, Fokus, Druck und Moduswechsel).
Die Prüfungen zur Dateiverarbeitung und Umleitung sind erfolgreich.
Druck-Workflows wurden für alle umgeleiteten Druckertypen validiert, die Benutzer verwenden werden.
Lokale Geräteinteraktionen (Audio, Webcam, USB und Smartcard) wurden für alle Geräte validiert, die Benutzer verwenden werden.
Multi-monitor Workflows wurden validiert.
Größe und Kapazität der Instanzen
Die Instanzfamilie wurde auf der Grundlage des Anwendungsressourcenprofils ausgewählt.
Single-user mit einem Image Builder gemessener Ressourcenverbrauch.
Die maximale Anzahl von Benutzern pro Instanz wurde in einem Pilotprojekt mit mehreren Sitzungen berechnet und validiert (falls zutreffend).
Konfiguration der Flottenskalierungsrichtlinie (Mindestkapazität, maximale Kapazität, Zielauslastung oder geplante Skalierung).
InsufficientCapacityErrorAlarm konfiguriert.
Pilotprojekt und Rollout
Pilotbetrieb mit 10—50 Benutzern für mindestens eine Geschäftswoche.
Das Feedback des Pilotprojekts wurde überprüft und alle Blockierungsprobleme wurden behoben.
Die Anwendung wurde für die Schulung von Endbenutzern dokumentiert (einschließlich aller bekannten Verhaltensweisen im nativen Anwendungsmodus, wie z. B. das Andocken von Browser-Tabs mit der Alt-Taste).
Mit den Stakeholdern vereinbarter Einführungsplan