Nomad 2012 Installation and Upgrades Best Practices

Nomad 2012 Installation and Upgrades Best Practices
Streamlined Systems Managment
www.1e.com
i
Version 5.0
Document revision 1
1E Ltd 2013
All rights reserved. No part of this document or of the software (the software) to which it
relates shall be reproduced, adapted, stored in a retrieval system, or transmitted by any means,
electronic, mechanical, photocopying, recording, or otherwise, without permission from 1E Ltd.
It is the responsibility of the user to use the software in accordance with this document and 1E
Ltd shall not be responsible if the user fails to do so. Although every precaution has been taken
in the preparation of this document, 1E Ltd and the authors assume no responsibility for errors
or omissions, nor shall they be liable for damages resulting from any information in it.
Trademarks
1E, the 1E device, APPCLARITY, NIGHTWATCHMAN, NOMAD, DROWSY and DROWSY SERVER
are trademarks belonging to 1E Ltd. 1E is registered in the UK, EU and the US. The 1E device
is registered in the UK, EU, Australia and the US. NIGHTWATCHMAN is registered in the EU and
the US. NOMAD BRANCH is registered in the EU and the US. DROWSY is registered in the UK.
DROWSY SERVER is registered in the US.
MICROSOFT, WINDOWS 7, WINDOWS VISTA, WINDOWS XP, CONFIGURATION MANAGER,
INTERNET EXPLORER are all trademarks of Microsoft Corporation in the United States and other
countries.
Macintosh is a trademark of Apple Inc., registered in the U.S. and other countries.
The NightWatchman Administrator's Guide

Contents ii
Contents
1. Introduction ................................................................................................... 3
2. Evaluating and updating your current estate .................................................. 4
2.1 Existing Nomad 2012 environment ........................................................................ 4

2.2 New Nomad implementation ................................................................................ 5
3. Infrastructure considerations and new feature details .................................... 6
3.1 Single Site Download .......................................................................................... 6

3.2 FanOut ............................................................................................................. 9
3.3 Hybrid vs. Full Implementation ........................................................................... 10
4. Testing ......................................................................................................... 11
5. Phased upgrade ........................................................................................... 12

6. Non-Phased upgrade .................................................................................... 13
7. Nomad registry reference ............................................................................. 14

Introduction 3
1. Introduction
Nomad 2012 version 5.0 is advancement on previous versions of the 1E technology and designed to give
organizations running Microsoft System Center Configuration Manager the ultimate system for content
control. While Nomad 2012 has helped many geographic disparate organizations manage software
distributions and migrate to new Operating Systems very effectively, 1E has now improved Nomad 2012
even further to bring the most advanced Systems Management features to market for bandwidth
management, server infrastructure and OSD automation. This has been achieved through two headline
features in this new release: Single Site Download and FanOut mode.
Single Site Download (SSD) allows large, complex organizations to effectively flatten and remove
complexity from their network infrastructure by grouping physical networks (including subnets) into
logical sites and locations.
Requiring no additional servers or management consoles, SSD works via a scriptable Application
Programing Interface (API) for the 1E ActiveEfficiency platform with which IT staff or third-party vendors
can integrate SSD features into their network services to allow their network to dynamically organize
itself. Through SSD, organizations using Microsoft ConfigMgr can optimize WAN traffic even further to
not only have systems management traffic back off to the business traffic, but at the same time ensure
that important data is distributed to remote locations with no impediments.
FanOuts new manyto-many method of P2P communication allows data transfer to happen in a fully
connected or spider web manner across the local network. With algorithmic optimization, FanOut is far
more efficient than linear topologies or daisy chain methods, which actually slow down software
deployments and OS migrations.
FanOut also enables Nomad 2012 to distribute data not only to peer systems (per the traditional P2P
functionality of Nomad), but it also allows for FanOut Peers. This Fully Connected (many to many)
topology allows multiple systems to distribute data to other multiple systems simultaneously on local
LAN segments across different geographic office locations.
1E has tested FanOut with real world customers over the past six months and found it to be at least
three times (3x) faster than before. These benefits are exhibited through clients starting deployments
faster, shorter deployment duration and the completion time for total end-to-end software deployments,
upgrades and patches significantly reduced.
This guide is designed to assist organizations get up to speed faster on the new features of Nomad 2012
and give prescriptive guidance in completing the upgrade process. By no means does this guide handle
all possible scenarios or situations and therefore 1E encourages you to contact us if you have any
additional questions for assisting you through your migration or implementation plan.

