In the first part of this blog, Careful What SCCM Infrastructure You Wish For (Part 1 of 2), I described my experience of migrating from a relatively simple SCCM 2007 infrastructure to a much larger SCCM 2012 infrastructure. It included a primary site, three secondary sites, and over 500 distribution points at retail locations across the country. The design was intended to reduce the WAN traffic from clients accessing SCCM package and software update content, and allow them to acquire it from a local distribution point. The burden on the network was reduced, but the operational and administrative overhead increased dramatically. This design seemed like the only option until I learned about the SCCM Alternate Content Provider (ACP) interface and Adaptiva OneSite Anywhere.
What is an Alternate Content Provider?
In SCCM, the ACP interface exposes a set of API calls and modifies the function of Data Transfer Services, such that an additional provider other than BITS can be used to retrieve package content. This function of the SCCM client allows the option of retrieving content from other sources rather than from a standard distribution point. The content still needs to come from somewhere, and to meet my requirement, it would have to be somewhere on the local LAN. Adaptiva’s OneSite Anywhere solution provides this functionality by caching SCCM content on other clients’ unallocated disk space at a location, creating a virtual SAN that works seamlessly with SCCM to replace the function of a distribution point server. Seamless is important of course when you’re looking to reduce administrative costs and, in my case, time!
So how does OneSite Anywhere work with SCCM and where does the content come from?
When an SCCM client receives a deployment policy and must download content, the Data Transfer Service detects an ACP and invokes the Adaptiva client. The Adaptiva client checks for the content on the virtual SAN comprised of other Adaptiva clients at that location (on that LAN), and pulls the content locally. The virtual SAN can maintain multiple copies of content (this is an administrator’s preference), ensuring that once content arrives on a LAN it will be available until deleted from SCCM entirely. If the content exists on a machine that is powered off, OneSite Anywhere will wake it up automatically. If no local client has the content, OneSite Anywhere will download it over the WAN.
The technology used to manage the WAN download is nothing short of revolutionary. An NDIS driver (aka the Adaptive protocol) dynamically predicts traffic on the WAN end-to-end in milliseconds. It transmits each individual UDP packet only when there is free bandwidth on the network. This means there is no need for throttling like with BITS and other TCP-based solutions. There is also no need to schedule SCCM delivery at night. Downloads can run during the day without upsetting the network or the network team.
The SCCM client then installs the software as required. Sounds great, but to coordinate all of that intelligence, it must require lots of administration right? Not at all! I was surprised to learn that this functionality is truly seamless to the administrator. The identification of content location and peer-to-peer file sharing is dynamic and requires no administration. It’s all self-managing.
How Could OneSite Anywhere Have Helped?
Reduced Boundary Management
One of the challenges I mentioned in my previous post was the management of thousands of individual SCCM subnet range boundaries. Subnet range boundaries were required because a whole subnet could not be used at a location due to vLAN restrictions in which some vLANs were blocked from communicating to the local server. This meant that not all subnets at a location could be added to a single boundary group for content location. Outside of the fact that having so many subnet range based boundaries is complex, content location requests from clients were causing unnecessary stress on the database.
With OneSite Anywhere, I could have created a single range in a single boundary group for all of my remote sites because the Adaptiva client doesn’t require boundary groups for content location. When a content request is made, the ACP kicks in and the Adaptiva client is dynamically directed to other clients, absolving us administrators from having to define content location rules ourselves. OneSite would have saved me from repeated audits and troubleshooting failed package deployments if a boundary was misconfigured. I could have just let Adaptiva do the work.
Significantly Reduced SCCM Infrastructure
Managing 500+ distribution points can be a heavy burden on administrators. When it was time to get a new package ready for release, our packaging team would start sending it out a week in advance because we knew we had to plan ahead to resolve failed package distributions. This was a given because approximately 10% of the distribution points in the DP group would fail to process the package for various reasons.
With SCCM, there is a limit to how many packages and distribution threads can occur at a time, thus causing a queue. In a busy environment with so many DPs, you can imagine the queue rarely cleared. Since all of our distribution points were children of secondary site servers, the secondary sites would have to process the package first. This would sometimes cause a bottleneck and if any of those secondary sites went down, package distribution would stop. It got to the point where we ran PowerShell scripts to check for failed distributions and reinitiated them programmatically. The daily monitoring of all of those DPs took time away from other tasks and projects.
With OneSite Anywhere, not only could I have eliminated 500+ distribution points, but all of our secondary sites as well. The only reason we implemented Secondary sites was to support all of those DPs in the first place. A secondary site server doesn’t require a great deal of administration, but in SCCM 2012 it participates in SQL replication between the primary, which can sometimes lead to problems if there are SQL replication issues. It’s not a huge problem, but why add the complexity when it can be avoided with no loss of functionality?
Let’s recap with visual aids. In my previous post I shared a diagram illustrating the current SCCM infrastructure. If I had implemented OneSite Anywhere, I would have enjoyed a much simpler infrastructure and more free time to work on other projects.
Pretty stunning right? I followed best practices to create the 500+ DP environment, and the solution met our design requirements. Even so, it created huge amounts of unexpected administrative work. If I had known OneSite Anywhere could do the work, I would have implemented it. That would have made things run more smoothly, saved a lot of money, and freed up my time for other priorities. But I didn’t know about Adaptiva then. When I found out, I joined the company!
