Symantec Management Platform (Notification Server)

Got my site server up and running, its in the correct subnet and the pcs on that subnet are showing under that site server.
Just have an issue with patch management. The PCs and site server on that subnet are showing patches status as retrying.
When I click on a patch and check download history it just shows attempts to download. The source listed for these attempts is blank.
Any ideas how to fix this ?

other questions aside :
How do I know the client is downloading the patch from the correct site server.
How do I know the site server has replicated all the patches from the notification server ?

Joe. (any help appreciated)

I posted this earlier but got hung up between proxy sessions, and my elegant prose was lost to history.

Ehem.. Anyway, it can take awhile, with some non-documented kinks for the site server to get it's codebases from the NS, before it can pass it on to it's clients. That's why I like to have the full infrastucture in place before rolling anything out. This includes the site server, and any packages staged, and replicated, prior to advertising to clients.

The packages status can be viewed by selecting settings - notification server settings - site server settings.

You can select either the NS, or the site server, and then services, package service, and you should be able to see the package status there.

As long as the site was setup with the correct boundries, the clients will automatically be assigned to the proper site. In the same location as the above (site server settings) you can see the clients assigned to the sites. Failover, meaning if the site server goes down, has to be configured separately, with the default being, if the site server goes down the clients will get no tasks\jobs, but will still communicate with the NS for basic and regular inventory events.

Hi - thanks for the reply. But you dont seem to have answered any of my questions. I assume from the first paragraph your saying the patch issue is just a matter of time before this fixes itself?

I cant see what clients are assigned to what site server under site settings (I can though under manage jobs and tasks and sort by site server)

The package status only shows me stats for my site server - as my NS does not have package server installed there is no stats displayed for that. How do I know they are both the same.

Is there a way to tell where the client is downloading the patch from (Even though everything is setup correct. I dont want to just assume all is working - not with my ecperience with this product)

1) yes it takes time, it varies from system to system

2) There are alternative ways of viewing client assignment, I listed only one

3) The package service should not be installed on the NS. It really depends on on how your replicate packages. Most people choose to replicate to all, however there are reasons why you may not.

There is no built in report for the package status of all site servers with package status, I'm sure one could be created.

4) Once the site server gets it's codebases, you can check on the client to see where it's downloading from. Until then the behavior takes place, there is no way to determine this. If your sites are setup correctly, the I'll have to say "it just happens that way". That is not comforting, but I have no insight into your system, and that is all I can tell you.

Perhaps one of the other members can provide a better explanation.

2) There are alternative ways of viewing client assignment, I listed only one

I'm not being pedantic and dont mean to be rude - but where can you view clients within site management. I cant see (slightly sidetracked here)

of the site server itself, all registered clients will display in the third box after task service and package service.

Still showing as trying on the Site server and the clients for this site ? any ideas anyone?

I was guessing at most a day. Take a look at the Altiris logs on the site server, and after that the HTTP logs and HTTP error logs. This seems to indicate a communication failure, but we'll need to trace it.