Last month, one of the largest transportation companies asked 1E how our Nomad product could help them accelerate the deployment of ConfigMgr to their PC estate. They had been working with several contractors to install and configure ConfigMgr into Azure, but were unable to address the slow rollout of the SCCM client to their computers – mainly due to a large number of computers they have and the vast number of “locations”. A location could be a small office with only a few computers connected by a consumer ADSL service, or just one or two computers on a train with a GPRS/3G/4G/LTE connection!
The customers’ architecture team already understood the content distribution challenges (and many other issues) of having ConfigMgr in the cloud, so Nomad was already on the table. But in this instance, they needed to understand how Nomad could accelerate the ConfigMgr deployment – the project was already several months behind.
We demonstrated how Nomad would eliminate the need to perform this level of discovery for each and every site. Nomad manages the bandwidth itself, and site boundaries are no longer needed either – this is basic stuff for Nomad!
The remaining challenge was getting the ConfigMgr Client source files to the computers without the need to schedule the download, and without disrupting the day-to-day business operations. Again, this is basic stuff for Nomad!
Microsoft suggests several ways to deploy the ConfigMgr Client in a greenfield site (one that doesn’t have an existing or standardized systems management tool), but they all require every computer to download the source files. The size of the ConfigMgr client source files (and pre-requisites) can range from 220MB up to 350MB, so you can’t just instruct all your clients to install it at the same time using the Client Push Installation feature.
Microsoft has described the possible methods and their disadvantages (notice that every method may cause high network traffic!)
Let’s cut to the chase; we can use Nomad’s ReverseQoS (intelligent bandwidth throttling technology) and Nomad’s caching and peer-to-peer sharing to make it considerably easier and faster to deploy ConfigMgr, not just at one site, but to all sites faster than they thought was even possible!
By using Nomad to download and install the ConfigMgr Client, this organisation will be able to rollout ConfigMgr immediately, and without needing to create a site boundary for every location, and comfortably know that Nomad will prevent a huge amount of network traffic being transferred over their WAN links.
The process is very simple actually:
The following steps will be wrapped up into a VBScript that can be deployed as a Computer Start-up Script using Group Policy – when a computer is next restarted the VBScript will run and will initiate Nomad to download the ConfigMgr Client source files and install the ConfigMgr Client (if Nomad or the ConfigMgr client aren’t already installed).
The following script does the heavy lifting for us – and you will need to customise the variables to match your environment, such as a central distribution point server name (sSMSDP), management point (sSMSMP), site code (sSMSSiteCode) and PackageID and version for the ConfigMgr Client Package (sContentID & sContentVer). I’ve highlighted the variables in red that will need changing.
You may also want to customize the CCMSetup.exe command-line to suit your ConfigMgr configuration.
When this script runs on a computer for the first time, it will:
What this all meant to the customer is that we were able to roll out the ConfigMgr Client to all their computers in all site locations in just a couple of weeks! This is just basic stuff for Nomad!