none
Insanely slow OS download in 2012 R2 WinPE

    Question

  • I'm testing out SCCM 2012 R2 in our lab.  I upgraded from SP1 CU3.

    With Native OSD, downloading the WIM from the DP is inanely slow; CPU is pegged 100% during the download (OsdApplyOs.exe) and it takes over an hour just to download the file.  I know it's not the network stack because I can simply robocopy the 7gb WIM in 2 minutes or so.

    Anyone else get this?  We were fine with SP1 CU1/CU2/CU3.

    Sunday, October 20, 2013 2:54 AM

Answers

All replies

  • it's also really bad downloading anything else too (Drivers, ConfigMgr Client) - http in general.
    Sunday, October 20, 2013 4:11 AM
  • Hello, we are seeing the same issue during out testing. Did you manage to find a solution for this?

    Thanks

    Tuesday, October 22, 2013 4:59 AM
  • might be interesting to know on which server OS you are running the sccm server?

    and/or antivirus solution that you have

    Tuesday, October 22, 2013 7:00 AM
  • Our LAB site servers is on Windows 2008 R2, and we run McAfee solution.
    Tuesday, October 22, 2013 7:27 AM
  • Hi,

     I have a customer with the exact same problem, after I upgraded to R2 saturday.

    Everything worked fine Friday, now everything is at a crawl when downloading using BITS from WinPE.

    The setup is also in https mode (native), with working PKI infrastructure and valid certificates.

    What I've tried:

    1) Mapped a share on the DP from WinPE and tried copying the image using SMB.

    Result was full 80+Mbit on a 100mbit connection, so "full" speed.

    2) Tried booting from an pre-R2 boot ISO (WinPE 4.0 / CU2) and starting a TS.

    Result was download was at full speed, until the new WinPE 5.0 / R2 boot image was downloaded.

    3) Tried adding the old WinPE4.0/CU2 boot image to SCCM and using that.

    Result was crawling speeds again, but the boot image was WinPE 4.0.

    4) The customer has 2 DP's available - One running HTTPS Only and one HTTP.

    We see the error installing from both DP's.

    5) Tried disabling antivirus (SCEP) on the DP's - no change.

    6) Checked that TCP offloading was disabled on the DPs (tried changing it and rebooted) - No change.

    So it's not a WinPE 5 issue, it's not a driver issue as I can get the same results on WinPE 4.

    Seems like a change in the R2 components (OSDApplyOS.exe) causing this.

    We are also seeing the 100% CPU load from OSDApplyOS.exe on the VM's we have been testing on (Win8 Hyper-V + VMware Workstation 10).

    I did some network traces from the DPs when the slow download occured and found a lot of TCP SWS waits (5000ms pausses on each), which leads me to think it's maybe a buffer problem on the client in the osdapplyos.exe, since it also uses so much processing and not really receiving the amount of data, the server sends to it. Just a wild guess though.

    So you're not alone ;-)

    My customer has raised a case with PSS on this issue and given that we are apparently not alone with this issue, hopefully something will show up fast ;-)

    -Heine Jeppesen / Globeteam


    • Edited by Heine Jeppesen Tuesday, October 22, 2013 10:34 AM Added more info
    Tuesday, October 22, 2013 10:15 AM
  • Hi All,

    We are also experiencing the same issue after upgrading to R2.

    I can also see high CPU load from the (OSDApplyOS.exe) process.

    Nathan

    Tuesday, October 22, 2013 10:38 PM
  • Same here.

    Server info:
    Server 2012 RTM (not R2)
    SCCM 2012 R2 RTM

    Was a bit slow in SP1 also, but now it takes like an hour to download a 6 GB image and then it has to apply it also. Drivers/apps download really slowly as well.

    • Edited by Iroqouiz Wednesday, October 23, 2013 11:45 AM
    Wednesday, October 23, 2013 11:44 AM
  • We are having the exact same issue. The network speed in WinPE5.0 is utter crap after upgrading to R2.

    Tried with previous verions of bootimages without any luck, and tried adding drivers for Win.81 without any luck either.

    Disabling the SCEP client on DP's has no impact either - tried that as well.

    I'm all ears on this one - hope something comes up.


    Martin Bengtsson | www.imab.dk

    Wednesday, October 23, 2013 11:55 AM
  • Same Problem here after updating from SCCM2012SP1 CU1.

    first we tryed was to build the boot Images from scratch - didn't make any difference.

    It seems to be a problem with the Tools injected to the PE Images when importing or building by SCCM cause

    first after Updating to R2 the old Boot Images worked with full Speed but after re-deploying them same Speed decrease like with the new PE5 Images.

    The Download Process is awfull slow on anything downloaded when Client is in WinPE

    and we also experienced Problems with Packages not working anymore after the R2 update.

    Hope there will be soon a Hotfix for this issue.

    Wednesday, October 23, 2013 6:00 PM
  • I can confirm that I have seen this issue on 2 customers and in my lab now.
    Network speed is about 28Mbit during downloading of the WIM and if I change to at WinPE 4 image the speed goes up to 700Mbit instead.

    (FEP as antivirus system and Server2012/ConfigMgr2012R2/MDT2013)


    Wednesday, October 23, 2013 6:56 PM
  • Daniel - Can you open a support case with Microsoft?  The more people who engage PSS the faster we'll see a KB article and a fix.

    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    <-- If this post was helpful, please click "Vote as Helpful".

    Wednesday, October 23, 2013 7:46 PM
  • I saw very slow downloads of "everything" recently at a client who has ConfigMgr 2012 running, I didn't think we found the root cause of the issue, but they where happy with this as it did immediately fix it:

    http://blogs.technet.com/b/configurationmgr/archive/2010/06/03/solution-you-may-experience-slow-performance-when-using-bits-and-kerberos-authentication-on-configmgr-2007-distribution-points.aspx


    Rob Marshall | UK | My Blog | WMUG | File CM12 Feedback | CM12 Docs | CM12 Release Notes

    Thursday, October 24, 2013 1:01 AM
  • Hi Robert,

    I tried the Kerberos change with no luck - Also it works with a boot image from before R2, so I don't think it's a server issue.

    Thursday, October 24, 2013 8:05 AM
  • Kerberos should not be an issue here. Daniel's statement ("Network speed is about 28Mbit during downloading of the WIM and if I change to at WinPE 4 image the speed goes up to 700Mbit instead.") also seconds that.

    Torsten Meringer | http://www.mssccmfaq.de

    Thursday, October 24, 2013 8:23 AM
  • Ok, a temporary "workaround" (I wouldn't even call it that):

    I made my TS install the image from the DP instead of downloading it first. That cut down deployment time significantly. The rest of my TS is not very large in MB/GB so this kinda works for me at the moment.

    Thursday, October 24, 2013 10:16 AM
  • so the problem cannot be due to the server OS or antivirus it seems.

    but everyone who is experiencing it did the R2 upgrade, no clean installs?

    what about MDT 2013 integration, everyone also using that or not?

    Thursday, October 24, 2013 12:26 PM
  • update: upgrade or not: the speed seems to be equal

    I just tested on a clean build with server 2012 and sccm 2012 R2 rtm, with win8.1 32bit image

    I hope this gets fixed soon; have to start a migration project next week...

    Thursday, October 24, 2013 1:41 PM
  • If you have a method of engaging Microsoft Support, please do so.

    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    <-- If this post was helpful, please click "Vote as Helpful".

    Thursday, October 24, 2013 2:20 PM
  • I will submit a Microsoft case on it today.
    I'll keep you all posted :)

    // Daniel

    Thursday, October 24, 2013 6:34 PM
  • I'm about to open a case myself.  I loaded up procmon and everything going on is hash/crypto stuff.  Utter paranoia if you ask me.  Tried the kerberos thing above and it made no difference.  I only get 4-6% of the 1gig link when OsdApplyOs.exe is pegging the CPU but I can use SMB/http by itself and it's fine - 92-98% network utilization and my 7 gig wim downloads in 1 minute. 

    If you have powershell enabled in your boot WIM, you can test a plain HTTP download:

    $source = "http://fqdn.dp.local:80/SMS_DP_SMSPKG$/LAB00001/sccm?/WimFile.wim"
    $destination = "c:\WimFile.wim"
    $wc = New-Object System.Net.WebClient
    $wc.DownloadFile($source, $destination)

    that will use all of your bandwidth.  It's not a server thing, my guess is that it is the massive hash calculation it is doing while it is downloading.  However, it does a full hash check when it's done, so it's a complete waste in my opinion.

    Thursday, October 24, 2013 10:06 PM
  • I have tested plain SMB filecopy to WinPE5 and that works OK.

    So I am guessing some issue with BITS settings here..
    Has anyone compared the BITS settings between WinPE4 and WinPE5 yet ?

    (I suggest that you open a case you self aswell to speed up the urgency in this matter.)

    Friday, October 25, 2013 4:28 AM
  • Good to dismiss it Heine, funnily enough that Kerberos issue induces exactly the same issue, delays, so was worth punting out there, thanks for confirming.


    Rob Marshall | UK | My Blog | WMUG | File CM12 Feedback | CM12 Docs | CM12 Release Notes

    Friday, October 25, 2013 9:25 AM
  • " I know it's not the network stack because I can simply robocopy the 7gb WIM in 2 minutes or so." - SMB is ok, possibly BITS is slow? Run from DP also works fine, as mentioned in this thread.

    "it's also really bad downloading anything else too (Drivers, ConfigMgr Client) - http in general." - Now it is categorical, across the board, not specific to one object, is pointing at BITS again. Only issue I know from the past that sounds like this, that Kerberos issue.

    "So it's not a WinPE 5 issue, it's not a driver issue as I can get the same results on WinPE 4." - If this guy is right, his testing discounted WINPE versions?

    This is were the convergence ceases - now the comments start to shift away from Kerberos being the issue but it definitely looks like a server-side issue. It doesn't seem to be an issue contained in WINPE but an issue sitting on the server post-upgrade to R2 - " did some network traces from the DPs when the slow download occured and found a lot of TCP SWS waits (5000ms pausses on each)," is another indicator of a server issue.

    I'd engage CSS right away ...


    Rob Marshall | UK | My Blog | WMUG | File CM12 Feedback | CM12 Docs | CM12 Release Notes

    Friday, October 25, 2013 9:33 AM
  • Correction in Rob Marshall post

    It is seems to be WinPE5 issue because if I just change the bootmedia to WinPE4 then is the network speed is ok.
    SMB is ok on WinPE5 and WinPE4

    Again it is pointing to BITS withins WinPE5.

    // Daniel

    Friday, October 25, 2013 9:46 AM
  • I can confirm that we are seeing the same results in our environment. I hope a hotfix for this issue is released quickly as our deployment time has practically tripled. I'm considering going through the pain of rebuilding back to SP1 because of this...
    Friday, October 25, 2013 10:02 AM
  • I also noticed that downloading a wim image is very slow after upgrading from SCCM 2012 SP1 CU3 to SCCM 2012 R2.

    Looking at the IIS logfiles on the DP the difference I see with pre upgrade to R2 is that every HTTP GET results in a HTTP 200 followed by a HTTP 206 status code. (Partial Content).

    The rate limit of the DP is set to unlimited.

    Friday, October 25, 2013 11:20 AM
  • Just curious to know whether you guys apply latest ADK which was released on 17 or 18th Oct. I read on blog that files were updated in ADK.
    Friday, October 25, 2013 3:39 PM
  • I have tested both versions of ADK 8.1 with the same result

    Friday, October 25, 2013 4:54 PM
  • I'm about to open a case myself.  I loaded up procmon and everything going on is hash/crypto stuff.  Utter paranoia if you ask me.  Tried the kerberos thing above and it made no difference.  I only get 4-6% of the 1gig link when OsdApplyOs.exe is pegging the CPU but I can use SMB/http by itself and it's fine - 92-98% network utilization and my 7 gig wim downloads in 1 minute. 

    If you have powershell enabled in your boot WIM, you can test a plain HTTP download:

    $source = "http://fqdn.dp.local:80/SMS_DP_SMSPKG$/LAB00001/sccm?/WimFile.wim"
    $destination = "c:\WimFile.wim"
    $wc = New-Object System.Net.WebClient
    $wc.DownloadFile($source, $destination)

    that will use all of your bandwidth.  It's not a server thing, my guess is that it is the massive hash calculation it is doing while it is downloading.  However, it does a full hash check when it's done, so it's a complete waste in my opinion.

    I can confirm that the PS script above works ok and takes all bandwidth (90%) in WinPE5.
    I have verifed that this is not an NIC releated issue in my VMware Workstation 10.0.1 LAB as well.
    Tested these NICS and monitored the traffic with wireshark
    e1000e: Poor SMB traffic (lots of errors)
    e1000: SMB traffic ok
    VMXNET3: SMB traffic ok

    I also made a wireshark log of the WinPE4 traffic and the WinPE5 traffic during OS.wim download.
    Lots of "bad checksum" errors in the winpe5 log
    I have sent these logs to the MS support techie aswell.

    Running out of ideas now..
    I think it is time to wait to see what MS development team has to say about it

    Sunday, October 27, 2013 6:12 PM
  • Can we get someone from MS to chime in on this thread? I don't have an MS partner so I'm not sure what the best way to engage MS about this issue is other than following this thread for any new info
    Monday, October 28, 2013 2:32 AM
  • I have tested both versions of ADK 8.1 with the same result

    Hi,

    i'm facing the same issue. Reaching 50-60Mbit on a GBIT Network. Did you Reimport the Bootimage to SCCM after you installed the "updated" Version of ADK 8.1?
    I guess only updating is not enough, as the Image has already been imported to SCCM 2012 R2 and is not affected by the ADK update?


    Monday, October 28, 2013 5:19 AM
  • I have referenced my case at Microsoft to this thread already.
    I'll post a solution for the issue when I have a solution from MS

    Monday, October 28, 2013 5:32 AM
  • I don't think that it has anything to do with ADK 8.1 or the ADK 8.1 update. I have seen this issue in Hyper-v environment with the same result and only the ADK 8.1 (updated version) was used there,  but again with the same result.

    Is there anyone that have upgraded to CM12R2 that have a good http download speed of the os.wim around 800Mbit (on gigabit network) AND using WinPE5 ?
    Monday, October 28, 2013 5:40 AM
  • not everyone is getting the issue, (I am not seeing it). As regards versions of ADK make sure you are using the recently updated 8.1 ADK  as detailed in the comments of this post.

    "Also, note that the Windows 8.1 ADK prior to 10/18 will display in Programs and Features with product version 8.100.25984. The current Windows 8.1 ADK (posted on 10/18) is version 8.100.26020."



    Step by Step Configuration Manager Guides > 2012 Guides | 2007 Guides | I'm on Twitter > ncbrady

    Monday, October 28, 2013 5:53 AM
    Moderator
  • Hi Niall
    Thanx for you post

    All environment that I have seen this issue on is running ADK 8.1 8.100.26020

    Monday, October 28, 2013 8:18 AM
  • Same version here (8.100.26020), OS is Windows 2012 not R2. And the VM is running in Hyper-V.

    Fast downloads :-(


    Rob Marshall | UK | My Blog | WMUG | File CM12 Feedback | CM12 Docs | CM12 Release Notes

    Monday, October 28, 2013 9:02 AM
  • Noted, thank you!

    Rob Marshall | UK | My Blog | WMUG | File CM12 Feedback | CM12 Docs | CM12 Release Notes

    Monday, October 28, 2013 9:03 AM
  • We also have ADK .26020 in environments where the problem is.

    I spend the weekend Building a new lab, based on Server 2012 R2 / SQL 2012 SP1, new domain controller etc. and did a clean install of 2012 R2.

    I'm still seeing the problem in this environment. I tried both with HTTP and HTTPS modes, no change.

    Running a Procmon trace in WinPE when slowdown occurs, gives me 200.000+ registry read hits on various Cryptography keys within litterally seconds, so there's something strange going on for sure.

    Since the new lab is built for this purpose, we will be suggesting our PSS contact today to remote into it and use it for debugging, to get some speed on this case.

    PSS' response sofar has been, that they have not been able to reproduce the problem..

    -Heine Jeppesen

    Globeteam

    Monday, October 28, 2013 9:10 AM
  • Thanks for going to the trouble Heine,  I was going to do exactly the same thing this weekend to rule out being anything to do with Server 2012 vs. Server 2012 R2

    Our production setup is an in place upgrade to SCCM 2012 R2 running on Windows Server 2012, previously no issues at all on SP1, upgraded to R2 and ADK 8.1 and then the extremely slow wim download issue appeared.  Our deployment time has tripled and I'm scrambling for workarounds at the moment including deploying from USB sticks utilising Task Sequence Media.

    Lesson learnt to not upgrade so quickly in the future....

    Monday, October 28, 2013 9:22 AM
  • I have the same problem.... Running Windows 2012 R2 + SCCM 2012 R2

    Monday, October 28, 2013 12:39 PM
  • Same here as well running Windows 2008 R2 in a Hyper-V.
    Monday, October 28, 2013 2:07 PM
  • I'm seeing very slow WinPE boot image downloads with the following configuration:

    • Primary Site server / Distribution Point running on VMware ESX (not sure of version)
    • Windows Server 2012 R2 Primary Site server (and PXE-enabled Distribution Point)
    • SQL Server 2012 Standard Edition with Service Pack 1
    • System Center 2012 Configuration Manager Service Pack 1 (SP1) with Cumulative Update 3 (CU3)
    • IPhelper address configured
    • No PXE-related DHCP options configured
    • Lenovo ThinkPad T430 as the PXE client
    • 100Mbit connectivity from client to Primary Site server / PXE-enabled Distribution Point
    • WinPE 4.0 boot images have no customizations external to configuration through ConfigMgr

    If this post was helpful, please click the little "Vote as Helpful" button :)

    Trevor Sullivan
    Trevor Sullivan's Tech Room
    Twitter Profile


    Monday, October 28, 2013 2:44 PM
  • @Trevor Sullivan, I think your issue is different than the one this thread is about. This thread is dealing with SCCM 2012 R2 and the OS image download during the OSD, not PXE downloads on the boot image. This article should resolve your issue: http://windowsdeployments.net/how-to-speed-up-pxe-boot-in-wds-and-sccm/
    Monday, October 28, 2013 3:01 PM
  • I'm having the same issue with the following configuration:

    • Upgrade from SCCM 2012 SP1 CU2 to SCCM 2012 R2
    • Dedicated hardware (physical server for site server and other various roles, another physical server for site database role)
    • Using latest ADK for 8.1
    • Content download is dramatically slower. Some remote sites are reporting failures in OSD... although I haven't looked into this yet.
    Monday, October 28, 2013 3:04 PM
  • Kevin,

    Thanks for that link. I gave that a try, and it seems to help a bit, but overall it still seems pretty slow. It could just be the network link that the client has to the PXE-enabled Distribution Point, but I am not entirely sure. Either way, it is vastly improved with the help of the link you posted. Thanks again.

    Cheers,

    Trevor Sullivan


    If this post was helpful, please click the little "Vote as Helpful" button :)

    Trevor Sullivan
    Trevor Sullivan's Tech Room
    Twitter Profile

    Monday, October 28, 2013 4:21 PM
  • I'm also seeing this in my environment. My configuration prior to the upgrade was Config Mgr 2012 SP1 with MDT 2012 Update 1 integration enabled – Boot images were MDT WinPE 4.0 generated within the Config Mgr console with Dart v7. OS wim files etc downloading normally under WinPE. This was running on a fully patched Server 2008 R2 instance with local minimum SQL 2008 R2 level DB instance.

     

    My PXE enabled DP’s are also running Server 2008 R2. I had one instance of WDS failing on one of the DP’s after the upgrade, removing WDS and reinstalling the role corrected the problem.

     

    Upgrade path as follows:

     

    Uninstalled ADK 8.0 via add remove programs

    Installed ADK 8.1

    Installed MDT 2013 which updated the MDT 2012 Update 1 instance

    Installed Config Manager 2012 R2

    Re-ran MDT Integration following successful upgrade to R2

    Removed existing WinPE 4.0 boot images from distribution points and left them intact within the console

    Created new MDT 2013 generated WinPE 5.0 boot images and replicated to DPs

    Created new MDT 2013 files package in Config Mgr after upgrading my MDT deployment share

    Adjusted Task Sequences etc, etc (Did not create new ones, just modified existing ones as the new MDT 2013 TS appears identical)

     

    I do have the Dart 7.0 components in my MDT WinPE 5.0 boot images however I don’t believe this is related to the slow downloads within the PE environment. No other additional components have been added when creating the WinPE 5.0 boot images and I don’t have any additional files or pre-exec hook’s built into the boot images. Just standard MDT generated with the Dart 7.0 component.

     

    OS wim files were captured using MDT 2012 Update 1 (for Win 7) and MDT 2013 (for Win 8.1) with standard sysprep and capture TS. Source wim images built and captured using Hyper V on Windows 8 Enterprise.

    My Configuration Manager environment runs completely on physical hardware - no hypervizor. 


    Hope a fix is found soon!

     

    Cheers

    Damon

    Monday, October 28, 2013 7:51 PM
  • Apparently CSS has identified the issue - apparently it was neither boot image or network related. Work has begun on a fix but it may be a few weeks away from anything being publicly released......
    Tuesday, October 29, 2013 12:00 AM
  • Did you get a private fix?
    Tuesday, October 29, 2013 4:39 AM
  • There is no fix for it yet.

    I got this message from Microsoft support today in this matter
    "we have identified root cause and Sustained Engineering is going to start working on a hotfix. Basically the block size for how often the Task Sequence Progress bar updated was changed and it was updating much more frequently, causing the download the slow down significantly. I’ll provide more details as I have them. Engineers are working on to create a Hotfix and it make take few weeks before we can see the hotfix."

    Tuesday, October 29, 2013 8:46 AM
  • "... how often the Task Sequence Progress bar updated..."

    Wondering if unchecking this would help?!

    #justsaying

    Tuesday, October 29, 2013 1:43 PM
  • Doesn't work unchecking Show Task Sequence Progress - Progress bar is still shown in WinPE.

    I tried looping a script in the background to constantly hide the progressbar, didn't make any difference either.

    -Heine

    Tuesday, October 29, 2013 2:30 PM
  • FWIW, I have tested the following and found it to work without any poor download speed.  At the risk of stating the obvious I have tested the R2 OSD functionality using the SCCM 2012 Sp1 Cu3 client.

    server = 2008 R2 patched.

    Sql Server 2012.

    When I Ran the TS from the Software Center on a machine that had CU3, I noticed no issues.

    Subsequent Re-images after the machine had the R2 client (after dropping the image.) exhibited poor download speeds as described.

    I tested this on Virtualbox, with 2 cpu's and 2048mb of ram.

    Could someone please test/verify this hypothesis? Not upgrading the client to R2.

    Also, I noticed that I haven't "redistributed" the boot wim since the original install of sccm 2012 sp1. 

    Thank you.

    -V



    • Edited by VLEASUM Wednesday, October 30, 2013 3:18 PM
    Tuesday, October 29, 2013 4:59 PM
  • I experience the slowness even with a PXE boot, with no client or OS installed on the machine.  So I'm not sure how your scenario worked out.
    Tuesday, October 29, 2013 6:30 PM
  • Just wanted you to let you know that capturing a VM Testmachine also just take about 5% of a Gigabit Ethernet so it takes AGES to Capture a machine :)

    Hopefully Microsoft will push to fix that issue in a short amount of time cause this is stopping me to do "prod" with 2012.

    Regards
    Flat

    Thursday, October 31, 2013 11:16 AM
  • Just wanted you to let you know that capturing a VM Testmachine also just take about 5% of a Gigabit Ethernet so it takes AGES to Capture a machine :)

    Hopefully Microsoft will push to fix that issue in a short amount of time cause this is stopping me to do "prod" with 2012.

    Regards
    Flat

    Capture using MDT in the mean time.
    Thursday, October 31, 2013 12:26 PM
  • I've switched to using "Access content directly from distribution point" to skip the download section - on our gigabit network I apply a 8GB WIM in 5 mins. Only downside is that you obviously can't use multicasting with this enabled, not a big deal for us as we rarely mass-deploy a bunch of new machines all at once. I'm considering leaving this enabled even after the fix since this is actually faster than 2012 SP1.
    Friday, November 01, 2013 6:38 PM
  • Hope the patch comes soon otherwise OS Deployment is unusable... :-(
    Wednesday, November 06, 2013 9:46 AM
  • Hey

    From MSS:

    Thanks for your email.

    I am sorry but right now we do not have an ETA about the release of the hotfix.

    Since our product team is already working on it, I will not be able to provide you a specific time duration on this. <u5:p> </u5:p>

    However, as soon as it is released, I will inform you and provide you the hotfix.

    Regards,

    Wednesday, November 06, 2013 10:26 AM
  • A workaround, as someone else suggested here, is to have it install the image directly from the DP.

    This does require double up on the storage requirements for the image alone, but it works fine.

    On the image to deploy, go to the Data Access tab and check the Copy the content in this package to a package share on distribution points.

    This will copy the WIM file to a simple file share.

    In the Task Sequence, find the Apply Operating System task and on the Options tab, check Access content directly from the distribution point.

    Now the image, and only the image, will be directly from the DP over SMB instead of being downloaded first.

    Ofcourse any other data needed in WinPE, such as drivers, unattend XML file and boot images still needs to be downloaded over BITS.

    But since Microsoft claims the bug is in the progressindicator, these data shouldn't be affected to much, as they are relatively small files compared to an image.

    This is what we are doing now and can now move on with their testing.

    -Heine Jeppesen

    Globeteam

    Wednesday, November 06, 2013 10:47 AM
  • Ok that's a good suggestion! Thank you

    Best regards from Austria
    Wednesday, November 06, 2013 12:02 PM
  • Hi,

    An update is available for the OSD feature of System Center 2012 R2 Configuration Manager http://support.microsoft.com/kb/2905002


    Revue du Geek | Astuces pour déployer Windows 7

    Friday, November 08, 2013 11:49 PM
  • Thanks Martin,

    Hi All - I have applied this fix to our SCCM 2012 R2 environment.

    I can confirm we are now receiving full speed of the WIM download.

    Thanks to everyone who posted.

    Nathan

    Sunday, November 10, 2013 11:25 PM
  • Has anyone else managed to install this ok? I just tried and it got stuck stopping the SMS Executive Service...

    Also, its my understanding that this looks like it can be installed onto the primary server and there is no need push an updated client to any other servers or workstations. From what i understand to fix this slowness issue, id just need to specify the patch in the TS for Setup Windows and Configuration manager and update the DPs for the boot images.

    Im also wondering if i would need to recreate the MDT boot images i have created, rather than just update them as i assume only the standard default ones are actually updated by the patch...?

    Monday, November 11, 2013 11:36 AM
  • Just in-case anyone else has the same problem i was getting - the SMS_Executive service was not stopping due to Endpoint Protection which was installed onto the server. Disabling real-time protection enabled the install to carry on as normal....
    Tuesday, November 12, 2013 12:03 PM
  • For anyone having issues with SCCM R2 CU3 and WinPE 5 / Windows 8.1 deployments.

    Issues encountered:

    1) WDS service crashing

    AND/OR

    2) Slow download / imaging

    HOTFIX:

    Go to support.microsoft.com - KB2905002

    Wednesday, November 13, 2013 9:42 AM
  • Is it me, or did MS remove the option to download the Hotfix? The "download hotfix" button is long gone. Wtf :(


    Martin Bengtsson | www.imab.dk

    Wednesday, November 13, 2013 1:52 PM
  • Its not you, its not there for me either. Wonder why they would have done this.... 
    Wednesday, November 13, 2013 2:30 PM
  • Its not you, its not there for me either. Wonder why they would have done this.... 

    Best bet: new obstacles from applying the hotfix. Guess I'm back to waiting :-(

    If anyone else knows something, please share - i was looking forward to getting this fixed.


    Martin Bengtsson | www.imab.dk


    Wednesday, November 13, 2013 2:37 PM
  • It seems This is still available via premier site

    Anoop C Nair - @anoopmannur :: MY Site:  www.AnoopCNair.com :: FaceBook:  ConfigMgr(SCCM) Page :: Linkedin:  Linkedin<

    Wednesday, November 13, 2013 3:03 PM
  • And the button is back - weird.

    Martin Bengtsson | www.imab.dk

    Thursday, November 14, 2013 7:29 AM
  • Could someone please let me know if after applying this update to my primary server I should be using the package it creates and updating the sccm client on all my workstations and servers also? Would it have negative effects if i don't?
    Friday, November 15, 2013 11:29 AM
  • Could someone please let me know if after applying this update to my primary server I should be using the package it creates and updating the sccm client on all my workstations and servers also? 

    Yes, I would recommend to apply the hotfix on to the clients as well. When I applied the hotfix to client, the Task Sequence engine got updated to 5.0.7958.1101. So client site update is also recommended. Also KB articles states you need to update boot images (custom and default) and need to create fresh offline media etc..

    Also, I've noticed that Offline media creation DLL file got updated Createtsmediaadm.dll  5.0.7958.1101. Some more details in the blog post here


    Anoop C Nair - @anoopmannur :: MY Site:  www.AnoopCNair.com :: FaceBook:  ConfigMgr(SCCM) Page Linkedin:  Linkedin<


    Friday, November 15, 2013 1:27 PM
  • Yeah it looks like they fixed more than I originally thought. I hate that this wasn't in RTM but glad it took only 3 three weeks to fix. Downloads of the WIM files now take seconds instead of an hour. I also see better results with task sequences but I need to do more testing to explain that.
    Friday, November 15, 2013 1:53 PM
  • it took a while to stop smsexec but did install ok.  if your goal is only to fix the slowness then the hotfix *should* do that.  It fixed the slow download for my test site, however it introduced a slow upload when capturing images...  It now uploads around 200KB/s
    Friday, November 15, 2013 3:20 PM
  • Nick: I have seen the slow capture when the SCEP client was enabled on the site server. Try to disable the real time protection. It had a major impact in my environment.


    Martin Bengtsson | www.imab.dk

    Friday, November 15, 2013 3:24 PM
  • Hi

    Applying the hotfix solve the problem with the slow Wim download.  However, It is still very slow at section where the sccm client gets installed.

    I see in the description .  to fully fix the problem is issue 2, the client side .msp file has to be installed during the Setup Windows and ConfigMgr task by using the PATCH= command.  I really don't understand what I have to do.  I suppose it would solve the last problem we have with R2.  Greetings

    Friday, November 15, 2013 3:35 PM
  • Hi

    Applying the hotfix solve the problem with the slow Wim download.  However, It is still very slow at section where the sccm client gets installed.

    I see in the description .  to fully fix the problem is issue 2, the client side .msp file has to be installed during the Setup Windows and ConfigMgr task by using the PATCH= command.  I really don't understand what I have to do.  I suppose it would solve the last problem we have with R2.  Greetings


    have a look at this post: http://www.imab.dk/configmgr-2012-client-update-during-osd/

    Martin Bengtsson | www.imab.dk

    Friday, November 15, 2013 3:38 PM
  • I see in the description .  to fully fix the problem is issue 2, the client side .msp file has to be installed during the Setup Windows and ConfigMgr task by using the PATCH= command.  I really don't understand what I have to do.  I suppose it would solve the last problem we have with R2.  Greetings

    Or this one: http://deploymentramblings.wordpress.com/2013/08/22/installing-configmgr-2012-sp1-cu2-during-osd/#comments
    Friday, November 15, 2013 3:46 PM
  • We've had our host-based protection disabled for a while to minimize problems with the test install.  I tried capturing to a remote server and it did improve, but is still about 1/2 the speed I was seeing last week on the local machine.  capturing locally was much faster last week as it was just taking data off one SAS 15k disk and writing it to another.

    Does 2012 r2 install scep by default?  when I check the client folder the installer is sitting at the root, and when I check the client settings on the primary site (administration, client settings, default client settings, endpoint protection) it looks like it is set to install, but is not managed.  All options are greyed out.  If it is installing this would not be good for those of us who already have AV/host protection services.

    Friday, November 15, 2013 4:36 PM
  • > Does 2012 r2 install scep by default?

    Installing a Management Point (for any version of CM2012) will also install the SCEP agent, but will leave Real Time Protection and Scheduled Scans off by default.

     


    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    <-- If this post was helpful, please click "Vote as Helpful".

    Friday, November 15, 2013 4:38 PM
  • I have applied the hotfix in our prod environment which has also corrected our slow downloading issues. 

    1. Applied hotfix on Primary and restarted

    2. Deployed client hotfix packaged to all existing clients

    3. Deployed console hotifx package to computers running the console

    4. Regenerated WinPE 5.0 MDT integrated boot images and replicated

    5. Set which boot image my Task Sequences would use

    6. Created new Configuration Manager Client package with hotfix directory and sub files

    7. Adjusted Task Sequences to include patch property

    I used this as a base guide for my installation and adjustments

    http://blogs.technet.com/b/configmonkey/archive/2013/11/13/deploying-configmgr-hotfixes.aspx

    Cheers

    Damon

    Sunday, November 17, 2013 7:45 PM
  • Hi,
    Now that I've applied KB2905002 and updated client, boot images etc, my image process is a lot faster again for most of the task. HOWEVER, it is still very slow at Apply Driver Package step.

    After that step has completed, everything is speedy again. It does not matter which computer model it is in the task, they are all slow at downloading - as in around 1 hour to download.

    The step in the task is just a WMI query on that model computer.

    Anyone else having the same issue?

    ***

    Think I might make a new post....

    • Edited by askzxy Monday, December 02, 2013 5:02 AM
    Monday, December 02, 2013 5:01 AM
  • Since you've updated your boot media after applying KB2905002, this is likely another issue.  You may want to open a support case with Microsoft for help troubleshooting the performance problem.


    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    <-- If this post was helpful, please click "Vote as Helpful".

    • Proposed as answer by Theo_Theodorou Wednesday, March 12, 2014 4:14 AM
    • Unproposed as answer by Theo_Theodorou Wednesday, March 12, 2014 4:14 AM
    Monday, December 02, 2013 6:48 PM