10 Replies Latest reply on Jan 23, 2012 3:09 AM by jwood8

    Slow core server

    jwood8 Apprentice

      Hi all,


      A bit of background - we have a main site in the UK with a LANDesk core, then a couple of satellite sites (Australia, Japan, New Zealand, Netherlands, Germany) which have another couple of cores between them.


      It's hard to pin down, but I think that our main core is very slow. For example, we are currently working on an Office 2010 deployment. We have used the same package files on all the cores, but when we deploy them (using SDP) in the UK it takes 1.5 - 2 hrs and in Australia (for example) it takes 24 mins. The agent settings are identical, and the network speed is actually faster in the UK than Australia, they are only using 100mb and the test machine was a laptop so nothing special.


      There are other issues which are similarly vague - if I add software to the SDP in the UK sometimes it won't appear, or it takes ages, whereas if I add it in Australia it goes on straight away. When building workstations, in the UK we often get the template timeout but elsewhere never.


      I know this is a bit of a tricky thing to answer but I'm really looking for some advice. Does anyone know anything worth checking? Another thought - is it possible to build another core in parallel from scratch, then transfer things across and see if that improves matters? Any ideas welcome!

        • 1. Re: Slow core server
          zman Master

          Like you said, one of those almost impossible items to answer on a community.

          • What version/SPs are you running on your cores/clients.
          • Same OS/SPs on all Cores.
          • Is the hardware identical on all cores.
          • Are node counts identical/close on all cores.
          • Is the work load identical/close on all cores (e.g., Scheduled tasks, Provisioning/osd, Patch, etc...)
          • Where are the DBs located in reference to all the cores.
          • DB sizes close.
          • Are you running maint on the DBs, or defragged the DBs lately
          • Running core remotely or from the core.
          • Same security software on all cores.
          • Have you monitored the cores vitals (cpu, memory, disk IO, etc...)
          • Have you monitored the DB servers vitals (cpu, memory, disk IO, etc..)


          The one scenario you mention, slow office deployment, may not be a core issue but a file transfer issue. Have you looked at the sdclient logs to see why it is slow (break it out - start of task - how long to download the files - how long to run the files) This will show where the bottleneck is.



          Please consider voting for these ERs:
          Provide Better Pre/Post LDMS Patch/Sp/.0 Information To The Community
          Cumulative Patch List for LANDesk Products
          Query Builder Import
          Provide bulk client deletions without carpal tunnel syndrome.
          Core Synchronization Allow Mirror functionality from Master Core
          • 2. Re: Slow core server
            LANDeskWizrd SSMMVPGroup

            To add to Zmans list, do you have any Preferred servers configured? This doesn't really sound like a core issue but rather a network issue.

            • 3. Re: Slow core server
              jwood8 Apprentice

              Hmmm, interesting - we don't 'use' preferred servers as such (i.e. we just have one core per region so we only have one preferred server listed) but I just noticed that on the UK one if I test credentials I get a failure. What is this actually testing credentials against? The user details are fine so I want to check the security settings on whatever it's connecting to - I thought the packages share but this should be OK. It tests OK if I put domain admin details in but obviously don't want to leave those in there.

              • 4. Re: Slow core server
                zman Master

                I've seen it fail sometimes when you test unc and you already have an authenticated session to that preferred server - mainly wehen running remote console and I have a billion driving mappings running. It is basically seeing if the supplied credetianls can access the UNC and HTTP path of the preferred server.


                The sdclient log file for the slow SD task will show you where the bits are being pulled from - maybe getting them across a wan link.

                • 5. Re: Slow core server
                  jwood8 Apprentice

                  This is on the server itself and no drives are mapped on there... so it is literally trying \\coreserver and nothing else?

                  • 6. Re: Slow core server
                    zman Master

                    So to be clear the preferred server is your core server? It just checks to see if it can authenticate to the box.  So if your preferred server is your core server, not sure how that would work with authentication - maybe the same symptom as already having a drive mapped.

                    • 7. Re: Slow core server
                      jwood8 Apprentice

                      That's correct - may be a red herring then, although in Australia the core is the preferred in the same way and that is fine when you test credentials. Odd!

                      • 8. Re: Slow core server
                        LANDeskWizrd SSMMVPGroup

                        Any reason why you are using the core server as your preferred server? Is the core server where you distribution package main file path points to? If it does, then don't really see any reason to have it listed. Regardless, I would check that the account you have defined in the preferred server has access to that server. In our case we use a service account.

                        • 9. Re: Slow core server
                          zman Master

                          Seems strange since if the preferred server is down the core is also down

                          • 10. Re: Slow core server
                            jwood8 Apprentice

                            Yeah, does seem odd - I inherited this LANDesk server so I wasn't involved in setting it up, can't really say why it was done that way. I tested credentials from another workstation using the management console and it worked OK so you must be right Zman about the server already having a connection to the resource and causing an error when you try it on there.


                            I've asked our SQL DBA to take a look at the databases and make sure all is well on there, I will try to look into some of the other things when I can.