IntroductionNote:
You can manage your Citrix Virtual Apps and Desktops deployment using two management consoles: Web Studio (web-based) and Citrix Studio (Windows-based). This article covers only Web Studio. For information about Citrix Studio, see the equivalent article in Citrix Virtual Apps and Desktops 7 2212 or earlier.
You can add or remove machines from a machine catalog, rename, change the description, or manage a catalog’s Active Directory computer accounts.
Maintaining catalogs can also include making sure that each machine has the latest OS updates. Including antivirus updates, operating system upgrades, or configuration changes.
For information about creating and managing connections to host hypervisors, see Connections and resources.
About persistent instancesNote:
MCS does not support Windows 10 IoT Core and Windows 10 IoT Enterprise. Refer to the Microsoft site for more information.
When updating an MCS catalog created using persistent, or dedicated instances, any new machines created for the catalog use the updated image. Pre-existing instances continue to use the original instance. The process of updating an image is done the same way for any other type of catalog. Consider the following:
You can manage a machine catalog in two ways:
Use Web StudioThis section details how you can manage catalogs using Web Studio:
- if the catalog is at the root level. VDA Upgrade VDA Upgrade State. Possible values include: Not configured, Scheduled, Available, and Up to date. Image Status The image update status of the catalog. Applicable only to non-persistent machine catalogs. Possible values include: Fully updated, Partially updated, Pending updates, Preparing Add machines to a catalog
Before you start:
To add machines to a catalog:
The machines are created as a background process, and can take much time when creating many machines. Machine creation continues even if you close Web Studio.
Delete machines from a catalogAfter you delete a machine from a machine catalog, users can no longer access it, so before deleting a machine, ensure that:
To delete machines from a catalog:
Choose whether to delete the machines being removed. If you choose to delete the machines, indicate if the Active Directory accounts for those machines are kept, disabled, or deleted.
Edit a catalogOn the NIC page, perform the following actions:
Only those subnets present in the host associated with the catalog appear in the Associated Network field.
You can only add NIC to Azure machine catalogs without machine profiles.
Note:
- For AWS machine catalogs, you cannot map the same subnet to more than one NIC.
- For machine catalogs with machine profiles, the number of NICs on the catalog must be equal to the number of NICs on the machine profile.
- This feature is not supported for IBM Cloud hypervisors.
- This feature is supported only for Nutanix Prism Element in case of Nutanix hypervisors.
You might see other pages depending on the catalog type.
For catalogs created using an Azure Resource Manager image, the following pages are visible. Keep in mind that changes you make apply only to machines you add to the catalog later. Existing machines remain unchanged.
On the Virtual Machines page, change the machine size and availability zones where you want to create machines.
Note:
- Only the machine sizes that the catalog supports are shown.
- If necessary, select Show only machine sizes used in other machine catalogs to filter the machine size list.
On the Machine Profile page, choose whether to use or change a machine profile.
(Visible only when the catalog is configured with a dedicated group host) On the Dedicated host group page, choose whether to change a host group.
On the Storage and License Types page, choose whether to change the storage type, license type, and Azure Computer Gallery settings (available only when Place prepared image in Azure Gallery is in use).
Note:
If the newly selected setting doesn’t support the current machine size, a warning dialog box appears, informing you that changing the setting resets the machine size setting. If you choose to continue, a red dot appears next to the Virtual Machines menu, prompting you to select a new machine size.
For Remote PC Access catalogs, the following pages are visible:
If your deployment has more than one zone, you can move a catalog from one zone to another.
Moving a catalog to a different zone, other than the hypervisor containing the VMs in that catalog, affects performance.
Before deleting a catalog, ensure that:
To delete a catalog:
To convert a non-machine profile-based machine catalog to a machine profiled-based machine catalog, complete the following steps:
Manage Active Directory computer accounts in a catalogNote:
Currently, this feature is supported only for Azure, AWS, and VMware.
To manage Active Directory accounts in a machine catalog, you can:
To manage Active Directory accounts:
Choose whether to add or delete computer accounts. If you add accounts, specify what to do with the account passwords: either reset them all or enter a password that applies to all accounts.
You might reset passwords if you do not know the current account passwords; you must have permission to perform a password reset. When entering a password, the password is changed on the accounts as they are imported. When deleting an account, choose whether the account in Active Directory is kept, disabled, or deleted.
Indicate if Active Directory accounts are retained, disabled, or deleted when you remove machines from a catalog or delete a catalog.
Update a catalogWe recommend that you save copies or snapshots of master images before updating the machines in the catalog. The database keeps a historical record of the master images used with each machine catalog. Roll back, or revert, machines in a catalog to use the previous version of the master image. Perform this task if users encounter problems with updates you deployed to their desktops. This minimizes user downtime. Do not delete, move, or rename master images. You cannot revert a catalog to use them.
After a machine is updated, it restarts automatically.
Update or create a master imageBefore you update the machine catalog, either update an existing master image or create one on your host hypervisor.
To prepare and roll out the update to all machines in a catalog:
Tip:
For an MCS-created catalog, you can annotate its image by adding a note for the image. A note can contain up to 500 characters. Each time you change the master image, a note-related entry is created whether you add a note. If you update a catalog without adding a note, the entry appears as null (-). To view note history for the image, select the catalog, click Template Properties in the low pane, and then click View note history.
Note:
The Rollout Strategy page is not available for persistent VMs because rollout is only applicable to non-persistent VMs.
To track the update progress, locate the catalog in Machine Catalogs to view the inline progress bar and the step-by-step progress graph.
When updating a catalog using PowerShell SDK directly, rather than Web Studio, specify a hypervisor template (VMTemplates). Use this as an alternative to an image or a snapshot of an image.
To roll out a new master image to Azure based machine catalog:
Rollout strategy:
Updating images on the next shutdown will immediately affect any machines not currently in use, that is, machines that do not have an active user session. A system that is in use receives the update when the current active session ends. Consider the following:
Roll back the master imageTip:
Limit the number of machines being rebooted by using the advanced settings for a host connection. Use these settings to modify the actions taken for a given catalog; advanced settings vary depending on the hypervisor.
After you roll out an updated or new master image, you can roll it back. This process might be necessary if issues occur with the newly updated machines. When you roll back, machines in the catalog are rolled back to the last working image. Any new features that require the newer image are no longer available. As with the rollout, rolling back a machine includes a restart.
The rollback is applied only to machines that need to be reverted. Machines that are not updated with the new or updated master image do not receive notification messages and are not forced to log off.
To track the rollback progress, locate the catalog in Machine Catalogs to view the inline progress bar and the step-by-step progress graph.
Change the functional level or undo the changeChange the functional level for the machine catalog after you upgrade the VDAs on the machines to a newer version. Citrix recommends upgrading all VDAs to the latest version to enable access to all the newest features.
Before changing the functional level for a machine catalog:
To change the functional level for a catalog:
After the catalog change completes, you can revert the machines to their previous VDA versions by selecting the catalog and then selecting Undo Functional Level Change in the action bar.
Clone a catalogBefore cloning a catalog, be aware of the following considerations:
Note:
If you select an Azure catalog to clone and select a Master image, the blade lists all the images that belong to the same region as those of Resources.
Copy. You can change the name. See Rename a catalog.You can create folders to organize catalogs for easy access. For example, you can organize catalogs by image type or by organization structure.
Create a catalog folderTip:
You can set your preferred default view (folder or list view) for the Machine Catalogs node by clicking the Folder icon in the upper right of the action bar.
Before you start, first plan how to organize your catalogs. Consider the following:
All nodes in Web Studio (such as Machine Catalogs, Delivery Groups, Applications, and Application Groups) share the same folder tree in the back end. To avoid name conflicts when renaming or moving folders, use unique names for first-level folders across different nodes.
If you create a folder using the New-BrokerAdminFolder SDK cmdlet and want it to appear under the Machine Catalogs node, you must add the ContainsMachineCatalogs metadata using the Set-BrokerAdminFolderMetadata cmdlet.
Example:
Set-BrokerAdminFolderMetadata -AdminFolderId {adminFolderUid} -Name ContainsMachineCatalogs -Value true
<!--NeedCopy-->
To create a catalog folder, follow these steps:
Move a catalogTip:
If you create a folder in an unintended location, you can drag it to the correct location.
You can move a catalog between folders. Detailed steps are as follows:
Manage catalog foldersTip:
You can drag a catalog to a folder.
You can delete, rename, and move catalog folders.
You can delete a folder only if it and its subfolders don’t contain catalogs.
To manage a folder, follow the below steps:
In the folder hierarchy, select a folder, and then select an action in the Action bar as needed:
Note:
This feature applies only to MCS catalogs.
Failed catalogs are marked with an error icon. To see the details, go to the Troubleshoot tab of each catalog. Before retrying catalog creation, be aware of the following considerations:
To retry creating a catalog, do the following:
You can now generate and manage enrollment tokens for non-MCS-provisioned VDAs. This implementation allows VDA registration over WebSocket without provisioning the VDAs with MCS. This feature also supports Linux Virtual Delivery Agent, Citrix Virtual Delivery Agent for macOS, and non-domain joined VDAs with Citrix Virtual Apps and Desktops.
Before you beginEnable WebSocket connection on the Delivery Controller. Run the following command on each Delivery Controller present on your site:
New-ItemProperty "HKLM:\SOFTWARE\Citrix\DesktopServer\WorkerProxy" -Name "WebSocket_Enabled" -PropertyType "DWord" -Value 1 -Force
<!--NeedCopy-->
Note:
Ensure that you restart the Delivery Controllers after enabling the WebSocket.
After you decide to enable token-based enrollment for non-Citrix provisioned machines, you must first generate tokens on a per-machine catalog basis, and then share them with VDA installation administrators.
An enrollment token features:
To generate a token for a catalog using Web Studio, follow these steps:
In the Token successfully generated window that appears, copy the token and save it in a safe place, or click Download to download it to the Downloads folder.
A token record appears in the token list.
Share the token with VDA installation administrators.
For more information about how to install VDA and a token on machines, see Install VDAs.
You have two options to revoke a token and make it unavailable for VDA enrollment:
Enroll machines to catalogs using the WebSocket VDA enrollment toolNote:
Expired tokens are automatically deleted in 14 days.
The WebSocket VDA enrollment tool facilitates token-based enrollment for VDA machines. This tool helps you convert a connection to a WebSocket connection by adding the VDA to the machine catalog using the enrollment token.
Note:
This tool is designed to enroll VDA machines that haven’t been enrolled in any machine catalog.
Follow the instructions to run the enrollment tool:
EnrollMachine.exe, in C:\Program Files\Citrix\Virtual Desktop Agent\Web Socket Vda Enrollment Tool.EnrollMachine.exe -websocket_token_string:xxxxxxxxxThe following table describes the input parameters of the enrollment tool:
Parameter Name Required Description Example-websocket_token_stdin Yes Reads the enrollment token. .\EnrollMachine.exe -websocket_token_stdin -websocket_token_string Reads the enrollment token directly from the command line parameter. .\EnrollMachine.exe -websocket_token_string:<token> -websocket_token_file:[token-file-path] Reads the enrollment token from the path provided. .\EnrollMachine.exe -websocket_token_file:C:\token\test2.txt log:[log-file-path] No Shows the Enrollment tool logs. .\EnrollMachine.exe log:[C:\ProgramData\Citrix\EnrollMachine\EnrollMachine.txt] -help No Shows a brief help text. .\EnrollMachine.exe -help
After successful enrollment, you will receive a success message on the tool and in the logs. Ensure to sign in to the Web Studio to verify that the VDA machine is added to the catalog and that the status of the machine is registered.
TroubleshootingBy default, you can find the logs of the enrollment tool at:
C:\ProgramData\Citrix\EnrollMachine\EnrollMachine.txt
If you have specified a different path for the logs, you can use log:[log-file-path] to retrieve your logs.
The following table lists the codes returned by the enrollment tool:
Code String Description 0 Success VDA is successfully added to the machine catalog. -1 InvalidArgument The input parameter in the enrollment token is invalid. -2 BrokerAgentNotFound The broker agent service is not found. -3 TokenInvalid The token entered is invalid. -4 TokenMissingRequiredClaims The required claims for the token are missing, for example, CustomerId, or Enrollment URIs. -5 InternalError A general error has occurred. -6 TimedOut The task has timed out. -7 FailedToDetermineMachineADJoinedStatus The service that returns the machine AD joined status failed. -8 ADMachineFailedToFindSid The service that returns the AD machine Sid failed. -9 EnrollRequestFailed The request failed due to an HTTP error. -10 EnrollResponseMissingRequiredFields The enrollment tool response is missing the parameterVirtualSiteId. -11 InsufficientPermission You do not have the required permission to run the task. -12 FailedToDetermineMachineAadJoinedStatus The service that checks the machine AD join status throws an error. -13 AadMachineFailedToFindDeviceId The additional parameter AAD device id added by the system is empty. -14 AadDeviceIdNotValid The additional parameter AAD device id added by the system is not a valid guid. -15 NoValidMacAddress Invalid MAC address. -16 FailedToGetComputerHostNameForVdaInstanceName Failed to get the computer host name to set the additional parameter VdaInstanceName. -17 VirtualDesktopAgentRegistryKeyFailedToOpen Failed to open the VDA registry key to write the list of Delivery controllers. -18 Failed Token reached the max count Failed Token reached the max count. Use PowerShell
This section details how you can manage catalogs using PowerShell:
You can get historical errors and warnings to understand issues with your MCS machine catalog and fix those issues.
Using PowerShell commands, you can:
To run the PowerShell commands:
asnp citrix* to load the Citrix-specific PowerShell modules.To get a list of errors and warnings:
Run Get-ProvOperationEvent command.
LinkedObjectType and LinkedObjectUid parameter: Gets all errors and warnings associated with a specific provisioning schemeEventId parameter: Gets a specific error or warning that matches this event IDFilter parameter: Gets errors or warnings by customized filterTo change the state of errors or warnings from New to Acknowledged:
Run Confirm-ProvOperationEvent command.
EventId parameter: Sets the state of a specific error or warning that matches this event ID. You can get the EventId of a specific error or warning as an output from Get-ProvOperationEvent commandLinkedObjectType and LinkedObjectUid parameters: Sets the state of all the errors and warnings associated with a specific provisioning schemeAll parameter: Sets the state of all errors and warnings as AcknowledgedTo delete the errors or warnings:
Run Remove-ProvOperationEvent command.
EventId parameter: Removes a specific error or warning that matches this event ID. You can get the EventId of a specific error or warning as an output from Get-ProvOperationEvent commandLinkedObjectType and LinkedObjectUid parameters: Removes all errors and warnings associated with a specific provisioning schemeAll parameter: Removes all errors and warningsFor more information, see Citrix PowerShell SDK.
Delete machines without hypervisor accessWhen deleting a VM or a provisioning scheme, MCS needs to remove tags from the VM, and sometimes from the base disk as well, so that the resources included in the deletion options are no longer tracked or identified by MCS. However, some of these resources are only accessible through hypervisor. Use the PurgeDBOnly option in Remove-ProvVM PowerShell to delete VM resource objects such as VM, base disk, image in ACG, and so on from the database even when there is no hypervisor access.
This option is enabled on:
You cannot use the commands -PurgeDBOnly and -ForgetVM at the same time.
Use the PurgeDBOnly commandWhen running the PowerShell command Remove-ProvVM -ProvisioningSchemeName SCVMM-MC -VMName SCVMM01 -ForgetVM the deletion operation might fail in the following scenarios:
Note:
Remove-provVM -ForgetVM targets only persistent VMs. If one of the VMs in the list is non-persistent, the operation fails.
When the operation fails because the hypervisor is unreachable, the following prompt appears:
Try to use -PurgeDBOnly option to clean DDC database.
Use the -PurgeDBOnly option in the Remove-ProvVM PowerShell command to delete references of a VM from MCS database. For example,
Remove-ProvVM -ProvisioningSchemeName SCVMM-MC -VMName SCVMM01 -PurgeDBOnly
You can add informative descriptions about changes related to image updates for machine catalogs. Use this feature to add a description when creating a catalog, or when you update an existing master image for a catalog. You can also display information for each master image in the catalog. Use the following commands to add or view image descriptions:
To add a note while creating a machine catalog with a master image, use the parameter MasterImageNote in the NewProvScheme command. For example:
C:\PS>New-ProvScheme -ProvisioningSchemeName <name> -HostingUnitName <name> -IdentityPoolName <name> -MasterImageVM
XDHyp:\HostingUnits\<hosting unit name>\<vm name>.vm\Base.snapshot -MasterImageNote "Note"
<!--NeedCopy-->
To update the master image associated with a machine catalog, use the parameter MasterImageNote in the Publish-ProvMasterVMImage command. For example:
C:\PS>Publish-ProvMasterVMImage -ProvisioningSchemeName <name> -MasterImageVM XDHyp:\HostingUnits\<hosting unit name>\<vm name>.vm\base.snapshot -MasterImageNote "Note"
<!--NeedCopy-->
To display the information for each image, use the Get-ProvSchemeMasterVMImageHistory command. For example:
C:\PS>Get-ProvSchemeMasterVMImageHistory -ProvisioningSchemeName MyScheme -Showall
<!--NeedCopy-->
To track the rollback progress, locate the catalog in Machine Catalogs to view the inline progress bar and the step-by-step progress graph.
You cannot roll back in certain scenarios, including the following. (The Roll Back Master Image option is not visible).
Use the PowerShell command Reset-ProvVMDisk to reset the OS disk of a persistent VM in an MCS created machine catalog. Currently, this feature is applicable to AWS, Azure, XenServer, Google Cloud. SCVMM, and VMware virtualization environments.
To successfully run the PowerShell command, make sure that:
Perform the following steps to reset the OS disk:
Run the PowerShell command Reset-ProvVMDisk in any one of the following ways:
Specify the list of VMs as a comma-separated list, and perform the reset on each VM:
Reset-ProvVMDisk -ProvisioningSchemeName "xxx" -VMName ("abc","def") -OS
<!--NeedCopy-->
Specify the list of VMs as an output from Get-ProvVM command, and perform the reset on each VM:
(Get-ProvVM -ProvisioningSchemeName "xxx") | Reset-ProvVMDisk "abc" -OS
<!--NeedCopy-->
Specify a single VM by name:
Reset-ProvVMDisk -ProvisioningSchemeName "xxx" -VMName "abc" -OS
<!--NeedCopy-->
Create separate reset tasks for each of the VMs returned by the Get-ProvVM command. This is less efficient because each task will perform the same redundant checks, such as hypervisor capability check, connection check for each VM.
Get-ProvVM -ProvisioningSchemeName "xxx" | Reset-ProvVMDisk -ProvisioningSchemeName "xxx" -OS
<!--NeedCopy-->
A confirmation prompt appears that lists the VMs to be reset along with a warning message that it is an unrecoverable operation. If you do not provide an answer and press Enter, no further action takes place.
Note:
Do not take VMs out the of the maintenance mode or power them on until the completion of the reset process.
You can run the PowerShell command -WhatIf to print the action it would take and exit without performing the action.
You can also bypass the confirmation prompt using one of the following methods:
Provide the -Force parameter:
Reset-ProvVMDisk -ProvisioningSchemeName "xxx" -VMName "abc" -OS -Force
<!--NeedCopy-->
Provide the -Confirm:$false parameter:
Reset-ProvVMDisk -ProvisioningSchemeName "xxx" -VMName "abc" -OS -Confirm:$false
<!--NeedCopy-->
Before running the Reset-ProvVMDisk, change $ConfirmPreference to None:
PS C:\Windows\system32> $ConfirmPreference='None'
PS C:\Windows\system32> $ConfirmPreference
None
PS C:\Windows\system32> Reset-ProvVMDisk -ProvisioningSchemeName "xxx" -VMName "abc" -OS
<!--NeedCopy-->
Get-ProvTask to get the status of the tasks returned by Reset-ProvVMDisk command.You can change the network setting for an existing provisioning scheme so that the new VMs are created on the new subnetwork. Use the parameter -NetworkMapping in the Set-ProvScheme command to change the network setting.
Note:
This feature is supported on Citrix Virtual Apps and Desktops 2203 LTSR CU3 and later versions.
To change the network setting for an existing provisioning scheme, do the following:
asnp citrix* to load the PowerShell modules.(Get-Provscheme -ProvisioningSchemeName "name").NetworkMaps to get to the network path that you want to change.Assign a variable to the new network setting. For example:
$NewNetworkMap = @{"0"= "XDHYP:\HostingUnits\MyNetworks\Network 0.network"}
<!--NeedCopy-->
Set-ProvScheme -ProvisioningSchemeName "name" -NetworkMapping $NewNetworkMap.(Get-Provscheme -ProvisioningSchemeName "name").NetworkMaps to verify the new network setting for the existing provisioning scheme.When an MCS machine catalog is updated with the Set-ProvScheme command, the current configuration is saved as a version. You can then manage the various versions of the machine catalog using PowerShell commands. You can:
A version includes the following information of a machine catalog:
Run the following commands (provided as examples) to manage the various versions of a machine catalog.
To see the configuration details of the various versions of a machine catalog:
Get-ProvSchemeVersion -ProvisioningSchemeName AzureCatalog
<!--NeedCopy-->
To see the configuration details of a particular version of a machine catalog:
Get-ProvSchemeVersion -ProvisioningSchemeName AzureCatalog -Version 2
<!--NeedCopy-->
To see the total number of versions associated with a machine catalog:
(Get-ProvSchemeVersion -ProvisioningSchemeName AzureCatalog).Count
<!--NeedCopy-->
To use any previous version to update the machine catalog:
Set-ProvScheme -ProvisioningSchemeName AzureCatalog -Version 2
<!--NeedCopy-->
To manually delete a version if it is not used by a VM of that machine catalog:
Remove-ProvSchemeVersion -ProvisioningSchemeName AzureCatalog -Version 3
<!--NeedCopy-->
To set the maximum number of versions to be retained by the machine catalog (default is 99). This setting is applied across all the catalogs. For example, in this case, a maximum of 15 versions will be retained for all the MCS provisioned catalogs.
Set-ProvServiceConfigurationData -Name "MaxProvSchemeVersions" -Value 15
<!--NeedCopy-->
If the number of versions reaches the maximum number of versions, then a new version cannot be created if older versions are in use by any of the VMs in the machine catalog. In that case, do one of the following:
You can use a VM, template spec (in case of Azure), or launch template (in case of AWS) as a machine profile input to convert a non-machine profile-based machine catalog to machine profile-based machine catalog. New VMs added to the catalog take property values from the machine profile unless overwritten by explicit custom property.
Note:
An existing machine profile-based machine catalog cannot be changed to a non-machine profile-based machine catalog.
To do this:
Run the Set-ProvScheme command to apply the property values from the machine profile to the new VMs added to the machine catalog. For example:
In the case of Azure:
Set-ProvScheme -ProvisioningSchemeName xxxx -MachineProfile XDHyp:\HostingUnits\<HostingUnitName>\machineprofile.folder\<ResourceGroupName>\<TemplateSpecName>\<VersionName>
<!--NeedCopy-->
In the case of AWS:
Set-ProvScheme -ProvisioningSchemeName xxxx -MachineProfile "XDHyp:\HostingUnits\<hosting-unit>\<launch-template>.launchtemplate\<launch-template-version>.launchtemplateversion"
<!--NeedCopy-->
In the case of VMware:
Set-ProvScheme -ProvisioningSchemeName "my-prov-scheme" -MachineProfile "XDHyp:\HostingUnits\my-hosting-unit\my-template.template"
<!--NeedCopy-->
You can reset the identity information of active computer accounts that have identity-related problems. You can choose to reset only the machine password and trust keys, or reset all configuration of the identity disk. This implementation is applicable to both persistent and non-persistent MCS machine catalogs.
ConditionsNote:
Currently, the feature is supported for AWS, GCP, Azure, SCVMM, XenServer, and VMware virtualization environments.
Ensure the following to successfully reset the identity disk:
To reset identity disk:
asnp citrix* to load the Citrix-specific PowerShell modules.Reset the identity information.
To reset only the machine password and trust keys, run the following command:
Repair-AcctIdentity -IdentityAccountName TEST\VM1 -PrivilegedUserName TEST\admin1 -PrivilegedUserPassword $password -Target IdentityInfo
<!--NeedCopy-->
The description of the parameters used in the command are as follows:
To reset all configuration of the identity disk, run the following commands in the following order:
Repair-AcctIdentity -IdentityAccountName TEST\VM1 -PrivilegedUserName TEST\admin1 -PrivilegedUserPassword $password -Target IdentityInfo
<!--NeedCopy-->
Reset-ProvVMDisk ProvisioningSchemeName <name> -VMName <name> -Identity
<!--NeedCopy-->
To completely recreate the identity disk:
Reset-ProvVMDisk -ProvisioningSchemeName <name> -VMname <name> -Identity -Recreate
<!--NeedCopy-->
Type y to confirm the action. You can also skip the confirmation prompt using the -Force parameter. For example:
Reset-ProvVMDisk -ProvisioningSchemeName <name> -VMName <name> -Identity -Force
<!--NeedCopy-->
Get-ProvVM -ProvisioningSchemeName <name -VMName <name> to check the updated identity disk setting. The attributes of the identity disk (for example, IdentityDiskId) must be updated. The StorageId and IdentityDiskIndex must not change.After creating a non-persistent catalog with MCSIO enabled, you can use the Set-ProvScheme command to modify the following parameters:
This feature is currently applicable to:
The requirements to modify the cache configuration are:
Enable the parameter UseWriteBackCache for the existing machine catalog. Use New-ProvScheme to create a machine catalog with UseWriteBackCache enabled. For example:
New-ProvScheme -ProvisioningSchemeName $CatalogName -HostingUnitUid $HostingUnitUid `
-IdentityPoolUid $acctPool.IdentityPoolUid -CleanOnBoot `
-MasterImageVM $MasterImage `
-ServiceOffering $ServiceOffering `
-NetworkMap $NetworkMap `
-SecurityGroup $SecurityGroup `
-UseWriteBackCache -WriteBackCacheDiskSize 8
<!--NeedCopy-->
Run the Set-ProvScheme command. For example:
Set-ProvScheme -ProvisioningSchemeName $provScheme.ProvisioningSchemeName -WriteBackCacheDisk32 -WriteBackCacheMemorySize 128
<!--NeedCopy-->
Note:
- The value of
WriteBackCacheDiskSizemust be more than zero because at least 1 GB of cache disk storage is required.- The value of
WriteBackCacheMemorySizemust be less than the machine catalog memory size.- These changes only affect new VMs added to the catalog after the change is made. Existing VMs are not affected by these changes.
Specify the VDA installer location through PowerShell cmdlets which reduces your effort from providing network rules to allow each VDA to go and fetch the new VDA installer from the Citrix Managed Azure CDN.
PowerShell cmdletsTwo new optional parameters added to New-VusCatalogSchedule and New-VusMachineUpgrade cmdlets that allow you to use installers from a local file share
The network shares containing VDA installer packages must have read access for the VDA Upgrade Agent service which runs as Local System (NT AUTHORITY\SYSTEM principal).
Domain-Joined file share permission
When the VDA machine is domain-joined, then the Local System account (VUA runs as Local System), uses computer credentials when accessing network shares.
The least privilege permission can be set by granting the Read access to Domain Computers.
Non-Domain Joined file share permission
When the VDA machine is non-domain joined, then the Local System account (VUA runs as Local System), uses ANONYMOUS LOGON when accessing network shares.
Note:
Restart your machine for the change to take effect immediately.
Download the VDA installer and place it in the shared file.
Note:
With Virtual Upgrade Service, you can select from either the Current Release track or the LTSR track.
For Example: If the machine catalog is set to Current Release that is 2311, and the VDA version is 2305, you must upgrade the VDA to version 2311.
Select the relevant VDA installer based on the catalog type.
Storage migration of VMsNote:
The version of the file share installer has to exactly match the version of the latest installer version published by VUS to the cloud.
You can move the disk storage of existing VMs from an old storage to a new storage in VMware and XenServer environments. During migration, MCS retains the VM capabilities such as power management, reset OS disk, and so on. You can also add new VMs to the machine catalog using the new disk storage. To do this, use the PowerShell command Move-ProvVMDisk.
You can migrate full clone persistent VMs and non-persistent VMs.
The new storage must satisfy the following conditions:
To migrate the disk storage:
Add a destination storage to an existing hosting unit. You can run the PowerShell command Add-Hyphostingunitstorage to add the destination storage:
If you do not want to add new VMs to the old storage, then change the old storage to Superseded. You can do this using Studio or PowerShell commands. For Studio, see Edit storage. Alternatively, run Set-Hyphostingunitstorage and set Superseded as true to disable new VM creation in the old storage.
Note:
For non-persistent VMs:
- If WBC is used, then configure the WBC destination storage in the hosting unit.
- If OS destination storage is configured, then WBC (if used) must be compatible with OS destination storage.
- If OS destination storage is not configured, then WBC (if used) must be compatible with the current OS storage.
Get the information about the provisioning scheme, hosting unit, OS disk storage, and WBC disk storage.
Run ProvResourceInStorage for OS storage information. For example:
$result=Get-ProvSchemeResourceInStorage -ProvisioningSchemeName xxxxx
$result
$result.ProvResourceInStorage | Format-List -Property *
<!--NeedCopy-->
Run TemporaryStorageInfo for WBC storage information. For example:
$result=Get-ProvSchemeResourceInStorage -ProvisioningSchemeName xxxxx
$result
$result.TemporaryStorageInfo | Format-List -Property *
<!--NeedCopy-->
Migrate the OS disk, Identity disk, and WBC disk (applicable to non-persistent VMs) to the destination storage using the Move-ProvVMDisk PowerShell command.
Note:
- Always provide the OS and Identity disks in the DiskType and
DestinationStorageIdparameters.- The
DestinationStorageIdfor OS disk and Identity disk must be the same.
Example:
Persistent VMs:
(Get-ProvVM -ProvisioningSchemeName xxxxx) | Move-ProvVMDisk -ProvisioningSchemeName "myFullCloneProvScheme" -VMName "machine01" -DiskType OS,Identity -DestinationStorageId datastore1,datastore1
<!--NeedCopy-->
Important:
For persistent VM, all disks are moved. You cannot select which disks to move.
Non-persistent VMs:
(Get-ProvVM -ProvisioningSchemeName xxxxx) | Move-ProvVMDisk -ProvisioningSchemeName "myCleanOnBootProvScheme" -VMName "machine01" -DiskType OS,Identity,WBC -DestinationStorageId None,None,datastore1
<!--NeedCopy-->
Important:
- If you don’t want to migrate a specific disk, set the value as
Nonefor theDestinationStorageIdparameter.- If the VM has WBC disk, then add the WBC disk in
DiskTypeparameter and add the required information inDestinationStorageIdparameter.
You can convert an existing MCS provisioned machine catalog into a prepared image machine catalog using a PowerShell command Set-ProvSchemeImage. However, you cannot revert to the legacy catalog after migration. Currently, this feature is applicable to Azure and VMware virtualization environments.
Consider the following limitations:
To migrate, do the following:
Create an image definition and image versions using Studio or PowerShell commands. See the steps to create image definitions and image versions in:
Azure:
VMware:
Run Get-ProvScheme command to get the provisioning scheme UID. For example:
Get-ProvScheme -ProvisioningSchemeName <name> | select ProvisioningSchemeName, ProvisioningSchemeUid
<!--NeedCopy-->
Run Get-ProvImageVersionSpec command to get the Image definition name, image version spec uid. For example:
Get-ProvImageVersionSpec -ImageDifinitionName <name> -Filter {IsPrepared -eq $true} | select ImageDefinitionName ImageVersionSpecUId
<!--NeedCopy-->
Run Set-ProvSchemeImage command to migrate an existing MCS provisioned machine catalog into a prepared image machine catalog. For example:
Set-ProvSchemeImage -ProvisioningSchemeName [ProvisioningSchemeName] -ImageVersionSpecUid [ImageVersionSpecUid]
<!--NeedCopy-->
Run Get-ProvScheme command to check that the catalog is migrated. For example:
Get-ProvScheme -ProvisioningSchemeName <name> | select ProvisioningSchemeName, ProvisioningSchemeUid, ImageVersionSpecUid
<!--NeedCopy-->
For information on managing specific cloud services catalogs, see:
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3