Catalog.xml and other patch files not getting deployed to clients

[Migration User]

We've recently set up a pilot for altiris 7,1 and ever since installing SP1 to get the new patch management features, we have seen many issues.  We've been able to work through most of them, however now we are stuck at a point where clients are not running their system assessment scans.

It looks as the the catalog.xml and other files that are supposed to be on the client machines inside of the softwaredelivery folder are not making it there for some reason.  The files on the server side look fine (I can read catalog.xml, etc.) and imports for patch data are running successfully.

So far I have not been abe to track down any log errors on either side with regard to the patching solution as of yet.  Has anyone seen this issue before?  If not, can anyone share a little knowledge on the policy/task/process that is supposed to push these files down?  I assume that is supposed to be a part of the system assessment scan process itself.  Any insight on the mechanics of this process would be greatly appreciated.  At this point, no clients are reporting in their scan data and no patch management licenses are showing as in use.

[Migration User]

Futher information...

 

I discovered that the clients are continually trying to download the assessment scan package but are always in a state of retrying.  I looked at the actual package share on one of the package servers and the files there do not match those on the NS under the install dir.  The catalog.xml file in the package share is 0kb.  Still not sure why the clients aren't even able to download these files, but something with the package seems to be messed up.  Unfortunately the package and task associated with the assessment scan is marked as read only, even for our altiris service accuont so i can't modify it or force any updates of the package.

[Migration User]

Is this thread helpful?  Several PM-related issues were described and resolved in this thread:

https://www-secure.symantec.com/connect/forums/patch-management-altiris-71-sp1-windows-system-assement-scan-return-code-6

If you work your way through it, is the 0KB catalog.xml issue resolved?

[Migration User]

Hey mclemson, I did take a look at that thread before starting this one.  The issue seems kind of sort of similar, but not exactly.  I have tried most of the things suggested there, but unfortunately it doesn't seem to resolve the problem.

There don't seem to be actual errors on the client side, they just continually indicate that they are retrying the package download.  The package on the distribution server has not updated since 8/20, so I think whatever process is supposed to update the package servers with the files from the NS is broken.  Unfortunately, I can't really edit or see far into the package or policy for patch since it's all very locked down. 

We did do a reinstall of patch management probably not far from the 8/20 date because we weren't able to download any patch data and had some other issues with the patch agent packages as well.  After the reinstall, we were able to import patch data but have been stuck with agents not reporting in.

Next we tried reinstalling all client agents and got the right versions on, but no dice.  Then I tried doing the reconfig of the patch management component on the NS.  This appears to have had no effect.  The package server where the agents get their downloads from still has not updated, no matter what we do.  Is there a way to force this update without trying to go through the software package?  The package is locked down to the point where I can't initiate an update of the package servers.  Other packages on that particular package server are successfully updating so I know it's not a widespread package issue, seems to just be for the patch files.

I think that is most of what was attempted in the thread you linked... I didn't see the stored procedure errors anywhere in our NS logs so I didn't really follow that line of troubleshooting too much but I think it was similar (reinstall, reconfig, etc). 

[Sergei Kljujev]

Hi nicoled18,

 

Could You be so kind to attach here some additional details: (1) Client policies from problematic Package Server, which reside in Altiris\Altiris Agent\Client Policies dir.

(2) Package Server Log files, collected when retrying download of Windows Assessment Scan. (3) Server Log, collected when running Patch Data Import task - maximum details, if it is possible.

 

Best regards,

Sergej.

[Migration User]

I've attached the following:

client policy xml

nsagent.log - notification server log from the c:\users\public location

nssystem32.log - notification server log from c:\windows\system32

psagent.log - package server log from c:\users\public location

When I look at the "packages" tab on the package server, the patch package shows a ready state and has the appropriate source location from the NS, however it still has old/corrupt files in its location and has not updated since 8/20.  I tried bouncing both machines, restarting iis on the ns, etc. but the package remains at a ready state even though that's not true. 

I did notice on the package server that it had ~80 packages that were pending and nothing was being downloaded... this picked back up after the reboot but the patch assessment package was not one of these.  When the Package Server (or any of the clients for that matter) try to download the package as a part of the policy, however, it indicates that the source files aren't returned by the server and keeps re-trying.  I am beginning to wonder, since everything on the NS looks correct, if the package server install itself has become corrupted somehow.  Maybe a reinstallation is in order in that regard.

 

Some time stamps of note for the logs:

notification server:

1:26pm and 1:31pm for errors w/regard to the patch assessment package as well as communication with the package server

1:59pm is when i initiated the patch import which successfullycompleted

for the package server, 1:23pm is when the altiris agent on the package server was trying to download the patch assessment package (based on the policy for the assessment).

Attachment(s)

milaltirismp01.artisanpartners.com_.xml   1.53 MB 1 version

PSAgent.log_.txt   4 KB 1 version

NSAgent.log_.txt   39 KB 1 version

NSSystem32log.log_.txt   481 KB 1 version

[Sergei Kljujev]

nicoled18,

