Upgrade Scenarios

Upgrading Nomad only

In this scenario, Nomad is upgraded separate from any Configuration Manager Current Branch upgrade. This is the simplest and most common scenario that typically occurs when you want to keep your software current, take advantage of new features and improvements in the latest versions, or your current version is nearing end of support. In some cases, new features in Nomad may require your ActiveEfficiency server to be upgraded or additional solutions such as Tachyon to be implemented.

Upgrading Nomad is a straight-forward process that involves upgrading the server, tools and console components first before upgrading Distribution Points and finally clients. Nomad is generally backward compatible and unless otherwise stated in the product documentation, existing features will be supported by the new version. 1E realizes the importance of compatibility to maintain client operations during the upgrade process.

1E recommends using the 1E Client Deployment Assistant (CDA) to upgrade clients. The CDA creates Packages, Applications, empty Collections and Deployments with custom Windows Installer transforms to simplify the installation and initial configuration of the 1E Client and its modules. You can then simply add devices into the Collections to upgrade Nomad on those devices. 

If previous versions of Nomad have been deployed as an Application in Configuration Manager, you should define supersedence on the Application that installs the new version so that it supersedes the previous versions. This is very important, as it prevents attempts at downgrading Nomad through Application Deployment Enforcement if there are still active deployments for the previous versions.

Upgrading Nomad may also require updates to existing Task Sequences. Existing Nomad Task Sequence steps will continue to work after upgrade, but it may be necessary to remove and replace them after upgrade to implement any fixes or improvements included in the new version.

Upgrading Configuration Manager

Configuration Manager (CM) Current Branch (CB) is updated three times a year. In most cases, updates to Configuration Manager do not affect core Nomad functionality. 1E endeavour to test all supported versions of all products and release a support statement within 30 days of General Availability ('slow ring') of a CM CB release. If any issues are identified, 1E will endeavour to fix the issue within the 30-day period, provide a workaround or communicate when the issue is expected to be resolved. Any such fixes will usually be implemented as a hotfix (that will be rolled into future versions) rather than an upgrade.

If your currently installed versions of Nomad and ActiveEfficiency support the version of CM that you are upgrading to, you can go ahead and upgrade CM. Even though your currently installed versions are supported, you may like to take this opportunity to upgrade to the latest versions, or at least apply the latest hotfixes, to keep your software current. In that case, upgrade CM first, then update / upgrade Nomad and ActiveEfficiency accordingly, following the process for upgrading Nomad only.

If your currently installed versions of Nomad or ActiveEfficiency do not support the version of CM that you are upgrading to, you will need to update (hotfix) or upgrade them before upgrading CM.

Side-by-Side Migration of Configuration Manager and Nomad

If you are implementing a new Configuration Manager hierarchy with the intention of migrating devices from a separate hierarchy to the new hierarchy. Nomad Branch Tools and Nomad Admin Console Extensions would need to be installed in the new hierarchy. If those devices to be migrated already have a version of Nomad installed that is supported on the CM version of the new hierarchy, they can be migrated to the new hierarchy with no further changes needed to Nomad. If the currently installed version of Nomad is not supported on the new hierarchy's CM version, you will need to upgrade Nomad before migrating clients to the new CM hierarchy.

If ActiveEfficiency is being used in the old hierarchy you have two options.

1. Reconfigure the existing ActiveEfficiency server to synchronize with the new CM hierarchy. This option has the benefit of retaining SSD site definitions and historical data for content distribution and pre-caching. If package objects have been migrated from the old hierarchy, thereby retaining their content ID, this option will also enable clients that have not been migrated to share content with those that have across subnets (using SSD). However once ActiveEfficiency is synchronizing with the new CM hiearchy, you will no longer be able to manage pre-cache jobs from the old hierarchy and the dashboard will only be updated with activity from clients reporting into the new CM hierarchy.
2. Implement a new ActiveEfficiency server configured to sync with the new hierarchy. As clients are migrated to the new hierarchy, they should be reconfigured to report to the new ActiveEfficiency server. Pre-caching, SSD and dashboard reporting can be managed independently from each hierarchy until all clients are migrated to the new hierarchy.

