It depends which part you're talking about as "still taking place". Are we talking about the "copying the file down to the client" part? The "Standard Push Distribution" does use bandwidth aware download (and limits usage to 50% of available bandwidth of the client), and other such details - though it does NOT use multicast. You may want to check your clients' "C:\Program Files\LANDesk\LDCLIENT\Data\SDMCACHE\" directory for the path/file of your XP-SP3 binary.
If the file is still in a "partial" state, we're still downloading it (or something broke while downloading it). Once the file has been downloaded 100%, it no longer has "partial" in the name, but is just the normal name (i.e. "xp-sp3.exe" for instance). Once the file is down on the client, you have the actual patch install ... that can take quite some considerable time too (and depends purely on the station) ... and there's little tracking we can do here if the UI is disabled (unless you can find a good log for XP SP3's progress from another source, nothing comes to my mind at this point shy of looking at an MSI log).
The key here is to figure out what's causing you delays - if we're talking about "copying the file down" - that's likely something we CAN do stuff about with configuration settings. If it's the actual install of XP SP3, that can take ages ... (one of the reasons it's recommended to do this one overnight), but that's out of our control.
Hope this helps a bit along the way.
LANDesk EMEA Technical Lead
I have successfully pushed the XPSP3 executable file, but need to install and do not know how to add an unattend file to install the service pack without remoting to each machine to run the service pack question files, i.e next, I agree, next, next questions that are asked when the initial install file is executed once installed to the targetted PC's - any ideas how this can be done via Landesk?
Well, if you had Security and Patch manager it would be automated for you. It would apply to any vulnerable machines.
If you want to create your own distribution Package, you need to research on Microsoft's site (or Google for that matter) the steps to deploy the service pack silently. You may try running the service pack's executable with a /? switch to see if it has silent switches.
Also, I am moving this thread to Software Distribution as the "Installation" section is for LANDesk Installation not 3rd party software distribution installations.
None of the information supplied by replies have helped, would be good if LANDesk had a fuzzy search as even searching through the forums takes longer than doing a search engine search and trying to find a suitable article for an issue and the 2 provided in this are not only not helpful but the stooge who wanted to move this into another area, makes the searching for information harder to find than a blind man in a dark room looking for a black cat that is not there.
Cheers for the no help.
- Download XPSP3 from Microsoft. Make sure to get the full file.
- Put XPSP3 on your Web Share or UNC share.
- Run it with a /? like I suggested and you will get the switches:
- In the Console create a new Distribution Package of type executable.
- Point to the share or web share with that has the file.
- There is a place in the Distribution Package to add the switches you want.
Note: You probably only want one switch: /quiet. But you may also want to use the /norestart if you don't want to reboot right away. Or if /forcerestart if you really want the restart to occur. If you no you don't ever want it uninstalled, you can add the /n switch to not backup files needed for the uninstall. Open a command prompt on a test XP box and try out the switches until you have the ones you want.
- Save the Distribution Package.
- Create a new Scheduled Task.
- Add the distribution package
- Choose your delivery method.
- Save the Scheduled Task
- Drag some nodes to the scheduled task.
- Right-click and choose Start now to start the deployment.
You also have the option to extract the service pack first before deploying it, but I don't recommend using that method with LANDesk if you can avoid it.
- Download XPSP3 from Microsoft. Make sure to get the full file.
No, still did not work comes up with error additional files required, whereas when I was pushing before at least would initiate the install file just needed all the NEXT, NEXT answer files done, seems another fine triumph for this LANDesk application.
Microsoft SMS seems the way to go if you want an application that firstly does what it should be able to do - i.e. install files from a central location and secondly actually reports on success/failures with a correct ratio and gives (in english) a reason if there is a failure, without having to research half a day for maybe a possible 15 failure points and another 25 fixes as to possibly why the install either did not work or to the obtuse failure messages.
Would not recommend LANDesk to any company to implement and horrified that where I am now use this product.
It would help if you'd give a bit more detail on what you've actually done / not done. Bear in mind you're trying to install something rather complicated through a medium which isn't entirely suited (after all - this is what patch management is for).
As hinted above - you can write your own custom definition for it - that way you can include your own scripting as needed. Alternatively, you can use a bit more scripting yourself. Batch-file (see http://community.landesk.com/support/docs/DOC-2320 ), AutoIT (http://www.autoitscript.com/autoit3/index.shtml) - there's lots of ways to automate things.
That way, you can just dump the files on the client, extract them as needed, and throw command-lines at them and/or (with AutoIT for instance) even through GUI's. You just need to find the right path for the right package - and Service Packs can be quite tricky in some instances. Particularly if you're not using something where "the kinks" are already worked out for you (i.e. - patch manager in this instance). We're not saying that it can't be done - because it can - it simply will require a bit of scripting around the problems you encounter from the service pack.
And that's actually also not too hard to do - assuming you have the right tools. AutoIT should - I hope - help you greatly with that, especially if you have any UI-stuff to deal with in the method you chose to go forward with. And - as an aside - you will run into problems with deploying various kinds of software, this is why (re-)packaging the software correctly is a big deal (and the reason why several people make a living our of this).
Which ever tool you use to distribute software at the end of the day, you will run into some kinds of problems. Most will be specific to the software you're trying to deploy. Some may be a combination of the tool you're using and the software (for instance one example in LANDesk -- software installs are done using the LOCAL SYSTEM account, but a few packages do require full Local Admin rights, LOCAL SYSTEM is not enough for those).
It's a little simplistic just blaming the tool for it - if the tool really were "this bad", it's not exactly likely that we'd have as big a customer base as we have, or that the company would've lasted as well as we have. And - as an additional point - there's plenty of help available - this place for instance is one such resource. We're hardly letting you stand by yourself with this - we're happy to help you along.
Some things ARE pretty complex to install, if you need / choose to install them in a certain way. That's a simple reality no matter which tool you use. Anyway - I hope the advice given in this post will help you along some - if automation is your current hangup - check out the tools I pointed out to you, they should help you along quite a bit.
LANDesk EMEA Technical Lead
Sounds to me like you are very frustrated.
I too do not like having to learn a new product to do something when I already know another how another product works and how it can help me do the task I need. Especially when it is not working like it should.
Since you are stuck with using LANDesk at your current company, let me help you get it working.
You mentioned you received the following error: "Error additional files required". Inside the task, if you right click on the device do you have an option to view the log file? If so, please post the log file to the community. This log will help us help you out in your knew work place where LANDesk is forced on you.
Thanks for the replies, but will find a more suitable product that actually works to achieve what I am trying to do rather than use a dinosaur product for the 21st Century.
Another frustrated comment is not helping your situation.
It worked first time for me following those steps.
Works for hundreds of customers.
Frustrated is mildly putting it.
Here is the log file of the failed installation.
The Core Server we are using is called OTTO
However when you look at the first line of the log it is trying to use a preferred server BARNEY, which is not even in LANDesk as it is a Virtual Server.
So why should it try a preferred server which has not been set in the Distribution Package Primary File?
Fri, 21 Nov 2008 11:32:02 Checking preferred server path \\barney\e$\Patches\xpsp3\WindowsXP-KB936929-SP3-x86-ENU.exe instead of \\otto\e$\Patches\xpsp3\WindowsXP-KB936929-SP3-x86-ENU.ex
I have attached the log file and a jpg of the Distribution Package, as I followed PRECISELY previous posts for the push and still fails to work.
How do I force the package to be deployed from OTTO and not BARNEY if this is the error in the first place which makes LANDesk fail?
Stulpy - this is exactly how Preferred servers *ARE* supposed to work.
I'll give you a quick rundown, maybe that'll explain it a bit better / make sense to you.
NOTE - Preferred servers are also covered in the Product Documented - check the LANDesk User Guide ("LDMSUsers.pdf" on your LANDesk CD/install-directory under "docs"). for the following items:
- "Configuring a file server for software distribution" - page 165 of 742.
- "Running packages from the source server" - Page 170 of 742
- "Configuring preferred package servers" - Page 171 of 742 (this explains somewhat more about them).
Now then - the "quick and dirty" variant.
By default, a LANDesk client (any LANDesk client) will behave in the following way ... let's say I want to push "PackageX.exe" that's located on "HTTP://MyLovelyServer/MyShare/PackageX.exe"
Step 1 - The client checks the local SDMCache to see if it already has downloaded the file. So in this case, it'd check for "\MyLovelyServer\MyShare\PackageX.exe" (since we mantain the directory-structure). If the package is not found there, we go on to ...
NOTE - this check is ALWAYS on (with a single exception - we'll get to that in a bit).
Step 2 - Peer download. The client sends a subnet directed multicast message, essentially asking "does anyone here have 'PackageX.exe' with the following hash value cached?' ... the first client to respond with "Yep - I do" is the connected to and the file is downloaded. This is one of the technologies we use to reduce WAN-downloads.
NOTE - Peer Download is ALWAYS on (with a single exception - we'll get to that in a bit - it's the same exception as for Step 1).
Step 3 - Preferred Servers are checked. Let's assume I have a preferred Server "MyLocalServer" configured.
The clients - dynamically - substitutes the UNC/HTTP path as required, and checks whether ""HTTP://MyLocalServer/MyShare/PackageX.exe" exists. Notice that the directory-structure was NOT changed, all we do is substitute the name.
Again, this is a WAN-offloading mechanism, to ensure that if you have your regional file-servers, that this is picked up AUTOMATICALLY, and requires less configuring on your part.
If this fails / if no preferred servers are configured, we proceed on to the final step...
Step 4 - The configured source.
When all the above steps have failed, clients fail over to the originally configured location and will download things from there. We've tried everything we can (at this point) to minimize WAN usage, and if everything else fails ... we have to cross the WAN.
Now - about this "EXCEPTION" that I was talking about... (This is also indicated in the explanation about preferred servers starting on page 171 I pointed to earlier).
You *CAN* circumvent this process - if you configure your delivery method to "download from source". More information can be found here on page 170 of 742 in the user guide, under the topic "Running packages from the source server".
The important point here is about the "download from source" option in the delivery method - when you enable run from source, software distribution WILL NOT download package files to the local cache, NOR will it run the package from a peer. It will still check for a preferred server, but if that fails, it will go on to the configured source.
So it's all about trying to reduce bandwidth usage over the WAN - we're trying (as much as possible) to automatically minimise WAN usage. if you do not want to use these technologies, simply don't configure preferred servers and/or use "run from source".
I hope that this explains what you've been seeing.
LANDesk EMEA Technical Lead
(Use of capitals is used for additional highlighting of important details. I try not to use 'em as much as possible - it's really all there just to mark things clearly ).
It's using it because someone told LANDesk to use this server for clients in that particular subnet - you have a problem because LANDesk is configured incorrectly. Would I be wrong in thinking that you just inherited LANDesk and didn't particularly want it in the first place? It has to be something very similar since your number one priority seems to be to prove that it is useless rather than finding out what you are doing wrong. Lets try to move the frustration out of the way, you can try to throw the product out and if you are the decision maker then that is your prerogative, but if not you need to find a better reason to throw away the investment your company made than you not having the knowledge to make it work.
The path that you are using is unusual in that you use an e$ share. Do you know for a fact that things have been successfully distributed from there before? It is a strong possibility that you have access denied here as well so you need to review all documents related to setting up permissions.
Preferred server setup defines where a package will be located on a server best suited for the client, it also defines the credentials to be used to access those files since LANDesk agents run under localsystem priviledges (please resist temotation to argue against this, there are pros as well as cons - you need to work with this). If your setup for preferred package server is incorrect and the location you are specifying does grant the machine account at least read rights, then this job is doomed to failure.
What you want to achieve is entirely possible without the use of Patch Manager or Security Suite, but it will not be possible for you if you lack the basic knowledge of how the product works unless you allow yourself to be led from first principles. I seriously suggest that you get someone involved (such as your company's ESP - the people that sold you the software) to get you trained and possibly use this situation as an example and walk you through how to get the system configured and working.
If time is against you then go to the preferred servers and review what is set in there. make sure it contains valid servers, those servers have exactly the same share structure as the core server (you use e$ which means e$ would have to exist there as well), and that the credentials provided would allow the rights to access and copy the files. Once you are certain your clients can locate and copy the file(s) then you can concentrate on launching with the correct switches.
Approach this with the patience a learning exercise requires and you will get there and your knowledge will be the better for it. Expect to hit more issues though.
Mark Star - MarXtar LANDesk Enhancements
Home of Power State Notifier & Wake-On-WAN for LANDesk