Strategies for Windows as a Service – A Process-Oriented Perspective
I am often asked about the right strategy for “Windows as a Service”. But is there the right way? The short answer is no. It depends as so often on the circumstances, the requirements of the customer and the other customer-specific circumstances. In this article, I would like to point out different ways to the subject of Windows as a Service (WaaS). You will also get tips on what to consider when searching for your way.
What is important is that Windows as a Service is not a project, it is a process. And the challenge is to develop the process for your company in such a way that it works performant but covers all contingencies. This doesn’t just include the question if you want to skip releases.
The audience for this article
Normally I don’t define the audience for an article, but this time a small remark. Most articles are relevant for medium-sized companies up to large corporations. If you are a one-person IT department, the article will be more from the category ” to use a sledgehammer to crack a nut”.
It is also important to note that this is more about processes and organisation than about technology. But I will link to further technical articles at the appropriate points.
If you are only interested in the topic “Preparations for an In-Place Upgrade with Windows 10” I recommend to take a look at the German Dell EMC Blog. There you will find two articles from me on this topic (Sorry, this article is only available in German):
- Vorbereitungen für ein In Place-Upgrade mit Windows 10 – Teil 1
- Vorbereitungen für ein In Place-Upgrade mit Windows 10 – Teil 2
General conditions, requirements and dependencies
Before we get down the path, let’s consider a few things. There are some things you need to think about if you want to find your way around WaaS. The most important topic is the requirements, which have to be fulfilled.
Requirements for Windows as a Service
Here you have to think about which requirements have to be considered in your strategy. These can be regulatory or legal requirements. Often there are also requirements from certifications such as ISO or IT-Grundschutz in Germany or similar. Other requirements can also be company agreements with the working council (e.g. keyword telemetry) or IT requirements from your own company.
It is important that you meet a requirement or have an exception approved for you. Here are some examples of requirements that affect Windows as a Service strategy:
- Validation according to Medical Devices Act (If also intended for software)
- IT basic protection rules like German IT Grundschutz
- Regulatory requirements for update management or software integration
- Company agreement on telemetry or software usage analysis
- Possible data protection laws / GDPR / DSVGO
- Internal processes on the subject of software management, partly specified by certifications
Examples from the field
To make the whole time a little more descriptive, here are a few selected examples from the field, and possible consequences:
- In the processes for quality assurance in the company, it is described that every new software version must be checked for function. This process is part of the iso certification in the company.
- Depending on the definition of the process, each minor update must be tested according to the process.
- Automatic solutions are more complex to implement the requirements of the process.
- This applies not only to feature upgrades but also to normal updates and security updates.
- In the IT works agreement with the working council, it is agreed that no telemetry data may be collected, also the recording of the use of the software is prohibited.
- No use of Modern Analysis for feature upgrades like Windows analytics or Desktop analytics is possible. Software dependencies must be analyzed independently.
- Influence on the selection of the Windows Edition: Telemetry 0 (only security-relevant) is only possible with the Windows 10 Enterprise Edition. The complete deactivation of telemetry is not intended and is not supported by Microsoft.
- There is no overview of which applications that have not been managed or installed by IT are on the systems. This can lead to compatibility problems with the next feature upgrade.
- According to the internal IT concept, based on the German IT-Grundschutz, security updates must be installed within 5 business days.
- For example, this can cause problems with the QA example mentioned above if the process is not appropriate.
- This affects the distribution and, if necessary, the monitoring of the update installation.
As you can see, some of the requirements can be very difficult. Now I have intentionally chosen a few more extreme examples from practice. The important thing is that if you have difficulties in the IT department with sorting out the requirements and designing the process, you can look to external experts for assistance. My tip is to ask them about their experiences and how many processes have already been designed for WaaS. Not every IT consultant has fully understood WaaS and knows the different possibilities.
The general conditions also include, for example, the circumstances that must be taken into account. Since WaaS has to consider not only the updates but also the upgrades, there are some things that can have extreme influences. Here again a few examples with the explanation of why this could be important:
- Number of employees for the Windows client and the necessary processes
- Depending on how complex the process is, it makes a difference whether one person or five people are available for these tasks.
- This is especially true when manual tests have to be performed.
- The number of applications that need to be tested for compatibility and how they need to be tested.
- Is it 10 applications or 3577 applications? This makes a significant difference when checking whether the software is ready for the next release. Especially if no modern analysis, like Windows Analytics, can be used.
- What does the check look like? Start, print, close without any error message? Or more detailed?
- Who verifies or approves a new version? The IT department or perhaps the application managers from a department?
- Is there a test environment?
- Is there perhaps a test environment where everything has to be verified first? This is safer but also ensures complicated processes.
- Does a new software have to be transferred to production after the evaluation as a change according to ITIL?
- Does the evaluation also take into consideration the different hardware platforms?
Here, again, it is easy to see how important some of the points are. It quickly becomes clear that a process that involves 2 people with testing 2500 applications manually before they are released is very difficult or even impossible.
The last of the three large areas of this preparatory mental exercise is the subject of dependencies. And this does not mean that application B needs a Java version that was delivered on stone cards. It is about dependencies for the process. An important factor for dependencies is the topic of time and cycle time. It is important that you know the respective connections and uses them accordingly.
Again a few examples from reality:
- Software with changed functionality (e.g. new Office365 release or new Windows 10 release) will need to be approved by the works council.
- From the experience, you should try to agree on an SLA. I once had the experience that a works council needed 9 months for a Windows 10 approval. Think about what this means for an 18 to 30-month support lifecycle. Tip: On Infrastrukturhelden.de you can download various Life-Cycle Diagrams for free. (At this point of time it is not translated, but you can check meanwhile)
- Security updates must be coordinated with the IT security officer.
- Also here the topic SLA and deputy regulation is important or must be waited 3 weeks until the safety representative person comes from the vacation?
- Dependencies to other departments, for example, new group policy templates can only be implemented by the Active Directory team.
What is important here is to find your interfaces and dependencies. Also look for SLAs for the respective connections, especially if an SLA is expected from you. How do you intend to meet a 30-day SLA for upgrade readiness if, for example, the works council allows 90 days for the check?
It is important to document requirements, dependencies, connections and framework conditions precisely. You can also be questioning the one or other requirement. Since the process for Windows has been changed by the manufacturer, it is legitimate to question the previous status quo. Possibly there will also be one or the other meaningful change in the previous workflows.
It is also important to collect these points in a team. It may also be useful to include other posts in the process, such as the works council or the IT security officer.
Common mistakes or suboptimal decisions from the reality of process design
Here are a few examples from reality which I think are sub-optimal or difficult. These do not necessarily have to be wrong, it depends on the requirements. Here are my personal two highlights from the field:
Acrobat PDF and its pitfalls
For this customer, IT was responsible for the function of the software. There were no test specifications from the business divisions regarding the respective software. Since IT has no specifications, the test scenario for Acrobat Reader was as follows:
- open a PDF file
- print PDF file
If this worked without errors and the printed output matched the PDF, the test was considered successful.
What IT didn’t know was that a mission-critical business application in a department was based on an Interactive PDF document created with an older version of Adobe Acrobat. The specialized application was mostly used at the end of the month. That doesn’t sound bad in itself, but interactive meant in this case:
- The form changes on the basis of the entries made at runtime.
- The print view does not correspond to the screen view (Intended, since the form does not have to contain all the information).
- The content of the form can be sent as a mail-in a defined format.
Something went wrong with these special requirements. Some of the functions stopped working unexpectedly. The sub-optimal circumstances in this case?
- The test cases were not agreed upon.
- IT was responsible for the function without knowing the demands.
- At the beginning of the month a test group received the new version, after 5 days without problems it was distributed to all systems => Unfortunately none of the test groups used the application with the special PDF during the 5 days.
This is one of my favourite real-world examples of why you should have a coordinated test protocol for all applications, even a browser or Adobe. Or even better, to delegate the responsibility for specialized applications to the respective department. This department should be responsible for testing and releasing. That’s where the competence for the application usually sits.
A customer has an extra test environment. New Windows releases and updates were tested in this environment. In this test environment, all defined tests were tested on virtual machines and a hardware category. Unfortunately, another hardware model, which accounted for about 30% of the systems in the environment, had a problem with the driver. This led to bluescreens at irregular intervals. Bonus issue: This was the preferred hardware model for VIPs.
What was good in this case?
- Own test environment and pre-production
- Change management according to ITIL
- Defined test protocols
What was sub-optimal?
- Too few hardware platforms
- No clean management of drivers. My tip: Treat drivers like normal software, including release management.
Solution approaches for a process
Basically, a Windows as a Service process is just like the previous processes for Windows updates and the implementation of a new Windows version including the migration there. I recommend mapping both topics in single processes: Normal updates and feature upgrades, i.e. new releases. Since my practical experience is that most customers have the update topics under control, I would like to concentrate here on the topic Feature Upgrade.
A classic process for this in the past, for example, looked like this:
The actual headings can also be used for the new process. The difference is that the process restarts immediately after completion or with the next Windows release. But that would be a very classic approach. This approach would also be more static and is often used by companies who want to go the old way first. But how could such a process look like for WaaS? Here is an alternative version:
This process looks a little more complex, so it is. But it’s just an example and depending on the environment it’s still pretty simplistic. For example, Windows Analytics Upgrade Readiness could be integrated as a selection criterion for the rollout. This means that only systems that are ready after upgrade readiness are migrated. Further process steps such as application tests could also be integrated by application managers.
This process design also takes into account new approaches such as Insider-Preview for Business to reduce implementation time. The ring model recommended by Microsoft is also used here. And before questions come, a detailed process description for copying I intentionally do not publish here. This process is an example, not a copy template.
This article first appeared on Infrastrukturhelden.de in German.