Just saw a nice infographic from the folks at 1e.com. Their Nomad product lets Microsoft System Center Configuration Manager handle large-scale Windows deployments. “But wait!” I hear you thinking. “Doesn’t SSCM do deployment on its own? Why another tool?” Good questions. The quick answer is Deployment Automation. Here’s my explanation:
Setting the Stage for Deployment Automation
Think about mammoth enterprises, with tens to hundreds of thousands of endpoints. Or ponder the US DoD, which has announced plans to upgrade ~4M endpoints by the end of 2017. Sure, SCCM can set up and fire off in-place or policy-based upgrades for endpoints. But alas, that is subject to some interesting issues:
- Bandwidth: upgrade packages for Windows 10 range from 3.2 to 4.2 GB in size. Also, they must be transferred to every endpoint. SCCM isn’t good at bandwidth throttling, nor can it stagger downloads to reduce traffic. Multiply this by large numbers, and what happens? Enough data in transit to choke WAN links of any size.
- Legacy hangover: Sure, an in-place upgrade sounds good. But it doesn’t support UEFI boot security on PCs running legacy BIOS. To benefit from UEFI boot security enhancements, the boot drive must be wiped and reformatted. Oops! That doesn’t work with an in-place upgrade.
- Manual labor: Many organizations still require human interactionto get upgrades installed. Ditto, for production systems migrating from an old OS to a new one. 1e’s infographic shows that over a third of organizations require manual intervention for OS deployments (40+%) and application migration (37+%). That’s alotta labor!
There are more issues worth chewing on, even for organizations willing to stage SCCM servers closer to sites where Windows 10 gets deployed. These include cost of additional SCCM licenses and platforms, admin overhead, and more. In short, there’s a big gap between what needs to be done to migrate and what SCCM can do unaided at enormous scales.
What’s the solution? Simply put: bandwidth conservation, proximity staging, and ample deployment automation. 1e’s Nomad addresses deployment all the way to the endpoints. It is especially relevant to remote endpoints. These might reside in remote premises, branch or satellite offices, or belong to itinerant field staff:
- Local staging: For each LAN, Nomad picks a “master” node. It gets one download of the deployment package over the WAN. All other clients on that LAN get their copy from that master. Thus, only one WAN transfer per LAN occurs. Local transfers work peer-to-peer, using an agent on each endpoint to request and manage delivery. Bandwidth is monitored and automatically throttled so transfer traffic won’t interfere with business traffic.
- Powerful deployment automation: On each client, automation tools preserve and migrate applications, settings, and preferences from an old to a new install. They also handle wipe-and-clean-install of Windows 10 where needed. Ongoing monitoring and status reporting built into the agents helps, too. It lets them flag a flubbed or faulty system, and revert it to its original state. It can even schedule that client for manual intervention through mechanisms the customer chooses. This might be something like “provide a replacement, ship unit to depot for service, swap replacement for upgraded unit,” for example.
This diagram from the Nomad page speaks to the product’s many capabilities.
These capabilities and techniques present a workable way to manage large-scale Windows 10 migrations and deployments. That’s what makes products like 1e’s Nomad worth investigating, and perhaps acquiring. For those with big Windows 10 deployment plans, it makes good sense to inquire further.