Response to the “1E Nomad questions you should ask” article

The team I work with at Infront have been working with Nomad 2012 from 1E recently, and the peers I’ve talked to appreciate it’s value, particularly in widely distributed environments. However, in my recent research and testing, this blog post came to my attention which poses 10 questions you should ask when comparing 1E’s Nomad 2012 with a competing product called Adaptiva OneSite:

In reviewing the answers, at first glance I saw a few comparisons I felt to be incomplete explanations and in some cases, inaccurate based on what I had learned in my own research. I felt compelled to reach out to 1E directly to ask some questions of my own and I am glad I did. Below, you’ll find some rebuttals to the information provided in the above article I hope will spark your interest to conduct your own research when evaluating partner solutions for Configuration Manager 2007 / 2012.


Before we get started, I want to make a few things perfectly clear:

  • I am not a paid blogger for 1E and 1E did not pay me to say anything contained in this post
  • The contents of this article are in no way intended to disrespect or marginalize the fine people and products of Adaptiva software, a well-respected System Center ISV partner. I’ll have nothing negative to say of their solutions in this post.
  • 1E is not a sponsor of System Center Central, I do not get paid when my company sells 1E software and if 1E were a sponsor of this site, I would receive no financial compensation, as we use our proceeds for solely for community purposes. I have no financial motivation whatsoever in this endeavor.
  • Their is no disrespect intended toward Anoop Nair (the author of the article I’ve taken issue with), who is a dedicated contributor to the System Center community at large. However, disagreement, discussion and debate amongst fellow community members are healthy aspects of community. This is something I’ve learned firsthand through my approximately 7 years as a System Center MVP and interacting with the more than 10 MVPs I work with at Infront Consulting Group.
  • My primary purposes here are education and a return to respectful dialogue. If this article succeeds in hitting the ‘reset’ button on this discussion by providing accurate technical information on 1E Nomad, then it has served its purpose.

<climbing onto my soapbox>

Finally, I want to say that a critical, one-sided comparison via a blog post is not something I make a habit of, nor do we at Infront encourage our team to publish online. I personally believe in respectful and constructive community dialogue, especially when it involves critique of someone else’s hard work. How would you feel if someone maligned your masterpiece?

The problem with such posts in the technology industry is that they are either 1) biased  or 2) inaccurate (at least in part), or many times, a mixture of both. I provide the facts as I understand them in this blog post , but suggest if you’re going to look at 1E or Adaptiva products you contact the vendors directly and get the facts, then make your own comparisons. It ensures fairness to the ISV partners competing for your organizations business in allowing them to tell their own stories, and at the same time, benefits your company through the acquisition of knowledge in the evaluation process. In the end, this ensures the best solution for your organization is selected.

<climbing down from my soapbox>

Now, let’s get down to business…

Below, I have called out excerpts from the post in question and supplied clarifying remarks for each.

Excerpt from blog post:

Q1: Will it eliminate all my Distribution Points?

OneSite – Yes, eliminates all DPs

Nomad – No, DPs are still required

OneSite doesn’t use DPs at all. OneSite server acquires packages directly from the Site server, and serves out the first copy directly to the first client. All subsequent downloads are from one client to another.

Nomad elects one client as the Master client for each subnet, which must have a DP available from which it copies packages. According to Mark Cochrane of vNext, “Our original architecture relied on 700 servers, with Nomad we have dropped that to 300?.

The facts:

While Nomad will require at least 1 DP in the environment, that role could be added to the site server so that no additional servers are required. This is actually an SCCM requirement, not a Nomad requirement. SCCM needs the DP role to be assigned in order for site content distribution and legacy package / application deployments to take place. Having multiple DPs (at least a few) in an environment it mitigates the risk of a single point of failure. There are many reasons to still have a handful of servers such as the just described fault tolerance or internet facing client scenarios. Would you poke a hole in your firewall (creating a potential security risk) for a minimal reduction in server count? Also, how well does a single content server scale for organizations with many hundreds or thousands of locations? Nomad does reduce server count and without creating a single point of failure.

Excerpt from blog post:

Q2: Can it prevent WAN congestion?

OneSite – Yes, monitors routers to prevent congestion

Nomad – No, uses a ping method that reacts to congestion after it has occurred

OneSite works by measuring the length of data queues on the routers and sends a chunk of data only when the queue is nearly empty. This prevents network congestion even before it happens.

According to 1E, Nomad clients ping the DP after every 4 seconds and slow down their copying if the responses get delayed. Usually pings get across the WAN very easily. If pings are getting delayed, it is a strong sign that network congestion has already happened.

The facts:

