9 Replies Latest reply on May 31, 2010 2:25 AM by phoffmann

    Scheduled task timeout query




      I'm currently testing a distribution package I've created to change some of the Office 2003 licenses used across our network. The idea is to remove Office 2003 pro and replace it with Office 2003 std (in addition it'll apply Office 2003 sp3 & install Access 2007 runtime).


      The problem I have is the  when deploying the package (which is ~600Mb) to a test box on a remote site (over adsl link - 512k) it's not reporting a successful completion. Checking the machine itself and the task has completed correctly (all applications are installed) - the sdclient log file is complete and returns the expected exit code, but the whole task takes around 12 hours to complete (I'm using a bandwidth aware multicast push, limited to 25% of available bandwidth).

      Viewing the log file from the console only has information about the process up to around 6 hours into the task.


      Presumably there's a limit to how long a target will stay in the 'active' list before timing out and failing; my question is can this be increased at all, or do I need to look at changing my deployment package?


      I've added the batch file used for the script & log files mentioned above if these are of any use in aiding my query.


      Any advice appreciated.





        • 1. Re: Scheduled task timeout query
          phoffmann SupportEmployee

          This sounds to me like a great way to use Preferred Package Servers (PPS's).


          Or at least, pre-loading your preferred MDR's (Multicast Domain Reps), if you don't have/make use of PPS's. Generally you really don't want to multicast (in a bandwidth aware fashion) something that big over that weak a link. Much easier to "have it on the other side" already, and just have it be either accessed as a preferred package server locally, or prepared for the multicasting?


          There is a configurable task time-out, but I doubt it can be cranked up to anything like 12 hours, truth be told ... I think the above will certainly be a lot more uesful (nipping the real problem in the bud) rather than assailing the symptom?




          - Paul Hoffmann

          LANDesk EMEA Technical Lead

          • 2. Re: Scheduled task timeout query



            Thanks for the reply. I thought that the package size/link speed combination would cause problems but having only recently started using LANDesk I'm unsure as to how MDRs work/are set up - do you have any links to documentation that might explain this? (apologies if if I'm missing something obvious!)


            We don't have any PPS's set up, though I'm not sure how these would aid the deployment as the majority of our remote sites are on similar weak links but don't have any onsite servers. Again, I could be mistaken; I will freely admit I'm quite the novice with LANDesk at present, but I plan on changing that!


            Thanks again



            • 3. Re: Scheduled task timeout query
              phoffmann SupportEmployee

              No shame to being new to something.


              I'll try to take some time tomorrow to document things out for you, so that things make sense. It's not all too complicated.


              They don't need to be "servers" per se, you can abuse other boxes as well .


              Here's a link on how PPS's work (knew it'd be useful for me to keep those):

              - http://community.landesk.com/support/message/21154#21154


              For the MDR's - in essence, you just drop "reliable" devices into the "Preferred Representative" section, to tell the Core "use these guys with preference".


              You can then 'cheat' to register the files/packages in the cache on the clients (will tell you how tomorrow if I can), and you've got most of the work done. Mostly you need to ensure that you've got a "reliable device" (once that you know will be on / you can get your hands on) on each site (how many we talking here? 10 or 10,000? Makes a bit of difference ), do a handful of things, and then you're ready.


              It'll be more work reading than doing, to be honest.


              - Paul Hoffmann

              LANDesk EMEA Technical Lead

              • 4. Re: Scheduled task timeout query

                It's around 300-350 sites from memory (not sure of the exact figure) - most of which are on 512k ADSL links. If I understand it correctly, could I specify an MDR at each site, cache the files (using a cache-only task) and then run another task at a later date for peers at each subnet to download & install from the local MDR?





                • 5. Re: Scheduled task timeout query
                  phoffmann SupportEmployee

                  Apologies for the delay in getting back to you David.


                  Now - you *CAN* multicast - if you so want - to the other sites, but you don't really have to. You could just create a 'dummy' package to copy the file over to the relevant device(s) as a normal unicast, if you prefer, but multicasting works too.


                  A "dummy" package in this case means that you have a batch-file that does nothing (save perhaps a "echo hello world" or something like that), whilst having the ACTUAL package you want to get out as an "additional file" (so that it does actually make its way to the clients).




                  Depending on the strength of your network links, it might be worth while to do an alternative approach - if you can't trust the links to be up, you might be better off getting the packages downloaded to a 'more permanent' location to begin with (since the default time that a package will stay in the client's cache is 2 days).


                  How is this done? Well - you can either use a job and have the "dummy bat-file" move the file from its present location in the clients' SDMCACHE directory to some other directory - say "C:\Storage\" for instance).


                  Once all your sites have the package "on site", you would now need to make the clients aware of the package again (I'm assuming that this may take more than the two days). This is actually pretty simple.


                  All you need for this is just a batch-file that copies the file from it's more permanent storage (i.e. - "C:\Storage\") back into the SDMCACHE directory (important, remember to retain the directory structure that we had in there before).


                  "C:\Program Files\LANDesk\LDClient\SDMCACHE\" is the place where we download/cache files for peer download stuff / multicasting. However, one little thing is needed on top of remembering to re-create the relevant directory structure to make sure that "LANDesk knows it has the file".


                  Once you've copied the directory structure of the share / the package back into SDMCACHE, you must re-start the TMC-client on the agent(s) in question.




                  The TMC-client is the one that does the householding of SDMCACHE (and the deleting of files / picking up of new ones). Since you've "cheated" in getting your files into SDMCACHE, you need to re-start the service, as one of the first things it does is to check "do I have any new files / do I need to delete any" ... once this is done, it'll actually be aware that it has the big zip-file in local cache and will then be able to act as an MDR / peer without problems.




                  You *COULD* in fact not use multicast at all (I prefer using multicasting over reliable networks), depending on how big the relevant sites are. Specifying "use peer download only" will prevent clients from going over the WAN to download the package from the Core / your HQ, if you want.


                  Multicasting will work as well, but it's worth keeping the latter idea perhaps on the backburner, in case you run into network problems (which, given the number of sites, is likely to happen 'somewhere').




                  Does this make all sense to you / help you with your project?


                  - Paul Hoffmann

                  LANDesk EMEA Technical Lead

                  • 6. Re: Scheduled task timeout query



                    Thanks for the information, that certainly does make sense. Just a few (more) questions if I may:


                    Would a unicast deployment with a dummy file be more reliable than multicasting to cache? I also noticed you mentioned deploying as a big zip-file - my package isn't zipped up (Office 2003 is just the contents of the cd put into a folder so it's ~200 individual files) - does this have any impact on the stability of the push?


                    As with the initial attempt at deployment, would this fall foul of the timeout message I got originally?


                    And finally, if I were to take the route of moving the files back into the cache, could I put the restart of the TMC service (presumably I can use net stop/start for this) in a batch file which could then call the original installation script? Would the service be able to pick up change in files on the cache quick enough for this to happen, or should I seperate this into 2 tasks?


                    I had tried last night to run a cache-only (using multicast and storing the package for 120 days) to my test machine on a remote site, but as luck would have it the link went down for a while shortly after the task was started, so it only managed to copy a fraction of the package.


                    Thanks again for all your help!



                    • 7. Re: Scheduled task timeout query
                      phoffmann SupportEmployee

                      You are milking this aren't you . No worries - I'll try to answer, I hope, in a way that'll make things clearer for you.


                      The Software Distribution stuff is a LOT to pick up, but it's VERY much worth reading up on / going through the docs and trainings. Once you've mastered the way that software distribution works, it'll open your eyes to a *LOT* of things.

                      GENERAL GUIDELINES:


                      Multicasting involves a fair bit of handshaking. Similarly does peer download (especially as we check each file individually).


                      So when sending out BIG packages (Office 2007 with its 4,000+ files is a big exmaple) you will be MUCH better off using compression to "only" deal with a single file.


                      A single file has MUCH lower risks of going bad on the wire (we check the downloaded/assembled file's hash against what it should be - if it doesn't match, we throw it away). When you have several 1,000 files your chances that 1 or more of those files will have been discarded because of "ghosts in your network" fiddling with the frames rise in number.


                      Also from a peer download point of view, it's MUCH easier just asking for a handful of files, rather than asking for 4,000 files individually...


                      So this is why I am a strong advocate for compressing files, among other reasons.


                      Be aware that we have a BKM on installing Office 2007  (I'm surprised you're not using an administrative install) here, it may help you with a few ideas:

                      - http://community.landesk.com/support/docs/DOC-2126


                      It's not so much that Multicasting is not reliable - it's more *vulnerable* to bad networks / connections / hiccups, which is why I would advise against relying on it overly much in ... well - unreliable networks .




                      The timeout could still be an issue - depends on how long it takes. However, because of the significantly reduced handshaking involved, it may be that his symptomatic problem will go away using unicast / the compressed zip + batch approach.




                      Whilst the TMC service only needs a few seconds to inventory the files in its cache, I would suggest keeping as either two separate jobs, or allowing a minute (or so) of delay inside a batch file (with a wait / sleep type command) before proceeding. Partially depends on how grunty or weak on the lungs your clients are.


                      Generally I'm an advocate of 'a bit of patience versus an ounce of making up for it', so that should help along.


                      And yes, a normal NET STOP / NET START and such will work just fine for the TMC client , so those can be tied into the batch file as well.


                      All the more reason to do this without multicasting, as you prevent yourself some problems that way (of the "it could happen" variety - I prefer not to attract Murphy's law so that it might bite me in my backside) .




                      Since I talked so much about batch files - just in case, here's a GREAT document on how to use them in relation to LDMS:

                      - http://community.landesk.com/support/docs/DOC-2320




                      - Paul Hoffmann

                      LANDesk EMEA Technical Lead

                      • 8. Re: Scheduled task timeout query



                        That's great, thanks again for your patience with my mass of questions. I'll certainly look into the guides and try a 2-stage approach with a single zip file/unicast - hopefully that'll be a lot more reliable over our WAN.


                        Again, your help is greatly appreciated!




                        • 9. Re: Scheduled task timeout query
                          phoffmann SupportEmployee

                          No problems - hopefully it should help along. At least with the byte-level checkpoint restart you'll benefit from the "fewer files == better" approach as well.

                          If there's nothing else, should this be marked as answered?


                          - Paul Hoffmann

                          LANDesk EMEA Technical Lead