5 Replies Latest reply on Aug 8, 2012 5:52 PM by lonniesohm

    Provisioning application caching extremely slow

    Rookie

      I am hoping someone can help me with this, as I am flummoxed.

       

      We have LDMS9 SP3.  I have been setting up provisioning for Bare Metal brand-new-out-of-the-box computers within our corporation.  I have built all my applications and tested them through the Software Deployment Portal, and they all now work flawlessly.  I have provisioning working just fine; thin Win7 OS image, HII, 'Mapped' resource to the applications directory, provisioning applications, domain join, then running a security/patch scan and install.

       

      The problem is, for our larger applications that I just added that require I build the 'Distribution Package' with the 'Additional Files' - like MS Office and Autodesk TrueView - when provisioning goes to install those applications it caches them locally first, but at an unbelievably slow rate.  Like as low as 1MBPS at times over my gig connection.  SLOOOOOOW.  TrueView is so slow (at over 800mb) that provisioning eventually just times out and closes.

       

      I have 'Mapped a resource' to be able to run the applications from their location on the network.  When I run the applications through the Software Deployment Portal, they cache and install in minutes.  Those machines are existing machines joined to the network already, but should that make a difference?  I have tried joining the provisioned machines to the domain before the applications push, but that doesn't help either.

       

      I did find a post regarding a version of LDMS8 that suggested there was a file that didn't get updated, but that doesn't seem to be the case.  I also found a forum post about somebody 'Zipping" their application first to avoid the hashes per file, but I'm not quite sure I understood that one.

       

      If anyone has any ideas, I would be very happy to try them.

       

      Thanks!

        • 1. Re: Provisioning application caching extremely slow
          MarXtar ITSMMVPGroup

          How many machines are you provisioning at any one time? I often find that most environments I work with have better results by just installing from the source rather than caching first although this can slow down a lot if you try to provisa lot of machines at the same time.

           

          When deploying software via provisioning the default delivery method is the standard policy supported push, you don't get to choose the delivery method if you push the template but you can if using the provisioning menu. To speed things up use UNC paths rather than http and consider using a run from source method. Also, I quite often don't use packages in templates, instead I map the network drive and then use execute file to launch the install; this is the same as defining the package as a run from source package but it allows me to use run from source for some but not others.

           

          Hope some of this helps.

           

          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

          Update - WoW & State Notifier now integrate for even more functionality

          • 2. Re: Provisioning application caching extremely slow
            Rookie

            Mark,

             

            Right now I am simply in the development phase of Provisioning, so I am only provisioning one machine at a time.  I currently have 3 machines - 2 desktop, 1 laptop - that I have been using in my testing, and I get the same result across all of them:  Software Portal deployments work quickly, provisioning very slowly for the same apps that have large file caches.

             

            I initially DID setup those larger applications as direct executable launches from within the provisioning template, and they worked great.  But then management threw a wrench in the mix.  We recently setup DFS (as we have multiple sites), and they want me to build these packages so they can be used from any of our locations that have their own LANDesk servers with no modification.  So I placed all the applications in a location they can be replicated from to our other locations file servers, and replicate our Deployment Packages and Provisioning templates across LANDesk servers.  And of course I modified all my packages (and reset hashes) and my provisioning template to point to the new location.

             

            The problem arose when I changed those direct executables in the provisioning template to point to our DFS location (IE. DomainName.com\DFSshare\path).  I have about 15 applications that get pushed through provisioning, and about half of those I setup as direct executables.  The first couple direct executables launch fine, but then the remainder fail.  It sometimes only launches 1 of the direct executables successfully, sometimes 4 or 5 - it's rarely the same.  To me it seemed like there was a refresh going on with DFS that was disconnecting my 'Resource Mapping', but my network techs "Assure" me that isn't possible.  So after much testing with the same results, I finally just created deployment packages for ALL my provisioning applications, and aside from the larger installations caching, it works great.  If I take the larger apps out of the mix, provisioning just rips through everything with swift perfection!  But when I add those larger app packages back, oh the slow caching pain and failure.

             

            I did play around with creating an EXECUTABLE deployment package for those larger apps, and not adding the 'Additional Files' in hopes that just pointing it to the executable itself would run it from it's location and not cache it, but apparently it wont work that way and the packages fail.  So I'm kind of stuck with using the packages since theres that odd disconnect running executables from the DFS location.

             

            My question really is: WHY does provisioning caching take SOOOOO long, when launching the same application from the Software Deployment Portal does the exact same thing (caches the application locally) but does it 90% faster?  This seems to me like something is broken in provisioning, as unless I am missing something very large, it should work the same way, since both methods use the same deployment package.

             

            Is this incorrect?  Because if not, color me sincerely confused.

             

            And thanks for the information so far!  It is greatly appreciated!

            • 3. Re: Provisioning application caching extremely slow
              MarXtar ITSMMVPGroup

              Am I reading this correctly? Your packages reference a DFS location? You are not using LANDesk preferred package servers?

               

              I haven't tried this so can't comment on whether it's a good thing or not for provisioning. I wonder if permissions will be an issue since you have a brand new machine account (has this replicated), and will be installing while logged in as a local user. Not sure if either of these would cause authentication issues but I even wonder if this means you are installing from the most local server.

               

              Anyone else tried this; combining DFS with provisioning?

               

              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

              Update - WoW & State Notifier now integrate for even more functionality

              • 4. Re: Provisioning application caching extremely slow
                Rookie

                That is correct.  Our packages are using a DFS location:  \\Domain.com\DFSshare\path\executable

                 

                We were recently told BY LANDesk that it is better in our environment to eliminate our extraneous LANDesk servers and leave only one or two and put our application packages on a DFS share and all the technicians would use the Remote Management Console to create packages that point to the same share so they can be used at any location.

                 

                During my troubleshooting and reading the log files, LANDesk doesn't seem to have any problem with the DFS pathing - it simply translates it to the actual local server and doesn't skip a beat.  The oddity is that my deployment packages point to the same location as the direct executables I had setup within the template, and without doing my 'Connect to a Resource' mapping in the beginning of my provisioning, neither the packages nor the direct executables would run.  So it is very odd that my direct executables will run one or two and then fail the rest now that I'm pointing to our DFS share, but the packages work just fine (except for the caching thing). 

                 

                If I werent already shaved bald, I would have pulled out my hair many times over by now!  As it is, my facial hair seems to be getting thinner instead... 

                • 5. Re: Provisioning application caching extremely slow
                  Rookie

                  For all of you who are searching for this answer because you're new to LANDesk and Provisioning and everything else involved, I managed to get ahold of LD Support and was given the answer to my woes.

                   

                  I am doing Bare Metal provisioning - boot my PC from DOS to the PXE Menu, choose WinPE Provisoning, then choose the Provisioning template I want to use and it launches.  When you perform provisioning this way, you don't manually create the 'Scheduled Task', but one gets created for you, and you can find it under 'Scheduled Tasks'. 

                   

                  If you look at the PROPERTIES of that Scheduled Task, under 'Delivery Method' it will show your 'Delivery Type' and 'Delivery Method' (in this case it is POLICY and ALWAYS LISTED FOR INSTALLATION').  Armed with this information, close the Scheduled Tasks properties and go to TOOLS> DISTRIBUTION> DELIVERY METHODS (or go there from your TOOLBOX view).  Now under 'All Delivery Methods' I open the 'Policy' container, then open the PROPERTIES for 'Always Listed For Installation.  Go to 'Network Usage' and change the default from 'Use Download From Source to Deploy Files' to 'Use Run From Source to Deploy Files'.  And BAM!!!  No more caching the application locally!  It now runs the application directly from it's source!  SWEET!

                   

                  Thank you John Trafelet, LANDesk Technical Support Engineer!  You saved my mental health with that answer!