During the tepid Summer of 2018, Microsoft announced that it would be extending Windows 10 support for Education and Enterprise customers from 18 months to 30 months. In conjunction with that extension, they also announced that Windows 7 would receive additional support options for a hefty monthly fee.
On the surface, I’m sure Microsoft’s marketing department thought these updates would generate goodwill and cheers of celebration. At a deeper level of analysis, the decisions by Microsoft are worthy of a facepalm because they fly in the face of how organizations should approach managing their Windows 10 ecosystem.
I’ve kept my thoughts to myself to give the news time to percolate through the industry, but I see customers are losing sight of the big picture and decided that someone needed to address the topic.
Viewed from a short-term, practical assessment, I understand that some businesses face considerable limitations regarding which applications they keep in their portfolio and the revised service extensions give them additional breathing room to migrate.
Nevertheless, by allowing organizations even more time to put off the inevitable, they are promoting the absolute wrong approach to modern management – to put off as long as possible until the product life cycle forces the organization forward.
That mode of thinking will be catastrophic for organizations attempting to exploit the rapidly evolving capabilities that come with each Windows 10 release.
Time to Rethink Servicing
It is imperative that CIOs, IT managers, and technicians recognize that the way they used to do things in a pre-cloud world will no longer suffice and will increasingly become hindrances to properly managing IT resources. It is time to accept the fact that Microsoft has transitioned to cloud-based services for all of its major enterprise offerings.
The transition means that Windows 10 is updated bi-yearly and major vendors are following suit with their application and hardware support statements. Once an organization pivots to Windows 10, for better or for worse, they have bought into a service-oriented paradigm that is constantly in flux and requires dedicated staff and resources to manage appropriately.
Just recently, a great community member, Aaron Parker, wrote an article about visualizing this new world of change. Aaron evaluated a few common elements that customers have in their environment and generated an interesting chart (see below). The chart shows that the release cadence for Windows 10 and Configuration Manager have become quicker over time.
Personally, I was surprised when I saw that Intune had also accelerated its release cadence to weekly. There is no doubt that heads are spinning as to how an organization successfully manages a constantly evolving application, device, and management ecosystem.
With prior operating systems we could easily deploy them well into extended support, even skipping releases because we knew how to mitigate the risks. As newer IT professionals entered the workforce, they were unwittingly indoctrinated into this strategy, which became common practice because it was perceived as delivering value to the business.
Over time, delaying or omitting OS updates became widely encouraged throughout the industry.
But the modern workforce now expects to have the same device capabilities and applications that they use at home, other jobs and even at school. Having a modern environment is about attracting talent and being effective.
One of the unforeseen consequences of less frequent releases is that more features and product architecture changes have to be bundled into each release, which increases the complexity and risk bundled into upgrade projects. In contrast, with a more frequent release cadence, developers are able to release more granular changes, which reduces the complexity and the risk.
I predict that Microsoft’s new servicing changes will further segment consumers into two groups. In the first, there will be organizations that have historically put off proper IT management practices, and, in the second, those organizations that are proactive and have learned how to adapt and take advantage of the rapidly growing cloud ecosystem.
I would loosely characterize the first group as unable to make sense of how cloud-based IT and management practices interact. As a result, they opt to do nothing rather than disrupt the status quo inside their organizations. In my experience, most organizations are precariously tilting in this direction because the new Windows servicing schedule scares the pants off of them, in part, because the status quo has been the safe play for legacy IT.
A deeply rooted corporate culture takes time and effort to disrupt, and without top-down buy-in and support, there is little chance for change.
I’m sure you can guess that the second group consists of the early adopters who have developed an organizational culture that is agile and able to disrupt the status quo when appropriate. Instead of avoiding the fear of change, they tackle it head-on and are reaping the benefits of modern IT management practices.
I really want to help as many organizations as possible find their way to true modern management. So I’ve started educating customers right away, during a proof of concept engagements, about the serious implications of not maintaining the latest version of Windows 10.
Once I can get a client to a state where both Intune and Windows Autopilot are used to manage production users, the administrators become eager to introduce new versions of Windows so they can access new management capabilities and end-user experience enhancements.
When I see companies in the startup phases these days they often make very conscious decisions to avoid legacy IT technologies in their environment because they understand how much drag that can put on their competitive edge. That is why I push customers forward to take advantage of Windows Servicing, it is part of the modern workplace paradigm that many organizations are striving for where users can easily collaborate and be productive anywhere.
I appreciate the scope of the situation and the overwhelming feeling it can be to modernize an organization, so I can’t deny that the extended support options announced by Microsoft will give some organizations needed flexibility.
That being said, I strongly encourage IT professionals and organizations to avoid the allure of that approach to Windows lifecycle management. As Aaron Parker demonstrated in his article, the Windows ecosystem is transitioning towards more frequent updates, so learn to embrace change.
Also, consider that other operating systems such as iOS and Android aggressively update as well. If you look at the App Store on those devices, you’ve no doubt noticed that there is a never-ending stream of application updates that are working in the background.
Effectively adapting to change is at the heart of modern management practices.
There were some hints wafting around the blogosphere that Microsoft might introduce dependencies between Windows 10 and Office 365, which would further necessitate version compliance. That hasn’t materialized yet, but don’t discount the possibility of Microsoft moving in that direction.
In the months and years ahead, businesses will (hopefully) become more motivated to keep their Windows version updated to access new capabilities, especially if they improve security and management or unleash a more productive worker. On the flip side, ignoring Microsoft’s release cadences will guarantee increased costs and decreased productivity for your IT department.
To put it simply, hardware and software vendors test against the current channel of Windows, and you will minimize the extent of your deployment issues by keeping your configuration as close to the current channel as possible. Furthermore, backporting features can be a lengthy, teeth-pulling process that doesn’t necessarily deliver value to the majority of Microsoft’s customer base. As such, it is bad planning to expect that vendors will invest resources to address your unique configuration.
We are entering the next major evolution of technology where applications and devices are penetrating deeper into our daily lives. The boundary between the desktop operating system and the mobile operating system continues to blur, and eventually, end-users will expect seamless access to services and applications regardless of their device or location.
Those organizations that drag their feet on deploying new releases of Windows 10 or skip releases entirely are enabling and further entrenching bad practices, which are only going to complicate application and device management.
As I alluded to above, most organizations that have migrated to Windows 10 have no formal strategy for dealing with Windows as a Service, partly because they thought they could address management issues separately from deploying Windows 10.
The hard truth is that once you deploy Windows 10, you must begin to manage WaaS. Ideally, it would be a part of the initial migration project, but proper servicing should begin shortly after Windows 10 has been deployed to the organization.
The goal is to have customers develop the operational capacity to deal with Windows servicing updates twice a year. Unfortunately, that involves a significant amount of behind the scenes work that is not well documented nor does it have the attention of the decision-makers to make it a priority.
Microsoft isn’t helping matters when it describes migrating to Windows 10 as the last desktop migration mega-project your organization will have to take on. The problem with their claim is that it’s only attainable if your production environment follows the latest Windows release closely. What Microsoft isn’t talking about is that the only way to keep pace with Microsoft is by having solid operational governance, scheduled procedures, trained staff, and sufficient resources budgeted to take this on as a recurring operational task.
When organizations delay or ignore Windows 10 servicing, the technical debt incurred by all the updates waiting to deploy quickly adds up, which yields bigger and more complicated migration projects.
Contained within that backlog of updates is a growing list of hidden dangers, which organizations could more easily avoid if they adopted modern management best-practices. Once you can stay current with Windows servicing, your configuration will likely fall within the set of test cases being targeted by developers both at Microsoft and in the industry.
Attempting to run the newest Office 365 client on a 28-month-old version of Windows 10 can’t have the same expectation of stability and functionality compared to the current channel of Windows.
As the digital transformation extends deeper into business operations, the importance of the device will increase. We only see the initial phases of mixed reality headsets and hybrid tablets, and that means you should anticipate and prepare for more device types and management technologies that are dependent on the latest version of Windows.
Managing risk by ignoring WaaS is not an argument that IT departments can make in 2019. We must learn how to innovate on our feet and strive towards maintaining 100% compliant systems.
It makes sense that organizations without a culture of continuously testing their application portfolio against every OS update would perceive Windows 10 servicing as overwhelming. I try to talk their technicians off the ledge by pointing out that the Windows security patching process already updates itself without full application testing.
Seasoned administrators are fairly comfortable with the fact that security patches occasionally break things, and, over the years, they’ve learned how to fix them while minimizing disruptions. The same is true for Windows servicing; occasionally things will break when you deploy a new version, and you need to respond to them appropriately.
In my opinion, the most intractable problem plaguing WaaS adoption is the lack of formal and documented governance in the initial Windows 10 migration project. There are a lot of reasons why that is the case.
One I encounter frequently is that organizations don’t have a dedicated architect that specializes in desktop computing. Instead, they assign those duties to a senior desktop resource who doesn’t have enough time to invest in high-level planning or long-term strategies. This has to stop.
By now, I hope I’ve made it clear that for WaaS to operate effectively, someone needs to manage the ever-changing roadmap of Windows versions and features and how those changes impact your applications, devices, and end-users. Your computing environment cannot survive or scale without governance and planning – it is no longer a deploy and forgets the world.
WaaS Governance is Critical, not Trivial
Proper governance starts with properly identifying the RACI matrix (Responsible, Accountable, Consulted and Informed. See Responsibility assignment matrix.) for all the WaaS components. When I implement WaaS for my clients, I identify the various technologies that form the Windows 10 platform and custom design the RACI for each technology.
For example, some technologies could include:
- Identity (AD/AAD)
- Remote Access
- Mobility (Intune)
- ESD (SCCM)
Windows 10 image
- Application Readiness (outside of the image)
- Operational Support Readiness
My goal at this stage is to ensure that the staff who are assigned to specific IT roles understand what their responsibilities are for each deployment of Windows and that those responsibilities are on-going.
I take each technology and identify the different activities that each department within IT would perform before releasing a new Windows channel to the environment. For example, I would start with activities that should be performed to make sure the technology is ready for the next release for Windows then proceed to list the different groups that may be involved. Using the RACI matrix, I would assign which groups are responsible, accountable, consulted and informed.
In the example below, I’ve put down two items that would be a part of the Windows Image RACI.
Windows Image Applications
Supported devices list
Once a RACI matrix has been filled out for each major technology, the respective groups can further refine their list of activities and checklists that must be performed before the Windows 10 release is deemed ready. Sadly, there isn’t a one-size-fits-all approach here. The detail and the formality will vary depending on change management processes, culture, and available bandwidth for staff to undergo the servicing activities.
Once you have a complete RACI matrix, turn your attention to drafting a sound version release strategy. I recommend that organizations follow Microsoft’s release cadence with a 30-day offset for the first pilot. In reality, some vendors are pushing 90 days after the release of the next current channel of Windows before they resolve bugs.
The takeaway is that everyone, hardware and software vendors alike, needs time to address issues with each new version of Windows. Some vendors are better than others at fixing these issues, so incorporate that into your planning.
Not surprisingly, since bug fixes lag behind the Windows 10 current channel release schedule, so do many vendor support statements, which means they sometimes aren’t sure whether their product is compatible with the current channel. I hope you can see the cascading effect of continuous updates moving through the ecosystem and how important it is to follow the path of least resistance.
The path of least resistance requires that you thoroughly test your entire line of business application portfolio, hardware drivers, and management software before every Windows release and generate compatibility feedback for your vendors as early possible. Those vendors that want to stay competitive will get better at detecting bugs sooner, so send them your feedback.
My biggest issues with application compatibility so far have mainly come from products using undocumented Windows APIs. Many pieces of third-party security, virtualization, and management software rely on kernel-level APIs to operate.
Vendors aren’t at fault here. It can be a real challenge for them to work with Microsoft because Microsoft’s documentation on these APIs also lags behind the release cadence. That is to say, while Microsoft releases and changes features with every version, they reserve the right to communicate those changes when they see fit.
The good news is that lots of vendors are decent at addressing their issues with Windows in a timely fashion, which is why I suggested the 30 days offset above. This cascade of issues ripples through the ecosystem down to consumers and can delay or even derail a migration project or a device deployment project if they are identified too late.
Don’t Fly Blind
I hope I’ve made it painfully obvious by this point that every new release of Windows is going to cause some degree of turmoil in your environment that starts from Microsoft then moves outward to your vendors and finally ends up in your lap.
You get to choose whether that’s a set of predictable activities or a steaming pile of chaos. Take my word for it, get into the habit of collecting compatibility details for all your vendors (hardware and software), for each Windows version. In the old days, I would’ve personally contacted my vendors regarding compatibility. However, those days are gone, and we need to incorporate new ways of collecting and assessing compatibility information.
One method you can use to collect compatibility details is to use Windows Analytics (originally called Upgrade Analytics), which mainly identifies the applications that are installed on your device fleet and compares that data to a sample of other environments. Windows Analytics then estimates the likelihood that the application would work with the version of Windows 10 you are targeting to upgrade to.
There are some Microsoft and third-party vendor statements in the Compatibility Assessment portion of Windows Analytics to provide stronger indicators of application compatibility, but, for the most part, the system has gaps that have to be overcome.
One of the gaps is with the application inventory. Be aware that it isn’t currently capable of reporting on software that has been repackaged into a virtual application format. If you use packaging technologies (e.g., App-V) in your environment, you’ll have to find other ways to assess those applications. For example, install applications without packaging them, which exposes the compatibility information available from Microsoft.
As though matters weren’t complicated enough, it turns out that some line of business applications require extensive customization at the customer level. That means some application configurations can be unique to a single company or a handful of companies working in a specific region.
Going forward, consider using Application Health Analytics (new to Windows Analytics) to report on more information about application compatibility. Additionally, you can gain insights into other aspects of user experience on Windows 10 such as using Device Health to gather information about driver stability. That data is essential when piloting the latest release of Windows to help fill in the information blind spots that naturally exist.
The Art of Deployment
Included within IT governance planning, I create a group of IT staff that become the primary pilot group who receive new updates and can cope with unforeseen issues better than the average end-user.
One benefit of stacking the pilot group with power users is that you can safely approach their machines with a less comprehensive set of activities and streamline your workload. Using the feedback gained from the pilot users, the end-user computing team can remediate any issues and then finalize the complete set of activities, that when executed, will make the next channel of Windows 10 ready for general consumption by end-users.
Resist the urge to over complicate the deployment of Windows 10 servicing updates in your organization. It is tempting to use all sorts of schemes to segment the end-user population, but your governance model will be more agile and scalable in the months and years ahead if you keep things as simple as possible.
I recommend that you limit the number of deployment of rings to five and be prepared to have good justifications to add more. For example, in those cases where highly sensitive data and a subset of end-users require special provisions, it makes sense to create special circumstances for those end-users.
I also strongly encourage you to practice reducing the length of time it takes to complete each deployment ring so that the entire deployment of the next channel takes no more than 30 days.
Putting it all together, the path of least resistance in managing WaaS means you begin deploying ~30 days from Microsoft’s serving schedule and aim to complete each deployment within ~30 days. It will take practice and perseverance, but eventually, it will become second nature as the processes and tools evolve.
Work with your colleagues to design and implement IT governance capable of handling Windows as a Service. That includes defining and assigning the various roles and responsibilities within your organization and the urgency of not falling behind the current channel.
Get into the habit of collecting telemetry data to supplement more traditional forms of compatibility information and look for tools that can automate reporting. Use the data to uncover blocking issues lurking in your environment and gain important visibility about the performance and stability of your pilot group.
Keep things as simple as possible. Don’t over analyze who gets what, when. Give the end-user some time to commit to an upgrade at a time of their choosing rather than force it on them. At the same time, we have ensured that the overall upgrade process isn’t drawn out.
More than ever, successfully managing WaaS is going to be a team effort given it touches nearly every facet of IT and affects all your end-users. To keep your team operating at peak performance and your production environment current, it is critical that you implement proper governance.