Looks like assessment package is generated on NS correctly, but somehow fails to reach Package Server. As a metter of fact I don't think that Package Server plugin reinstallation would help - problems seem to be rather on the server side.
For a further investigation, You could dig into problematic package server, Package delivery folder:
C:\Program Files\Altiris\Altiris Agent\Package Delivery\{6D417916-467C-46A7-A870-6D86D9345B61}. There are several files in there: log.xml, package.xml and snapshot.xml. They all carry information, of where this package was downloaded from and what are the exact contents of this package.

Please, analyze them for any clues of problem's cause - and attach them here, with any Comments/thoughts. You can refer to Article How the Altiris Agent obtains Package Codebases (download sources) for details on investigation.

Cheers,

Sergei

[Migration User]

Ok, so here is what I have found... it looks like there is possibly a package versioning discrepancy on the package server.  In comparing to another working package, I saw that the "package version" was the same across log.xml, package.xml as well as the client policy xml. 

 

However, here is what I found for the patch assessment package...

From Client Policy XML

- <SoftPkg Name="Patch Windows System Assessment Scan Tool Package" displayName="" Id="{6D417916-467C-46A7-A870-6D86D9345B61}" Version="7.1.0.0" InternalVersion="1316107514" Originator="NS" Destination="" CleanupAfter="-1" Priority="Low" StatusEventsEnabled="true">
- <PackageDescription>
- <![CDATA[ Patch Windows System Assessment Scan Tool Package
  ]]>
  </PackageDescription>

 

 From "log" XML
- <Download version="1313897341" status="valid" statusDescr="valid" transferBytes="2574733" packageSize="5316357">
  <Session startTime="2011-08-21 14:58:59" endTime="2011-08-21 15:01:35" source="http://milaltirismp01.artisanpartners.com/Altiris/PackageShare/{6d417916-467c-46a7-a870-6d86d9345b61}" transferRate="160920" transferBytes="2574733" transferCache="2741624" result="0" />
  </Download>
 

From "package" XML
<Package id="{6D417916-467C-46A7-A870-6D86D9345B61}" name="Patch Windows System Assessment Scan Tool Package" size="0" version="1313810934" remote="false" priority="Normal" status="valid" minspeed="0" enableMulticast="false"

 

From "snapshot" XML
- <Snapshot id="{6D417916-467C-46A7-A870-6D86D9345B61}" path="e:\Program Files\Altiris Agent\Package Delivery\{6D417916-467C-46A7-A870-6D86D9345B61}\cache" time="2011-08-20T22:29:01" version="1313897341">
 

 

I see several different "versions" for the same package throughout these four files... I imagine this could cause some issues with the package server not knowing that it is supposed to be updating.  Even the example in the link you provided has the versions the same throughout.  However, I'm not sure how to fix this.  As far as I can tell, there is no way to initiate an update from the NS through the web interface since the package is locked down... how cany I make the package server force an update of the content for that specific package?    I can see the problem right in front of me, but I am not sure what step to take next to make this package server realize that the content for this package is out of date.

By the way, thank you for your help thus far!

[Migration User]

Update Distribution Points

1. Manage > Software 
2. Open the software resource
3. Under the Package tab, click on the package
4. Right-click the package and choose Update Distribution Points (or use the Actions menu with the package highlighted)

Might have to go to Manage > Resource.. and choose Package from the list since this isn't a software resource.  Find the resource in the list, select it, choose OK, choose More Actions > Update Distribution Points.

[Migration User]

Unfortunately "update distribution points" is not an option, even in the Manage>Resource view.  This particular package appears to be locked down so much that I cannot even do that.

[Migration User]

This ended up being a package server issue. 

I had to delete the client policies xml file, the aexswdpolicy.xml and the snapshot.xml of the patch assessment package, restart the server and then do a refresh/resend packages.  I left it to sit overnight and it refreshed all of the packages including the patch assessment package.  This is now updating on the distro point properly and getting out to the clients which are successfully reporting in patch data.

I have a newly discovered but related issue, however.  It looks as though all of the patch packages that were downloaded Pre-SP1 are still on the package server but they are not seen as actual packages by the NS.  There aren't associated guid entries for them in the client policy xml on the package serer and they aren't represented in the Package Server tab of the agent.  So it looks like the old patch packages are just sitting there taking up (a lot of) space.

Aside from looking at each package individually and verifying whether it's valid and deleting it if it's not, is there a way to clean this up?  Can I just delete EVERYTHING in the package delivery folder and let it re-synch?  The package server things it has ~8000 packages.  However, if I look in the package deliver folder, there are about 11,000 package subfolders.

 

Any thoughts?  I may just end up uninstalling altiris on this server and re-setting it up fresh.

[Sergei Kljujev]

Hi nicoled18,

Actually, those packages should be deleted physically after one week (by default). This is managed through Settings -> Notification Server -> Site Server Settings -> Site Management -> Settings -> Package Service -> Package Service Settings. Setting is "Delete Package files if they are unused for".

Are they still exist on disk?

[Migration User]

Yes, they still exist on disk but they are not even recognized as packages on the NS and they do not exist on disk on the NS, just on the package server. 

Our "Delete if unused" is set to one year, not sure why.  If the NS doesn't even recognize these packages as legit, will turning the setting to one week actually delete them?

[Sergei Kljujev]

That's the case - "Delete if unused" means period, package files are hold on Package Server, after Package Database items are deleted from CMDB. So, in Your case packages files will be deleted after a Year.