Hi,

Recently, we have installed 2 distribution points in our lab environment on 2 separate machines to lower the load on our primary site server. Both distribution points have the same boundaries associated.

I don't know if it is related to those 2 DPs, but applying the OS image is taking very long (+30min). If I copy the wimfile manually from the same location, it's done within a minute. Maybe we saw it after installing the 2 dps because of excessive testing.

We are running SCCM 2012 R2 CU1, so kb2905002 should be installed (included in CU1).

We only see this slow download on Virtual machines, (1CPU/4GB). On physical machines, applying the same image only takes a few minutes. I also observed that in rare cases, it goes fast on a VM also...

Any ideas?

• Edited by WiM8 Thursday, February 05, 2015 11:28 AM

It's a bit confusing as you mention both the download and the applying of the image. Assuming that it's about the applying of the image (as the title suggests) than my first guess would be that it's storage related (especially because you're only seeing it on VMs).

Indeed applying the image...

Are there some loggings I could check where I should see error messages? In the smsts.log, I can only see that the image is being applied.
Copying the Wim.file manually, is really fast, less than a minute, so storage should be ok, no?

After you applied CU1 on your server, did you update (redistribute) your boot images on your Distribution Points ?

I installed CU1 during upgrade to R2. Afterwards new bootimages were created and ditributed. It was installed in june and the last distribution date of the bootimage was in novermber...

Have you checked at the virtualisation layer to confirm that you're actually getting the maximum throughput that you expect?

This applies both to your end device VMs and your 2 DPs (which I assume are also VMs given this is in a lab)

• Marked as answer by Daniel JiSunMicrosoft contingent staff, Moderator Monday, March 09, 2015 9:22 AM

The throughput should be fine because a manual copy from the exact same source to the exact same destination is going very fast, of course another protocol is used during a manual copy.

It is also happening in our other environments where only 1 dp is installed, so it is not related to the 2 new dp's. As we did not find the reason yet, we are accepting the slowness...