With Windows 10 now into its latest edition, the 1607 “Anniversary” update, it now appears, for better or worse, to be here to stay. It has generated a lot of interest; supposedly the “last version of Windows”, many expected it to be akin to Windows 7 – an improvement following a much-maligned previous Windows version. However, the reality has turned out to be somewhat different from what many were expecting.
Microsoft are now “cloud first, mobile first”, and a lot of this new strategy shows through – sometimes somewhat cynically – in Windows 10. For my sins, I’ve been involved in a Windows 10 deployment since August of 2015, so now, just over a year in, it is maybe time to share the things I’ve learned in the hope that it may give some of you a bit of help when it comes to deploying (or not deploying!) this new version of Microsoft’s flagship operating system.
This set of articles is going to expand at the rate of one a day over the next week or so, and cover a wide range of issues for those of you deploying Windows 10 – whether it be fully virtualized via Citrix XenDesktop or the like, or simply a general physical deployment. Hopefully, it will be everything you need to know!
The first part of this series – Editions – can be viewed here.
SERVICING BRANCHES
Firstly, let’s dive into some terminology.
Feature upgrades are entire copies of the Windows 10 operating system. Gone are the days where you would have to load the OS and then slipstream a service pack to activate new features – Windows 10 feature upgrades ship as entire operating system packages. Essentially, this means we’re already adopting Windows As A Service – the RTM version could be considered 10.0, the 1511 “Threshold 2” update 10.1, and the recently-released 1607 “Anniversary/Redstone” update is 10.2. So when you’re applying a feature ugprade, bear in mind this is an entire operating system you’re loading up, as it was when moving from NT4 to 2000 or XP to Windows 7. So with that in mind, when you’re thinking about releasing a feature upgrade to your users, it needs to be thought about a lot more seriously then any patch, rollup or even service pack. To avoid unforeseen problems, I’d always recommend that you “wipe and reload” when it comes to a feature upgrade – rather than “upgrade in place” – but this does mean your user settings and data will need to be stored somewhere other than in the local image.
Servicing updates are what we’ve traditionally known as hotfixes and patches. There are occasional larger “cumulative updates” (which you might look at as service packs or “rollups”), which tend to land almost at random. You will also start to notice an annoying lack of details in the servicing updates that you receive – the generic term “bug fixes” is sometimes all the information you are given. Update – the “cumulative” model is now being adopted exclusively for Windows 10, and also back-ported to Windows 8.1 and 7.
Definitions apply to things such as Windows Defender updates and new versions of software like the Malicious Software Removal Tool.
Deployment mechanisms
You can receive the feature upgrades and servicing updates in one of three main ways:-
Windows Update – direct connection to the Microsoft update servers
Windows Update for Business – this is primarily a “WSUS-lite” aimed at SMEs. You can use GPO or InTune MDMs to split your devices into “rings” for instant or deferred deployment. The controls allowed in WUB are not as granular as those of WSUS or SCCM. You cannot defer definition updates at all, servicing updates can only be deferred by a maximum of four weeks, and feature upgrades by eight months. More details on WUB here.
WSUS/SCCM/other third party tools – these are the traditional tools that enterprises use for deployment. They allow full deferral control of all updates (feature upgrades, servicing updates and definitions).
Branches
Each deployment mechanism is invoked by a particular servicing branch. There are effectively four you need to be concerned with:-
- Windows Insider
- Current Branch (CB)
- Current Branch for Business (CBB)
- Long Term Servicing Branch (LTSB)
Each branch can be accessed by specific Windows editions. The diagram below hopefully may simplify the relationships between editions, servicing branch and deployment mechanisms.
Now, some commentary on this.
Windows Insider can be accessed by any edition and is turned on via Control Panel or GPO. Effectively this is an alpha tester branch. I would highly recommend getting a number of test systems onto Windows Insider, so that you have advance warning of upcoming changes to the interface and can validate application compatibility. For instance, the 1607 update introduced a change to the Start Menu which users found confusing. By using Windows Insider test machines on a limited basis, we had prior knowledge of this.
Home edition users can only use Current Branch, which means they receive all feature upgrades and servicing updates at the time of the release. So effectively, Home users become beta testers. There is no way to defer updates at all (see below), which means (the clue’s in the name!) that Home edition is not suited at all to business use. Professional, Education and Enterprise can all use Current Branch if they wish – but to be honest, in a business environment of any size, you’d be mad to install all updates as soon as they’re available, so stay well away from adopting Current Branch.
 |
