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 native ConfigMgr environment.
This is the fourth and final part of my four-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 (trying to troubleshoot a ConfigMgr distribution problem)
Part two of this story (investigations into possible solutions)
Part three of this story (evaluating the proposed solution against our requirements)
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 package distribution. My manager asked me to investigate other possible solutions, and I successfully evaluated 1E Nomad. We are now implementing the software throughout our environment.
IMPLEMENTATION! Pilot to Production
The purpose of this engagement was to plan and implement the Nomad solution into the production environment. This would also allow 1E to demonstrate the product’s functionality and how it would ultimately achieve a reduction in our hardware costs, improve our existing software distribution, and increase our operating system deployment capabilities.
The first couple of days were spent in workshops with the 1E team to agree the project scope. This included design decisions and selection criteria for pilot computers. During this time we also got down to the technical detail of the Nomad configuration and OSD task sequence integration. This was probably the most exciting part of the project for me as I could now see how everything would fit into place and what our future ConfigMgr hierarchy would look like. It just appeared to be so easy, and I think this was because Nomad made ConfigMgr easier. We would have fewer remote servers and all other ConfigMgr infrastructure, so everything would be consolidated and centralised in the data centers. The overall hierarchy (and its Visio diagram!) was so small and was going to be considerably easy to manage.
The output of our work with 1E would generate many deliverables:
- Conduct a design workshop and document findings and decisions
- High level 1E solution design to including the integration of Nomad, PXE Everywhere and ActiveEfficiency components
- 1E solution test document for Nomad and PXE Everywhere
- Nomad components and packages installed on required ConfigMgr 2007 infrastructure servers and pilot clients
- Windows 7 task sequence and deployment process to include Nomad
- Pilot of software distribution and software updates
- Pilot of Windows 7 OSD
- Project management
CONCLUSION: What we discovered since implementing 1E Nomad with ConfigMgr:
- Probably the most important point was the dramatic operational cost reduction of managing ConfigMgr. This really falls into several different categories, such as:
- We now have 137 fewer servers, yet now guarantee 100% ConfigMgr functionality at all office locations throughout the world. This is something we couldn’t possibly do with ConfigMgr by itself.
- From a business perspective, my manager now depends less on the Infrastructure Team and server (budget) availability.
- The network team is happier because ConfigMgr traffic (now managed by Nomad) doesn’t cause any concerns.
- Helpdesk Calls specific to ConfigMgr related activities (like Application installations) have reduced by approximately 60%. This is simply down to the fact that ConfigMgr is now able to successfully obtain content the first time. No more failed downloads because laptop users are moving between subnets & sites etc.
- Only three site boundaries for our entire ConfigMgr hierarchy for over 165 locations, including partners and (VPN) gateways. This is absolutely amazing – no dependence on the Network or Active Directory teams, or misconfigurations which would leave clients in an unmanageable state.
- Users now experience much faster application download and deployment times – regardless of where the user is in the world, they can get any applications they need. And Nomad delivers the application faster than BITS because BITS was forced to use a maximum rate of 15kbps during the day, whereas Nomad obtains the content from a peer computer or download it from the central DP’s using its bandwidth throttling technology. Brilliant!
- Higher compliance of security updates. Before Nomad, typically a week after we deployed security updates our compliance percentage was hovering between 85%-90%. Now that Nomad is being used to help ConfigMgr clients download content, we now have seen the compliance percentage increase to 95%-99% within only two days of deploying new security updates to the field.
- New remote office locations can now be brought online with no budget requirements from the ConfigMgr team – because obviously no remote ConfigMgr server infrastructure is now required. And because we now have site boundaries that span our entire internal network we do not have any reliance on the Network or Active Directory teams to bring on new (or existing) offices. This allows us to move faster than any other department when bringing new offices online; awesome!
- And lastly, and most probably our most recognised benefit of using Nomad, is the ability to image computers anywhere in the world! Nomad enables new and existing computers to be imaged by ConfigMgr without any server infrastructure. We were able to image computers beforehand, but we always had users in specific office locations that were forced to send in their computer to HQ. Now the user can re/image their own computer without any effort or interaction with IT. This is locked-down to corporate-purchased hardware. The entire business LOVES this new capability!
And what a “conclusion” it was. I started out explaining the effort involved to keep the distribution point lights on, and I’ve ended up with eliminating all but three DP servers, and using 1E Nomad instead. Amazing!
The left picture is just the first page of the old SCCM hierarchy – it’s three pages! And on the right is the new hierarchy with Nomad – in its entirety (one page)! Which version looks better (and more manageable) to you?!
This is part four of a story I experienced in a past life as a ConfigMgr Administrator.
