Jump to content

Recommended Posts

Posted

Have managed to get my 2012 server up and running with MDT using WDS for PXE booting clients. Works a charm on my 2 test machines using Unicast but when I enable Multicast and try it then the deployment goes from 25 minutes for both machines to over 2 hours for same image same machines.

 

Server and clients are all connected to core switch (which has IGMP enabled). I havent enabled IGMP on any of my other switches yet.

 

I have googled and the only info I can find is about reducing the APBlockSize. In WDS for Server 2012 it is already set low by default.

 

When Multicasting the Transfer rate jumps around from 54KBps to 4000KBps.

 

I have split the WDS setting so that clients are split into 3 sessions (slow, medium & fast) but both clients jump transfer rates at the same level.

 

I am getting closer to the point where I need to start imaging whole IT Suites so I need to get Multicasting sorted.

Posted

Same issue here, many google searches state the same; that unicast is far faster than multicast (up to a certain amount of computers being deployed).

 

For now, we just cancel the multicast and deploy via unicast...

Posted
Same issue here, many google searches state the same; that unicast is far faster than multicast (up to a certain amount of computers being deployed).

 

For now, we just cancel the multicast and deploy via unicast...

 

How big is your image? How long does the imaging take with Unicast?

How many have you tried with unicast in one go?

Posted

Have you any unmanged switches/hubs floating around on your network anywhere?

 

When I was multicasting in the summer I disconnected parts of the network with any unmanaged networking device on (not my doing, still trying to replace with managed stuff) and it boosted the speed no end. There was one client in one room for some reason that slowed the multicast for whatever reason, just disconnected that one and did it seperately from the rest.

 

Might be worth disconnecting parts of your network from the core to see if you can narrow down any particular area that's causing a problem during a multicast?

Posted
Have you any unmanged switches/hubs floating around on your network anywhere?

 

When I was multicasting in the summer I disconnected parts of the network with any unmanaged networking device on (not my doing, still trying to replace with managed stuff) and it boosted the speed no end. There was one client in one room for some reason that slowed the multicast for whatever reason, just disconnected that one and did it seperately from the rest.

 

Might be worth disconnecting parts of your network from the core to see if you can narrow down any particular area that's causing a problem during a multicast?

 

There are a couple in other buildings but if the clients and WDS server all connected to same igmp enabled switch surely the switches in the other areas shouldnt affect it?

Posted
There are a couple in other buildings but if the clients and WDS server all connected to same igmp enabled switch surely the switches in the other areas shouldnt affect it?

 

I thought this, but it just about brought the network to it's knees when doing multicasting. Maybe I don't have it configured right, but the unmanaged stuff was throwing all the multicast traffic back into the network as broadcast unicast (I think), so would be worth checking out.

Posted

there is a patch from MS to resolve this issue. A friend had exactly same same issue and eventually found a hotfix.

 

I will try to get the kb

Posted
This is the KB Dean was referring to: Multicast Deployment Fails from Windows Deployment Services (WDS) - worth a look.

 

 

Also, just out of curiosity, you don't happen to have Hyper-V installed with a virtual switch configured for the VM's do you?

 

This is what I was referring to in my original post about the APBlock size. On 2012 its already set low.

 

I do have Hyper-V with a virtual switch set up but not on the WDS server.

Posted

Does this mean that MDT2012 running as a Hyper-V VM cannot support Multicast using a Virtual Switch?

 

If so, would that explain why we always use Unicast as Multicast takes many. many times longer?

 

Thanks

Posted
We noticed an issue that when Hyper-V was using the same NIC via a virtual switch that the MDT server was using for deployment, the speeds were very slow. It could be a possibility MYK-IT - based on our experience.
  • 9 months later...
Posted

HI there,

 

We're having similar issues, our server (server 2012 with MDT 2013) is a VM running on vmware 5.0 and the multicast is very slow. Is multicast not recommended on servers that are VM?

 

Thanks,

 

Ash.

Posted

I found it was very reliant on the virtual nic. I think ESX has a few you can try. We use hyper v here and we had to change this registry entry

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSMC\Protocol]

 

"TpMaxBandwidth"=dword:00000001

 

Its set too 100 (decimal) by default. Which is fine if your clients have the same nic speed as the server. After dropping it to 1 we had less errors as the wds/mdt server was sending packets to the network at 100mbps rather than 10gbps. In testing using esx I had to change to use a emulation nic. The thing with multicast is that it needs to work with your slowest client usually 100mbps.

  • Thanks 1
  • 1 year later...
Posted

I haven't tried free780's reg edit, but have done some experimentation with the WDS server multicast settings.

 

Using MDT/WDS running on Hyper-V, and just one physical client.

 

Unicast speed: 17MB/s

multicast (separate clients into three sessions (slow, medium fast)): between 17-22MB/s (even with just one client)

multicast (keep all multicast clients in a session at the same speed): 2MB/s

 

After the 1-session multicast, I put it back to 3-session and the speed was still 2MB/s. I restarted WDS, tried again, and the speed went back up to about 17-22MB/s

 

It seems that WDS is making decisions about what speed a client should get and sticking to that.

 

Anyway, for me, letting WDS use 3 sessions had best results, even faster than unicast.

  • 1 year later...
Posted (edited)

Over, your info is interesting. I am experiencing the slowness problem with our MDT 2013 (6.2.5019.0) WDS 8.100.26629, running on VMware Virtual Host with Win Server 2008 R2 Standard platform, and this just started occurring recently. I have not been able to pin-point the problem yet. Regarding your comments on "letting WDS use 3 sessions had best results", is this an internal setting within WDS or is this a server setting? Can you direct me to where I can change this?

 

I appreciate your response.

Edited by GovMule
Posted

Thanks BosPete, are you referring to the Multicast tab of the server Properties window while in the Windows Deployment Services utility? If "yes", then I think I see what you referred to, the "Separate clients into three sessions(slow, medium, fast)" ""Separate clients into two sessions(slow, fast)". Mine is set for "keep all multicast clients in a session at the same speed".

 

Working with some of my network server brethren and one of our Network Engineers, we found another, different Multicast setting under the DeploymentWorkbench utility when invoking the properities of the "MDT Deployment Share" in the Deployment Workbench->Deployment Shares->MDT Deployment Share (C:\LTI)" object the General tab shows a check box to Enable multicast for this deployment share(requires Windows Server 2008 R2 Windows Deployment Services) We UNchecked(disabled) this and now my 11GB WIM images take about 20min. start-to-finish!

I have no idea whey this occurred in the first place or why this works. I have not piled 20 computers onto my KVM and core switch to image them yet so it remains yet to be seen if this ultimately fixes the problem.

 

Thank you for your input.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...