Sessiehostupdate voor Azure Virtual Desktop (preview)

Met sessiehostupdate kunt u het schijftype van de onderliggende virtuele machine (VM), de installatiekopie van het besturingssysteem en andere configuratie-eigenschappen van alle sessiehosts in een hostgroep bijwerken met een sessiehostconfiguratie. De toewijzing van de bestaande virtuele machines wordt bij de sessiehostupdate ongedaan gemaakt of verwijderd en er worden nieuwe gemaakt die met de bijgewerkte configuratie worden toegevoegd aan uw hostgroep. Deze methode voor het bijwerken van sessiehosts komt overeen met de aanbeveling om updates binnen de kernbroninstallatiekopie te beheren, in plaats van updates naar elke sessiehost afzonderlijk te distribueren en te installeren volgens een doorlopend herhaald schema om ze up-to-date te houden.

Dit zijn de wijzigingen die u kunt aanbrengen bij het uitvoeren van een update:

• Installatiekopieën van virtuele machines
• Grootte van virtuele machine
• Schijftype van virtuele machine
• Beveiligingstype virtuele machine:
  • Standaard
  • Vertrouwde virtuele machines starten
  • Vertrouwelijke virtuele machines
• Referenties voor Active Directory-domeindeelname
• Microsoft Intune-inschrijving
• Referenties van lokale beheerder
• Een PowerShell-script voor aangepaste configuratie uitvoeren

Nadat u een update van uw sessiehosts hebt voltooid met behulp van sessiehostupdate, worden alle sessiehosts in een hostgroep gestandaardiseerd met de wijzigingen die u hebt opgegeven. Andere Azure-eigenschappen van de sessiehosts, zoals de beschikbaarheidsconfiguratie, netwerkconfiguratie en locatie, blijven behouden voor alle updates.

Updateproces

U kunt het aantal sessiehosts in een hostgroep opgeven dat gelijktijdig moet worden bijgewerkt, ook wel een batch genoemd. Deze waarde is het maximum aantal sessiehosts dat tegelijkertijd niet beschikbaar is tijdens de update en alle resterende sessiehosts beschikbaar zijn voor gebruik. Wanneer een update wordt gestart, is er slechts één sessiehost (de initiële host genoemd) om te testen of het end-to-end-updateproces is geslaagd voordat u de rest van de sessiehosts in de groep in batches bijwerkt. Deze benadering minimaliseert de impact als er een fout optreedt.

Hier volgt een voorbeeld: als u een hostgroep met 10 sessiehosts hebt en u een batchgrootte van drie invoert, wordt één sessiehost (de eerste) bijgewerkt, waarna de resterende sessiehosts worden bijgewerkt in drie batches van drie sessiehosts. Op elk moment nadat de initiële sessiehost de update heeft voltooid, zijn er minimaal zeven sessiehosts beschikbaar voor gebruik in de hostgroep.

Tijdens een update volgt de sessiehostupdate dit proces:

1. Bestaande sessiehosts worden geselecteerd op basis van hun naam en de grootte van de eerder opgegeven batch. Een melding die is opgegeven door de beheerder wordt verzonden naar alle verbonden gebruikers. Vervolgens wacht de service op de duur die ook eerder is opgegeven voordat de resterende gebruikers worden afgemeldingen.

2. De geselecteerde sessiehosts worden in de drainmodus geplaatst en vervolgens verwijderd uit de hostgroep. Het computeraccount voor sessiehosts die zijn gekoppeld aan een Active Directory-domein, wordt niet verwijderd.

3. Hetzelfde aantal nieuwe sessiehosts wordt gemaakt met behulp van de bijgewerkte configuratie van de sessiehost. De nieuwe Azure-resources voor de VM, de besturingssysteemschijf en de netwerkinterface hebben de indeling SessionHostName-DateTime. Een bestaande VM met de naam VM1-0 wordt bijvoorbeeld vervangen door een nieuwe VM met de naam VM1-0-2023-04-15T17-16-07. De hostnaam van het besturingssysteem wordt niet gewijzigd. Deze nieuwe sessiehosts worden toegevoegd aan uw directory met behulp van Azure VM-extensies.

   Sessiehosts die zijn gekoppeld aan een Active Directory-domein, nemen de bestaande AD-computerobjecten over. Met dit proces wordt de vertrouwensrelatie tot stand brengen en wordt de bestaande vertrouwensrelatie met de vorige VM's verbroken.