Preparing for Upgrade

You should include the following steps in your preparation for upgrading.

1. Review how you are currently using Nomad
   1. Confirm which components you have implemented and where (clients, Nomad Branch Tools, Nomad Admin Console Extensions, ActiveEfficiency)
   2. Confirm which features you are currently using (e.g. SSD, FanOut, PBA etc.) and ensure your current configuration settings are recorded. Be aware that newer versions of Nomad may change the default values of some configuration settings. In most cases the original settings will be preserved when Nomad is upgraded, however it is important that new clients are deployed with a configuration that is compatible with existing (upgraded) clients.
   3. Identify any clients that have a special Nomad configuration. For example, you might consider some clients to be sensitive and consequently have adjusted their Nomad election weighting so that they never become Nomad masters. You should review whether there are any such exceptions and incorporate them in your plan accordingly
2. Familiarize yourself with the features that have been introduced and other differences between your currently installed version and the new version.
   1. Check the Features by release page in the Nomad documentation
   2. Check the Preparation and Prerequisites pages in the Nomad documentation as there may be new pre-requisites and some versions of Windows, CM and SQL Server may no longer be supported.
   3. Determine how the new features can benefit your organization and then learn the details to make them effective. You may prefer to wait for the upgrade to complete and settle down before enabling new features.
3. Check if any hardware upgrades or new hardware are required for any new features you intend to implement (for example, Tachyon is required for the Nomad Download Pause feature) and plan for these sufficiently in advance.
4. Obtain the latest software versions and hotfixes from the 1E Support Portal
5. Review CM health. You will be using CM to deploy the upgrade to clients, so any effort in ensuring CM is functioning well will ease the upgrade.
6. Plan your upgrade
   1. You should have a lab or pre-production environment that closely reflects your production environment to test your upgrade process before going into production.
   2. Document an upgrade plan and validate it in the lab or pre-production environment. Validation should include all features that you are currently using.
   3. Where practical, upgrade all clients on a subnet at the same time. This minimizes the potential for version-specific issues such as hash or election differences (specifically when taking advantage of newer Nomad features such as the Cloud DP and CMG support functionality). Nomad elections are subnet based, so any Nomad client on the subnet could respond to another Nomad client, regardless of Nomad version or Configuration Manager differences. If the Configuration Manager clients that Nomad is installed on are the same version and reporting to the same hierarchy then issues related to Configuration Manager differences are avoided. 
   4. Start small. Build Collections for pilots. The wider upgrade can be deployed to a Collection of all clients with the old version installed. As clients are upgraded they will move out of the Collection.
   5. Validate each stage before progressing to the next stage. Things to check:
      
      • The correct versions are now in place
        • Configuration Manager hardware and software inventory reports can confirm this
      • Core functionality is working – downloads over the WAN and peer-to-peer content distribution
        
        • Manual inspection, including log reviewing, is ideal to confirm this in the early stage
        • The Nomad Dashboard can confirm it on a broader scale
      • Core scenarios are working – deployment of the various content types you use, representative operating systems and hardware
        • Nomad Dashboard can be used for this
      • No negative side effects
        • Thorough lab testing is important
        • Stay alert to helpdesk incidents and other means of reporting anomalous behavior
      • All components are upgraded – clients, Nomad Configuration Manager Admin Console UI components and ActiveEfficiency as appropriate to your environment
        • Configuration Manager hardware and software inventory reports can confirm this as well
      • Secondary functionality and scenarios are working as desired
        • Status reporting for OSD deployments or similar efforts provides this
      • Server workloads do not change unexpectedly, and the server performance continues to be acceptable at all times
        • Standard server monitoring and alerting
      • After all clients are targeted with your Nomad client upgrade, the targeting collection will become smaller (since it is targeting clients that are not the correct version). It may take some time to become empty due to clients that are offline
        • A small number of collections will be involved, so use manual inspection in the Configuration Manager console
