Troy Martin and I have been very pleased to make the Nomad Upgrade Guide available to you and to have been able to present this blog series on the topic. I want to finish by focusing on the best practices for Nomad upgrades (and ConfigMgr upgrades that include Nomad).
We should start by remembering that best practices are generally the best approach but not necessarily the best in all cases. You might have extenuating circumstances that make it more appropriate to use a different practice. And even if you do want to follow the best practices, practical realities may mean that they can’t be fully followed in production.
In the Nomad Upgrade Guide you will find some best practices that may well be common sense, such as the suggestions to verify success and to upgrade as new releases become available. We expect you knows those already, but our experience is that they often don’t get followed. So maybe the extra details in the guide will help. Or maybe they’ll help when you go to your management to make the case for prioritizing that work.
We also encourage you to upgrade Nomad or ConfigMgr first and then when that project is done you should start taking advantage of new Nomad features. We certainly don’t want to discourage you from using the latest goodness in Nomad, but focusing on the upgrade helps to maximize success. And if something does go wrong then you don’t have to wonder whether it’s due to the upgrade or due to how you’re using the new features.
One of our suggested best practices, to maximize ConfigMgr client health, might not sound very Nomad related. However, we find that when doing Nomad upgrades this is actually one of the biggest contributors to success. In most cases ConfigMgr is used to deploy the Nomad upgrade, so if ConfigMgr isn’t healthy enough on a client to deploy the upgrade then that client will be left with the old Nomad version. That old version may respond to Nomad elections even though it doesn’t have the latest content or metadata (LSZ file).
A couple of the guide’s best practices are definitely Nomad-specific. Namely to upgrade the servers (distribution points) first and then to upgrade subnets as a whole. Upgrading servers first is also a best practice for ConfigMgr, so that won’t be a surprise. Servers are relatively few in number and so they can be upgraded quickly. Any compatibility issues will be addressed there so that they can serve both old clients and new. Upgrading subnets as a whole might be less intuitive but the key point is that Nomad clients work collectively on subnets to help each other. Elections are subnet-based, and peer-to-peer sharing is typically on the same subnet. So if you upgrade all the clients on a subnet at essentially the same time then they are ready to work together using the same version.
By understanding whether there’s a chance that you could face any challenges, by using good processes, and by following best practices, you’re sure to have a great Nomad upgrade experience. The Nomad Upgrade Guide has the full details you need for complete success. Enjoy your upgrade!