It's the same as for any other software distribution task. Just read up the manual / documents on preferred package servers, and then mirror the patch-location directory structure, and you're good to go.
Patch Manager uses exactly the same download mechanisms as "normal" software distribution, so this is easiest to think of as a simple distribution task.
LANDesk EMEA Technical Lead
Thanks for your reply. But i need some clarification . When i setup preffered server they will have different ip addresses for different subnets althogh i mirror the patches the
ip' s will be different . Do i have to change the patch location everytime on the core or how do i go about.
Awaiting for your reply.
Please be aware that I (a) tend to travel from time to time, (b) can get pulled aside for other things that take all of my attention. In general I try to spare as much of an eye on things in the community, but things can (and will) drop off inevitably. This isn't me ignoring anyone personally.
In regards to this one, I'm not sure I understand your statement at all, actually.
You can (you don't HAVE to) configure Preferred package servers by subnet. Are you saying the entire networks will change? If that's the case, you have some serious infrastructure problem that you need to work around.
Alternatively, you just don't use network-specific preferred package servers, and instead just use a static list.
If I've misunderstood your question, please reformulate it a bit clearer, as I've read it a few times and am not quite sure what it is you're trying to clarify.
LANDesk EMEA Technical Lead
Inspite of busy shedhule thanks for replying to my query.
To make it more clear . I will explain you the scenario . I have one core server to which 50 locations are connected over a slower wan link(64k link,128 k).
with 15-20 pcs populated at each location. What i am trying to do is setting up a preffered server in each location with patch repositary. Patches will be copied during non
business hours(During Night) using file replicator utilty. My question is as follows
1) In security and patch manager do i have to change the patch location every time for different preffered server's on core server.(Screen Attached). Or it will be taken care
on its own.
2) How will the clients recognize and communicate with the preffered server.
patch.JPG 43.6 K
1 of 1 people found this helpful
Ah - I think I see - you misunderstand how preferred servers works. It's actually wonderfully simple to explain :).
So - you have a share on your Core - or wherever - which can be either UNC or HTTP. For this example, I'll use an HTTP share. So let's call this share:
Now - any client where no preferred package server is configured will simply go to "http://MyCore/MyPatches/Mypatch.exe" and download the file from there.
Now - you have two clients. ClientA which is on Site-A and has PackageServer-A configured.
And ClientB, which is on Site-B and has PackageServer-B configured.
The two package servers are replicating with the Core (or wherever), and so its ensured that the same HTTP/UNC directory structures exist.
Now - ClientA receives the order "go forth and download http://MyCore/MyPatches/Mypatch.exe and install it, and all will be good".
So - ClientA checks its local information - "do I have a preferred package server" it asks itself, in effect. Based on the network information it has, it finds out "aha - based on my IP-range, PreferredServer-A is my preferred server".
So - it tries to substitute - AUTOMATICALLY - first of all the path with the name of the preferred server.
NOTE: This is all that happens. ONLY the Server-name gets replaced, this is why it's VITAL that the UNC/HTTP directory structure be identical.
If the preferred server HAS the package, the client will download it from there. If not, it'll fail over and download it from http://MyCore/MyPatches/Mypatch.exe as defined in the task.
Now let's imagine ClientB is supposed to install "
Here, it too checks the information it has, to check whether it has a preferred server to go to. In this case, let's assume it has to go to PreferredServer-B.
This is done - 100% dynamically - by the CLIENT. All you do is configure the "normal" path to the package. All the clients (try to) do is then substitute the name of whatever server you specify with their assigned preferred package server.
Preferred package servers are "always on" (i.e. - clients will ALWAYS try to get the package first from the preferred package server, if no peer has it). The ONLY time when preferred package servers don't work is Targeted Multicast (makes sense, based on how it works) :). Preferred package servers work for both Software Distribution and Patching (the patch-component uses the software distribution component to get to its files).
The client updates its preferred server information every 24 hours, and/or if its IP changes (it can get it from a peer or - failing that - from the Core).
Does this answer your question?
LANDesk EMEA Technical Lead.
Does this make any more sense to you?
Thanks a lot's paul for explaining me so well.
i just found this thread about preferred servers in conjunction with patch management and i already understand, how preferred servers work using "normal" packets. i can even see in the client's logfile, that the pref. server is used for source-file-download.
but patchmanager-packets work somewhat different - as far as i understand.
First of all there is the setting called "web url where clients access patches" witch points to http://CORESERVER/LDLogon/patch
If i check a repair package - generated by the patch manager - it looks like this:
http://CORESERVER/landesk/files/ldrunner.exe with command line parameter ""%LDMS_CLIENT_DIR%\vulscan.exe" /repair "vulnerability=958752" /agentbehavior=1"
the client does this:
Wed, 14 Jan 2009 15:57:02 Downloading file 1 of 1 from 'http://CORESERVER/landesk/files/ldrunner.exe'
Wed, 14 Jan 2009 15:57:02 Checking preferred server path http://PREFERREDSERVER/landesk/files/ldrunner.exe instead of http://CORESERVER/landesk/files/ldrunner.exe
This won't work because PREFERREDSERVER is not running a webserver service.
My questions are
1) do i have to install a webserver on each preferred server to get it working with patch packets ("normal" packets use UNC-Path)
2) what does ldrunner.exe and/or vulscan.exe do in the background to retrieve the patch? do they use unc-pathes to get the patch-installer?
the problem is, that we often use e.g. a nas-filer as a preferred server which the client can only access via a unc-path.
Thanks for your help,
In short, yes, you will.
Though you don't need to install a WebService (that's a separate thing all together, and one needs to be careful with terminology), but you will need to install IIS on it, so that it may host a web-share.
ALL patches are referenced by clients as an HTTP path (you'd have to essentially write things by hand to make it point to a UNC share) -- as described above, Preferred servers only replace the name, they don't turn UNC into HTTP.
So you need to have the right directory structure (and files, obviously) - for your patches, and hosted on a web-share on youre preferred server(s).
LANDesk EMEA Technical Lead
Thanks for your reply, Paul. I meant a "webserver service" ... like a http daemon ... not a webservice.
What else can we do if we have no possibility to install iis to a site/preferred server?
Targeted Multicast is the only alternative which comes to my mind right now.
TMC is certainly a possibility ... the other is UNC.
To be honest though, I'd recommend to have a chat with whoever set up this policy (and I assume it's a policy) of not installing IIS on a server (or - arguably - any HTTP-server could do the trick). That may be the better way to attack this.
To quote a clever say - technology can not often be used to fix a problem of society (or policy, in this case).
LANDesk EMEA Technical Lead.
Just a short update on this problem:
we mananged to get the whole thing working without httpservers running on the preferred servers. it's working fine with UNC-pathes now.
The trick was to enter a UNC-Path in the settings where landesk asks for "Web URL where clients access patches". We just entered \\coreserver\ldpatch. That's it.
I have LDMS 9.0 and have the core server using a different path as the patch location. Since i am using a VM for the core, i dont have much space to use for that server's repository.
http://core/ldlogon/patch was changed to http://serverA/ldlogon/patch but the problem is, none of the machines are using preferred server instead they all are picking up the data from http://serverA/ldlogon/patch. What am i missing?
Thanks for the time in advance
Make sure that you have the mini rollup patch for 9.0 applied. We had a bug early on where patch manager was not using the preferred server. This was corrected in the mini rollup patch.