3 Replies Latest reply on Aug 15, 2012 4:21 PM by AspenSkier

    SD fails because? reliance on preferred server?




      I think I have a pretty simplistic landesk & network environment that is being needlessly complicated by the LANDESK PREFERRED SERVER functionality of LDMS 9.0 SP3.  I'm wondering if someone might be able to explain some problems I am seeing.


      currently things look like this:

      I have a landesk core server which shouldn't really have anything to do with software distribution packages.

      I also have a technology share on a NAS appliance which contains all of my software packages and device drivers.

      In order to get HII to work I had to configure the landesk core as a preferred server...I couldn't get HII to compile my device drivers without a preferred server.  I though, okay whaterver.

      I have no active content replication taking place nor do I want any.

      In fact, I really don't want any preferred servers.  I simply want my landesk core and my tech share on the NAS and I don't want them to mix.


      A while ago things looked like this:

      A few months back I remember configuring my tech share to be a preferred server somehow and I don't remember why.

      I did not have any content replication taking place; I'm sure of this.

      Then about a month ago I deleted all of my preferred servers by mistake and the only one that I rebuilt was the LANDESK CORE because I needed it for HII support.



      Here is my problem.  I have some software distribution tasks that simply won't run anymore.  I think this has to do with preferred servers and the fact that I don't really have any.  I recall looking at some log files when I discovered that things were broken and saw that SD tasks were looking to my landesk core as the preferred server and were ignoring the fact that my SD PACKAGES were configured to look at files on my tech share.  My work around was to create a delivery method which uses "RUN FROM SOURCE TO DEPLOY FILES" rather than multicast or download from source.  This sort of worked but now I am finding more tasks that used to work and now don't.  I don't really want to get into more work arounds, instead I want to solve the underlying problem and restore the functionality to tasks which used to work but now don't.


      So my questions are these:


      Since my tech share IS the preferred location for my SD PACKAGES, and is in fact the only place where they live, is there a way to bypass or turn off the preferred server functionality so that all SD TASKS look to the tech share and no other location?


      short of that, is there a way to simply tell landesk that my tech share is a preferred server without having to create some content replication on another server?

        • 1. Re: SD fails because? reliance on preferred server?
          MarXtar ITSMMVPGroup

          You can set anything to be a preferred server without needing replication. What will happen is that you can set these servers to service IP ranges. If you don't set this, then the client will decide which to use based on the closest/fastest link.


          So if you have a situation where HII will only really be done for machines in a particular network, then you could set your core server to service that IP range only and leave the other (your NAS device) to service everything else.


          Preferred servers aren't intelligent. All that happens is that the server name you specify in the package definition is replaced by the server name of the preferred server for the location of the device. So therefore, as long as you can consistently get the right server to respond and that server holds the packages already (no need to replicate), then everything works.


          Now, if you have a gateway appliance and want to distirbute, then the package need to be on the core server so you'd set replicate to replicate from your NAS device to the core.


          Hope this helps.


          Mark McGinn

          MarXtar Ltd


          LANDesk Silver ESP


          The One-Stop Shop for LANDesk Enhancements

          - Wake-On-WAN - Distributed Wake-On-LAN, Scheduled Power Down, and SWDist Sequencing

          - State Notifier - Real-Time Device & User State Inventory Updating & Alerting

          Update - WoW & State Notifier now integrate for even more functionality

          • 2. Re: SD fails because? reliance on preferred server?
            zman Master

            So the preferredservers.CORENAME.dat should be rebuilt whenever a user runs an app from Desktop Manager. On the machines in questions, check the .dat and see if your core is listed, also make sure the path in the distribution package is pointing to your tech share. I would also reset the package hash and restart the scheduled task just o be sure. If this still fails, contact support. I know of one defect with preferred server and download from source.


            Download from source is a workaround, also creating a package wrapper (batch or script that simply calls the exe/msi from where you want it).

            • 3. Re: SD fails because? reliance on preferred server?

              Thank you gents,


              Any talk about gateways and different IP ranges for various preferred servers is beyond the scope of my simple network's needs.



              All of my SD packages are currently pointing to \\tech\Packages\superlameSoftware01\crappyapp.msi for example.


              My tasks seem to want to point to \\landesk\Packages\superlameSoftware01\crappyapp.msi instead, because \\landesk is my only preferred server because I have to have one for the HII to work.  And this is the problem because the landesk core does not have any software packages on it.


              Based on Mark's comments it looks like I need to create a preferred server for my \\tech share.  This will work because it matches the SD package locations exactly.  I've done this but left everything blank except for the server name and read-only credentials.  Is this enough info to get my landesk agents to pull SD packages from the tech share?



              Based on Zman's comments I am wondering what the delivery method should look like for a scenario where I am trying to do a work-around?  I have several .BAT packges simply because I couldn't get .EXE or .MSI installations to work whenever I had multiple files associated with the package.  <gee I wish SD suppored .ZIP packages the way that patch manager does>  In these cases I simple have a NET USE line in the .BAT file and point the client to run the install from the \\tech share directly.  I supply the same read-only credentials as I specified in the \\tech preferred server setup.  In this way I just need a single .BAT file to go down to my clients and then they can install the software from the network using UNC paths.  Can you tell me what my delivery method should look like to ensure reliability?