10 Replies Latest reply on Sep 30, 2015 6:36 AM by gwhitt

    Bandwidth and provisioning

    Rookie

      We've been having issues with imaging taking a long time even when multicasting. Landesk does not seem to be using all of its available resources and our network monitoring although limited always shows plenty of overhead. Is there a bandwidth control somewhere specific to provisioning. As a side note on a small scale like 6 computers single computer imaging seems faster but of course that will eventually lead to maxing out bandwidth to an area. As far as hard numbers Im seeing an image take 6 hours to multicast to 18 computers and utilization at our smallest known chokepoint never going above 40% and even then that was only while the multicast master was getting its initial image.   Any ideas on things to check.

        • 1. Re: Bandwidth and provisioning
          Kenyon Expert

          The default delivery method for a scheduled provisioning task is "Standard policy-supported push distribution" which is set at 50% bandwidth. If you PXE boot the default is "Allways listed for installation" which is set at 25%.

          Capture.JPG

          Capture.JPG

          1 of 1 people found this helpful
          • 2. Re: Bandwidth and provisioning
            Rookie

            Scaled this all the way to 100% no change so far 16 computers are still going 6 hours later It took 2.5 hours for the multicast master to finish caching but nothing was even close to maxing out it's networking bandwidth. It would seem they probably won't finish for another hour or two. The preferred server has been shown to output an image file copied via windows explorer at 3gbps the monitor hasn't gone above 300mbps today and traffic to that switch is only a little higher. Still no luck in making this run at an acceptable speed compared to traditional multicasting.

            • 3. Re: Bandwidth and provisioning
              Kenyon Expert

              Multicast is also throttled by packet delay as well as bandwidth. Multicast will only be as fast as the slowest machine in the communication as all machines have to receive the packets at the same rate. Test a single machine unicast first and make sure the selected delivery method is st at 100%.

              • 4. Re: Bandwidth and provisioning
                Rookie

                Eventually the multicast rep automatically rebooted and the rest according to data traffic logs just defaulted to pulling from the source and saturated the link to that switch. Still waiting on a single image to that location to complete.

                • 5. Re: Bandwidth and provisioning
                  Kenyon Expert

                  Standard Multicast has a bad reputation for flooding a network so for this reason LANDESK built in a packet delay. How many machines are you wanting to image simultaneously?

                  • 6. Re: Bandwidth and provisioning
                    Kenyon Expert

                    One other solution you could consider is utilizing Preferred Server for remote locations.

                    • 7. Re: Bandwidth and provisioning
                      Rookie

                      Right now I am running a testbed of 16 computers but we need to be able to scale up to labs of at least 50 computers and we do have preferred servers per site but we can't exactly have one per switch. Also I can't figure out why the multicast rep would have rebooted to windows before the session completed.

                      • 8. Re: Bandwidth and provisioning
                        Kenyon Expert

                        You might be thinking about the PXE rep as there is no need for a separate preferred server per switch. An IP address range can also be specified in the preferred server settings. As for troubleshooting why the multicast rep rebooted you could try looking at log files on the machine. Start by looking in the x:\ldprovision directory. This directory is deleted before the reboot so it may not exist anymore. If the directory no longer exists you will be out of luck as far as if any details in this location will have been lost.

                        • 9. Re: Bandwidth and provisioning
                          Rookie

                          Okay a unicast computer took 2 hours to complete the multicast to 16 took 9-10 hours. The frustrating thing is traditional multicasting was taken out in 9.6 when we used to use multicast in ghost it would take maybe 20% more than a single unicast to do 30-40 computers. Even when you consider 2 hours for image to go to the rep at worst total we should be looking at 4 hours it would seem?

                          • 10. Re: Bandwidth and provisioning
                            Rookie

                            Issue was related to a few computers in the group that were at 100mb connections due to faulty wiring in the walls and they were getting chosen as the rep. Because of the way the rep works it cant even use the full 100 because it is both sending and receiving the image making this a lot slower than traditional multicasting. We also ran into and issue with the rep rebooting before the rest of the computers were done receiving but it only happened when it was taking the 9 or 10 hours. In a full gig set up it has yet to do it.