Not much is needed in terms of set-up no.
It mainly requires the things you'd expect:
- Oodles of disk space
- Good network card(s).
... it doesn't need a LANDesk Agent as such, since "it" (the preferred server) doesn't get talked to, unless you want to use file replication on it as well.
If it's "just" to be a preferred server (and you've got an existing process around file replication) then it's "essentially" just a case of:
- Giving the client(s) in question a set of credentials to hit up the Preferred Server
... hope that clarifies / explains things? If it's "just" from a side of having clients access it, it's "just" a file server & doesn't even need to know about LANDesk's existence .
Hope this helps / clarifies a bit?
Oh, I was under the impression that clients would automatically talk to the closest preferred server (or peer) that had the files- like in 9.5, only better. You're saying that this is not the case? I have to manually point clients to a particular preferred server in their area? I am assuming this means creating packages and/or templates that explicitly point to "http://MyPreferredServer/MyShare/MyFile.exe " rather than the core. So, in LD 2016, if we have 10 preferred servers throughout our enterprise, I need to create 10 separate software packages for the same executable, each pointing to a different server and then assign the right package to the appropriate clients? This seems like a hell of a lot of work. In 9.5, we pointed everything to the Core and the job handlers sorted out which server was closest and then substituted that preferred server path for the core path that was specified in the package. It no longer works this way?
1 of 1 people found this helpful
Errr - no. That's not what I said (or meant to say).
I explained how the Preferred Server bit "works" as far as the client is concerned. It's a thing that's easy to explain that it just automatically substitutes the server-name in a package location. So that part still works "just fine" - that part works "automatically" if you permit it in the delivery method.
You configure Preferred Package Servers centrally (on the Core) once - and clients just pull down that list & apply the one that applies to them (usually based on networking information). So - you're still just configuring a package 1x ... no panic. Not sure where the wires got crossed, but there's no reason to panic.
The client (in essence) goes through these steps:
- Client gets told by the Core - "Go forth, and download these files. Use Preferred Servers".
- If client doesn't have currently a preferred server list (usually only lives for a max of 24 hrs), it asks the Core for the list.
- Assuming you've enabled the usage of preferred servers, the Client tries to download the file - from the preferred server first, instead of the source (as you'd expect). This is the stuff I (tried to) describe(d) above as "just substituting the server name".
- ... if download is successful - great.
- ... if download from peer fails, it tries to download from other sources as permitted (i.e. - usually the source at this point).
... does that make it clearer?
OK, this is how I originally understood it to work. Thanks for your clarification... I stumbled off course at your mention of giving clients credentials and pointing them to the Preferred Server UNC directly.
What I am after is a set of instructions for setting up a Preferred Server- the actual box. My goal is to create a provisioning template that will build a preferred server for me with all the required software installed and configured (as thoroughly as possible, anyway) so that I can roll one out in short order when we setup a new remote subnet. I presume I must configure shares on the preferred server, add permissions, possibly enable IIS and configure that, etc. However, I cannot find an explicit set of instructions on how to set up this preferred server so that it responds to clients and replicates files from the core. Unless the whole process of configuring the preferred server itself is done automatically when it is defined on the LANDESK Core (via serverside script or SDP or the like), there seems to be a missing set of instructions.
1 of 1 people found this helpful
Here a additional Document
How to set up an HTTP share for a Preferred Package Share <-- only needed if you use http instead of UNC paths
2 of 2 people found this helpful
EDITED to add UNC share command
I have actually been looking up and documenting this exact information. I'm not completely finished yet but here's what I've found so far...
This is based on a newly built system with no custom configurations. i tested this on a Windows 7 system but the features should be the same or at least close on a server.
Below is the list of commands I have so far. I do not currently have the Shared folder setup scripted yet but I'm working on it. This will not setup anything within the LANDesk console so you will still need to go in the console and set that up.
-Commands are case sensitive
-You may not need all of these features but this is what I have enabled and working
-Follow the commands in order as some of them are dependent on previous commands
%windir%\system32\dism.exe /online /Enable-Feature /FeatureName:IIS-WebServerRole
%windir%\system32\dism.exe /online /Enable-Feature /FeatureName:IIS-WebServerManagementTools
%windir%\system32\dism.exe /online /Enable-Feature /FeatureName:IIS-NetFxExtensibility
%windir%\system32\dism.exe /online /Enable-Feature /FeatureName:IIS-ISAPIExtensions
%windir%\system32\dism.exe /online /Enable-Feature /FeatureName:IIS-ASP
%windir%\system32\dism.exe /online /Enable-Feature /FeatureName:IIS-APIFilter
%windir%\system32\dism.exe /online /Enable-Feature /FeatureName:IIS-ASPNET
%windir%\system32\dism.exe /online /Enable-Feature /FeatureName:IIS-CGI
%windir%\system32\dism.exe /online /Enable-Feature /FeatureName:IIS-ServerSideIncludes
%windir%\system32\dism.exe /online /Enable-Feature /FeatureName:IIS-HttpRedirect
%windir%\system32\dism.exe /online /Enable-Feature /FeatureName:IIS-WebDAV
%windir%\system32\dism.exe /online /Enable-Feature /FeatureName:IIS-BasicAuthentication
%windir%\system32\dism.exe /online /Enable-Feature /FeatureName:IIS-ClientCertificateMappingAuthentication
%windir%\system32\dism.exe /online /Enable-Feature /FeatureName:IIS-WindowsAuthentication
Add MIME types:
%windir%\system32\inetsrv\appcmd set config /section:staticContent /+"[fileExtension='.',mimeType='application/octet-stream']"
%windir%\system32\inetsrv\appcmd set config /section:staticContent /+"[fileExtension='.*',mimeType='application/octet-stream']"
Setting up UNC share:
net share SHARENAME=SHAREPATH /GRANT:USER/GROUP,PERMISSIONS
Example (create share Fileserver with EVERYONE=Read and Admin=Full):
net share Fileserver="C:\Software Packages" /GRANT:Everyone,Read /GRANT:Admin,FULL
Setup Virtual Directory:
NOTE - replace the following variables
VIRTUALDIRECTORYNAME = What do you want your virtual directory called?
UNCPATH = What is the UNC path to the directory that this will point to
DOMAIN\USERNAME = User that will authenticate to the UNC path for the virtual directory. Domain piece is required for a domain user.
PASSWORD = Password for user
%windir%\system32\inetsrv\appcmd add vdir /app.name:"Default Web Site/" /path:/VIRTUALDIRECTORYNAME /physicalPath:\\UNCPATH /userName:DOMAIN\USERNAME /password:PASSWORD
Example: %windir%\system32\inetsrv\appcmd add vdir /app.name:"Default Web Site/" /path:/Fileserver /physicalPath:\\ldprefserver\packages /userName:domain\ldsvc /password:MyPass123!
Thank you all for your contributions to this thread. I understand why I was confused initially. In our environment, our Preferred Servers also serve as PXE Reps for provisioning and replication targets for LANDesk replication. I thought this was all one system- all part of the Preferred Package Server role. But it looks like:
- The Preferred Package Server only requires that it be accessible to clients and that it is defined as a PPS on the Core. Distributed availability of the files used in Software Distribution and Provisioning are handled by this service. The PPS does NOT require that a LANDESK Agent be installed.
- The PXE Rep is a separate mechanism that can co-reside on the Preferred Package Server. Distributed availability of the WinPE boot WIMs are handled by this service. The device acting as a PXE Rep DOES require that the LANDESK Agent be installed.
- Replication is a separate mechanism that is optional, assuming you have some other way to replicate data from the core to your PPS. (Not sure if an Agent is required on replication targets and/or the replicator.)
Do I have this right?
Thanks! I did have those links already. I was confused because I was looking at PPS/PXE Rep/Replication as one big process and was confused as to why I could not find any documents that addressed it in this way.
So - if this is resolved / answered, would you be OK with marking the thread as such & marking the answer that helped you out the most, so that it'll included with your question (and can help other folks who may search for the same)? .