7. Follow your upgrade plan in the production environment

Upgrade Sequence

The upgrade process presented within this document implements three simple maxims

• If you are upgrading Configuration Manager and your currently installed versions of Nomad or ActiveEfficiency are not supported on the new CM version, you must upgrade these before upgrading CM.
• If you are upgrading Configuration Manager and Nomad at the same time and your currently installed versions of Nomad and ActiveEfficiency are supported on the new version of CM, upgrade CM first then upgrade Nomad and ActiveEfficiency,
• Upgrade server components before clients

The figures below describe the principal processes and the sequence of steps involved when performing an upgrade. Described, is the logical progression of an upgrade process based upon the following possible scenarios:

• Nomad only upgrade
• Configuration Manager only upgrade
• Configuration Manager and Nomad upgrade
• Side-by-side migration of Configuration Manager and Nomad.

Upgrade FAQ

Client Upgrade FAQ

This section will attempt to answer some common questions related to upgrading the Nomad client.

What versions of Configuration Manager does Nomad 7.0 support

Refer to Supported Platforms.

How do I upgrade?

Follow the process described above.

Do I need a new license key when I upgrade Nomad?

No. Old versions of Nomad required a license key, but a license key is not required to install 1E Client with Nomad enabled. However, your organization must still buy a license to use Nomad.

Why use the 1E Client Deployment Assistant during the upgrade?

The Client Deployment Assistant (CDA) was developed to allow easy installation and configuration of all 1E Client modules and the PXE Everywhere client. CDA includes all the client installation packages and is updated and released alongside new client releases.

CDA is an installation wizard that guides you through the configuration creation and deployment of Applications and Packages that install the 1E Client modules (Nomad, WakeUp, Shopping and Tachyon) and the PXE Everywhere and NightWatchman clients. The CDA is designed to speed up client deployment and ensure consistency of their configuration with the CDA providing a set of recommended configuration settings that can be changed either through the wizard or by editing the AppImport.xml file and running CDA in unattended mode. For more information on how to use the CDA, refer to 1E Client Deployment Assistant 1.5.

During an upgrade, are my customized registry settings preserved?

Yes. All upgrades will preserve the Nomad registry settings, as well as any content that exists in the Nomad Cache. However, it is recommended that users always deploy the upgrade using their desired transform (MST) in order to ensure that any existing clients that may be misconfigured are brought into line.

Users should consult new release documentation in order to understand the settings related to implement new features present in the release. 

Are Nomad 7.0 clients backward compatible with previous versions?

Yes. Nomad 7.0 is backward compatible with Nomad v6.3. Older versions of Nomad are no longer supported.

Do I need to upgrade my clients at once?

It is recommended that you endeavor to upgrade clients by subnet where practical. Mobile clients moving from on-premises to Cloud DP locations should be upgraded as soon as possible.

For customers not using Cloud DPs and mobile clients, it is generally not necessary to upgrade a set of particular clients at once. 1E always makes sure Nomad clients are backward compatible in terms of being able to download and share new and existing content between clients of different versions. 

If needing to upgrade both the Configuration Manager and Nomad clients, which is done first?

Best practice is to upgrade the Configuration Manager client prior to the Nomad client. The exception is when the currently installed Nomad agent does not support the new version of CM.

Under normal operation, Nomad is designed to instantly recognize and remediate if it is not configured as the Alternate Content Provider (ACP) for the Configuration Manager client. When upgrading the Configuration Manager client or Nomad client, no additional steps are required to make sure Nomad remains configured as the ACP. The one exception is where the Nomad client installation is run on a host that does not have the Configuration Manager client installed. In this case, if installing the Configuration Manager client after installing Nomad, then you will need to perform a restart of the NomadBranch service for successful ACP registration. Therefore, as a precaution, if reinstalling both agents clients, it is recommended that the Configuration Manager client is always installed/upgraded before Nomad.

