Windows 10 Branch Upgrade Solution Architecture Part 1
In previous articles, I’ve covered a lot of information on Windows 10 branches. As you have seen there are a lot of new concepts and challenges with Windows 10 branch upgrades that did not exist in previous versions of Windows. With all of that as background, this article is the first of two parts around a Windows 10 branch upgrade solution architecture.
In order to build an effective solution, the following elements should be in place:
- Upgrade Education
- End User Communication
- Solution Preparation
- Upgrade Rollout Model
- Issue Management
Before doing an upgrade, consider the changes to the user experience. Branch upgrades are not as drastic as a new version of Windows, but instead introduce new features and usability gradually. Depending on your organization, you may simply inform them that a new version of Windows 10 will roll out and to expect changes. For change sensitive people, you may need to consider some deliberate training in preparation. Use experience from previous operating system migrations to determine what is best here.
Do not underestimate the importance of communication as you develop your solution. As noted in the Windows 10 Current Branch article, upgrades will be disruptive and take around 30 minutes. With these challenges in mind, communications should be multi-phase:
- Pre-upgrade application owners: Application owners should be notified of the upgrade plan and schedule so they can test their application to ensure business continuity. Constant communication of the upgrade process should be delivered to the application owners.
- Pre-upgrade end users: Users should be prepared to understand that the upgrade experience is unlike anything they have experienced in the past. It will take time and prevent them from doing work. Show them screen shots of what they can expect and remember users will ignore your emails. Per the upgrade education section, make sure to educate them on changes before the upgrade.
- Upgrade launch: Per my previous point, users will ignore any emails you send them. Before launching the upgrade, they should have an on screen notification that summarizes what will happen and point them to a web portal with detailed explanations.
- Post upgrade: Branch upgrades introduce new features and we all know that despite all the testing you may do, there is the potential for issues. Make sure that post migration, there is a method to gather feedback and measure upgrade issues.
- Upgrade readiness: An operating system migration requires many considerations (CPU, RAM, etc.). In the case of the branch upgrade, the one element that should be constantly monitored is free disk space. It isn’t clear how much space is required for a branch upgrade, but remember the upgrade file is 3 GB for x86 and 6 GB for x64 plus space for temporary files. As a safe bet, keep to the Windows 10 specifications for free disk space of 16 GB for x86 and 20 GB for x64.
- Targeting: As mentioned in the Branch Upgrade Strategy, enterprises need to plan on having a systems on multiple branches. This will require that users and computers are assigned to groups identifying them with their branch. Once done, you need to plan on targeting migrations appropriately (for example Current Branch to Current Branch).
- Distribution: As upgrade packages are large, enterprises will need a plan for how the package will be distributed and cached. The existing software delivery architecture needs to be ready for 4 GB files as that is the size of the 1511 x64 package.
- Off-network systems: In many enterprises a significant minority if not majority of clients will be laptops many of which spend little time on the corporate network. With these systems, there must either be the option to remotely upgrade them or have a planned upgrade when they are on the network.
There is a lot of information to cover for a Windows 10 branch upgrade solution architecture. In part 2, I will dive into the upgrade roll out model and issue management.