Enable deadline randomization for Applications and Packages in addition to software updates
Deadline randomization is currently in place for software updates only. We were hoping that would expand to both applications and packages as well. This would reduce the demand for applications and package installations in a shared environment (virtual). We currently have this available with software updates. We'd like to see the scope expanded to include package and applications.
This is enabled for applications as part of phased deployments – in #SCCM 1806
Here is a what we are facing with SCCM and why we are requesting this feature to be added to Applications and Program deployments.
Current state. We are a 100% virtualized organization. Each employee has a Virtual desktop (VM). With over 1100 VMs in our environment. We have 16 virtual hosts. The primary storage array is flash.
A few issues we have run into when doing larger deployments of software. When we deploy a new version of software to VMs we started testing with 100 at a time. The way application deployment works when software has a required deadline, it downloads software from the DP all at the same time. It installs the software all at the same time, and it reboots the VMs all at the same time. So three issues we have and why we cannot deploy to large groups in our environment:
High Storage Latency/IO
These issues do not affect the traditional PC/Lab environments.
Because of those issues we are forced to break out our deployments into smaller groups of 20-25 because of the way required application deployments are designed. Because of this, it takes more time and more complexity to deploy software to over 1000 VMs
We would like the ability to control randomization of software installs at the deployment level. Ideally SCCM would allow the administrator to configure a max quantity of machines to retrieve content/install/reboot at the same time. Perhaps have the option to enable/disable randomization per deployment, and a max amount of machines that can install at the same time. Or even configure how many machines can deploy within a certain time period. Maybe even a auto randomization option as well, as some organization may not want to configure to the level we desire.
This feature would greatly help any organization with VDI as primary compute.
D. Yamada commented
Thanks David! Additional customer verbatim similar to the one below,
We’ve enabled deadline randomization in our lower environments to help minimize impact to our vdi environment. As we continue to grow in that space, we continue to find that deploying to all VDI’s at the same time is not an option. The deadline randomization has helped minimize impact to host resources and the user experience. We plan on rolling out this setting to our production VDI machines in the coming weeks.
Here is where we need your help. We found out that this setting is limited to software updates only. This means we still have issues deploying other packaged software to the VDI environment without impacting our hosts or our end users. For now, we have been breaking up our clients in collections/maintenance windows so that we minimize impact but this doesn’t come without its own challenges. This setup requires us to setup deployments to 16+ collections for each deployment. This number can exceed over 70 deployments when we have to deploy multiple packages at a time. We are in need of a solution from MS that helps randomize these deployments similar to the deadline randomization software updates use. "
Jamal Mabra commented
Right now, we need to separate our virtual environment into multiple collections to stagger packages and application rollouts so we don't overload the hosts when a scheduled deployment occurs. We were hoping that deadline randomization that we started using for our patching deployments was available for application/package rollouts also so we didn't have to split rollouts over multiple collections. The deadline randomization would allow us to send these rollouts to one or two large collections and we wouldn't worry about overloading the hosts since SCCM would be able to spread out the installations for us.