Evaluating and updating your current estate 4
2. Evaluating and updating your current estate

The first part of your v5 implementation plan should be evaluation of your current estate. There are two
main scenarios: an existing Nomad environment or new implementation. This section gives a broad plan
and best practices for upgrading the Nomad 2012 version to 5.0.
2.1 Existing Nomad 2012 environment

With an existing Nomad implementation the first step before moving forward is to take an inventory of
your current client estate. While for the most part different Nomad client versions can operate on
subnets this is not best practice or 1E recommendation. When mixing client versions in the estate there
can be troubleshooting issues, functionality confusion (for instance newer features not in older versions)
or even edge case operations that do not function as expected. The below procedure outlines safest
mechanism for rollout and is only a suggestion. From a high level the upgrade process is just upgrade
your Distribution Points first and then all of your clients second. We include the below process in order to
assist you further with guidance.
1. Take inventory of any Nomad settings on your Distribution Points that you might have
previously set and then upgrade your DPs to the version 5.0 client and ensure that settings
are configured appropriately post upgrade(i.e. SpecialNetShare, etc).
2. Take inventory of any Nomad client settings you might have previously configured and then
create a Package & Program in ConfigMgr to upgrade your clients. Run this on a handful of
test clients that had the older Nomad client, ensuring that post upgrade they are configured.
a. You could alternatively use Applications in ConfigMgr 2012 or possibly Task
Sequences for targeting.
3. Create a Collection of all Nomad clients with a version older than 5.0.
4. Limit the Collection in step #3 to a few subnets and distribute the Nomad 2012 client
Package for version 5.0 to the Collection in step #3.
5. Use ConfigMgr Reports to ensure that the distribution of the new client is taking place
successfully and without issue. You can also use the 1E Nomad Reporting Pack to show the
current distribution of Nomad 2012 client versions across your estate. Contact 1E support to
acquire the latest version of the reporting pack.
6. Keep adding subnets to the Collection limit and reviewing the distribution progress until you
have added all (or close to all) of the subnets in your infrastructure.
a. Note that this is just for controlling the distribution. Alternatively you could just
quickly deploy Nomad everywhere and not worry about slowly rolling out one
location at a time. This method is only outlined for customers whom wish to be as
safe as possible.
7. When penetration of the new version 5.0 client is appropriately high enough (for instance
higher than 90%) take the limitation off of the Collection created in step #3 so that it
contains any extra systems that havent migrated to the new client. Continue to monitor this
Collection until it is empty and all systems have migrated successfully.
Separately to Nomad 2012 client upgrade process the upgrade of Console extensions and OSD tools
from 4.1.100 to 5.0 is fully supported by 1E. For upgrading these components you have to simply run
the 5.0 MSIs and it'll upgrade automatically (i.e. you don't have to uninstall 4.1.100 and then install 5.0
for the upgrade).
Nomad 2012 settings applied on Packages, Applications, Software Updates, Boot Images, Driver
Packages and OS images are maintained on upgrade so no need to reapply these settings. The Nomad
Task Sequence actions also upgrade fine, only the 'Install and configure Nomad in WinPE' step needs to
be re-applied with Nomad 5.0 license key and the Boot Images have to be updated on DPs post-
upgrade.

Evaluating and updating your current estate 5
From a staggered production rollout perspective, it's doesn't matter if Console extensions and OSD tools
are left in the end or upgraded first, since it'll work fine both ways between 4.1.100 and 5.0. The only
difference between 4.1.100 and 5.0 Nomad TS actions is that the 'Install and configure Nomad in WinPE'
step requires 5.0 license key and it has the new Single Site Download options, which matters only if the
you are planning to use Single Site Download feature in WinPE.
At this point in the implementation you will have upgraded your environment to the latest version of
Nomad. However you have not taken advantage of the new features yet namely FanOut and Single
Site Download. These are discussed later in this document around implementation. FanOut could have
actually been introduced as part of the upgrade process above by setting the appropriate value in
SpecialNetShare on the Nomad client agents. Single Site Download we recommend you implement as a
separate process due to the extra infrastructure component required.
Note that while this document primarily addresses the supported upgrade path of 4.1 to 5.0 of Nomad
2012, prior versions (such as 3.2) have been tested by 1E and recommendations for upgrade to 5.0 are
similar.
2.2 New Nomad implementation

