Install From Distribution Point or Run from Local cache
Hi,
We are in the process of architecting and implementing SCCM. In the past, we have used DFS to get install files to a branch office and clients would install software from that location.
With SCCM, of course, we can have the client download the installation source from a distribution point and run the program from there.
Some of our packages are very large. 2-3 GB maybe. In that case, have you typically still ran the program from a local source or run directly from a distribution point? I guess it would depend on how close your distibution points are to your clients, no?
We are planning on implementing Internet-based client management as well, so really those clients would have to retrieve the packages and run the programs locally.
Just looking for a little advice for an SCCM n00b. :)
We are in the process of architecting and implementing SCCM. In the past, we have used DFS to get install files to a branch office and clients would install software from that location.
With SCCM, of course, we can have the client download the installation source from a distribution point and run the program from there.
Some of our packages are very large. 2-3 GB maybe. In that case, have you typically still ran the program from a local source or run directly from a distribution point? I guess it would depend on how close your distibution points are to your clients, no?
We are planning on implementing Internet-based client management as well, so really those clients would have to retrieve the packages and run the programs locally.
Just looking for a little advice for an SCCM n00b. :)
0 Comments
[ + ] Show comments
Answers (9)
Please log in to answer
Posted by:
anonymous_9363
14 years ago
As my current client is an all-MSI house, I prefer to have locally-cached copies, if only to facilitate operations which require access to the original source media.
If your mention of package size is concerned with network traffic, have no fear: the transfer process uses BITS. If it's concerned with the disk usage at the client end, I'd say that client-end disk is too cheap to worry about.
If your mention of package size is concerned with network traffic, have no fear: the transfer process uses BITS. If it's concerned with the disk usage at the client end, I'd say that client-end disk is too cheap to worry about.
Posted by:
pjgeutjens
14 years ago
Some of our packages are very large. 2-3 GB maybe. In that case, have you typically still ran the program from a local source or run directly from a distribution point? I guess it would depend on how close your distibution points are to your clients, no?
In the end, whether you cache locally or not, the application will have to go across the wire no matter what. The point where I see the biggest difference is for repair and self-healing purposes (if we're talking more than what the default cached installers in %windir%\Installer can handle). With locally installed source you won't have to pull anything across the wire anymore in this case, but you'll lose a degree of "centralisation" in your software management.
Another thing to take into account is installation speed. A direct install over the network will be alot faster than a 2GB+ copy over the network, followed by the same install. Personally, when we're talking very large packages, for me this becomes the most important consideration.
just my 2c
PJ
Posted by:
Jsaylor
14 years ago
It depends entirely on what your priorities are. Directly running programs from the DP will likely be faster, but you lose out on a bit of the resiliency of the local cache (as mentioned above, this cache is not permanent unless you specify it to be though, so can't be explicitly relied upon) as well as the resiliency of BITS. If you lose network connectivity for a moment while directly running a program, that program will fail and have to be run again. With BITS, if you lose network connectivity, you just resume right where you left off.
I've typically not had a problem using the default (and fairly beefy) 5120 MB cache size in SCCM, so as long as your clients can handle that, it should cycle all of your enormous programs through without any problems.
I've typically not had a problem using the default (and fairly beefy) 5120 MB cache size in SCCM, so as long as your clients can handle that, it should cycle all of your enormous programs through without any problems.
Posted by:
DaveHahn
14 years ago
Thanks for the input, it's really appreciated.
A lot of our bigger packages have custom scripts that do a variety of things. In a lot of these scripts, the developers need to know what directory they are starting in. I know in the Program definitions, there is a start in field. If you leave this blank, where does the command start? In the cache folder?
A lot of our bigger packages have custom scripts that do a variety of things. In a lot of these scripts, the developers need to know what directory they are starting in. I know in the Program definitions, there is a start in field. If you leave this blank, where does the command start? In the cache folder?
Posted by:
Jsaylor
14 years ago
The command will start from the cache folder that's created when the program is copied. So if you have a script that simply calls "Thingy.exe," it will actually call c:\windows\system32\ccm\cache\<advertisementID>\Thingy.exe
Does that answer your question?
Does that answer your question?
Posted by:
anonymous_9363
14 years ago
the developers need to know what directory they are starting in.No offence but what sort of developers are they that can't use standard tools to determine what the current directory is?!?
Posted by:
DaveHahn
14 years ago
ORIGINAL: VBScab
the developers need to know what directory they are starting in.No offence but what sort of developers are they that can't use standard tools to determine what the current directory is?!?
You're telling me! :) I know I always find out myself when writing scripts. Just htought I would cover that base if asked :)
jsaylor, yes, that's what I am asking. Thanks!
Posted by:
Barkerd007
14 years ago
One bit of advice I would offer based on a problem we hit when first using SMS...
If you select the "Download First" the content will be downloaded as soon as the PC sees the Advert. If you have the default polling period of 1 hour, all the PCs targetted will start downloading within an hour.
We had a Very Large app which was advertised to many PCs, they all started downloading within the hour and caused lots of network issues (we assumed the download would happen when a user elected to install the advertised program.)
If you select the "Download First" the content will be downloaded as soon as the PC sees the Advert. If you have the default polling period of 1 hour, all the PCs targetted will start downloading within an hour.
We had a Very Large app which was advertised to many PCs, they all started downloading within the hour and caused lots of network issues (we assumed the download would happen when a user elected to install the advertised program.)
Posted by:
anonymous_9363
14 years ago
My understanding is that SCCM now uses BITS for all downloads, e.g. source server to DP and DP to client, for precisely that reason.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.