SMS 2003 software distribution points



Hi,

I've been using SMS 2003 for about 18 months now in a site with about 400
computers. We deploy all our software using SMS. I never had any training
with the product and was thrown into the deep end, so I just worked it out
myself. Now that things have settled down and I understand the product
quite well I am looking to make sure I adhere to common best practices and
hopefully that things are done "right".

I have never used a software distribution point in SMS and I was wondering
if there is anything I am missing out on by not doing so.

All of our packages are MSIs. When I create a package, I choose the option
to "create package from definition" and then I point it to the MSI file. I
choose the "no files in package" option. Once the package is created, I
edit the Programs and modify the default command line that SMS generates.
The default is something like:

msiexec.exe /q ALLUSERS=2 /i "program.msi"

I change it to:

msiexec.exe /q ALLUSERS=2 /i
"\\servername\deploymentshare\programdir\program.msi"

Therefore none of my packages are actually associated with deployment points
and the machines execute the software directly from the location above.
This seems to work fine, but I was wondering whether it's ok to do it this
way?

My site is at a single location and there is a single primary SMS server. I
realise that software distribution points allow packages to be replicated to
many remote sites and that SMS clients will use the nearest distribution
point, so I do understand the nature of what they do. I also understand
that roaming clients can cache packages using BITS from a distribution point
over time until they have the entire thing and then they execute it locally.
I have no need for either of these features.

I guess what I am asking is whether or not the way I am doing things is
"bad". Is there anything inherently wrong with doing it this way? My
deployment share has about 100 Gb of programs in it. I could create a
software distribution point and set them all up that way, but the only thing
that I can see it achieving is that I would have to find 200 Gb of space
instead of 100 Gb, as all the packages would be copied from the source to
the distribution point.

Is there any functionality that I am missing out on (other than the features
I already mentioned that I understood and have no need for)? Is my method
"bad" in a single site with only 1 SMS server?

Cheers,
David


.



Relevant Pages

  • Re: SMS2003 parent with sms 2.0 children and SUS
    ... version in those packages. ... If you do all of that, then your 2.0 clients at the child sites will ... work when advertised from a 2003 site to clients of a child 2.0 site. ... The Dell Update scan tool will only work on SMS 2003 SP1 advanced clients. ...
    (microsoft.public.sms.setup)
  • Re: Testing packages in SMS 2003?
    ... You must mean SMS 2.0, ... With 2000 I would advertise unassigned packages ... > 2003 and am beginning to regret the upgrade. ... > View|Refresh in Advert prog monitor in 2000). ...
    (microsoft.public.sms.admin)
  • RE: does SMS distribution support multicast?
    ... Set up a share on a client in the network you'd like to advertise packages ... Setup a "Server Share" in sms to point to that share. ... Then since you've transferred the package to a client using BITS, ... SMS server could support multicast so that not all access to the SMS server ...
    (microsoft.public.sms.swdist)
  • RE: SMS 2003 user profile migration
    ... registry section in-place will stop further reruns of packages. ... Both domains have SMS 2003 installed and running; ... When I login with the user id in the new domain; SMS tryes to install ... bealived some how SMS keeps track of the SID and because when I ...
    (microsoft.public.sms.admin)
  • Re: SMS 2003 - Mandatory packages for Advanced Clients
    ... Why do you need to even make the packages manditory at that point? ... Microsoft MVP - SMS ... > mandatory packages for that servers onthe advanced client side. ... > turn off software distribution in a soft way or maybe -even better- is ...
    (microsoft.public.sms.swdist)