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 CommunityCumulative Patch List for LANDesk ProductsQuery Builder ImportProvide bulk client deletions without carpal tunnel syndrome.Core Synchronization Allow Mirror functionality from Master Core
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.
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.
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.
This is on the server itself and no drives are mapped on there... so it is literally trying \\coreserver and nothing else?
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.
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!
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.
Seems strange since if the preferred server is down the core is also down
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.