The exact details of a Nomad 2012 implementation can vary from organization to organization. Nomad
has been around for a long time and as such is a very mature product and has many features. Will you
be using HTTP or SMB? Will you be disabling File & Print Sharing? Will you be implementing Nomad 2012
with Internet Based Client Management? Are you going to be performing Operating System migrations
with ConfigMgr using the Nomad advanced Task Sequence actions, Peer Backup Assistant or PXE
Everywhere functionality? All of these are valid questions to ask in the planning stages.
This guide is aimed at version 5 specifics of Nomad 2012 and as such the details of a full implementation
are out of scope. However there is a basic process that most engagements follow and 1E recommends
as best practice.
1. Decide which features are necessary for your success to identify the appropriate server side
and client side settings for Nomad operations (i.e. Connectionless functionality, etc).
2. Install the Nomad client on the DPs you wish to use (remember you will after the fact
remove many servers from your organization) and configure the appropriate settings
defined in Step 1. Settings can also be implemented at installation time via MSI command
line parameters.
3. Define a Nomad 2012 client Package and Program in ConfigMgr. The Program should call the
Nomad 2012 client MSI with appropriate client settings defined in Step 1.
4. Enable Nomad 2012 for Legacy Packages, Software Updates and Applications in the
ConfigMgr Administrator console. 1E offers utilities to do this automatically and free of
charge. Contact 1E support for more information.
5. Install and configure the 1E Reporting Pack. You can get this through 1E support.
6. Test some software distributions in ConfigMgr and validate the information in the reports.
Steps 1-6 above define the basics of Nomad 2012 operations for Software Distribution. If you are
implementing OSD with Nomad 2012, 1E recommends you first start with a working process and Task
Sequence which can build a system. With a working process you can then add the Nomad 2012 Task
Sequence extensions to ConfigMgr and take advantage of the OSD functionality. This is all fully
documented within the Nomad 2012 online documentation. For further information please contact 1E
support.

Infrastructure considerations and new feature details 6
3. Infrastructure considerations and new feature details

3.1 Single Site Download
To make Nomad even more efficient the latest version implements a Single Site Download (SSD) feature
that ensures that a download across the WAN only happens once per site. To do this it maintains
information about which subnets are neighbors of each other (i.e. accessible via LAN rather than WAN),
so that when an elected Nomad master is contemplating downloading from a DP, rather than a peer in
its subnet, it can find out which other local subnets, if any, already have the package. The subnets are
typically at a single customer site, i.e. a single geographical location.
The information about which subnets are in which sites is stored and maintained in ActiveEfficiency and
when a Nomad machine downloads a package it also registers this information with ActiveEfficiency. In
this way ActiveEfficiency builds a dynamic map of which Nomad machines on which subnets hold
particular packages. Then, when a Nomad machine requires a particular package it uses the following
approach: it first tries to find a copy on the local subnet; if no local copy is found it then tries the
ActiveEfficiency database to see if any Nomad machines on other subnets at the same site hold a copy;
only when all other avenues have failed will Nomad resort to downloading the package from the DP over
the WAN. This architecture is visualized below.
Before SSD can be used, an ActiveEfficiency instance must be populated with information about the
subnets in each site. Nomad needs to know, for a given subnet in which it finds itself, which neighboring
subnets on the LAN it can potentially fetch packages from in preference to downloading the information
again over the WAN from the DP. This information is typically (but not necessarily) gathered from AD
and an example PowerShell script is supplied. The script uses an ActiveEfficiency API that has been
designed for SSD to enter information about the subnets and locations. Customers or 1E Partners are
free to customize this to pull information from other sources and populate ActiveEfficiency as long as
they are using the supported API for entry.
The script can be run manually and/or configured to run periodically as a scheduled task on the
ActiveEfficiency server. Once this location information has been entered the Nomad 2012 clients can
then to begin to consume this and leverage peer subnets for content distribution. The Nomad 2012
clients need two things to be configured in the registry to take advantage of SSD:
SSDEnabled: Defines what mode that SSD can run in