4. De nieuwe sessiehosts worden gekoppeld aan de bestaande hostgroep en de drainmodus is uitgeschakeld en de sessiehosts kunnen verbindingen accepteren.

5. De oorspronkelijke VM's worden verwijderd.

Er kan slechts één sessiehostupdatebewerking worden uitgevoerd of gepland in één hostgroep tegelijk. U kunt echter updatebewerkingen voor sessiehosts uitvoeren op meerdere hostgroepen tegelijk.

De bestaande energiestatus en de afvoermodus van sessiehosts wordt gehonoreerd. U kunt een update uitvoeren op een hostgroep waarbij de toewijzing van alle sessiehosts ongedaan wordt gemaakt om kosten te besparen.

Virtuele machines en beheerhulpprogramma's

De nieuwe installatiekopieën moeten worden ondersteund voor Azure Virtual Desktop en de generatie van de virtuele machine en kunnen afkomstig zijn van:

• Azure Marketplace.

• Een bestaande gedeelde installatiekopieën van Azure Compute Gallery.

• Een bestaande beheerde installatiekopieën.

Wanneer sessiehostupdate nieuwe virtuele machines maakt, moet deze worden toegevoegd aan een map. U moet dezelfde map gebruiken als de bestaande VM's. U kunt de map niet wijzigen tijdens een update.

Aanpassingen, zoals bestanden, registersleutels of certificaten die handmatig zijn toegevoegd aan sessiehosts, zijn niet aanwezig nadat de update is voltooid. U kunt sessiehosts in de pool niet afzonderlijk bijwerken, dus u moet deze aanpassingen toevoegen aan de installatiekopie zelf, ervoor zorgen dat de aanpassingen worden toegepast door hulpprogramma's voor configuratiebeheer, zoals Intune of groepsbeleid, of deze aanpassingen toevoegen aan het aangepaste configuratie-PowerShell-script in de configuratie van de sessiehost.

Tijdens een update met sessiehosts die zijn gekoppeld aan Active Directory, worden computerobjecten niet verwijderd. Dit betekent dat er tijdelijk zwevende computerobjecten in Active Directory zijn. Wanneer de nieuwe virtuele machine wordt toegevoegd aan het domein, wordt de oorspronkelijke hostnaam gebruikt en wordt het zwevende computerobject overgenomen. Als u het domein wijzigt, moet u de zwevende computerobjecten uit het vorige domein verwijderen.

