Recently I deployed SCCM 2012 R2 for a customer mainly for the purpose of deploying desktop operating systems over the network.
A site server with a local SQL was deployed in the customer’s datacentre with the management point and distribution point role. A distribution point server was deployed in the customers head office to services content (images) to pc’s on the local area network.
However, shortly into the testing phase of the OSD process, it was reported that network services were being disrupted on the LAN (e.g. access to LOB applications, file servers etc)…..and across the WAN!! This was happening when deploying the image to less than 5 PC’s simultaneously. The DP server in the head office and the PC’s being images (new PC’s) were all connected directly to the same switch. The image was approx. 8GB in size.
There were lots of questions asked e.g.
- How is SCCM deploying images?
- Unicast or multicast enabled?
- Is the content being deployed over the WAN?
- How big is the image?
In a nutshell…What mis-configuration within SCCM is causing this issue??
I didn’t believe SCCM was causing the issue. But how did I go about proving it?
I hate getting caught up in network related issues cause I’m not a network guy. So my approach to dealing with this was to isolate the issue and determine if indeed SCCM was the cause, or if it was simply the trigger. So how did I do this….
- I deployed MDT on the distribution point server in the head office.
- I got the network team to set up the relevant network captures
- I then recreated the deployment scenario by deploying the same image via MDT as I used in SCCM to the same group of PC’s
Why did I do this?
- If the same issue was occurring when deploying images via MDT, then it wasn’t a configuration issue within SCCM causing the problem.
- Then hopefully, with the right network capture, the network team can identify what issue on the network is causing the problem
The result of the test was that the same network outage symptoms occurred when deploying images over the network via MDT. Therefore, it was not a configuration issue within SCCM 🙂
In terms of what is causing the issue, there are some theories emerging from the network team (misconfigured default gateways / DHCP / switches), but it’s still under investigation. I’ll post an update when I hear back. But for now, SCCM (and me) are in the clear! 🙂 🙂