1. Will Nomad eliminate all my distribution points?
One of Nomad’s main premises is to enhance Microsoft System Center Configuration Manager (SCCM) and it does this by leveraging the native infrastructure components for the most efficient and optimal design to meet an organization’s requirements. Nomad is not designed to simply eliminate all Distribution Points from a SCCM design but to enable a more efficient design. Having said this, our customers (ranging from 1000 to 450,000 clients) see significant infrastructure reduction in their designs of SCCM with Nomad.
Typically a Nomad integrated design sees a reduction of at least 95% of the servers required within a SCCM, infrastructure as compared with a native-only design. It can be a reduction or elimination at all levels – Primary, Secondary and Distribution Point servers as well as the complete removal of the server requirement for PXE Service Points and State Migration Points in order to additionally support a robust and efficient zero-touch operating system deployment strategy. By eliminating all unnecessary servers, an organization with a hundred site locations for example, can centralize and consolidate the Distribution Points to two or three DPs in their central data center. (A minimum of two is advised as this provides redundancy if one of the DPs requires rebooting due to security updates etc.)
Another design consideration of Nomad is to simplify site boundaries and boundary group management. When following the recommendations to aggressively eliminate distribution points – down to only a few co-located at a core datacenter location – creating boundaries and boundary groups for locating content is no longer required. The Nomad Add-on installed on all SCCM clients provides the end-point intelligence needed to protect the WAN when downloading from the DPs at the core datacenter. Nomad’s Single Site Download (SSD) feature further simplifies content distribution because there will only ever be one SCCM/Nomad client downloading from the central DPs, per package, per site/location.
During content distributions, the SCCM client factors in the boundary (or boundary-less) situation when sending a Content Location Request to a Management Point, when determining which DP to download content from. After the SCCM client gets a list of DPs to download from, it (Content Transfer Manager) then passes on the list of DPs to Nomad. So the boundary situation and its impact to locating DPs has already been evaluated by the time Nomad is invoked. This is why Nomad does not require boundaries to be configured – SCCM client has already selected the relevant DPs to download content from.
Nomad has developed over the past 10 years in close partnership with Microsoft and is designed to enhance, rather than replace, the core functionality of SCCM. Organizations are able to build on the well-known and fully supported component services of SCCM as well as the Microsoft technologies on which it is built. As well as ensuring full professional support from Microsoft and 1E there is the availability of a large and highly specialized community-based support network.
2. Can Nomad prevent WAN congestion?
One of the main design principles of Nomad is to always ensure that SCCM bandwidth utilization never impacts that of business traffic. Nomad is a “gentlemen” on the network, conceding to other traffic as more important than itself.
Nomad uses a deterministic statistical algorithm, we call Reverse QoS, to continually analyze the available bandwidth across any end-to-end network route required for downloading content. The Reverse QoS algorithm analyzes the throughput as each block of a file or package is downloaded by Nomad and as this is a continuous process it is able to rapidly adjust its own throughput accordingly to account for any changes in network utilization (by other non-SCCM traffic). It calculates network speed and congestion, irrespective of the network infrastructure configuration or number of hops. (note: Nomad detects congestion that can occur anywhere as there are multiple hops between the client and server.)
As this analysis is continuous throughout the entire download process, Nomad is able to identify any increase in network traffic on the network and rapidly reduce its throughput accordingly to compensate for this and ensure that it does not use the network when other systems require it. Conversely, if the algorithm identifies that more bandwidth becomes available as other systems usage reduces then Nomad is able to increase its own throughput to make use of this spare network capacity and thus accelerate the download process.
Nomad is proven across its many customers to account, and automatically adjust, for all types of networks as may be require; from well-connected LANs to extremely low-bandwidth WAN connections and even low-bandwidth, high-latency satellite links.
3. Can Nomad perform byte level-differencing?
Nomad leverages Microsoft Remote Differential Compression on SCCM distribution points to create what we call Nomad RDC. Nomad RDC uses the RDC APIs to create binary-level differences of files between package versions. Binary deltas have a far greater efficiency over that of byte-level differencing because the RDC algorithm is based on fingerprinting blocks on each file. Since many types of file changes can cause the contents within a file to move location (e.g.: a small insertion or deletion at the beginning of a file can cause the rest of the file to become misaligned to the original content) the blocks used for comparison are not based on static arbitrary file addresses but on addresses defined by the contents of each file segment. This means that if a part of a file changes in length or blocks of the contents get moved to other parts of the file, the block boundaries for the parts that have not changed remain fixed related to the contents, and thus the series of fingerprints for those blocks don’t change either, they just change position.
The Nomad RDC on Distribution Points determines the binary-level differences and synchronizes the changes with Nomad on the SCCM clients – and not the entire content package. Nomad RDC on the Distribution Point handles binary differences of the files in the content, therefore removing the dependency of the Microsoft Remote Differential Compression service on the SCCM client computers. There are no component requirements on the client end-points, other than the Nomad Add-on itself being installed.
4. Does Nomad perform Peer-to-Peer distribution?
Yes. Nomad uses a master-to-peer methodology to maximize throughput and speed of sharing content from the downloading (or cached) master to other requesting peer clients whilst also being highly resilient to any client power or network state changes and avoiding any single points of failure in the process.
A Nomad master is elected to this role based on a number of criteria such as chassis type, uptime, resources and OS to ensure it is the best possible candidate for the role. As it is downloading, it is simultaneously sharing this content with up to six peers at any one time. After a peer has transferred an amount of data from the master it will disconnect to allow any additional peers to connect to it and continue this process.
As the Nomad master will have the slowest WAN network connection to transfer data, it is this client that is the slowest common denominator in terms of potential throughput in this process. As a consequence, with peers connecting on a faster LAN connection, the method of connect/transfer/back- off/re-connect of the requesting peer clients has the result that all clients will obtain the complete package being downloaded at almost the same time as the Nomad master. Nomad’s base standard peer-to peer capability has been proven when delivering content to as many as 254 simultaneous clients in a Class-C subnet.
With Nomad v5.0, we created the Fan-Out feature to provide even greater speed and performance in delivering content to many clients simultaneously. This new feature was primarily designed to deliver rapid transfer performance in subnets with greater client numbers than a Class-C subnet, such as a super-net, and also when the download master is well connected to a distribution point, such as on a LAN or over a superfast WAN connection. This feature is however equally relevant to a normal Class-C subnet over a limited WAN as it simply improves Nomad’s original performance metrics.
Fan-Out achieves this increase in peer-to-peer performance by providing extra layers of Fan-Out peer masters that directly feed from the main Nomad master and can each in turn serve content to a number of peer systems in the same peer-to-peer method as the base method described above.
5. Will Nomad manage the SCCM client cache?
Nomad uses its own dynamic cache for storing downloaded SCCM content while using Windows NTFS hard-links to mirror the existence of this cached content in the SCCM Client cache folder as a requirement of the SCCM client itself to execute from. Hard-linking is a Microsoft designed and supported technology included as part of the underlying Windows NTFS file system that allows for content to appear in two folder locations within the NTFS file structure whilst only existing as a single instance on the physical disk.
To remove aged package content from the Nomad cache in efforts of freeing cache space to accommodate new content, Nomad invokes an automatic cache cleaning operation. This operation goes through an intelligent devolution process to make sure the best and most efficient decisions are being made before downloading the requested package content and deleting others that have already been downloaded. A cache priority setting for each package can additionally be set by SCCM administrators within the Nomad properties tab of a SCCM package directly within the SCCM console. As space may be required within the Nomad cache for new packages being deployed, or to adjust the maximum cache size, Nomad automatically manages this cache content by prioritizing the removal of package content according to the cache priority settings of the previously deployed and installed packages contained. This automatic management of content within the Nomad cache ensures the most relevant packages are retained while only redundant content is removed to make space for the newly deployed packages as and when this is required.
6. Can Nomad support PXE in branch offices?
Nomad includes SCCM-compatible PXE technology on all computers wherever they are located, head office or remote locations, this is known as PXE Everywhere. This feature allows dynamic elections to take place at local sites, and peer systems to determine the best system to host the PXE process and respond to PXE requests.
SCCM is used to populate the necessary boot image(s) on SCCM client computers. This process is straightforward and requires no configuration. For example, if a computer performs a network boot (i.e.: pressing F12), then the PXE Everywhere master first checks with SCCM to determine what should be provided back to the PXE booting computer. SCCM variables (such as the boot image and Task Sequence IDs) are used to automatically determine which boot image should be used by the client requesting the PXE services.
PXE Everywhere is well-integrated with SCCM and includes a web service which fosters this relationship. The PXE Everywhere web service adds a layer of security to the PXE boot process, seamlessly integrating with SCCM security:
Accepts credentials from PXE client – accepts a PXE client’s MAC address and SMBIOS GUID that are later forwarded to the SCCM site for authentication.
Determines if PXE client is authorized by SCCM – queries SCCM, asking if there is an approved OS deployment assigned to the PXE booting computer.
PXE Everywhere has always been an integral part of the Nomad solution offering and license, making it a key component of any effective automated zero-touch operating system deployment capability. PXE Everywhere was the first enterprise-ready PXE service running on workstation class operating systems in the market and continues to build on its pedigree in enterprise systems management with its recent enhancement of the patent-pending Dynamic PXE capability.
Additionally, Nomad was the first peer-to-peer software solution with full capabilities available within the Windows PE environment, and allows Nomad to locate and obtain content locally through its peer-to-peer capabilities all package content required from WIM (OS) image files, driver packages, software updates and applications for a fully automated end-to-end operating system deployment process.
All of these capabilities can be directly injected into the native Task Sequence build process logic with Nomad-specific Task Sequence actions for all operations available within the native SCCM console.
7. Can Nomad give me visibility into downloads?
The Nomad report pack is a fully supported suite of reports that can be installed directly into the SQL Reporting Service interface of the native SCCM reporting site. These have been designed to not only assist with the operational management of Nomad in Software and OS deployment operations but also to enable the organization to demonstrate the savings and efficiencies being delivered by the Nomad solution and substantiate the investment made in the integrated SCCM and Nomad architecture.
8. What kind of SCCM data can Nomad manage?
Nomad is designed to deliver all types of SCCM content – applications, packages, software updates, drivers, boot images and WIMs – to client systems from a centralized native SCCM Distribution Point infrastructure. This is a key area in native SCCM infrastructure that is only scalable in a distributed environment if Distribution Point servers are placed within locations with poor WAN connectivity in order to preserve the effectiveness of this WAN network.
Other key SCCM infrastructure components can be centralized in their native form as the operations of a Management Point have been designed in a highly scalable manner with high compression to support large numbers of clients throughout a distributed environment for all of its services such as Policy Management, Inventory collection and status message gathering.
Furthermore, during an OS deployment Nomad provides a location on peer machines to temporarily host captured user data, so that the data can dynamically and safely be restored to the computer later in the deployment process. The OS deployment process can easily be modified to dynamically determine when USMT should use hard links or Nomad Peer Backup Assistant.
9. Does Nomad use bits or BranchCache?
Short Answer: No – Nomad does not use BITS or BranchCache, period. 1E have invented an intelligent bandwidth throttling technology (not rate-limited like BITS), and many-to-many sharing (like peer-to-peer but with the scalability required in large organizations).
Long Answer: The early Nomad pre-dates BITS (and obviously BranchCache too). Organizations that used SMS (pre-SCCM) needed to transfer content to remote computers or Distribution Points around the world, but due to poor WAN links, the package distribution process kept failing. 1E created “SMSNomad” to help SMS Clients download content from centralized Distribution Points (usually in the HQ or Datacenter). This was the first SMS add-on to query the network connection between the client computer and the remote DP, including all the switches and routers between the two points. From the early days Nomad’s intelligent bandwidth throttling technology exceeded all our expectations – our customers could even transfer 5GB OS images to remote locations – and all without any changes whatsoever to the existing infrastructure!
10. Can Nomad support App-V environments with streaming from a DP?
Nomad fully supports streaming and download & execute modes for all App-V applications when integrated with SCCM. Nomad adds additional network efficiency by only downloading the shortcut icons and advertisement information, therefore saving time and bandwidth. Nomad further optimizes the download of App-V content by enabling normal Nomad behaviour to obtain App-V content from peer computers, rather than being forced to obtain the content from a centralized App-V streaming server or Distribution Point.
11. Can I cancel any transfer to site should I want to stop the distribution of content?
Nomad is deeply integrated with SCCM and if you instruct your SCCM clients to install an application then that is exactly what SCCM will do – with or without Nomad. Remember, Nomad is the content provider and will do what it is told to do by SCCM. There are mechanisms to tell SCCM clients to pause or stop distribution of content. As always during any production deployment ensure the content you have instructed SCCM to transfer has been tested and validated, and tested again to prevent the desire to cancel or stop deployments mid-way through deployment and/or installation.
12. What agents need to be installed on the client – and how much in terms of resources are taken up?
Nomad is an add-on to SCCM and executes as a service on the SCCM clients. 1E has ensured that Nomad is extremely lightweight by being programmed in the Microsoft C language. Nomad requires no third-party dependencies such as Java or Visual C++ runtimes, no filter drivers and no kernel-mode drivers. At idle Nomad uses approximate 5MB of memory and up to 15MB during heavy load. Nomad never impacts the user, the computer, the network or the business.
13. How is space calculated on the client – how much space can I expect a 500GB SCCM software repository to take up on client machines on site?
Nomad ensures it will never impact the user or computer, and therefore always ensures that at least 10% of the total disk space is always available for the user and system. This is a feature we’ve included in Nomad because SCCM can completely fill up all available disk space and prevent the computer from operating correctly.
SCCM clients (with Nomad) will only obtain content that is actually required by them (to be installed), and this means you won’t need to have your entire SCCM software repository located at all site locations – only the content those clients actually need will be obtained.