I think you have a few different questions here:
1. Can I host my packages internally on a different server than our core yet still have them be available via the CSA?
In short no this is not a supported method. You will be required to host any packages that you wish to have available from internally to the outside via the core. Secondly you will not improve performance by going down this route because the traffic will have to go a further distance to the CSA and back to the client.
2. Can I have my agents download files from other sources than via the CSA?
In theory you probably could.
Start by hosting your software some where else such as Amazon, etc. as well as on your Core keeping the same folder structure.
Next change this setting in your Distribution and Patch settings:
Then package your software as Custom Definitions (instead of Distribution packages) and set the Manufacturer's URL as wherever you have hosted the installers.
Next right click on your Custom Definition and click repair.
Change Task settings to Policy, run once, download and execute.
Change Portal settings to Optional (display in portal)
Then assign this the same as your other packages.
3. I don't like option 2, what else can I try?
The other option that you could try is pre-caching your software on devices. Possibly packages that are either high volume downloads or large in size that take too long via the CSA.
This means you would setup two policies for each package but would still be using the distribution package route.
The first policy pre-caches it.
The second policy makes it available to install.
4. I do not like option 3, what else is there?
You can setup another core server and another CSA to help move the hosting closer to those regions. This is the supported option.
5. We have a fair amount of exe and batch file installers that can't be distributed from a web share. Does anyone know of a way around this limitation?
If this is a technical problem of the installers not working properly with out mapping drives, etc. Then you are probably out of luck unless you have an open UNC port from the outside world somewhere - which is discouraged.
If this is a concern about sensitive data being passed over http then you could look at enabling HTTP auth: Can software distribution be setup on an http share, without granting anonymous access?
Traffic from the core to the CSA to the client is encrypted over TLS as well.
I would probably need a lot more information to completely answer this question - but hopefully this helps get you down the right path of what you are looking for.
I just wanted to add a note on one of your comments:
"If we set up our distribution packages to be web sourced, this will increase the load on the core server and possibly slow the installs for the remote offices because they will not draw from their preferred server. Source the distribution packages on UNC and the remotes will pull it from their preferred servers quickly,"
Your remote sites will still pull from your preferred servers if you configure http shares on them, and the clients are in-band. You are not forced to only use unc. The only time your comment above is true is when they are going through the CSA, which I discussed above.
Thank you for the detailed response.
This has definitely pointed me in the right direction. Also, it seems that I had some misconceptions about how LD handles some things.
I did not realize that preferred servers could be set up on http shares. This will definitely help. One issue I have though, is our content is on NAS and I will have to figure out how to set up a web share with off server storage.
The Patch manager solution is an interesting one, but I am just getting into Patch and am far more comfortable with straight up distribution. That may be something that I look into down the road.
One question I have is whether credentials are passed through the CSA when accessing the software repository on the core. You said that the traffic is encrypted, I assume that distribution through the CSA will pass through the preferred server credentials necessary to access the locked down http share, correct?
Thanks again for taking the time to answer this.