Here are problems I remember running into that can cause downloads from DPs to go slow.... My details are all sketchy, sorry.
Does your network support IPv6? If not, do you have it disabled on your servers? If you have IPv6 enabled on your servers and they have registered their IPv6 address in DNS then WinPE will attempt to connect over IPv6 first and then fall back to IPv4. The timeout is ~30 seconds if I recall. You could check this if you open a dos prompt (F8) and ping the DP. Does it try to do a IPv6 ping. Set your servers to not use IPv6 so they DNS won't give out IPv6 addresses. In full Windows, you can set the Registry to prefer IPv4, but I don't think you can do that in WinPE. Another thing I have seen is that with BITS, there was a setting about session authentication vs needing to authenticate every file or block. I don't remember all the details of this, but it had something to do with needing to send reauthentication hundreds of times to download one package. There is a setting to say to use session based authentication. Maybe someone else remembers this problem? I only recall vague details. I am not sure if SCCM 2012 now sets DPs correctly to get rid of this problem. This looks like it discusses what I mean http://blogs.msdn.com/b/benjaminperkins/archive/2011/10/31/kerberos-authpersistnonntlm-authentication-request-based-vs-session-based-authentication.aspx You could try setting your DPs to "allow clients to connect anonymously" just temporarily and see if it helps - that would mean it is some problem with credentials like above. Like it tries Kerberos first and has to timeout to get back to NTLMv2 or something... There is a fix for this, but again details are foggy. You might look in the IIS logs of your DPs to see if there are errors or anything weird. Maybe your network guys have seen a lot of traffic to your DPs and throttled the connection. Don't discount the idea that outside forces are conspiring against you. You could be flooding your data center firewall - that is especially true with that authentication thing I mentioned above. From: [email protected] [mailto:[email protected]] On Behalf Of Stephen Owen Sent: Wednesday, February 05, 2014 4:48 PM To: [email protected] Subject: Re: [mssms] After installing slow OSD KB in R2, it is still slow? Did I miss something? Could you recommend any troubleshooting steps or tools to use to try to isolate the issue? Image downloading, MDT Package Download and any data transfer are all incredibly slow. On Wed, Feb 5, 2014 at 1:29 PM, Jason Sandys <[email protected]<mailto:[email protected]>> wrote: The hotfix only addressed the actual OS image downloading slowly. Boot images come down via TFTP and the other content comes down via the normal content distribution process and BITS. If you are seeing slow download times on multiple different methods (as you've described), you've got other issues. J ________________________________ From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Stephen Owen <[email protected]<mailto:[email protected]>> Sent: Wednesday, February 5, 2014 11:53 AM To: [email protected]<mailto:[email protected]> Subject: [mssms] After installing slow OSD KB in R2, it is still slow? Did I miss something? Downloading the WinPE image, downloading the toolkit package, all still taking forever to download. I recreated the WIM after installing the OSD fix, and applied it to the CAS and each primary. Do I need to restart SCCM or WDS or anything else? ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________