PlatformURL: The ActiveEfficiency web service location to update and receive SSD requests
See the last section of this document or the online Nomad 2012 help for registry key locations.
The PlatformURL will be something along the lines of http://AEserver/ActiveEfficiency with no variation.

SSD has a few different integer options:
0: Off
1: Consume data from peer subnets
2: Provide data to peer subnets
3: Consume & Provide
Note that in OSD scenarios when you utilize the Install and Configure Nomad in WinPE Task
Sequence action by default SSD will be configured to Consume but not Provide
(SSDEnabled=1) as you wouldnt want a system in WinPE to be providing content to peer
subnets. 1E also recommends setting this when setting Sensitive server weighting (registry
key P2PElectionWeight=0).
If you are planning on implementing SSD you should consider how you plan on performing software
distributions and if a system separate to your ConfigMgr server for ActiveEfficiency is necessary for your
organization. For the very largest organizations this may or may not make sense while for smaller or
medium sized organizations this wouldnt be as necessary. Note that by ConfigMgr server we are
generalizing as ActiveEfficiency could run on a member server such as a Distribution Point or
Management Point and not necessarily a ConfigMgr site server. 1E has done significant performance
benchmarking, testing and analysis with this in mind and provided the following recommendations for
implementing ActiveEfficiency with Nomad 2012.
Config.A and B Config.C Config.D
Total number of machines 50000 100000 300000
Registration requests
number of machines to register in one go 5000 5000 5000
Time period over which requests are made 60 min 60 min 60 min
Safety factor for fluctuations 2 2 2
Registrations requests rate to be matched 3 Req/s 3 Req/s 3 Req/s
Content download requests
Number of updates in one go 50000 100000 300000
Time period over which requests are made 60 min 60 min 60 min
Download requests rate to be matched 28 Req/s 56 Req/s 167 Req/s
Content requests
number of primary machines 7000 15000 20000
Time period over which content is requested and

60 min 60 min 60 min
marked
Content requests rate to be matched 4 Req/s 8 Req/s 11 Req/s
TOTAL REQUESTS RATE TO BE MATCHED 34 Req/s 67 Req/s 181 Req/s

Below is the 1E recommended configuration for a split installation (SQL and ActiveEfficiency web service
separate) which is common practice for many organizations. These are only recommendations and by no
means what an organization must do. For further discussions please contact 1E Support.
Config. 1s Config. 2s Config.3s Config.4s
Active Efficiency database
CPU Cores 2(1) 2(1) 2(1) 2(1)
RAM 4 GB 8 GB 8 GB 16 GB
AE db MDF 2 GB 2 GB 4 GB 4 GB
AE db LDF 1 GB 2 GB 4 GB 4 GB
Active Efficiency web site
CPU Cores 2(1) 4(1) 8(1) 8(2)
RAM 4 GB 4 GB 8 GB 8 GB
Deployment limitations
Maximum number of machines 50k 100k 200k 300k
Average downloads per machine per year 100 100 100 100
Maximum number of downloads in an hour 50k 100k 200k 300k
The assumptions made in the above analysis are as follows:

Split deployment AE service and AE database on different servers.
(1)
CPU assumed for Gainstown CPU: IntelXeon E5506 @ 2.13 GHz
(2)
CPU assumed for Westemere-EP CPU: IntelXeon E5620 @ 2.4 GHz
AE database LDF, MDF files and TempDb on separate disk drives.

