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.

Hi here is an update from my side. We scheduled the System_Discovery starting at 10:15 (every two hours). The timestamp for the data discovery records are 10:15:00 totally independent when the client is exactly detected. The heartbeat data timestamp as mentioned in my last post is somthing like 10:00:35. The result was perfect. The heartbeat ddr was delivered before the system discovery ddr was available. No more timestamp errors in the logs. The only outstanding question is why is the heartbeat schedule not considered. Any know bugs? Cheers Joachim

Hi not sure if somebody still have this issues. We have a lot of those entries in our logs. This is critical in our environment because some collections are dependent on a successfull System_discovery. This update is not written to the database because newer entries are detected. 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 doesn’t have anything to do with time zone, though. The next step regarding this statement was to examine why is the heartbeat data newer than the system discovery data. I looked into the client schedule log and recognized that a DDR is created each hours instead every week as configured. So for example if a system discovery is scheduled every two hours also a heart beat discovery data is schedule on the client. It seems that the heartbeat data is always newer because system discovery logged e.g. 11:00 and heartbeat data logged as 11:00:xx. The question is why is heartbeat data delivered each hour when configured to send only once a week? A DDR is sent to the management point. (MP_DDR.log). Thanks Joachim

Again an update. The heartbeat was configured to occur once a week resulting in a ddr sent each hour. We changed the configuration to update the ddr via heartbeat every 6 days. The hourly entry to sent a ddr in the client schedule.log is gone so we expect every 6 day the ddr is updated. No sure but it seems that the weekly scheduled heartbeat discovery leads to deliver it every hour. Is that a bug which wasn't detected by anyone or maybe I misunderstand the whole stuff. Cheers