3 Replies Latest reply on Mar 29, 2018 3:48 AM by phoffmann

    Preferred Server without IP Address Ranges


      I am new to Landesk so this might be a stupid question... I added a new preferred server for a remote location as the current one will be decommissioned soon. I did not provide IP address ranges as I just kind of wanted to have it ready and I wanted to add the IP ranges once the old server is decommissioned. So after that, suddenly all clients from all locations had this new server in the preferredservers.dat which led to an issue during OS Provisioning. I removed the new preferred server and the issue was gone. So the question is: When I configure a preferred server without IP ranges, will it be identified by ALL the endpoints, also from other locations, as a preferred server?

        • 1. Re: Preferred Server without IP Address Ranges
          phoffmann SupportEmployee

          Effectively - yes.


          If there's no limitation on the IP-ranges, it's "a general preferred server".


          Folks have file-servers (usually in smaller companies), so they use those as preferred servers. Think of the IP restrictions as a means of filtering "Only YOU guys talk to this one...".


          If that's not there, it's an "all hands - have at it!" type situation. So "working as configured" (rather than intended).


          Don't worry - that's pretty much EXACTLY a replay of how I learned my lesson on that topic too .

          1 of 1 people found this helpful
          • 2. Re: Preferred Server without IP Address Ranges

            Good, at least I know what happened now So if I want to create the new preferred server just to start the content replication, I would need to provide any IP range (even invalid one, like - in order to stop clients from contacting this server, right? And once the replication is done, I could remove the old server and provide the new one with valid IP ranges?

            • 3. Re: Preferred Server without IP Address Ranges
              phoffmann SupportEmployee

              That SHOULD work, yes.


              Your approach is the right one ... dealing with the replication first & then "making it go live" once it's ready.


              I've never tried giving a "fake" IP range of 1.1.1.x though -- I usually use more "realistic" ranges that shouldn't cause me grief -- i.e. "" or so, but I don't see why 1.1.1.x shouldn't work (I just get suspicious about inadvertently causing unexpected problems by using truly outlandish IP ranges).


              .. and clients will then pick up the updated preferred server list after you've let it go live.


              Just a note of heads-up ... in order to prevent any unexpected issues, give them a few days of running in parallel, so as to prevent any "oops" situations where clients are trying to reach the old server, haven't picked up the new one from the Core yet (seem to recall we only check every X days for updates), and you'd end up in a situation where it'd be effectively a case of "Hey, old server isn't there so ... I'm gonna go to the source to get it, all right".


              It SHOULD all go well, but being paranoid keeps the job running smoother .

              1 of 1 people found this helpful