For small or medium organizations many may wish to run the ActiveEfficiency database and service
combined on a single server. The recommended configuration for this setup is below.
Config. 1c
Active Efficiency combined install
CPU Cores 2(1)
RAM 4 GB
AE db MDF 2 GB
AE db LDF 1 GB
Deployment limitations
Maximum number of machines 50k
Average downloads per machine per year 100
Maximum number of downloads in an hour 50k
Assumptions:
Combined deployment AE service and AE database on different servers
(1)
CPU assumed for Gainstown CPU: IntelXeon E5506 @ 2.13 GHz
AE database LDF, MDF files and TempDb on separate disk drives
3.2 FanOut
The following terms should be used when discussing FanOut:
Nomad Master: The machine that wins the Nomad election on the subnet and is the central
resource for the download
FanOut Peer: A machine connected to the Nomad Master share that responds to FanOut
requests and allows other machines to connect to it
Nomad Peer: A machine that requires the download
Nomad FanOut is a mechanism that recompenses for the Windows imposed limit on the number of
simultaneous connections to peer systems so that more Nomad Peers can be updated at the same
time. It does this by enabling Nomad Peers connected to the Nomad Master to themselves allow
connections to other peers requiring the download. Using Nomad FanOut when a Nomad Peer is blocked
from connecting to the Nomad Master, rather than just waiting for the next available connection to the
master, it will try to get content from another connected Nomad Peer that has more of the download.
If a Nomad Peer gets a Maximum connections limit when trying to connect to a Master, the Nomad
Peer broadcasts a request who has more than a certain percentage of a piece of content". Depending
on a set of conditions then a FanOut Peer can respond to this request with the content. In this way, with
the default settings, 42 machines (6 FanOut Peer machines connected to the Nomad Master and 6
Nomad Peers connected to each one of those) can be accessing the download from the Nomad Master.
Of course this can also scale to a larger amount of systems if necessary in a dynamic manner.
FanOut is configured via a registry setting on Nomad 2012 client systems. You must add or modify the
SpecialNetShare value and set bit 6 (0x40).
See the last section of this document or the online Nomad 2012 help for registry key locations.
Note that FanOut and Multicast are mutually exclusive within Nomad 2012. Enabling Multicast
will disable the FanOut functionality on a per-content basis. FanOut also is not currently
supported in WinPE or Standalone Mode.
As you can see enabling FanOut is very simple. A small amount of extra broadcast traffic on a LAN for
peers to communicate content messages is expected but from 1E testing with customers is negligible

however you should be aware of it. The 1E best practice recommendation for rolling out FanOut in an
organization would be to first try it for a group of systems in a subnet and have your network team
monitor the activity on that LAN. If they have no objections after the test has completed try it on a few
more subnets at different locations and monitor the activity. If there are still no issues at that time you
should move forward with enabling this feature at any location you prefer to do so. The easiest method
for enabling this is via DCM or a ConfigMgr Package & Program. A simplified diagram of FanOut
communications is below.
3.3 Hybrid vs. Full Implementation

Notice that the configuration of SSD and FanOut are completely independent to one another. This is
because architecturally the FanOut functionality applies to peer systems while SSD applies to subnet
masters during an election. As such there is nothing wrong with using a hybrid implementation where
FanOut is used at some locations and SSD is used at some locations. You can also use both features at
different locations or neither one. All of these are possibilities and fully supported by 1E. Nomad 2012 is
designed to give organizations many options to optimize their ConfigMgr infrastructure and the flexibility
in the product to do this as easy as possible.

Testing 11
4. Testing
As with any new feature and functionality 1E recommends a testing phase before implementation. For
example you can install ActiveEfficiency in your organization, import location data and simply enable
SSD for one location to validate that the feature is working without issue. Following this you could then
enable it for separate locations as necessary. The same prudence should be used when enabling the
FanOut feature for your systems.

Phased upgrade 12
5. Phased upgrade
The Phased upgrade approach is what 1E recommends as a best practice. This is the safest method for
any environment to upgrade their Nomad 2012 infrastructure to the latest version and take advantage
of new features at the right time without any risks. This process can be diagrammed as follows:
Server and client settings

Environment OSD baseline
Evaluation
Server upgrade & validation

