Video Screencast Help
Give us your opinion and win with Symantec! Please help us by taking this survey to tell us about your experience with Symantec Connect, so that we can continue to grow and improve.  Take the survey.

How do I prevent clients from getting patches from other Package Servers?

Created: 12 Feb 2014 • Updated: 24 Feb 2014 | 10 comments

My setup is pretty straight forward. We have a NS and PS at HQ and a PS at all of our remote sites. All sites are connected via 10Mb WAN. Currently, if for some reason a package server fails at a site then clients will download SW updates/Patches from another site, most frequently the PS at HQ. this completly saturates the links. I have bandwidth throttled per client but it doesn't take too many clients to saturate a 10Mb link.

I would be OK with SW delivery/Patching to be broken at that site until we can sort out whatever issue is preventing the local package server from servicing the clients in that site. failover to another site is not manditory. 

What is the best way to prevent those clients from contacting other package servers in the company outside their site? I am using SMP 7.5

Operating Systems:

Comments 10 CommentsJump to latest comment

Preppietechie's picture

You'll want to make sure you have a site set up for each location, and the appropriate package server associated with each site. Then, if you enable the "constrain" option for that site/package server, clients will only download updates from their site's package server.  Make sure to not constrain the top level/primary package server, or none of the remote sites will be able to download packages from the primary package server. Let me know if you need any specifics, or if this is a good enough nudge in the right direction.

Bret Brutlag's picture

Actually I do have a question. If I leave the top level unconstrained, I understand why, doesn't the same mechanism that allows the downstream PS download, allow the clients the same?

Preppietechie's picture

That's a good question.  To be honest, I'm not sure I can offer much more details beyond "that's how Altiris works."  I THINK it has to do with the fact that the site isn't really "preventing" the agents from downloading from the primary package server.  Rather, it simply isn't telling the agents that the primary package server is an option.  However, the downstream package servers are specifically told to grab their packages from the primary. 

Someday I hope altiris allows for more of a "peer to peer" download method between agents.  I know that multicast is a great option, but it isn't always the ideal option (at least not for us).

SK's picture

I know a product that provides peer to peer downloading between its agents.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

Bret Brutlag's picture

Thanks, I was under the impression that the contrain option only applied to Site Server to Site Server downloads not the clients. I will enable that. Thanks for the help. 

SK's picture

The constrained and unconstrained ps option is only for ps's.

Ucps's download from either smp or another ucps. Cps's can only download from ucps's.

Clients can download from all three if allowed.

Site maintenance usually prevents clients from downloading from the smp; however, its logic does allow for it.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

SK's picture

Here is the site maintenance logic:

1. Client goes to getpackageinfo. NS checks its ip. If it finds a ps in the same subnet that gas the package, it gives the client that ps's codebases.
2. If no ps in subnet, yhe NS checks for a ps in clients site tgat has the package. If it finds one, it gives the client that ps's codebases.
3. If no ps is found in the clients subnet or site, the NS gives tge client its own codebases.

I have found in the past that if a ps has the package and is in either the clienrs subnet or site, the client will still try and download from tgat ps when the ps is offline, as the NS does not know about the ps's oine status as it runs its logic through ira database.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

JoeVan's picture

I agree, the constrain setting only applies to package servers thus only matters if you have more than one PS assigned per site. 

For what you want, just make sure that only the PS at each site is assigned to that site.  If you eliminate the PS at a site, clients will start downloading from another site.  However, as long as a PS remains assigned, clients will not pull from another site just because the PS is busy or not responding.  They will wait.  With this configuration, you'll want to make sure you monitor the health of the PS closly since if one goes offline, no machines will receive swd policies / patches until it is brought back online.  I created a report that gets sent daily with any PS that has been offline for more than 6 hours. 

Joe VanHollebeke
Systems Engineer

Bret Brutlag's picture

I thnk my best course is for my larger sites to deploy more than one PS at that site. Early in our deployment I had a misconfigured PS server and it crippled the WAN with 400+ clients trying to download from the NS server at HQ. I just need to make sure that doesn't happen again. I have the bandwith contrained but even at 512K max 400 clients maxes a 20Mb WAN pretty fast. I posted the question to support and so far its been deer in the headlights response. IF I ever get an official response I will post that here, but thanks for the sane reply. Any chance you can share your report?

SK's picture

You can either use Altiris Monitor Solution or a different monitor vendor to keep track of your PS's health and to also provide automated remediation actions.

NS 6.0 SP3 provided a PS heartbeat which was unfortunately not included in the 7.x product lines.  Although the functionality was never activated, it was still possible to use it via a custom action and custom inventory.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.