I'm noticing several DDR's being rejected in ddm.log because their timestamp is older than the existing records timestamp. I'm working in a multi timezone environment and it appears that systems discovered from AD are not having their attributes updated because the heartbeat ddr has a more recent timestamp. Is this how this is supposed to work? I did not notice this in SMS 2003. Thanks Steve

I have seen this in sms as well although I am not 100% positive it was on ddr's could have been hardware inventory.

I've emailed dev on this, and when I get a response back, I'll update the post. I am not aware of any difference here, but that doesn't mean there aren't differences :-)

Any Updates on this issue. I am facing exactly same issue. Appreciate your help.

Nope I never got a response from dev, so just asked again. If I get an update, I'll post it here.

I did get a response from dev. Here's what I was told: We did change the behavior in v4 to treat heartbeat with a higher priority than AD. The intent is that AD will not overwrite heartbeat data. At the same time, heartbeat should not overwrite properties that only are reported through AD. This doesnt have anything to do with time zone, though. What message does the customer see in ddm.log? Is it DDR was rejected because it did not contain any new information.

Thanks for the reply. The error message received is the subject. I think that its problematic that new AD DDR's won't be discovered when their was a recent (or future) DDR generated by heartbeat discovery. Let's say a system changes it OU and you have a software distribution based on that, well you don't want that DDR ignored because a heartbeat discovery has taken place recently or has a future date (because the heartbeat was in a future timezone than the timezone where the AD discovery is taking place). This isn't a huge problem with the default weekly heartbeat, but daily or more frequent heartbeats can start creating problems with AD Discovery. This is especially true now that AD discovery is being used for more than just basic system discovery but also for extended attributes.

DDR timestamp of "3/2/2008 7:00:01 PM" for agent "SMS_AD_USER_DISCOVERY_AGENT" is older than existing record's timestamp of "3/2/2008 7:00:02 PM" DDR timestamp of "3/2/2008 7:00:01 PM" for agent "SMS_AD_SYSTEM_DISCOVERY_AGENT" is older than existing record's timestamp of "3/3/2008 3:28:10 AM" The above two are errors which I see in DDM.log

I had a very aggressive Discovery schedule on all my primary sites which resulted in a lot of backlog in DDM.box. I have adjusted this to once a day and I am no longer facing the issue of backlogged DDR's. Theheartbeat discovery is done once a week. Eventhough the error for "DDR Timestamp" occurs everyday the count of these error messages has drastically reduced. Will these errors keep comming becuase of the change in the way in which SCCM handles discovery? Please suggest.

I've asked dev a couple of times for updates, and not received anything. So, I can only suggest opening a case with product support and have them repro it. If so, they can file a bug on it. Sorry I can't do more.

Will do. Thanks for your help. Cheers.

Certainly post back the response when you get it figured out.

----------- I literally FORGOT about this until This issue resurfaced yesterday------------------------ And then I remembered that I had to post the response for this.The issue was really a convergence of three things 1: SCCM can process the data faster than SMS did 2: We had the discovery configured to overlap 3: We were running discovery on different sites so close together if we Alter any one of the things mentioned in Last 2 and the problem should be taken care of.The First one is something MSFT did to help make SCCM less susceptible to inbox backlogs that SMS was. @ Wally... Someone Said "Better late than Never" .... Apologies for forgetting to post the response.