This description of how Nomad performs its throttling is incorrect. Nomad doesn’t use pings, instead it is optimized to never let systems management network traffic compete with business applications by using a Reverse QoS technology allowing business traffic to take precedence. 1E has talked about this and even has a blog post on the subject titled, appropriately enough “How does Nomad Enterprise determine network bandwidth and protect your network? Ping? Nope. Try Reverse QoS TM instead”. (in fairness to Anoop, this was published some months after his article, though anyone can learn this as I did…through a query to 1E requesting clarification). Nomad looks at each block of data in a packet to evaluate the entire end-to-end bandwidth. Nomad will automatically throttle up or down in immediate response to the needs of business traffic. Nomad also doesn’t impose an unnecessary requirement on your router hardware.

Excerpt from blog post:

Q3: Will it compress data sent over the WAN

OneSite – Yes, compresses packages before sending over the WAN

Nomad – No, copies full packages

The OneSite server compresses each package while acquiring it, and publishes a highly compressed copy of it. This compressed copy is then sent across the WAN.

In my testing, I created an AutoCAD package with all prerequisites, with a total size 3 GB. OneSite compressed it down to 2 GB before sending over the WAN, and then re-expanded it into the client cache.

Nomad Master clients copy full expanded packages directly from the DP, so there is no compression.

The facts:

Package content is often already compressed. Whether the installation source is in MSI format, cab files, or files contained within a setup.exe. In my view, recompressing already compressed content produces very minimal gains as far as size reduction – typically in the single digit percentages. Today’s packaging and sequencing tools do a very good job at this. The process of compression increases the amount of time before package content is available and produces an unnecessary resource strain on the server performing the compression as the process is very CPU intensive. However, Nomad does support the use of the Remote Differential Compression feature of ConfigMgr to ensure that only necessary bit level deltas of data traverse the WAN. Additionally, Single Instance Storage (SIS) in ConfigMgr 2012 negates the need of compressing data even further.

Excerpt from blog post:

Q4: Can it do byte level differencing?

OneSite – Yes, automatically performs byte level differencing

Nomad – No, there is no byte level differencing

Byte level differencing is especially useful for images. In my testing, when I added some files to an image, OneSite automatically sent out only a small diff file instead of sending the whole image.

Nomad has to resend the whole image after any changes have been made.

The facts:

This data is also incorrect. Nomad does support byte level differencing and does this using the Microsoft Remote Differential Compression (RDC) technology, which has been shown to be quite effective, safe and secure.

Excerpt from blog post:

Q5: Is it really Peer to Peer?

OneSite – Yes, one client sends to only one other client

Nomad – No, master client behaves like a BDP

OneSite clients arrange themselves in a daisy chain and each client sends the package to the next and so on. Each client actually sends the package to only one other client. It behaves like a true Peer to Peer system.

In case of Nomad, one of the clients on each subnet gets elected as the Master, all other clients connect to it and start copying files over SMB. This is very similar to how a BDP actually works.

The facts:

Nomad actually has several modes of operation – peer to peer, local multicast, central multicast, connectionless and also FanOut mode. The peer to peer mode is definitely peer to peer and in effect Nomad is an improvement on traditional peer to peer. Nomad on the other hand uses a “star topology” so that systems simultaneously can pull blocks of data from a master much faster. 1E controls the priorities and rates at which this happens so that no user activity is impacted. Using multicast Nomad can support one download per location. It can also greatly reduce the amount of network traffic generated by software distribution and drastically reduce the time needed for deployments. With the local multicast option the elected master sends out a multicast scream of the package that all other clients receive at the same time. The central multicast option is the most efficient use of the WAN possible allowing for a single copy of the package to be streamed to all targeted clients at one time regardless of location. Finally the FanOut option allows a “spider-web” distribution model when allocating software to different clients on a network.

Saying that Nomad acts like a BDP is also factually incorrect. Not only do BDPs not have the distribution methods of Nomad as outlined above but they also have significant administrative overhead costs. Nomad is completely dynamic and fault tolerant allowing for processes to complete and different systems to take over if users shut down systems or do other activities which would impact the distribution.

Excerpt from blog post:

Q6: Will it manage client caches?

OneSite – Yes, caching file system

Nomad – No, separate tools are provided

OneSite contains a caching file system driver, which creates a virtual SAN in each branch office. It automatically manages the client caches for the whole branch office, and there is never a need to manage the cache manually.

Nomad starts deleting packages based on package priority when the disk is more than 90% full. But this can lead to deletion of useful packages, so tools have been provided which administrators can run manually to delete useless packages.

The facts:

This statement is also inaccurate. Nomad has many options for managing the cache. The cache can be set to any percentage of the available disk space or to a static size. Old content is automatically cleaned from the cache only when space is needed. Content can easily be designated as critical so that it remains in the cache unless an administrator chooses to remove it. Also, Nomad manages disk space more efficiently as it creates a link into the CCM cache for all of its content.

Excerpt from blog post:

Q7: Can it support PXE in branch offices?

OneSite – Yes, Peer to Peer PXE built-in, no extra purchase or install required.

Nomad – Yes, PXE Lite with purchase of Enterprise edition and consulting services.

