Windows 10 Branch Upgrade Solution Architecture Part 2

Managing-Windows-10-Updates

In part 1 of this discussion on Windows 10 branch upgrade solution architecture, I set out the key elements of a Windows 10 branch upgrade solution architecture. The points of upgrade education, end user communication, and solution preparation were discussed in that first article. Let’s complete this discussion by diving into the upgrade rollout model and issue management.

Upgrade Rollout Model

In the article on Windows 10 Branch Upgrade Strategy, I outlined different models and timelines for how to rollout your upgrades. Create a similar rollout model for your organization making sure you have nailed down these key elements:

  • Rollout Groups: Hopefully you have already structured your organization into groups for patching, software rollouts, and previous operating system migrations. If you haven’t, now is the time to do so. At minimum have a pilot or test group and a production group. It is very likely you will have more than 1 of each. Here is one example to get you thinking:
    • Pilot Group 1 – IT: Start here as you should have the most communication with these individuals and they should be technical enough to provide detailed feedback if issues are encountered.
    • Pilot Group 2 – Power Users and Application Owners: Find the tech heads of different departments who will, again, provide detailed feedback if issues are encountered. Also, find the business application owners who aren’t in IT. If you don’t know who these people are, start networking internally. They will surface if you ask.
    • Production 1 – Non-Critical Systems and Users: This is a loaded term, but figure out what systems and users won’t cripple the business if the upgrade has issues. Different departments may be more critical at different times or the year or quarter (sales, finance, etc.). This difference in time of year and quarter could merit breaking this group into 2 or timing very strategically. Every organization is different so make sure you understand yours before assigning anyone to a group.
    • Production 2 – Critical Users: This is the phase to address those critical users like sales, finance, or service delivery. This phase may need to be paused depending on the time of the year or quarter.
    • Product 3 – Critical Systems: This probably includes any system that has material impact on the business in terms of generating review or delivering a service or product to a customer. It could include systems that control medical devices for example. Again timing may apply criticality here, but understanding your business is paramount.
  • Timing: Each rollout group should have a set time in which the upgrade occurs. Remember the 80\20 rule in that you will likely get 80% of the group upgraded quickly and will have to work hard for the other 20%. Also, the upgrade is not the end goal, but making sure business continuity is maintained with optimal service levels. If you have 3 months for pilot group 1, try and get the upgrades completed in month 1 so the remaining 2 months can be used to assess impact.
  • Acceptance Criteria: Before moving to the next phase, know what you consider success. Is it 100% desktop usability (or 95%)? Is it based on a review of all critical incidents related to user’s who were upgraded? Who makes the approval decision? Answer these questions before moving on to the next phase.

Issue Management

One can expect a certain percentage of systems to have issues during the upgrade process. Part of the solution architecture should take into account how to address issues so as to not slow down the overall rollout and to ensure that systems are upgraded before patch support is discontinued.

There are likely many areas to plan for, but I will throw out two that you can prepare for:

  • Hardware: Two examples: Do drivers impact the upgrade? Are storage limitations an issue?
  • Application compatibility: This is likely the number one issue you will run into. What business and 3rd party application teams\vendors do you need to call on when issues are encountered? If a compatibility issues become an upgrade blocker, what is the plan?

Key Takeaways

As the challenge is big, so is the solution. Here are the key points to share around an upgrade solution architecture

  • Upgrade education: prepare your users for the changes
  • End user communication: remember to communicate expectations before, during, and after the upgrade
  • Solution Preparation: the solution architecture needs to be robust and automated
  • Upgrade Rollout Model: break your enterprise into groups and upgrade methodically
  • Issue Management: Windows 10 forces tight timelines so prepare for issues in advance

With the solution architecture setup, I will next explore how LANDESK can help with Windows 10 branch upgrades.