Content FAQ

This section will attempt to answer some common questions related to Nomad content during a 1E Nomad upgrade.

What happens to my existing cached content when I upgrade?

An upgrade of the Nomad client does not delete content from the Nomad cache. Similarly, an upgrade to the Configuration Manager client will not result in content being deleted from its cache. The new Cache Optimization (CO) feature introduced  in Nomad 6.3 is turned off by default. CO allows content to be automatically purged from the cache based upon the last time it was copied by a peer or downloaded – whichever came last.

Does Nomad support the use of shared DPs during a side-by-side migration?

Yes, for a shared environment, provided the content version is consistent between the old and new site/hierarchy, the content locations will be supplied to the Nomad client by the Configuration Manager client and accessed by Nomad in the usual way. This is true for native Configuration Manager deployments as well as Nomad Pre-caching when the Nomad client performs its own content request. The Nomad client installed on the shared DP will continue to function as normal.

For a side-by-side migration, can existing cache content be used in the new infrastructure?

Yes. Migrating objects in Configuration Manager is performed using migration jobs and content identifiers are maintained after migration. This means all content metadata gathered by the Nomad client in the old hierarchy will be valid in the new.

When performing a side-by-side migration, will Nomad reuse cached software updates?

Yes, the software update identifiers and metadata generated by Nomad in the source site remains valid in the new hierarchy.

When performing a side-by-side migration and executing Configuration Manager migration jobs, are Nomad settings preserved on migrated content?

For packages, no. Users must manually configure the Nomad settings on their migrated content in the new site. This can be automated by running a post migration script in order to set the required Nomad properties. Because of this, it is recommended that deployments are set to disabled in the package migration jobs.

For applications and software updates, this is not a concern since the setting to use Nomad is made in the Configuration Manager Client Settings policy, rather than against individual pieces of content.

ActiveEfficiency FAQ

This section will attempt to answer some common questions related to ActiveEfficiency when upgrading Nomad.

When upgrading ActiveEfficiency are custom configuration settings preserved?

No. Prior to upgrading, it is recommended to take note of any customizations. If you have customized settings such as IIS bindings or changed the service.exe.config file, then these will need to be reapplied after the upgrade.

Operating System Deployments FAQ

This section will attempt to answer some common questions related to OSD when upgrading Nomad.

Is there a new version of PXE Everywhere released with Nomad 7.0?

No. PXE Everywhere 4.0 is the latest version, released earlier in 2019.

Do I need to recreate my PXE boot images after the upgrade?

Unless you are upgrading the Windows ADK, you do not need to recreate your Nomad enabled PXE boot images. Admins do however need to update and deploy their boot images to include updated Nomad 7.0 program files when upgrading the Configuration Manager site server, SMS provider components, or the Nomad Branch Tools. Updating is achieved by simply redistributing the boot image package using the Configuration Manager console. The PXE boot image must then be re-deployed to your PXE Everywhere endpoint agents.

Do I need to update my OSD task sequences after the upgrade?

1E are always looking for ways to simplify and enhance our customers OSD experience and will often release new built-in task sequence steps as part of a Nomad release. 1E recommends that whenever possible, users take advantage of any new task sequence steps and update their task sequences accordingly.

If users wish to retain the configuration of their existing task sequences, then the older steps will typically remain supported unless otherwise stated in the release documentation. Where existing steps are supported into the latest release, no action is required on existing task sequences once the Nomad Branch Tools and Configuration Manager Admin Console UI extensions have been upgraded. Configuration Manager admins are then able to open and edit their existing task sequences, and they will continue to function in the same way.