Citrix Provisioning Services (PVS) has long been a trusted delivery mechanism for images across customer estates. It provides infrastructure teams with the ability to manage many thousands of devices with a single image, simplifying operations, and, in many ways, enhancing an organization’s security posture by ensuring devices are clean before a user consumes a service.
If you’ve been around Citrix products a while, you’re probably familiar with the debate over Citrix Provisioning Services and Citrix Machine Creation Services. Both products share similar driver stacks in terms of the way they can front storage with memory cache to improve performance. Check out this blog post, which explains RAM cache with overflow to disk extensively within PVS.
Citrix has made many optimizations and tweaks throughout the years to ensure that PVS performs at its best from the perspective of device check-ins, failover times, and scalability. We’ve published posts in the past covering optimizations for PVS, and these recommendations have been based on previous best practices. But approaches are constantly evolving, and as products and customer needs change, so do our recommendations. This post provides updates to those. Previously we may have recommended:
- Adjusting ports and thread configuration
- Dedicated streaming network (not required by default)
- SkipRimsforPrivate registry key (only required for certain behaviors)
I have good news. We’ve made things simpler. Now, you can leave ports and threads on their default configuration. Unless a customer has a specific need to adjust ports to meet security requirements, no changes from the default configurations are needed for PVS functionality and scalability. Now that the previous optimizations are no longer required, this simplifies PVS deployments for 90 percent of our customers! And, of course, it makes PVS troubleshooting easier, too.
A default install is sufficient for most environments, though there are a few things to consider as you work through your PVS design:
- The number of PVS servers in a site: Make sure you have a suitable failure domain. Aim for 400 devices per PVS server on a 4vCPU x 16GB RAM. (This is a rough guidance; you may have a requirement to run more devices per PVS server, which is acceptable. Engage with Citrix Professional Services to ensure that your PVS servers are scaled correctly.) Take a look at this blog post when thinking about sizing.
- vDisk store location: Replication of images has required long and laborious scripts and methods. For those of you who aren’t aware, there’s a tool that also simplifies the roll out process.
- Place PVS servers close to the target devices: Avoid routing PVS traffic through firewalls when possible. This is something our consulting team has long advised, and it links closely back to the idea that “simplicity is king.” Streaming PVS images through firewalls in nearly all cases leads to a performance issue of some sort. Ensuring that simple network configurations between PVS and the target devices are deployed keeps things performant.
- Boot options: In nearly all environments now, a boot device manager (BDM) that creates a small partition with the necessary PVS server locations is enough (and is the default). However, depending upon your requirements, there are a couple of options. This Citrix Support article covers different boot options.
And don’t forget those pesky antivirus exclusions!
In newer deployments, customers might choose now to deploy Citrix Provisioning Services within Microsoft Azure and Google Cloud Platform. If this is the case in your environment, reach out to your local Citrix Professional services teams for assistance.
This update should help customers as they design their Citrix Provisioning Services environments. For more information about Citrix Provisioning Services, please check out our product documentation. And of course, consult your local professional services team.
Kelan Rowe, Principal Escalation Engineer, contributed to this blog post.