I’ve recently had the pleasure of working with our Nomad team including the product manager, Troy Martin, and other Nomad experts on our recently released Nomad Upgrade Guide. Our Nomad documentation has always been very complete but one topic we wanted to address even more thoroughly was upgrades and related scenarios. As Troy mentioned in his blog posting announcing the guide, there can be special circumstances where additional steps might be needed in your upgrade process.
So what might complicate your Nomad upgrade, or your ConfigMgr (SCCM) upgrade that includes Nomad? The ultimate answer is to read the guide, but some key points in the meantime:
- Are you moving from ConfigMgr 2007 to ConfigMgr 2012 and do you have 64-bit clients in your environment?
- Do you have a mix of ConfigMgr 2007 and ConfigMgr 2012 clients in your environment and are both doing software update management?
- Are you migrating from ConfigMgr 2007 and ConfigMgr 2012 and using Package Migration Jobs?
The 64-bit point is easy to understand and just requires a bit of adjustment to your Nomad client deployment process. The software update coexistence scenario is a concern because ConfigMgr 2007 and ConfigMgr 2012 use different hash sizes when verifying content integrity. Software updates have universal identifiers (as opposed to site-specific identifiers), and so Nomad clients for both hierarchies can readily share software update content. Therefore you have to be sure that both hash sizes are available for the Nomad clients. That’s easy to understand but not necessarily something you would have thought about prior to reading the guide.
If you migrate packages using Package Migration Jobs from your ConfigMgr 2007 hierarchy to your ConfigMgr 2012 hierarchy you will find they also have identifiers that are common to both hierarchies (they retain their package ID). The same is true for applications migrated from one ConfigMgr 2012 hierarchy to another (they retain the application content ID). So those are much the same scenario as with the software updates.
Other considerations include:
- If you’re going to start using Single Site Download or Single Site Peer Backup Assistant, you should consider whether there will be a significant workload on your ActiveEfficiency server. Or will you be using those features more than you used to? If so, then you should review the size of your ActiveEfficiency server and possibly make some adjustments
- When you upgrade your ConfigMgr 2007 clients – that have been using Nomad – to ConfigMgr 2012, do you want to keep the ConfigMgr 2007 content in their Nomad cache? It could be beneficial to peer ConfigMgr 2007 clients that haven’t been upgraded yet. The content will be automatically purged by Nomad cache management when the disk space is needed for ConfigMgr 2012 content. However, you might prefer to clear out the old content right away. That’s really just a perception issue, and there’s a valid question as to whether any users would even notice. But sometimes perceptions matter.
There aren’t a lot of possible issues when you upgrade Nomad, and they’re easy to understand and mitigate if need be. But it’s only prudent to read the guide and think through the possibilities as part of your upgrade planning.
Enjoy the document, and we look forward to seeing your comments!
