Automation is the order of the day in enterprise IT. Not only can automation greatly expedite common day-to-day IT processes, but it is a crucial component in every organization’s disaster recovery plan. Automating the build of web servers, database servers, and different infrastructure components can be relatively quick and simple. Unfortunately, automating the complete build of new desktops has been anything but simple.
Using SQL Database Severs as an example on the infrastructure side, automating the build process is relatively simple. No matter what the configuration requirements are for the database, the base is always the same. It is always SQL. The configuration options available are only those available in SQL.
You can quickly and easily spin up a brand-new desktop VM in Azure with Azure Resource Manager (ARM) templates, but for desktop applications there are thousands of different applications with virtually infinite variables to consider. How can you make the packaging and deployment of these applications easier? How can you optimize your automated desktop builds by modernizing application deployment with container management?! That is where Cloudpager comes in!
Reduce Desktop Image Size to Optimize Your Automated Builds
Today, perhaps you use Azure Image Builder and deploy custom images to your DaaS platform of choice. Maybe you include all your users’ apps in that image. Even if you automate the build process, if you put all your apps into your base image that can lead to application conflicts, image sprawl, and increase the size of your images and desktops. All these inefficiencies lead to greatly increased costs when working in the cloud.
Ideally, you should establish a single and small golden image, automate the update of your image, and deliver most of your applications outside the image management process.
Of course, this methodology can also yield great results for physical endpoints too. Perhaps you have used a product like Microsoft Endpoint Configuration Manager or Microsoft Deployment Toolkit. When deploying apps outside of the base image itself you will have sequential tasks installing each application after the desktop boots up. While these are tried-and-true solutions, the process is not optimal. It can take a long time to go from imaging a desktop to users being able to access all their apps and work without disruptions.
Maybe you use Microsoft’s Autopilot and your remote workers have expectations when they receive their new hardware that they need to boot it up and basically down tools for 45+ minutes until they are ready to work.
A common scenario for those booting up a new PC is that they believe their desktop is up and ready for them to work and then a few minutes into working they see some command prompt pop-ups or install dialogs followed by an unexpected reboot. The employee experience can be frustrating, and everyone’s time is too valuable to waste waiting for apps to install.
With Cloudpager, you only need to put the Cloudpaging Player and Cloudpager Client in your image. When end users log in, applications will be dynamically provisioned to them from the cloud without requiring installations, reboots, or logouts. No more waiting many minutes or even hours until a desktop is fully ready after deploying.
Achieve a Single Golden Image to Accelerate Automated Builds with Cloudpager
If you are reading this and you already have a light base image with most apps installing onto the desktops after the initial boot-up then I am likely preaching to the choir. The good news for you is that Cloudpager can improve the overall onboarding time for your employees when they receive a new PC and greatly speed up the provisioning of their applications.
I encourage you to ask yourself some questions: How long does it take for all of those apps to be available to your users? Have you encountered applications conflicts yet? Is there a risk of poor packaging practice or the wrong package parameter causing conflicts and downtime?
I can draw off some of my own experience. I would like to share two incidents I encountered at different organizations.
Incident 1
More than a decade ago I worked on a desktop team where we had a mix of several apps in the image, with more apps installed outside of the image as part of the build process. It was reliable and worked, but the total build time was about an hour and ten minutes. One of the apps we were requested to put in the image was a large framework called FileNet, which was used by several apps including one of the most business critical.
One day we were asked to update FileNet in the image. We tried but it failed to uninstall. No matter what we did, we could not get it uninstalled to perform the required update. We had to sift through older images to find one that allowed us to uninstall it. This took days!
Lesson learned: Keep your images light and clean. Dynamically provision your apps!
Incident 2
I worked at a Cloud Services Provider. We had a slick automated build process. We didn’t rely on any vendor’s provisioning tools; we used our own in-house custom built solution. For some customers, all their apps were setup.exes or vendor msis. The automated build took about 25 minutes to complete. It worked great. The latest patches were always installed as part of the build process and updating individual apps was as simple as swapping out installers in the sequential steps or adding a new step.
Unfortunately for customers with locally installed apps, we still ran into issues such as applications installed in the incorrect order causing issues or applications conflicting with other applications. Of course, any time applications or application updates were added to the build process but the application owner gave incorrect installation instructions, extensive rework was required.
When we discovered an issue, we had to spin up a new desktop image without the problem application installed, install the problematic applications manually, remediate the problem if it persisted post-manual install, and reflect the fix into the scripted build. With a 25+ minute build time, a simple fix could take hours to implement.
Lesson learned: Locally installed apps negate some of the benefits of an automated build process. The turnaround time for updates can be slowed down, not sped up.
Eliminate the Need for Sequential Application Installs During Your Desktop Build
Through my lived experience in IT, I reached the conclusion that dynamically provisioning applications in containers is the best solution. If you use a product delivering locally installed applications or apps in layers where they appear local to the system, this can lead to issues that ultimately slow down your automation efforts, negating some of the benefits of automating in the first place. Be fast, be agile! Containerize!
In the video below, I demonstrate how to create an automated build process using some commonly used solutions, including basic Azure Resource Manager (ARM) templates, PowerShell, and an awesome Robotic Process Automation (RPA) product called Automai.
We are really spoiled for choice with great automation tools. I could have used a number of different solutions, such as Azure Image Builder, Azure Bicep, Packer, and Terraform, to create an even more streamlined process than what you see in the video. However, I wanted to record the video in a way that illustrates exactly what the RPA is running and doing. If it was just running PowerShell scripts and you could not see anything happening, it would have made for a lackluster demo 😊. If you have never heard of an RPA before, seeing it in action in this demo will be a treat.
My goal for the build was to have a repeatable automation process that I can run each month to create a Windows 11 custom image for my Windows 365 Cloud PCs. This image will be fully patched each month and have the Cloudpaging Player and Cloudpaging Client installed. This will allow me to deploy my custom image to all new PCs with only my agents installed, ensuring the image is lightweight. When a user logs into their desktop the first time Cloudpager will dynamically provision any App-V, Cloudpaging, or MSIX containers the admin assigned to their group.
By using application containers and Cloudpager, I eliminate the possibility of something in my image creating application conflicts. If I ever do need to remove a container from an end user desktop, the removal will be quick and clean. If I detect an issue, I can also quickly rollback any changes from Cloudpager. On the other hand, future patches to application containers can be seamlessly deployed to the users without any disruption, including those in active sessions. Best of all, this is an awesome experience for users. They do not see disruptive install dialogs, they don’t need to wait 30+ minutes for apps to complete installing, and won’t get surprise reboots. Applications appear dynamically and are ready to use within seconds.
Productive employees, make happy employees!
Create an Enterprise-Ready Application Experience on Windows 365 in 30 Minutes
Join Rory Monaghan and Ryan Will on September 29th at 10am PDT for a live demonstration on how to create a robust, enterprise-ready application experience on Windows 365 from scratch. During the webinar you will learn how to:
- Rapidly upload application containers to Cloudpager and deploy them to Windows 365 Cloud PCs
- Auto-deploy application containers to Azure AD security groups and users
- Dynamically provision applications and updates to Cloud PCs within seconds
- Execute instant application rollbacks and software reclamation
- Automate software license policy enforcement