OneSite includes Peer to Peer PXE built-in.

According to Adaptiva, “P2P PXE is included with your basic One Site license – there are no additional licensing costs, and no consulting services that need to be purchased”.

OneSite’s P2P PXE doesn’t require any installation: “No servers or server roles are required. No router changes are required. No DHCP server configuration changes are required. There is nothing to install, or configure, in any of your branch offices, period.”

Nomad branch and PXE Lite are sold together as Nomad Enterprise, which also requires purchase of professional services for deployment. According to 1E, “this tool is also a bit complex to set up initially, hence the need for a services engagement in production”.

This is probably because PXELiteServer.EXE needs to be installed on 2 – 3 machines on each subnet of every branch office in order for the solution to work.

According to 1E, “There’s also a web service which is used by PXE Lite Server to interface with the ConfigMgr database; there’s a stored procedure which is installed into the ConfigMgr database (for the use of the web service, unsurprisingly)”.

The facts:

Nomad can indeed support PXE in branch offices. The PXE Everywhere agent (previously called PXE Lite) is included with Nomad and allows workstations to act as PXE service points and offer OS images and package content locally to peers. PXE Everywhere eliminates management effort in ensuring that systems are online for peers to PXE boot from at remote branches. With PXE Everywhere an election process takes place (similar to classic Nomad functionality) when a system needs to PXE boot and a suitable host is found for the system to pull the content down from. There is no additional server required with PXE Everywhere. The PXE Central service can be and usually is installed on a ConfigMgr site server. Additionally PXE Everywhere’s election process is intelligent enough to offload the PXE boot hosting processes to multiple systems so that not one single system is overloaded with requests and it also handles edge cases such as preventing failure if a PXE host is set to go to a lower power state.

Excerpt from blog post:

Q8: Will it give me visibility into downloads?

OneSite – Yes, 40 real-time web reports built in, shows WAN and LAN costs, etc.

Nomad – No reporting, but client side console can be used to look at downloads happening on a single machine.

OneSite automatically creates about 40 real-time web reports during installation. These display real time data about all downloads that are taking place, per collection, per package, per AD site, etc., including the WAN and LAN costs for each download.

Nomad provides a console that can be used for visibility into a single client machine, but there is no central reporting feature provided.

The facts:

This is also incorrect information. Nomad can provide excellent reporting data through the status system and inventory features of the ConfigMgr agent – all displayed through the native ConfigMgr reports console node and in the native web reports. 1E has a standard reporting pack offered to all Nomad customers which is free of charge. Detailed data about completed download percentages, elected masters, peer to peer and multicast utilization, cached packages and versions and additional information can be reported.

Excerpt from blog post:

Q9: What kind of SCCM data can it manage?

OneSite – Packages, Policy, Hardware inventory, Software inventory, Software metering, Status messages

Nomad – Packages

OneSite is meant to be a solution for all kinds of SCCM data, including SCCM Policy, all types of Inventory data, and Status messages, in addition to Packages.

Nomad manages only SCCM Packages.

The facts:

1E has provided this functionality for several years in their NightWatchman product. Additionally Nomad has features that allow video streaming in the same peer to peer based manner of content distribution. Do keep in mind though that the policy, inventory and status information is very small when compared to software distribution traffic. Most often there is no need to throttle this traffic as it is a small fraction of package content size.

Excerpt from blog post:

Q10: Does it support package encryption?

OneSite – Yes, packages can be encrypted with a 128-bit security key

Nomad – No, there is no support for package encryption

OneSite contains a built-in encryption engine that will encrypt packages using a 128-bit encryption key. Clients can host the packages and share them with other clients, but only those clients will be able to use the packages which have been targeted with an advertisement.

Nomad does not support package encryption.

The facts:

This information is also false. Nomad performs consistency checks and hashing both at the server and client before and after transmitting any data across the WAN. Nomad uses the latest security protocols and implements a private key algorithm. Nomad shares are also locked down and communications channels regenerate secure information each time the Nomad service stops and starts. All election and communications traffic is encrypted.

The 1E people have also in addition to this given the Infront consultants some great information separate to these points, such as the fact that Nomad 2012 completely integrates into the SCCM Admin console (I am a big fan of “one console”) doesn’t require any kernel drivers (eliminating the risk of a BSOD) and they also have a solid OSD story when you look at how Nomad integrates with Shopping and AppClarity products to address software waste and reduce version sprawl in the OSD process. Nomad integrates with the SCCM backend Task Sequence process (there are custom console extensions) to work fully in WinPE.


In closing, I want to reiterate the sole purposes of this post are education in providing what I believe to be factually correct information. As a community of IT Pros and IT partners, we should always support one another in our endeavors to provide value to the community. If you take issue with or have questions on any information in this article that is perfectly okay. For clarification, I encourage you to take your questions straight to the people who can answer them best – 1E, at or Adaptiva at