5 Replies Latest reply on Apr 9, 2014 10:51 AM by rictersmith

    Policy Supported Push - Simultaneous Distribution Limits

    zman Master

      So more of a question/poll. As our shop continues to grow, I've been pondering the fixed limit of 240 devices that a policy supported push can manage simultaneously. With the server and network infrastructure advancements, I'm wondering if this should be increased. Long policy pushes are taking an increasing longer to finish. I believe this should have a higher limit that we should be able to set based on our core architecture. What's your opinion?

        • 1. Re: Policy Supported Push - Simultaneous Distribution Limits
          MarXtar ITSMMVPGroup

          Honestly, I want to see this mechanism changed so that the core tells the client to initiate and then the client continues without the core needing to stay connected, similar to the way provisioning works. I particularly want to see this with multicast jobs so that the multicast job also copies down the instruction on how to execute the task rather than having to then deal with a unicast connection to initiate the installation and losing a lot of the benefit that multicast gave us.

           

          Mark McGinn

          MarXtar Ltd

          http://landesk.marxtar.co.uk

          LANDesk Silver ESP

           

          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 Inventory Updating & Alerting

          • 2. Re: Policy Supported Push - Simultaneous Distribution Limits
            zman Master

            So the distributing processing of tasks is always brought up and nothing is ever done. I think you would still have a spinner for the amount of devices to handle simultaneously processing (there would be traffic between client and core, and distribution traffic client to peer, or package server). Good points, but I don't see this anytime soon. I think the current architecture is showing its age and scalability.

            • 3. Re: Policy Supported Push - Simultaneous Distribution Limits
              MarXtar ITSMMVPGroup

              I agree, just doesn't make sense to me that the core should wait for the whole thing to finish, we could still have limits on how many could be instructed simultaneously when using unicast, but the rolling window would be far quicker, and the load on the core far lower so that the window could be far larger. Upload of status to the core can be handled relatively easily since cores are able to handle large quantities of this data when doing vulnerability scans, even with large distributions this should be a much lower load than that and it doesn't absolutely have to be realtime.

               

              With multicast it just seems daft to me (has done since it first got released) that we can distribute simultaneously to over 10,000 machines but it could still take hours to install because we can only have small blocks of them actually installing what we gave them.

               

              Mark McGinn

              MarXtar Ltd

              http://landesk.marxtar.co.uk

              LANDesk Silver ESP

               

              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 Inventory Updating & Alerting

              • 4. Re: Policy Supported Push - Simultaneous Distribution Limits
                zman Master

                Yep. My concern with the limits is not on the core side but other ancillary IT infrastructure (package servers, local/wide network links, etc...) So the setting could be global or per tasks - on (set limits)/off.  ot sure why they have to keep that pipe open during actions. With software sizes and installation times expanding, patching cycles increasing, etc... there is no need.

                 

                I would put in an ER on this but those are just plain useless. I prefer offloading from the core, that's why I recommend LSTs so much, just think like you that it should be totally overhauled.

                • 5. Re: Policy Supported Push - Simultaneous Distribution Limits
                  rictersmith Specialist

                  ZMAN - Thanks for this post. I was actually looking you up and oddly enough found this as the first link in your profile, because we are getting frustrated with slow Push jobs. Even jobs where we have already multicast the installation files locally to all of the target devices so that we can shorten  the installation window.

                   

                  For example, we are now on 9.5 SP2, a super beefy new core and a pretty good network\server infrustructure.

                  Multicast Cache-only all of the files to 101 devices, not a large set by any means. All devices were validated as having the files in their sdmcache.

                   

                  That night, we started our PUSH job to 77 devices. An hour later we see the first signs that a device is starting to process (task log file in the local data folder) an hour later? Really?

                   

                  It took about 5 minutes to validate the 5 files already cached on the system. Each install took about 20 minutes. 2 hours after starting the job, we are at 44 success and 7 failures and 26 Active showing  'multicast in process'. Looking at the local client log files, there isnt even a task for the PUSH even created yet. Something odd going on here, to which we are engaging our TAM. Wondering if anyone else is seeing similar issues though.


                  Which really brings me to what I was really curious about if anyone had any better templated distribution methods for larger enviornments with better networking support.