NOTE: Obsoleted by LANDesk Management Suite 8.7.

LANDesk Management Suite v8.5 allows nodes to specify their preferred Software Distribution server. This extension allows road-warrior laptops to auto-select the proper distribution server. It is implemented as a Visual Basic script and should run on Windows XP only -- if you need Win2k, contact me. To use it:

1. Edit the list of preferred servers in the script. I suggest using DNS names so that you can change servers later without redistributing the script.
2. Deploy it to your clients in a known, sensible location (e.g. C:\Program Files\LANDesk\LDClient\)
3. Create a Local Scheduler script with the following parameters:
   • Command = wscript.exe
   • Parameters = c:\program files\LANDesk\LDClient\set_preferred_server.vbs
   • Freq = 1 min
   • On IP Address change

This should make the script run within one minute of an IP address change.

Download it here, contact me with questions and issues.

Version history:
' version 1.3.1, fixed a bug for situations where the first server was the best choice
' version 1.3, added support for multiple preferred servers (thanks Roger T. Leff for testing)
' version 1.2, added environment variable export
' version 1.0, initial implementation

Frequently asked questions:

1. What's the point of preferred servers? There are two:
   • large multi-core networks: If you want to distribute the same file quickly to sixty thousand desktops on three continents, you don't want all of them coming back to Chicago for that file. Even with targeted multicast cutting it down to one rep per subnet, that's still a lot of downloads hitting the Chicago server. By using preferred server, you can force Europeans to download from Munich, Asians to download from Tokyo, &c.
   • road warriors: If you set a policy requiring laptop users to get a package, and the package lives in Los Angeles, but you've got a few people who frequently go to New York, you don't want them pulling the package from LA to NYC. Targeted multicast and peer download will take care of this during the initial push, but after the two week cache period is over, new policy enforcements will want to go back to LA. But if you set up a network of preferred servers, sdclient will go to the nearest preferred server for the software. So when your executive loses his laptop in NYC, the policy refresh will pull packages from the preferred server in NYC, not LA.
2. Why the environment variable? So that you can use preferred servers from custom jobs, too. While sdclient will use the preferred server registry key, some times you just want to do a simple REMEXEC01=\\%PREFERREDSERVER%\path\to\my.exe.
3. What about autofix patches? If you distribute the patch ahead of time, then it will be sitting in cache and will get executed from cache. If it's not in cache, vulscan will pull it down from the patch location that was defined during your initial core installation. To change this location, go to Security & Patch Manager > Download Updates > Path Location. Theoretically, you could make this http://%PREFERREDSERVER%/LDLogon/patch/, but this would probably cause Macintoshes to break. A fully qualified domain name pointing at distributed load balancer would be the ideal solution.
4. How can I make it work with targeted multicast? tmcsvc.exe does not automatically use the preferred server registry key on 8.5; however, you could always modify your distribution jobs to use a path like \\%PREFERREDSERVER%\path\to\file.msi. LDMS 8.6's tmcsvc.exe will use the registry setting properly.
5. What are some other ways to provide a list of servers? A very simple one is to modify the ntstacfg.ini file generated for each agent configuration and give it a list of server names separated by semicolons, which will be tried in order. Examples later.