I have run into an issue where the agent install action will pull down from the core server rather than utlizing the preferred server. This isnt a workable solution for remote sites with low bandwidth links. Has anyone come across a good solution to this issue as you cant take advantage of any of the provisioning actions in system configuration without an agent installed on the client OS?
The options I can think of are
Both would work but I am hoping there is a better / easiser way to resolve this.
Create the Agent as a self-contained EXE. Put the EXE in a replicated folder that would be configured by the preferred server. Havent tried this but its a thought.
Maybe this utility can help?
Dont forget, to use this utility you still need to have some kind of agent in your image as it will use SDclient to determine your preferred server. Also, you will need to copy the complete LDLogon map to your preferred server and cant use the Configure Agent action, but will need to use Execute File to run WSCFG32.exe from the drive mapped by those tools or run the Self-Contained Agent EXE as also suggested.
We have a self-contained agent package pushed down the the c: drive of the machine during winpe as drives are already mapped to local shares at this point. Then when the machine comes into windows, we have an exectue file action to run the self-contained agent package.
This works brilliantly (especially with LDAV agents as the self contained package is over 100mb so would be a nightmare over a WAN link). We've also implemented this for several of our customers who all seem very pleased with the results.
Thanks to all that replied but Jack you hit the nail on the head! Nice simple solution that works well!
Thanks for sharing this working method.
The speed of the LANDesk agent installation in the remote sites improved easily by +- 15 minutes.
It helped me a lot.