The trick is to configure preferred server, use an account that is a local admin for the pref server account, and use run from source. Make sure you clear sdmcache.
Also, you could use an Autoitscript or other scripting agent and use the RunAs command (internal to Autoitscript) with credentials passed on the command line so they are not in the package. The downside of this is LANDesk puts the command line options on the distro package in the local log files. I've done some really weird Autoitscript using obfuscator, encrypted passwords on command lines etc... to work around these issues. Try the run from source first.
THanks Zman. I am a bit new to LDMS. Can you expand on Preferred server and where to find it?
So one thing you will find out is not all the Console functions are availble on a remote console.
- So fire up the console on the Core
- Select Configure
- Select Preferred Server
- Select Help - Read about Preferred Server
- Configure Preferred Server
Configuring preferred package servers
You can specify the default 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 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).
The core server also uses preferred servers. 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. 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 the WAN link for hashing, so hashing files on a server that's local to the core will be much faster and use less low-speed 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 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.
just to point out the other option, application virtualization is another solution.
Virtualisation is toooooo expensive.
Thanks Zman. Great help :)
So just to followup.
One you enable preferred server you dont have to do anything to the client or the package to make the job work?
If downloading the files as LocalSystem was your original problem, then yes.
I had the same issue with a program that would not install as Local System nor would installing as current user because of lack of rights. I created a SWD package that would run at next login and used the below line to install it. Kinda fun...
startasuser.exe hidedos.exe cmd /c runas /user:<Local Admin Account> "setup.exe -s" | sanur <Local Admin PWD>
startasuser.exe - Comes with LANDesk
hidedos.exe - you can find it in the forums somewhere. It hides the CMD window
runas - part of XP
sanur - freeware tool, allows you to pass the password to the runas.exe command
Worked like a charm. Weird things we do sometimes not to walk around to several hundred machines, lazy us...
App virt is one of those items that if you just consider the up front costs, then it look expensive. If you consider the time and money saved with:
- Regression testing - the testing cycle is much quicker
- Ability to run legacy apps under newer OS. No need to repackage
- No additional infrastructure required like other solutions
- No dll hell, ability to run under other solutions - Citrix, Thin clients, etc...
- Productivity loss on the user side waiting for the app to install or troubleshoot app issues.
The costs savings on the back end more than pay for the product.
In regards to placing usernames and passwords in exes, that is risky especially in Package Builder apps. Encrypted command lines offer a better solution.