5 Replies Latest reply on Apr 22, 2014 7:36 AM by MarXtar

    Best practices for multicasting?

    Rookie

      Hello,

       

      First off, here are a few details of my site.

      Version: LANDesk Management Suite 9.0.3.1

      30,000+ pc's running Win7

       

      I understand each organization has its own needs, but is there a general best practice in regards to large multicast deploys?

      We currently have guidelines in place that I think our outdated.

       

      Example of deployment to 10,000 pc's with a 500MB package

       

      - policy supported push used

      - # of devices for distribution = 61

      - bandwidth, WAN = 25%, LAN = 75%

      - max # of MDR = 5

      - max # of failed multicast to process = 240

      - # of days to cache locally and on MDR = 14

      - # of install tasks used = 20

       

      A typical deployment would consist of multiple install tasks with no more than 500 pc's in each.  This is what I am challenging.

       

      The logic behind this decision was the # of potential calls to our service desk if something goes wrong with the deployment.

      If I had only used 2 tasks of 5000 vs 20 tasks of 500 and something went wrong (whether it be LANDesk or the package itself), our service desk would be inundated with calls.

       

      The only benefit I see to having more tasks is that you have more MDR's and the distribution goes faster, but also adds more strain to the network.

      In almost all cases, issues arrising from a deployment are not caused by LANDesk itself, so I don't see the benefit of multiple tasks.

      Many of the deployments we do are much smaller than 500MB. 

       

      Are there any gurus out there that can either validate this or recommend a better/best practice?

       

      Thanks,

       

      DS

        • 1. Re: Best practices for multicasting?
          rictersmith Specialist

          I think this is going to depend greatly on your enviornment and the experience of those from various enviornments.

           

          Just looking at what you wrote, I'm curious if using an initial multi-cache cache only job well in advance to predepoy all of your install files slowly might be the best way for you to start.

           

          Then create a second push job that will run the files already in the cache.

           

          We personally do not create multiple tasks over and over again. Instead we will link the task to a query. If you had some sort of custom inventory data linked to specific buildings or geographical locations, or even network subents, you could just update the query each time, and rerun the job on all devices that had failed to run the task. It would not re-try the succesfull ones.

           

          We do this so that we also pick up a remediation along the way. Some times we will not do it, incase the remediation devices just keep failing and slowing things down because they are always offline or something.

           

          The other option would just be to keep grabing a set of 500 devices and add it to your existing task.

           

          I might just be really tired, but I am not sure why you are creating multiple tasks for your jobs. Multiple tasks I dont thinkg gives you multiple MDRs per subnet. You still only get 1 MDR per subnet, as far as I know.

           

          Also are you using preferred servers at the various locations? This would also cut down on bandwidth across the WAN or other networks if you had several perferred servers that devices could pull from and might help in the scenario where if you had used cache only and a device failed to recieve it, then it failed a peer download it would go back to a preferred server before trying the source or core.

          • 2. Re: Best practices for multicasting?
            MarXtar ITSMMVPGroup

            It sounds like this model you have is simply to reduce calls to the service desk if something goes wrong with the installation. There is nothing specific you have listed that would mean LANDESK needs to have multiple tasks.

             

            I think it would be worthwhile as suggested to do a download only job that does multicast and also if the machiens fail will use unicast to download to the cache. If you have the bandwidth controls so that only one device per subnet can download from source and also set decent throttling, then as suggested you could do a much larger job to cache in advance.

             

            In theory this job could deploy the software to everyone with no more load than if you had multiple tasks.

             

            A couple of possible scenarios to consider either way:

             

            1 - If you do one large distribution/cache only job, if your subnets are not in a hub and spoke model then you could have multiple downloads across WAN links happening at the same time from the master source. This can be offset by a mixture of bandwidth throttling and perhaps preferred servers

             

            2 - In your existing model, any overlapping of distribution tasks that do multicast can cause systems to drop out of the job because the multicast jobs clash. This 'might' have led somebody to create this model. In short, only have one major multicast job running at any one time to avoid clashes.

             

            It definitely lends itself to an architecture and best-practice discussion for what best suits your environment and the types of activities you do.

             

            The idea of caching and then controlling deployments site by site might be a good one if you want to manage calls to the service desk.

             

             

            Mark McGinn

            MarXtar Ltd/MarXtar Corporation

            http://landesk.marxtar.co.uk

            LANDesk Expert Solution Provider

             

            Update - New v2.3 Adds Process Monitoring & Historical Analysis for Concurrency and Device Based

            Update - New v2.3 Now with Automated Subnet Rep Selection and Optional Maintenance of LANDESK Reps

             

            The One-Stop Shop for LANDesk Enhancements

            - Wake-On-WAN - Distributed Wake-On-LAN, Scheduled Power Down, and SWDist   Sequencing

            - State Notifier - Real-Time Device, User State and Process Monitoring. Inventory   Updating, Alerting & Historical Analysis

            1 of 1 people found this helpful
            • 3. Re: Best practices for multicasting?
              Rookie

              Thanks for the reply.

               

              I should clarify that we don't re-use tasks over and over.  Once a specific job is complete we delete them.

               

              Ideally what I would like to do is create a single task and drop my query into it (regardless of the # of targets).

              Currently I would break out these targets by subnet to keep the groups less than 500.  That would result in the multiple tasks.  By the end I could have 15-20 install tasks instead of just 1.

               

              My understanding of multicasting leads me to believe that LANDesk is capable of handling very large numbers and if configured correctly, will deploy in the most efficient way possible.

               

              In regards to the MDR comment.  You can adjust the # of MDR in the properties section of the deployment method.  So technically each task is its own entity.  If my MDR limit is set to 6 and I have 20 tasks, I should have 120 MDRs.

               

              Thanks,

               

              DS

              • 4. Re: Best practices for multicasting?
                Rookie

                You are correct.  This method of doing things is all about impacting our service desk.

                I have personally never come across an issue that was directly related to LANDesk.  Install issues are usually caused by a packaging error or something on the client end.  But somewhere, someone got the idea that 500 was the magic number.

                MarXtar wrote:

                 

                 

                It definitely lends itself to an architecture and best-practice discussion for what best suits your environment and the types of activities you do.

                 

                You nailed it there.  I think the best way to approach this is with someone on the architectural side.

                There is probably not a single right answer to this question.

                 

                Thanks,


                DS

                • 5. Re: Best practices for multicasting?
                  MarXtar ITSMMVPGroup

                  If you are heading over to Interchange next month then it might be worth registering for session 719 on the wednesday morning - "LANDESK Infrastructure Design -- How to Scale". Even if the topic doesn't cover your specifics it would be a good opportunity to network with other larger organisations to discuss how they approach this sort of thing.

                   

                  Maybe see you there.

                   

                   

                  Mark McGinn

                  MarXtar Ltd/MarXtar Corporation

                  http://landesk.marxtar.co.uk

                  LANDesk Expert Solution Provider

                   

                  Update - New v2.3 Adds Process Monitoring & Historical Analysis for Concurrency and Device Based

                  Update - New v2.3 Now with Automated Subnet Rep Selection and Optional Maintenance of LANDESK Reps

                   

                  The One-Stop Shop for LANDesk Enhancements

                  - Wake-On-WAN - Distributed Wake-On-LAN, Scheduled Power Down, and SWDist   Sequencing

                  - State Notifier - Real-Time Device, User State and Process Monitoring. Inventory   Updating, Alerting & Historical Analysis