Client upgrade & validation
Upgrade Task Sequence Engineering and OSD update
FanOut configuration
New Feature Single Site Download implementation
Implementation
In the Environment Evaluation piece you first take inventory of any previous client or server settings and
validate they will be used in version 5.0 of Nomad 2012 or if you might need some changes. This is also
an appropriate time to take an OSD baseline of your organization to ensure that you have some basic
functionality. For instance do you have a basic Task Sequence that can build an operating system? Are
you using MDT for this or is everything done from scratch? Having some basic OSD operations
independent from Nomad functioning is a good starting point.
The upgrade process is next in which you should always upgrade your DPs to version 5.0 first and
ensure that the appropriate settings have persisted through the upgrade process. Once all the DPs are
updated clients can be upgraded using a standard ConfigMgr Package & Program with the appropriate
settings. 1E recommends that you upgrade subnet by subnet as best practice and not to run multiple
version of Nomad 2012 on the same subnet. During this upgrade process you can also address your
OSD process by using the Nomad 2012 Task Sequence actions, Peer Backup Assistant and PXE
Everywhere client. For detailed information on using these pieces of functionality please see the Nomad
2012 documentation or online training videos.
Now that the environment has been level set with the latest version of the Nomad 2012 software you
can implement the new features. Depending on your needs you can use FanOut at some locations, SSD
at some locations or both. 1E supports the hybrid configuration where necessary. What is recommended
as best practice is to turn one feature on for a location and then another but not both at the same time.
If there was an issue due to environment or otherwise it is always easier to pinpoint the problem if only
one thing has been enabled. Generally speaking the FanOut functionality is easier to enable and 1E best
practice is to implement this before SSD if possible.

Non-Phased upgrade 13
6. Non-Phased upgrade
If you have read through the rest of this document up to this point you may have noticed that the
settings for the new features of version 5 FanOut and SSD are client settings with a backend
infrastructure component. This in many ways is no different from the ConfigMgr architecture where a
client agent has certain settings configured which allow it to take advantage of different features. This of
course means that features can be enabled at installation time rather than the phased rollout described
above.
Turning on all features at installation or upgrade time is the prerogative of you as a customer and 1E
supports this fully with best practice at this time being the previously discussed phased approach. An
implementation or upgrade plan which encompasses enabling FanOut and SSD would from a very high
level look like the one below:
1. Upgrade all DPs to version 5.0 of the Nomad 2012 client.

2. Install Active Efficiency on the server earmarked for SSD organization. Depending on the size
of your organization this may be your ConfigMgr server.
3. Test that client systems can reach the Active Efficiency URL for registration via a web
browser.
4. Configure the import script to run regularly and ensure that it has run at least once.
5. In your v5 upgrade Program within ConfigMgr ensure that you have the appropriate settings
for FanOut and SSD configured.
a. FanOut Set bit 6 (0x40) on the SpecialNetShare registry key for Nomad.
b. SSD Set the SSDEnabled and PlatformURL flags in the registry.
6. Create a Deployment within ConfigMgr that sends data to a location with multiple subnets
defined to be a location as part of your import script in #4 above. Verify that just one system
pulled content across the WAN. You can use the Deployment Report in the 1E Reporting
Pack to validate this.
As an example Program command line the below would work for a 32-bit Nomad client not performing
OSD:
msiexec /i NomadBranch.msi /qn /li C:\Temp\install.log SpecialNetShare=64
SSDEnabled=3 PlatformURL=http://AEserver/ActiveEfficiency
The SpecialNetShare value for FanOut (64d = 0x40) might need to be combined with other flags. Please
see the Nomad 2012 documentation for more information on this. SSDEnabled should usually be 1 for
OSD as this indicates it can consume data from peers yet not host.
Note that if SSD is enabled on install and that Nomad 2012 discovers packages in its cache when it
starts up, the packages automatically get registered with ActiveEfficiency. Therefore you should stagger
the rollout of Nomad 2012 if enabling SSD as part of the install so that you do not overwhelm the
ActiveEfficiency server during deployment. However, the cache is not registered if SSD is turned on after
install and therefore you could deploy Nomad in this case in a non-staggered manner. If you wish to
register the Nomad cache after installation you can create a ConfigMgr Package that runs the command
line nomadbranch.exe activateall.

Nomad registry reference 14
7. Nomad registry reference

In ConfigMgr 2007 machines the registry values are located in:
32-bit systems 64-bit systems

HKLM\Software\1E\NomadBranch HKLM\Software\Wow6432Node\1E\NomadBranch
In ConfigMgr 2012 machines the registry values are located in:

HKLM\Software\1E\NomadBranch

Nomad 2012 Installation and Upgrades Best Practices

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nomad 2012 Installation and Upgrades Best Practices

Uploaded by

Copyright:

Available Formats

Nomad 2012 Installation and Upgrades Best Practices

Streamlined Systems Managment