Machine catalogs, delivery groups and controlled image updates
Separate provisioning from entitlement
A machine catalog describes a collection of machines under the supported operating-system and provisioning model. A delivery group organizes which resources and machines are offered under the configured access conditions. Membership and supported compatibility matter, but do not assume that every catalog machine has the same individual user assignment or public address. A machine can be available in inventory while not offering the intended resource to the intended user. Validate the catalog, delivery-group configuration and actual entitlement separately.
Machine Creation Services uses the configured hosting platform and image workflow to provision machines. The exact disk arrangement depends on platform, persistence choices and supported feature version; it is not always one universal linked-clone layout. Citrix Provisioning, historically called Provisioning Services or PVS, uses its supported streamed-image and target-device model. Boot paths can differ, so a remembered PXE/TFTP sequence is not the only possible arrangement. A Boot Device Manager approach can support an alternative bootstrap method, but its actual dependencies still require verification.
Assignment does not define persistence by itself
A random assignment describes which available machine is selected, while persistence describes which machine or user state is retained. These concepts interact with the actual provisioning and reset policy. Do not infer that every random desktop discards every change immediately at logoff or that a dedicated desktop has an adequate backup. State when and what is reset, where user state belongs and how applications or data outside the image are protected.
Test the image and the update path
Maintain a known source image, versioned changes, approved software and suitable test evidence. Review application compatibility, VDA and hosting support, identity behavior and relevant security controls before promoting a change. A pilot should represent actual users and workloads; one successful administrator login does not test printer mapping, application access, profile mounting or concurrent load. Record the association between the tested image and the catalog version deployed.
Plan rollback and recovery before broad update. Reverting an image does not automatically reverse changes to a user profile container, database schema or external application state. A snapshot can support a particular rollback path but is not universal independent protection against storage loss. Keep appropriate retained recovery copies and test restoration under the actual architecture. Review power-management behavior and available capacity after updates rather than assuming that a provisioning success message proves the service is ready for every user.