Why are you so hung up on the advanced agent? The primary things it brings to the table are:
- Bandwidth awareness (which you can configure)
- Peer download (which is enabled by default)
- Byte level checkpoint restart (which we equally have by default on full agents)
... so if you configure this as a policy, you should be set to go. If you're not sure what the options in software distribution mean, have a look through the manual / consider attending a training course (provided by your ESP or ourselves, for instance).
There's nothing "particularly" magical about Advanced agent, so I'm a bit confused why you're so set on advanced agent ... advanced agent is a cut down version of the LDMS agentry with the sole purpose to get the agent-file down.
Hope this sheds light on the right things?
LANDesk EMEA Technical Lead
What I'm "hung up on" is the part where it continues to download the item until completely done and THEN performs the install. I don't want to have to have it completely download every time a connection back to the core server is made, since that will make it take even longer.
If you know which settings make this effect, then share... Otherwise, don't be so lofty in your response.
Urm - there was nothing haughty in my question - I was trying to understand what you were after really - sorry if you misread it as such.
It was a matter of clarification, as it didn't make much sense to me without an explanation of what you were really after.
So - with a normal policy this should be working just fine - since the partial file should be identified on the client locally and continue to download where it was left off. Is this not happening for you?
This is not something that needs to be "set" per se - it's just enabled by default, as it's a part of us trying to get a file down.
If the connection cuts out (i.e. - you pull the network cable) and we then try and download the file again in the future (i.e. - you reconnect the NIC cable and run policies again), the byte-level checkpoint restart should pick up just where it was.
The only thing you can configure in this regard, really, is the bandwdith usage, but that's about it. As long as your delivery method states that you want to download the file and then run it, check-point restart should work just fine.
LANDesk EMEA Technical Lead.
Blame it on a bad weekend... Or a weekend that never was... I had to re-rebuild one of the remote core servers I'm in charge of because the local (to that server) Wintel admin didn't do it the way I requested the first time.
I'll test it as put above and see if it works, or how we have to tweak it to get it to work...
If this had been clearly documented in the different deployment methods, I never would have asked the question here...
1 of 1 people found this helpful
No worries, that kind of Monday morning would ruin most people's days .
The part of the tech is simply "on", much like peer download, as we couldn't come up with a scenario where one wouldn't want to have a byte-level checkpoint restart being enabled and such.
I'll see what I can do about the documentation, will try to add it to the mental list of issues I'll try to address regarding that in the week :).
LANDesk EMEA Technical Lead
I've since gone to a policy based push method to deploy the new software. This is working fairly well, for a decent amount of the systems. Of course, it's impossible to get everyone no matter what methods you try. Compound that with systems that are in locations too remote to hit within a reasonable amount of time (MA to Memphis, TN just isn't viable)... So far ~75% of the nodes getting the install have it... Just need to get the remaining 25% to get the item before the end of this week (or the end of month deadling)...
Usually figures are roughly that 90% (sometimes more, sometimes fewer) of clients are reached within 1-3 days of a policy. The rest can be a while, because people are on holiday / on the road / spilled coffee over their PC and are watching it hiss and fuzz / abducted by aliens - the usual stuff.
Depending on the nature of your remaining 25% being bothersome, there's a few tricks you can pull (such as a WOL-job (if WOL is enabled) ) to wake up your clients and force a policy check, for instance. If it's networking issues (either routers not liking you or "clients are flat out not there" for instance) there's only so much you can do.
If it's a single site (or a handful) that give you trouble, you can look at those in detail, and maybe schedule a separate job out to them, as needed. It can get tricky, depending on the spread of your non-installers so far.
That 100% guaranteed deployment stuff only works if the clients are actually there - which is not something you can guarantee yourself, really (it's not like you're keeping tabs on 100's or 1,000's of workers personally, now is it) .
For systems that are "remote", I would suggest making use of the "Preferred Server" options we have - that'd allow you to transfer a file (mailing by CD/DVD, in some extreme cases I know of, for REALLY remote locations) and throw the binaries on a specific location and clients will get it from there. There's stuff on preferred package servers in the help + manual doc's to read up on. But the short of it is that rather than using "SomeServer/Path/Path/File.exe" clients automatically try to replace "SomeServer" with "Their configured preferred package server", to check if they can get it from there.
This does require you to have identical folder structures, but works quite happily whether you use HTTP or UNC.
There's lots of little tricks to help out with bandwidth-starved places like this, but preferred package servers is certainly one of the best (and permanent) solutions to this kind of problem. Hope this helps :).
LANDesk EMEA Technical Lead