Management and Security powered by Landesk
You can specify the preferred server that devices will check for software distribution packages. This can be important in low-speed WAN environments where you don't want devices downloading packages from off-site servers. When you specify preferred servers, you can also specify the credentials managed devices should use to authenticate with each preferred server. You can also specify the IP address ranges that a preferred server will be available to.
When using preferred servers with a distribution job, only the server portion of the UNC or URL file/package path is replaced; the rest of the path must be the same as what was specified in the distribution task. If the file isn't on the preferred server, it will be downloaded from the location specified in the distribution package. The only distribution method that doesn't support preferred servers is Multicast (cache only). UNC, HTTP, and HTTPS package shares work with all packages.
The core server uses distribution package hashes to verify distribution packages in scheduled tasks. The core server will first try to generate these hashes from a preferred server, if available. Using a local preferred server makes the hashing process much quicker. If the package isn't available on one of the preferred servers, the core server falls back to generating the package hash from the path specified in the distribution package. You generally won't want the core server pulling a large package over a WAN link for hashing, so hashing files on a server that's local to the core will be much faster and use less bandwidth.
Managed devices store the preferred server list locally in the preferredserver.dat file. To create this file, a device communicates with the core server and then makes a filtered list of preferred servers (based on IP address range limits, if any). The device then does a bandwidth check to each preferred server and saves the top three servers in the preferredserver.dat file. Note that the bandwidth check doesn't produce guaranteed reliable results. For example, a server that's close by may have a high load at the time the agent checks, so it may get bumped off the list even if normally it's the best candidate.
The distribution agent updates the preferredserver.dat file every 24 hours or when the IP address changes. Not every device has to go through this process. Devices share their preferred server lists with peers. This is the process managed devices go through to maintain a current preferred server list:
- If preferredserver.dat is in the local file cache, the distribution agent uses it.
- If preferredserver.dat is on a peer, the agent retrieves the file from that peer.
- If preferredserver.dat isn't available locally or on a peer, the device contacts the core server, creates a filtered preferred server list, and saves that locally as preferredserver.dat.
- If preferredserver.dat is empty or if none of the preferred servers respond, the agent checks for a preferred server list in the local registry.
If none of these steps results in an available preferred server, the local agent uses the distribution path specified in the distribution job.
Was this article useful?
The topic was:
Not what I expected
Copyright © 2018, Ivanti. All rights reserved.