Symantec Management Platform (Notification Server)

I've been having problems with the Deployment Server "scrape" into NS over the past month and I wanted to see if anyone has experienced a similiar problem.

The "scrape" itself runs and data moves between the Express DB and the Altiris DB with no obvious problems. The problem is that when a computer is moved from one DS group to another the scrape runs and puts the computer into the proper NS collection which mirrors our DS groups. However, the old collection also shows the computer as still being a member. I thought this might be an issue with our Production server so I tried it on our test servers. Here's a summary of what I found:

In DS, created 2 groups, Test and Test2.

Checked NS after scrape ran and both Test and Test2 showed up as new collections under Resources->Deployment Solution Groups like you'd expect.

Created a test computer, TESTPC, and put it into DS group Test. Waited for scrape to run and checked the corresponding NS collection and found that TESTPC showed up under the collection Test (so far so good).

In DS, moved TESTPC to group Test2. Scrape runs and the NS Collection Test2 shows TESTPC listed like you would expect. Checked the NS collection Test and TESTPC still shows as belonging to that collection as well.

So, the scrape seems to capture the computer as it moves from group to group and puts it in the right collection. However, it doesn't remove it from the NS collection that it was in. I can't see that being normal behavior because that creates duplicate records in the NS collections. We use those collections for patch management so besides cluttering up the tables, we run the risk of applying patches to PCs that are no longer in the group.

Altiris support doesn't seem to know much about the scrape process and I've read as many KB articles as I can find about it. This is on DS 6.8 SP2 and NSSP3R8 (with the same version of Deployment Solution as our Deployment Server). Anyone had or having a similiar experience? Or is this a known bug?

Properly explained (like you have done here), there shouldn't be any question about what the DS Scrape is. If there is, you can always ask that the ticket be escalated.

That being said, I'm aware of no known issues. The one thing I would mention is to check your NS automatic collection update schedules. If, after that interval has passed (and you can view in the logs that the collections have been updated) and the membership of the collections remains the same, I would say it's an issue.

NS isn't really real-time, and the DS Scrape is just dumping data into the database, and as far as NS is concerned, it's "just another" group of collections that need to be updated.