You need to learn about the agent side tools.
We have a tool called Local Scheduler on our agents. It runs all the other agent tools. You should do a search for Local Scheduler and read about it. You really don't have to configure it, cause we pretty much have it done for you, but you could customize it if you so desire.
Each agent is by default configured to have local scheduler call a tool that checks for policies. This is configured to occur once a day. See you agent configuration settings. In 8.7 and prior, this tools was called amclient. In 8.8 and later, it will be called policy.sync.exe.
The clients are going to have a time in the day where they run policy sync and this time can migrate and change (so that you don't have all your boxes hitting your Core at once).
So basically, you have done all you can do from the Core side of things. NOw you just wait for the agents...at some point they will check for policies.
If after 24 hours, you don't see your agents checking in, then check if the device is on, check the local scheduler tasks on that client...etc...
I'll use a slightly different way to explain things - hopefully somewhere between the two explanations, things will become clear to you.
Push -- "Core goes out and tells the client what to do". Straight forward - relies on the Core being able to reach the client (so any client that's off, you can't tell it to do whatever you wanted).
Policy -- conceptually like a GPO -- "Core has a set of policies that the client has to contact the Core for to check". A policy is a PULL based approach. The client runs a client-side policy binary, which then goes out to the Core and checks "Hey - do you have anything for me?", and the Core responds with "Here's your list of things".
Now, when you "start" a policy, that only means that you've made it active. You still need clients to actually go out to the Core and check for these policies. The benefit here (much like a GPO) is that you just set something to "Go" - and clients will (normally) in their own time pull the policy down.
By default - for instance - we run a policy check 1x / day - but you can run it manually as well (if you want to test things).
The section on policies in the product manual seem quite OK to me - though I guess it can be a bit much to take in at once?
Does this help clarify things a little for you?
LANDesk EMEA Technical Lead
that is exatly what i'm surching for and i really understood this now :-)
One mor question about the multicast.
If i push something to one client that will transfer with multicast, doest it means the server contact the whole network, all clients?
or which role does the multicast have here?
So, I've gotten used to explaining multicasting in the context of a classroom full of students + a teacher.
So - for now - conceptualise that every site you have is "a classroom" with the clients being students.
The Core server is the "headmaster" of the organisation.
The following happens.
1 - You give the headmaster the order to do something.
2 - The Core-headmaster compiles a list of which students are located where (effectively, we create a chart of what clients are where, based on networking inventory information).
3 - The Core-headmaster elects its teachers (the Multicast Domain Reps). This can take two forms:
3.A - Static assignment - you've select certain servers/clients to be MDR's because they're highly available.
3.B - Dynamic assignment - the Core does a pingsweep on a network and the first client to respond, will be the MDR.
For the sake of this conceptualised example, think of the MDR's as "the teacher". Think of the teacher's each being given a head-piece through which they can hear the Core talking to them
4 - The Core-headmaster starts to send information (the package/files) to the MDR-teachers.
5 - The teachers - in realtime - broadcast the very same information to the entire classroom.
(NOTE -- it's a common misconception that MDR's recieve the package first and THEN send it around - that's wrong. This happens in real time).
Think of it as a teacher shouting (rather loudly) to a (very large) classroom.
Interim - a few details:
Multicast versus Unicast reminder
Unicast == Teacher goes to each individual student and says "You're a banana" - and does this to 1,000 students. This would ensure that all 1,000 students have recieved the message "You're a banana", but it takes a long time (1,000 times the message itself + the "walking between desks", or otherwise handshaking/negotiating) .
Multicast == Teacher shouts - at the entire class room - "You're a banana". The message only goes across ONCE, but all the students (=clients) recieve it.
- Now - you get a few students/clients that are not interested in the message (are not part of the job) - they just ignore this.
- Equally, you get students/clients that are faster - they will have to wait.
- You get students/clients that are slower (or simply lose some of the message), and may send a re-send request ("What did you say?"), in which case the message is repeated.
The MDR-teacher always (thus) is limited to the slowest member of the group
I'm still skipping some details here, but these are a few basic things to remember.
Now then - back to class...
So you see - Multicast is a variant of PUSH-based approach (after all, the message comes from the Core-headmaster via the (site-local) MDR-teacher to each student/client), and requires the clients to online.
The only difference (conceptually) is that you save yourself a lot of bandwidth by sending a package over the wire only once. However, because of the overhead involved (clients need to confirm each TCP-frame they get, and the MDR needs to make sure all of its clients have recieved all frames before moving on to the next window of TCP frames of the package its sending out), there's a LOT of overhead here.
So Multicast is *NOT* (usually) worth while doing if you're sending a job to 10 clients. But if you're sending a job to 1,000 - then yeah, it gets interesting (where your personal cut-off point of "good / bad to use TMC" is dependant on your network. A *LOT* of variables here depend on the quality of the NIC's you have on your clients, and even the networking gear you have on your sites).
Hope that this explains things well enough?
LANDesk EMEA Technical Lead
such a detailed Answer, great!!!
my next question
if push an aplication on one client with 4mb it takes about 3 min to install this.
If i push a aplication (Office 2007) with 780mb it takes about 30 min till the client start to recieve the files. An while this 30 min in the colum result in the tasks i see the message "Multicast in process" as i understood the core should shout here is office and only the client which is selected in the taks have to answer i would liek to have the app.
Why it takes so long till the files start the copy process to the client?
I'm going to take a stab in the dark here, and assume that this is the first time you run the job, right?
If the answer here is "Yes" (and I'd expect it to be), then the answer is simple - hashing.
When you run a package (any package) the first time, the Core actually goes and copies all the package's files locally to calculate their hash (so it can put that info into the database + task manifest).
This is a necessary process to make sure that the files clients download are "healthy" (the Core essentially sends a client a list of files to download + their hashvalues. Once the client has got a file downloaded, it calculates the hash and checks against the "what it should be" value).
Now, in a single-file package that's not too big, this doesn't take too long. Office has several 1,000 files and several 100 (at the least) MB of not GB of data, so takes a *LOT* longer.
This hash caluclation takes place on the first run of the job (not before) - it was decided against doing it "at package creation time" as
- Files could change after creating the package
- It would make package creation VERY painful (as you'd have to wait for it to finish hashing, before you can go on and create the next package).
I don't want to come across here the wrong way, but considering the questions being asked (and I take it you need all this for your job) ... but this would all make a rather strong case to get your boss to send you on a LANDesk training course (either run by us ourselves, or by your preferred ESP). A solid week's worth of training should help you immensly in using the product and seeing the potential in how it can make your job easier and better.
LANDesk EMEA Technical Lead
now im installed the office again on the same pc and it takes second time the same time till it start to install abou 35 min.
You said the hash calculates only on the first job, but it seems to take the same time on second job.