A day in the life of a ConfigMgr administrator: Part 2

Keeping the Distribution Point (DP) servers Lights On

Point-of-View: from a ConfigMgr Administrator to his Manager, discussing how he/she spends their day managing a ConfigMgr environment.
This is the second part of my three-part story that details what we did in our company (in a previous life) to help reduce the DP server management nightmare. Part one of this story can be found by clicking here.
So a little background first; we’ve got 140 Distribution Points in our ConfigMgr environment and sometimes we have package distribution problems. I’ve previously described to my manager how I spent an entire day troubleshooting a failed application deployment, and what I had to do to fully resolve the problem. Well, when I mean “fully resolve”, I mean resolve the problem within the current constraints of ConfigMgr itself.
When I reported back to my manager, he was understanding of my problem but prompted me to find out if there was a better way to resolve these types of problems. My first instinct was to push this out to our Network Operations Centre, which would probably mean writing a script to automate the remediation of these issues. There are some things that can be automated, and others that can’t. So I got onto the Internet and Microsoft Forums (which are great for MVP’s advice) and easily discovered there were a number of options that could take away the headache of managing so many DPs – like really expensive WAN Caching devices ($$$$!!!!), and built-in options like Microsoft BranchCache and Pull Distribution Points. However I was advised to focus on Alternate Content Providers (“ACP”). These are purpose built content transfer mechanisms for ConfigMgr (eg: by default, BITS is an ACP that ConfigMgr uses). Advanced ACP’s negate the need for local Distribution Point servers in all types of office locations (whether it be the main headquarters or remote satellite offices). Everyone was talking about 1E Nomad – so all these options required further investigations!
BranchCache – unfortunately BranchCache still utilizes the BITS technology (which we previously had to restrict heavily with 5kbps rate-limits to avoid WAN saturation) and therefore it would take days for packages to be transferred to remote locations. We had many offices with multiple subnets, which meant ConfigMgr would have to transfer the same content multiple times over the WAN link (using BITS) to each subnet at the same time. We would also still need to keep the Distribution Point anyway as we needed the PXE network boot capability on a Windows server. Oh, and the State Migration Point or another file server storage for user profile & data backup when performing OSD. All these restrictions immediately discounted the use of BranchCache anywhere. We found a few more, lesser known areas that discounted the use of BranchCache further. BranchCache required twice the disk space of a normal ConfigMgr Client cache as content was required to physically reside in both cache locations, and there is no way of telling what content was held in the cache or how long this would be retained until tombstoned/deleted. Yeah, BranchCache was definitely not an option for our business.
WAN Caching devices – an advantage for us was that we already had these in our Tier-1 office locations. It was hit-and-miss at our smaller Tier-2 offices, but nothing at all for offices in smaller locations like South East Asia. OK, not a massive problem. We could take advantage of the caching boxes where we had them and maybe use something else at the other locations. The network team didn’t like this at all! When I said we might want a few GB’s of storage for ConfigMgr they simply couldn’t believe me. “WAN Caching devices are used to cache Internet content that is continually reused by users”, they told me. I said that was exactly what ConfigMgr was doing, we needed to cache applications that were going to be used again and again for months on end. “Ahh, the content on the caching devices can only be kept for a few days before it is rolled over (deleted) during refresh.” That is not going to work with ConfigMgr, as that will usually mean the same application is having to be re-transferred over the WAN multiple times! That isn’t very efficient at all! Plus we’d have different processes for different offices, and I’d prefer to keep to one standard operating procedure.
1E Nomad – this software doesn’t cause WAN congestion as it is true adaptive bandwidth throttling, rather than basic rate-limited technology (like BITS). The most interesting point of 1E Nomad is the fact that it will be transparent to my normal day-to-day operations of ConfigMgr. I won’t have to worry about a managing the Nomad add-on as a separate infrastructure outside of ConfigMgr (like WAN caching devices) as I can control 1E Nomad within the same ConfigMgr Administrator Console I use every day. And I can see where content actually exists (cached), whereas I couldn’t with BranchCache. Another great feature with 1E Nomad is that I won’t have to worry about ConfigMgr site boundaries – more importantly overlapping or misconfiguration of site boundaries! Furthermore, 1E Nomad would provide the same level-of-service as if we had a real ConfigMgr Distribution Point. The PXE Everywhere and Peer Backup functions of Nomad provide the normal PXE Point and State Migration Point functions respectively, and utilize the same “most suitable computer” technology to automatically choose the best computer to perform these functions. Nomad is obviously much more than just an Alternate Content Provider.
I reported back to my manager with this preliminary information and we decided to evaluate 1E Nomad further. We contacted 1E, and after an initial meeting to understand the basics, we were provided with the evaluation software, access to the online documentation, and I was engaged by a Solutions Engineer who helped get me going in our lab environment. The Solutions Engineer remained on hand to answer my questions and helped me whenever I needed throughout our evaluation.
This is part two of a story I experienced in a past life as a ConfigMgr Administrator. The third part of this story will detail our evaluation and testing of 1E Nomad, and what we had to prove so we could put this tool into production use within our business.
Software Licence Audits – The Ultimate Defence Kit.
Software vendors are getting more predatory about license audits. If you're passive about it, you're the prey. If you're active, you'll save millions and fly through your audits (they hate that). Download our four weapons and fight back.