In my first blog, I mentioned that I had three priorities. The first one was: Be the product, customer, and partner advocate. With that goal, I set out to meet with various people whether customer, partner, community, friend of a friend, etc. and talk change and managing change for Windows workspaces. I have been able to gather some great information about the “lay of the land” in this regard, whether it is physical desktops or virtual desktops, single session, or multi-session. Some of it surprised me at first but upon taking a step back and looking at the current IT landscape, it probably shouldn’t have. Let’s dig into some of my findings.
But first, let me cover a couple of things.
Here are the three of the takeaways with some thoughts along with them.
1. Going through, or following completely, a change management process is becoming much less prevalent.
I chatted with people that did describe very strict change management and almost non-existent change management. The majority though described a growing laxity of going through and/or following the change management process. The major reason being that there is simply not enough time and admins to handle all the changes much less go through a committee for approvals, times, documentation, etc.
2. Most organizations with a “healthy” mix of physical desktops and Citrix/Horizon environments tend to target the virtual environments first when onboarding new applications.
This is especially true for organizations that may have users geographically dispersed or remote but is also quite prevalent in companies with a large contingent of “in the office” workers. The key word is “healthy” because we are talking about companies that are using remoting for a good number of applications already versus companies that may only use it for a few applications.
There does appear to be a prevalent issue though. The change, specifically new applications, are tested in production. The applications are installed onto a remoting server and published to a few users to test. At first blush, that looks ok. The problem is that the application hasn’t been tested with the other applications already on the server and if the new application “breaks” something, you’ve now potentially affected every user on that server. Testing in production is never a good thing.
3. No automated testing before any sort of deployment
It’s interesting that pushing a change is typically automated but testing before deployment is a manual process at best. How does the change affect my Windows workspaces and by extension the employees? This goes beyond applications and includes security policies, GPOs, or any environmental change that may affect the employee’s ability to do their job.
The coordination and effort required by an IT administrator to get users to test their applications against upcoming changes is daunting. Most administrators simply do not have the time to handle this, so the easier path is taken. This, unfortunately, leads to the change being deployed and tested in production. That is never good and, in my opinion, is unsustainable long term.
What is my takeaway from all this? IT continues to be understaffed and expected to do more and more. This has been true for a while, but it reinforces the impetus to implement automation where you can to take pressure off. As I mentioned above, deploying change is automated already but making sure that those changes are not going to adversely affect the user experience is still a very manual process. This is where Rimo3’s unattended, intelligent automation comes in. It is always best to be proactive rather than reactive. Be the IT hero!