(Originally published on LinkedIn)
This is the second part of a series about the digital transformation journey we are doing at Sandvik. You can find the first part here, Leaving legacy in 2018.
When I joined Sandvik back in 2017 we were right in the middle of upgrading our Configuration Manager environment from SCCM 2007 to SCCM Current Branch. This was a huge project in which we invested a lot of money and time into with our delivery partner.
We finally pulled through. Everyone involved in the project did a huge effort to get us there, from the SCCM delivery team/technicians to local IT. This was our first step towards the future for our clients and this meant we could start working on Windows 10.
Configuration Manager and deploying applications were however still somewhat of a struggle for us. Every other time we did a large deployment we had to deploy in waves, spend a lot of time and effort into not “killing” the slower sites which often meant deploying on weird hours and asking users to leave their machines on during the night at the office. It happened more than one time that we had to pull the plug on deployments since we were consuming all the bandwidth in the network for some sites, even the bigger ones. We did have a peer-to-peer solution, but it was not spread out to all sites and machines.
We had to fix this.
Since we had moved to SCCM CB a lot of new opportunists opened up (maybe not from day one though) which meant that we actually had tools in our toolbox to solve this in a new way, such as Branch Cache and Peer Cache (which in them self are not new functions).
We decided to start with Branch Cache since our biggest problem was application distribution. We piloted the Branch Cache at a few sites to see if we actually could gain something from this, and the results were really promising so we started deploying this throughout our whole environment, starting with the most prioritized sites without local distribution points and then over to all sites. When Branch Cache was widely deployed, we scaled down our 1E Nomad solution and eventually removed it.
We managed to do the following bigger things without causing network interference and seeing Branch Cache being utilized.
- Deploy Office 365 ProPlus update to > 25 000 computers
- Deploy Windows 10 feature update to > 18 000 computers
And then we had the one we are most proud of to date. We deployed Teams to > 25 000 users, with utilization in Branch Cache of 70%. This is our best number so far for applications, and then we are not yet using phased deployments in Config Manager.
Our next step right now is to get Peer Cache out on a few sites, especially sites with bad connections to the closest distribution point. The reason we want to get Peer Cache out in the environment is to ease PxE installation on our smaller/remote sites. In parallel to this, we are also investigating how we could utilize LEDBAT for the traffic between our SCCM servers. This, however, requires that our SCCM servers are running at least Windows Server 2016 and we are not completely there yet. But there is still a lot of time left during 2019!
The take away from this
The biggest takeaway, Branch Cache works, and it works really well. If you have not yet started to investigate Branch Cache, I would advise you to do so. This has saved us a lot of headache and time since we can now deploy with great confidence that we will not disturb our critical business systems with our traffic which might not be as critical. The fact that we have managed to reduce the WAN traffic with up to 70% for larger deployments has improved the trust of other teams that we can deploy things in a disturbance-free way.
I also want to point out that our team of technicians and architects has done tremendous work making this possible.
Leave a Reply