I have several remote servers (about 16) that are being utilized as file servers that have many binaries on them to be used by users and remote site admins for content. Can I have SCCM just use these pre-existing locations as package sources, or is this not considered best practice? 

Or

Should I create just one package source within close proximity to the Site Server, or on the Site Server itself?

Thanks

The primary site server is responsible for grabbing the source data and turning it into packages for Distribution points.  so while you can use ANY UNC to be a source location for content, you should be aware of where that content exists in regards to your primary site server.  If your source content is in Montana but your primary server is in California ... there's going to be a WAN hit ... even if the DP it's destined for is also in Montana.

Second, I strongly recommend locking down your source UNC path so that only the servers and SCCM admins can access it.  This will prevent side-loading of content  as well as any "accidental changing" of folder structure that could cause your applications/packages to go crazy.

Put the two together and I typically recommend you create a DSL (distributed source library) share and slowly migrate all your content into it as you create your packages/applications.  You can then safely create batch installers, manage content versions, and other things without fear of someone running something out of context.

 

• Edited by Justin.King 11 hours 23 minutes ago

As Justin said, keeping the source close to the primary site server should be a first consideration.  Depending on the environment in which I am working, I use a share on the primary site server or possibly a DFS share that is locked down appropriately.

Jeff

The primary site server is responsible for grabbing the source data and turning it into packages for Distribution points.  so while you can use ANY UNC to be a source location for content, you should be aware of where that content exists in regards to your primary site server.  If your source content is in Montana but your primary server is in California ... there's going to be a WAN hit ... even if the DP it's destined for is also in Montana.

Second, I strongly recommend locking down your source UNC path so that only the servers and SCCM admins can access it.  This will prevent side-loading of content  as well as any "accidental changing" of folder structure that could cause your applications/packages to go crazy.

Put the two together and I typically recommend you create a DSL (distributed source library) share and slowly migrate all your content into it as you create your packages/applications.  You can then safely create batch installers, manage content versions, and other things without fear of someone running something out of context.

 

• Edited by Justin.King Tuesday, February 24, 2015 12:51 AM
• Proposed as answer by Jason SandysMVP 21 hours 37 minutes ago

As Justin said, keeping the source close to the primary site server should be a first consideration.  Depending on the environment in which I am working, I use a share on the primary site server or possibly a DFS share that is locked down appropriately.

Jeff

• Proposed as answer by Jason SandysMVP 21 hours 37 minutes ago

Ok that is what I thought as well. What is a Distributed Source Library, or did you just make that up?

Thanks