groepsbeleid-objecten (GPO's) worden gebruikt om beleid toe te passen op sessiehosts en worden meestal toegepast op OE-niveau in het Active Directory-domein. Er kunnen echter toepassingen/filters worden uitgevoerd met behulp van computerobjecten of groepsobjecten. Omdat de nieuwe VM's de zwevende computerobjecten overnemen, zijn bestaande GPO's nog steeds van toepassing. U moet ervoor zorgen dat bestaande GPO's nog steeds van toepassing zijn als u het OE-lidmaatschap wijzigt als onderdeel van het updateproces.

Plannings- en gebruikerssessies

Als er gebruikers zijn aangemeld bij een sessiehost wanneer deze begint met bijwerken, ontvangen ze de melding die is opgegeven door een beheerder. Gebruikers moeten zich afmelden en zich vervolgens opnieuw aanmelden. Gebruikers kunnen zich onmiddellijk opnieuw aanmelden om verbinding te maken met een andere sessiehost in de hostgroep.

Nieuwe verbindingen worden omgeleid naar sessiehosts die worden bijgewerkt om te voorkomen dat ze zich aanmelden bij een sessiehost die binnenkort wordt bijgewerkt, alleen als ze worden gewaarschuwd dat ze zich opnieuw moeten afmelden. Aan het begin van een update zijn er echter geen nieuwe bijgewerkte sessiehosts, dus gebruikers die zijn gevraagd zich af te melden en onlangs zijn aangemeld bij sessiehosts die nog moeten worden bijgewerkt, worden gewaarschuwd om zich opnieuw af te melden.

Met slechts een beperkt aantal sessiehosts dat beschikbaar is, moet u een update plannen op een geschikt moment voor uw bedrijf om onderbrekingen voor eindgebruikers te minimaliseren.

Bekende problemen en beperkingen

Hier volgen bekende problemen en beperkingen:

• Update van sessiehost ondersteunt alleen sleutelkluizen die zijn geconfigureerd om openbare toegang vanuit alle netwerken toe te staan.

• Sessiehostupdate is alleen beschikbaar in de globale Azure-cloud. Het is niet beschikbaar in andere clouds, zoals Azure Us Government of Azure beheerd door 21Vianet.

• Voor sessiehosts die zijn gemaakt op basis van een gedeelde installatiekopieën van Azure Compute Gallery met een aankoopplan, blijft het plan niet behouden wanneer de sessiehosts worden bijgewerkt. Als u wilt controleren of de installatiekopieën die u gebruikt voor uw sessiehosts een aankoopabonnement hebben, kunt u Azure PowerShell of Azure CLI gebruiken.

• Sessiehostconfiguraties bieden momenteel geen ondersteuning voor toegang tot een gedeelde installatiekopie van Azure Compute Gallery die zich in een ander Azure-abonnement bevindt dan de hostgroep.

• De grootte van de besturingssysteemschijf kan niet worden gewijzigd tijdens een update. De updateservice heeft standaard dezelfde grootte als die is gedefinieerd in de galerieafbeelding.

• Als een update mislukt, kan de hostgroep pas worden verwijderd als de update is geannuleerd.

• De voortgang van de update wordt alleen gewijzigd wanneer een sessiehost is bijgewerkt. Als voorbeeld: in een hostgroep met 10 sessiehosts, terwijl de eerste sessiehost wordt bijgewerkt, wordt de voortgang weergegeven als 0,00%. Dit wordt pas verplaatst naar 10% zodra de eerste sessiehost is bijgewerkt.

• Als u besluit een installatiekopie te maken die is genomen van een bestaande sessiehost die u vervolgens gebruikt als de broninstallatiekopie voor de update van de sessiehost, moet u de C:\packages\plugin map verwijderen voordat u de installatiekopie maakt. Anders voorkomt deze map dat de DSC-extensie wordt uitgevoerd die de bijgewerkte virtuele machines toevoegt aan de hostgroep.

• Als u Azure Virtual Desktop Insights gebruikt, wordt de Azure Monitor-agent of Log Analytics-agent niet automatisch geïnstalleerd op de bijgewerkte sessiehosts. Als u de agent automatisch wilt installeren, zijn hier enkele opties:

  • Voor de Azure Monitor-agent kunt u Azure Policy gebruiken.
  • Voor de Log Analytics-agent kunt u Azure Automation gebruiken.
  • Voeg deze nieuwe sessiehosts handmatig toe vanuit Azure Virtual Desktop Insights in de Azure Portal.

• Het wijzigen van een sessiehostconfiguratie in een hostgroep zonder sessiehosts op hetzelfde moment dat een sessiehost wordt gemaakt, kan leiden tot een hostgroep met inconsistente eigenschappen van de sessiehost en moet worden vermeden.

• Updates met grote batchgrootten kan leiden tot onregelmatige fouten met de foutcode AgentRegistrationFailureGeneric. Als dit gebeurt voor een subset van sessiehosts die wordt bijgewerkt, wordt het probleem meestal opgelost door de update opnieuw uit te voeren .

Volgende stappen

• Meer informatie over het bijwerken van sessiehosts in een hostgroep met een sessiehostconfiguratie met behulp van sessiehostupdate.