| It’s now, or later – how updates are delivered in Windows 10 Home |
Current Branch for Business can be accessed by Professional, Education or Enterprise clients. CBB entitles you to use Windows Update for Business, WSUS, SCCM or third-party tools for deployment. Unless you are a very small business with limited IT function, I would not recommend utilizing Windows Update for Business, as it gives limited deferral for servicing updates. Most businesses probably already use SCCM or WSUS, and it would be prudent to continue doing so. CBB coupled with WSUS or SCCM allows you to defer feature upgrades and servicing updates for a window somewhere between 8 and 12 months (dependent on Microsoft’s release schedule). It’s also interesting to note that if you end up using Citrix’s upcoming Azure-based Windows 10 platform, you will need to be on CBB as your servicing branch.
Long Term Servicing Branch can only be accessed by Enterprise edition. LTSB is essentially a different operating system and has many features removed, particularly the plethora of Modern Apps (more on Modern Apps in part #3 of this series). If you wish to move between LTSB and the other branches, it will necessitate an operating system reinstall (conversely, the difference between CB and CBB amounts to nothing more than some policy settings for installation). LTSB allows you to defer feature upgrades and servicing updates for a window between 1 and 10 years (the choice is yours how long you leave it).
CBB and LTSB aren’t exclusive – you can mix and match your devices between the two and manage them all centrally. So what parameters do you need to be aware of when it comes to choosing between these servicing branches?
To LTSB, or not to LTSB?
According to Microsoft, your business should be a mix of CBB and LTSB on Enterprise. The “regular” machines are intended to run CBB (so never falling more than about eight months behind the current release schedule) with anything hyper-critical (like life support systems and air-traffic control stuff) sitting on LTSB. That’s what they’ve envisaged, anyway.
Unfortunately, there are problems with this. Firstly, many businesses consider their “regular” desktops to be mission-critical, especially when they are being used by employees that generate revenue streams. A feature upgrade or servicing update that kills an application that is vital to these employees will be a big issue. Of course, Microsoft envisions that the eight-month deferral should be enough to identify any problems and correct them, but is this enough? What about seasonal applications only used at particular times? A good testing process should help with this, but sometimes vendors can have turnaround times for fixes that will far exceed an eight-month limit (and that’s assuming that you discover the issue straight away – what if it takes three months of testing to uncover the problem?) And if the vendor position becomes “our application should only be run on LTSB in a Windows 10 environment” (which it might well do!) then you might find yourself having to change tack rather abruptly.
The second problem is that Microsoft have surreptitiously turned the sacrosanct system of Windows Update into a vehicle that delivers not just security patches and fixes, but now appears to have been abused to push advertising, unwanted upgrades, make patches that were manually disabled reappear, and run activation and DRM updates. It took a lot of time after the 2003 Blaster and Sasser attacks to get people to take updating their Windows machines seriously. Now that we’ve reached that stage, do we want Windows 10’s aggressive update functionality to potentially turn them back the other way?
Of course, many people point to Apple’s OSX, and the Chrome and Firefox browsers, as examples of how an aggressive, fast-release update cadence works well. The Windows operating system, though, is a different kettle of fish. Breaking a browser doesn’t generally bring things to a grinding halt – you can simply switch to an alternative. And Apple’s OSX doesn’t have the huge legacy application compatibility that Windows prides itself on to be considered comparable – in fact, that backwards compatibility is often one of the reasons Windows operating systems are actually in use.
So what do we do?
The key question here is
Can my LOB application vendors reliably provide a fix to a discovered application issue within an eight-month servicing window?
This answer determines, in my opinion, whether machines using that application are best suited to CBB or LTSB.
If you’ve got LOB applications that, in the event testing throws up an issue, can get that issue resolved or worked around by the vendor within eight months, put the devices using those applications onto CBB.
If you’ve got LOB applications that, in the event testing throws up an issue, the vendor can’t produce a resolution or workaround within eight months, put the devices using those applications onto LTSB.
Summary
You need to think very carefully about Windows 10; and the depth of that thought depends on the applications you rely heavily on. Because there’s been a change to the way updates are handled, you need to ensure that your update processes and the applications that they support are going to be safe on a Windows 10 platform. And if you can’t ensure that they will run without interruption, you need to take the appropriate remedial actions, whether that be adopting LTSB, virtualizing them through an application virtualization/layering solution, or something else. Windows 10 brings with it a big difference to the way we’ve managed our environments for the last fifteen years or so – and you need to make sure you’re not just aware of it, but well on top of it.
But anyway – here are my key recommendations:-
- Get a number of test machines onto Windows Insider to stay aware of future changes. Microsoft don’t just add features, they also take them away (see Wifi Sense for an example of this). If your user base have come to rely on a feature in Windows 10, and Microsoft decide to take it away because they can’t be arsed with it any more, it will cause disruption!
- Do not use Current Branch, unless you’re insane and like fighting fires.
- Do not use Windows Update for Business, unless you’re a very small business.
- Use WSUS or SCCM or similar for deploying updates – this is the tried-and-tested method, and should be persisted withUse Current Branch for Business on all machines where possible, if the vendor can meet the lower end of the servicing window deadline
- Use LTSB on specific target machines where the vendor cannot meet the servicing window deadline
One final thing – if you fail to keep machines up-to-date and miss the servicing window deadline, it’s not entirely clear what the penalty is. I’d appreciate some clarity from Microsoft on this (ever hopeful!), but best I can tell, either the system will be classed as unsupported, or it will stop receiving future servicing updates. Either way, it’s probably best to try and avoid falling into this area.
Stay tuned for part #3, which will delve into the mysteries of Modern Apps on Windows 10.
Share
