Do I deploy 1E Nomad everywhere, or to remote clients only? (Part 2)

Background

In Part 1 of this two part series I talked about the many advantages of opting to deploy 1E Nomad on all client systems throughout the entire enterprise. In this concluding article I address the disadvantages of opting for a potentially lower initial cost (fewer agents deployed), and focus on the many advantages to be realized when installing Nomad on all managed systems.
The first and likely not obvious issue is that of potential WAN impacts. After all, you are purchasing Nomad for exactly this reason – less impact to the WAN when deploying systems management data. So what is the risk if Nomad isn't deployed to all systems? Consider the scenario of a laptop in the main office without Nomad. That system gets content nicely from its well-connected link to the DP in that central office. What happens, however, when that user packs up the laptop and goes on the road? Remember, the remote locations have Nomad so there are (hopefully!) no longer any remote DPs. If that is the case, how does the road warrior get content when away from the main office? Is it configured to only download (via BITS) if there is a local DP? Does it not download at all if there is nothing local? Is it possible that it will attempt to download across the WAN (again using BITS) if something is misconfigured? Is BITS set across the board to limit its possible WAN Impact? What about travel outside the enterprise, maybe a home office or a hotel? Are you now forced to stand up Internet Based Client Management and all that entails, or is your existing VPN implementation sufficient to support those? How many additional DPs will be needed to support those non-Nomad systems beyond the minimum count needed for an all-Nomad scenario?
Then there's the added administrative aggravation of keeping track of your purchased license count, and are you up or down on your legal position as time goes on. Of course, I could simply say here that there's an app for that! Instead I'll simply say that you can simplify this issue by using a standard configuration across all systems in the estate that includes Nomad.
Of course one is also confronted with the need for different imaging techniques with the Nomad equipped systems, and those without. Nomad provides significant added capabilities and features that dramatically improve all aspects of the imaging tasks. Those advanced features inherent in Nomad are not going to be available to the Administrator when dealing with those other systems. Consequently there will be a need to maintain two discreet Task Sequences for the OSD processing, with vastly different capabilities in each.
Security update processing will of course be slower for those other systems as well, meaning the Administrator still has the same old headaches before Nomad was introduced at all.
Using Nomad globally removes the need to maintain site boundaries – hence new subnets do not need to be worried about – Nomad is peer-peer and essentially site agnostic. The only information Nomad is truly aware of and evaluates when attempting to obtain content is:

• Content data e.g. package id, version
• Available DPs to download from
• Peers on local subnet

The "site-awareness" logic is already evaluated by and determined in the ConfigMgr client before being passed to Nomad (e.g. DP information: preferred/local, fallback/remote, fast, slow, etc). It is this detail that makes boundaries and boundary groups optional. How great would that be? How great would that be?
Nomad is rock solid when it comes to getting content where it needs to be (and only there!), and has the added advantage of a very robust reporting subsystem that is fully integrated with the native ConfigManager status message subsystem. Here you will find a ton of detail around the Nomad-specific content distribution process and related status. This provides a high degree of confidence on exactly where those Nomad systems are at any point in the process which is vastly improved over the out-of-the-box ConfigManager status detail
Rebuilding end user systems (whether new or refreshed) is significantly enhanced with the use of Nomad everywhere, including that well-connected back office. Without Nomad everywhere, those systems will still require a state migration point and a PxE server with all that entails. Meanwhile, the remote systems will be leveraging each other for peer-peer state migration and PxE boot support.
Let's not forget the overall costs as well. Remember, those back office DPs will be looking at a replacement scenario in three or four years down the road or whenever a lease expires. Over five years one could be looking at double the cost on servers alone. Don't forget the soft costs associated with the technicians tasked with setting up and maintaining those added devices over their lifespan. Here are some nuggets often overlooked when considering this last point:

• It takes 12 hours per year per DP to maintain a DP (monitor, troubleshoot, planned and unplanned replacements, repair, disk space, capacity planning). Can you even do this remotely or do you have to send a man and a van to do this on some sites. That is added expense.
• 10% of DP's fail in any given year, typically requiring approximately 16 hours to rebuild.
• Routine patching of those DPs
• Added license costs for proper monitoring of the server itself (e.g. Operations Manager)
• It can take 8 hours per DP to set-up and analyse the network details for boundaries and optimise throughput on remote DPs. Also consider the work to install the DP and WDS/PXE roles

In summary, without deploying Nomad to all your managed systems regardless of location or connectivity considerations, you are confronted with maintaining two standard configurations (systems with and without Nomad); the OSD process requires two different task sequences, State Migration Points, and PxE servers; the Administrator is still messing around with the management of site boundaries, and confronted with less than desirable package FanOut troubleshooting to the additional DPs required to support those back office systems. The simple logic in this decision point is to Imagine how much easier your life becomes if you have a fully self-managing DP on every subnet in the estate? With a DP on every subnet, think of all the added things you could then do easily, or not have to do at all? Once all of this is evaluated as I've described in this two part series, the answer should be obvious.
We can actually place a very accurate cost quantification on all of these points in an ROI business case prepared by our IT Financial Analyst team.

Further Reading

If this series of articles were of interest, you will also want to read a related post from my colleague, Jim Bezdan:

• Why should I use Nomad when I have a server at each site?

And this from Saurabh Vij:

• Nomad – A Truly Serverless Solution

You can also read more about Nomad at https://www.1e.com/nomad/, or follow our LinkedIn Showcase page.