Update van sessiehost voor Azure Virtual Desktop (preview)
Belangrijk
Update van sessiehost voor Azure Virtual Desktop is momenteel in PREVIEW. Raadpleeg de Aanvullende voorwaarden voor Microsoft Azure-previews voor juridische voorwaarden die van toepassing zijn op Azure-functies die in bèta of preview zijn of die anders nog niet algemeen beschikbaar zijn.
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. Bijwerken van sessiehost wordt de toewijzing van de bestaande virtuele machines ongedaan gemaakt of verwijderd en worden nieuwe machines gemaakt die met de bijgewerkte configuratie aan uw hostgroep worden toegevoegd. Deze methode voor het bijwerken van sessiehosts is afgestemd op de aanbeveling om updates binnen de kernbroninstallatiekopie te beheren, in plaats van updates afzonderlijk te distribueren en te installeren naar elke sessiehost 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 virtuele machine
- Beveiligingstype van virtuele machine:
- Referenties voor Active Directory-domeindeelname
- Microsoft Intune-inschrijving
- Referenties van lokale beheerder
- Een powerShell-script voor een aangepaste configuratie uitvoeren
Nadat u een update van uw sessiehosts hebt voltooid met behulp van een 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 tussen updates.
Update-proces
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 tijdens de update niet beschikbaar is en alle resterende sessiehosts beschikbaar zijn voor gebruik. Wanneer een update wordt gestart, is er slechts één sessiehost gericht (ook wel de eerste host genoemd) om te testen of het end-to-end-updateproces is geslaagd voordat u verdergaat met het bijwerken van de rest van de sessiehosts in de pool in batches. Deze benadering minimaliseert de impact als er een fout optreedt.
Hier volgt een voorbeeld: als u een hostgroep met tien sessiehosts hebt en u een batchgrootte van drie invoert, wordt één sessiehost (de eerste) bijgewerkt, waarna de resterende sessiehosts in drie batches van drie sessiehosts worden bijgewerkt. 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 sessiehostupdate dit proces:
Bestaande sessiehosts worden geselecteerd op basis van hun naam en de grootte van de eerder opgegeven batch. Een melding die door de beheerder is opgegeven, wordt verzonden naar alle verbonden gebruikers. Vervolgens wacht de service op de eerder opgegeven duur voordat de resterende gebruikers worden afgemelding.
De geselecteerde sessiehosts worden in de afvoermodus geplaatst en vervolgens verwijderd uit de hostgroep. Het computeraccount voor sessiehosts die zijn toegevoegd aan een Active Directory-domein, wordt niet verwijderd.
Hetzelfde aantal nieuwe sessiehosts wordt gemaakt met behulp van de bijgewerkte configuratie van de sessiehost. De nieuwe Azure-resources voor de VM, besturingssysteemschijf en netwerkinterface hebben de indeling
SessionHostName-DateTime
, bijvoorbeeld een bestaande VM die wordt aangeroepenVM1-0
, wordt vervangen door een nieuwe VM met de naamVM1-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 toegevoegd aan een Active Directory-domein nemen de bestaande AD-computerobjecten over. Met dit proces wordt de vertrouwensrelatie tot stand brengt en wordt de bestaande vertrouwensrelatie met de vorige VM's verbroken.
De nieuwe sessiehosts worden gekoppeld aan de bestaande hostgroep en de afvoermodus is uitgeschakeld en de sessiehosts kunnen verbindingen accepteren.
De oorspronkelijke VM's worden de toewijzing ongedaan gemaakt of verwijderd, afhankelijk van of u ervoor hebt gekozen om de oorspronkelijke VM's op te slaan.
Er kan slechts één sessiehost-updatebewerking worden uitgevoerd of gepland in één hostgroep tegelijk. U kunt echter sessiehost-updatebewerkingen uitvoeren op meerdere hostgroepen tegelijk.
De bestaande energiestatus en de afvoermodus van sessiehosts wordt gehonoreerd. U kunt een update uitvoeren op een hostgroep waar alle sessiehosts de toewijzing ongedaan worden gemaakt om kosten te besparen.
Belangrijk
Als u Azure Virtual Desktop Insights gebruikt, wordt de Azure Monitor-agent of Log Analytics-agent niet automatisch geïnstalleerd op de bijgewerkte sessiehosts. Ga als volgt te werk om de agent automatisch te installeren:
- Voor de Azure Monitor-agent kunt u Azure Policy gebruiken.
- Voor de Log Analytics-agent kunt u Azure Automation gebruiken.
Houd rekening met quotumlimieten voor uw Azure-abonnement en overweeg een aanvraag in te dienen om een quotum te verhogen als een update de limiet overschrijdt.
U wordt aangeraden het updateproces te testen op een testhostgroep die is afgestemd op de hostgroep die u wilt bijwerken. Hiermee wordt het updateproces zelf getest en ook het resultaat van een nieuwe VIRTUELE machine met dezelfde naam als de vorige VM in uw omgeving. Het is ook belangrijk om te testen of updates, zoals nieuwe toepassingen of hotfixes, werken zoals verwacht in uw omgeving voordat u een productiehostgroep bijwerkt.
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 azure Compute Gallery-installatiekopieën.
Een bestaande beheerde installatiekopieën.
Als sessiehostupdate nieuwe virtuele machines maakt, moet deze worden gekoppeld 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. Voeg deze aanpassingen dus toe aan de installatiekopie zelf, zorg ervoor dat de aanpassingen worden toegepast door hulpprogramma's voor configuratiebeheer, zoals Intune of Groepsbeleid, of voeg deze aanpassingen toe aan het PowerShell-script voor aangepaste configuratie in de configuratie van de sessiehost.
Tijdens een update met sessiehosts die zijn toegevoegd aan Active Directory, worden computerobjecten niet verwijderd. Dit betekent dat er tijdelijk zwevende computerobjecten in Active Directory zijn. Wanneer de nieuwe virtuele machine is 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.
Groepsbeleidsobjecten (GPO's) worden gebruikt om beleid toe te passen op sessiehosts en worden doorgaans toegepast op OE-niveau in het Active Directory-domein. Er kan echter een toepassing/filter worden uitgevoerd met behulp van computerobjecten of groepsobjecten. Als de nieuwe VM's de zwevende computerobjecten overnemen, zijn bestaande GPO's nog steeds van toepassing. Zorg ervoor 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 wordt bijgewerkt, ontvangen ze de melding die is opgegeven door een beheerder, die gebruikers moet informeren om zich af te melden en vervolgens opnieuw aan te melden. 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, zodat ze zich alleen opnieuw kunnen afmelden. Aan het begin van een update zijn er echter geen onlangs bijgewerkte sessiehosts, zodat gebruikers die zijn gevraagd zich af te melden en onlangs zijn aangemeld bij sessiehosts, nog te worden bijgewerkt, worden gewaarschuwd om zich opnieuw af te melden.
Als er slechts een beperkt aantal sessiehosts 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 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, wordt het abonnement niet bewaard wanneer de sessiehosts worden bijgewerkt. Als u wilt controleren of de installatiekopieën die u voor uw sessiehosts gebruikt, een aankoopplan hebben, kunt u Azure PowerShell of Azure CLI gebruiken.
Update van sessiehost vereist momenteel toegang tot het openbare Azure Storage-eindpunt
wvdhpustgr0prod.blob.core.windows.net
om de RDAgent te implementeren. Totdat dit is gemigreerd naar een vereist eindpunt voor Azure Virtual Desktop, kunnen sessiehosts die geen toegangwvdhpustgr0prod.blob.core.windows.net
hebben, worden bijgewerkt met de foutCustomerVmNoAccessToDeploymentPackageException
.De grootte van de besturingssysteemschijf kan niet worden gewijzigd tijdens een update. De updateservice heeft standaard dezelfde grootte als gedefinieerd door de installatiekopieën van de galerie.
Als een update mislukt, kan de hostgroep pas worden verwijderd nadat de update is geannuleerd.
De voortgang van de update wordt alleen gewijzigd wanneer een sessiehost is bijgewerkt. In een hostgroep met 10 sessiehosts, terwijl de eerste sessiehost wordt bijgewerkt, wordt de voortgang weergegeven als 0,00%. Dit wordt slechts 10% zodra de eerste sessiehost is bijgewerkt.
Als u besluit een installatiekopie te maken die wordt gemaakt 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 u dat de DSC-extensie die de bijgewerkte virtuele machines aan de hostgroep toevoegt, wordt uitgevoerd.Als u Azure Virtual Desktop Insights gebruikt, wordt de Azure Monitor-agent of Log Analytics-agent niet automatisch geïnstalleerd op de bijgewerkte sessiehosts. Ga als volgt te werk om de agent automatisch te installeren:
- 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 Azure Portal.
Het wijzigen van de configuratie van een sessiehost in een hostgroep zonder sessiehosts tegelijk dat een sessiehost wordt gemaakt, kan leiden tot een hostgroep met inconsistente eigenschappen van de sessiehost en moet worden vermeden.
Updates met grote batchgrootten kunnen leiden tot onregelmatige fouten met de foutcode
AgentRegistrationFailureGeneric
. Als dit gebeurt voor een subset van sessiehosts die worden bijgewerkt, wordt het probleem meestal opgelost door de update opnieuw uit te voeren.