Hi,I've configured Active Directory System Discovery in a SCCM 2007 R2 SP2 configuration. I see several SCCM clients being populated with OU information, but others do not. I've taken a look in the adsysdis.log. There it states for a verylarge number ofcomputer accounts:INFO: discovered object with ADsPath = 'LDAP://<domain controller>/<DN computerobject>'WARN: Could not get property (domain) for system (0x80005010)Afterwards there is no entry that states a ddr is written for this computer object and the SCCM client object is not populated with information.Can someone explain what exactly is the issue, and how to solve it?

I got exactly same issue - SCCM 2007 SP2 two primary sites (one central). AD sctructure got one forest and two domains.Does anyone solved this issue ?adsysdis.log :Starting the data discovery.SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)INFO: Processing search path: 'LDAP://CN=COMPUTERS,DC=MY,DC=DOMAIN'.SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)INFO: Full synchronization requestedSMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)INFO: DC DNS name = 'dc01.my.domain'SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)INFO: search filter = '(&(objectClass=user)(objectCategory=computer))'SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)INFO: ads path = 'LDAP://dc01.my.domain/CN=COMPUTERS,DC=MY,DC=DOMAIN'SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)INFO: Bound to 'LDAP://dc01.my.domain/CN=COMPUTERS,DC=MY,DC=DOMAIN'SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)INFO: discovered object with ADsPath = 'LDAP://dc01.my.domain/CN=TEST1,CN=Computers,DC=MY,DC=DOMAIN'SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)WARN: Could not get property (domain) for system (0x80005010)SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)INFO: discovered object with ADsPath = 'LDAP://dc01.my.domain/CN=COMP2,CN=Computers,DC=MY,DC=DOMAIN'SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)WARN: Could not get property (domain) for system (0x80005010)SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)INFO: discovered object with ADsPath = 'LDAP://dc01.my.domain/CN=SRV2,CN=Computers,DC=MY,DC=DOMAIN'SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)WARN: Could not get property (domain) for system (0x80005010)SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)INFO: discovered object with ADsPath = 'LDAP://dc01.my.domain/CN=SRV3,CN=Computers,DC=MY,DC=DOMAIN'SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)WARN: Could not get property (operatingSystem) for system (0x80005010)SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)WARN: Could not get property (operatingSystemVersion) for system (0x80005010)SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)WARN: Could not get property (domain) for system (0x80005010)SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)WARN: Could not get property (dNSHostName) for system (0x80005010)SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)ERROR: System SRV3 is a unsupported operating system, unsupported version, or malformed AD entry. Reported system type is: ().SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)WARN: CADSource::ProcessSystemInfo: Failed to get IP Address for the system.SMS_AD_SYSTEM_DISCOVERY_AGENT19.11.2009 17:11:155360 (0x14F0)

I am having the same issue too, for those that said they would contact MS, was there any resolution to this problem?Running SCCM SP2 R2Cheers

All,I have contacted microsoft. I saw the same error about domain in my sysdisc log but my main issue is new machines were not being discoverd. Old machines were running fine. what ended up being the cause is I had include groups in my system discovery. Microsoft stated that this was most likely the issue if their ad query found more than 10000 records it would error and not import in all the machines. The 10000 limit would be groups and systems combined. I unchecked the include groups checkbox as i still had ad group discovery already turned on and on its next run everything was found and imported into the sccm database. Hope this helps.

Hi All,Thanks for all he replies. It seems indeed the DDRs are written even if the warnings appear in the log. Still to me it is confusing what discovery methods add which attributes in the SCCM database, especcially the OU's / containers. If I take a look at the attributes added by the AD system discovery it states: ADSPath which is apparently not the OU the machine account is placed......Cheers,Trumpeteer

especcially the OU's That's AD system group discovery.

the same errors in adsysgrp.log Which ones? Are DDRs generated? Is OU or group information added to client records? That thread talks about AD system discovery (not AD system group discovery). Please read me answer from "Friday, December 04, 2009 8:32 AM" again and see if that clarifies things.

DDRs are generated and AD system group and system discovery seem to be working fine. So there's no problem IMHO. The logfile says "WARN" and not "ERROR", so nothing to worry about.

I have no ConfigMgr server right next to me so I can't look up anything right now ... Am I right that you're just "complaining" about some lines in a logfile OR is a discovery method missing functionality (IOW some fields are not populated)?

I have the exact same error and have been working with MS Technical support on this issue.The response I got from them was: - Code 0x80005010 means E_ADS_COLUMN_NOT_SET or "The specified column in the directory was not set." - Tests confirm that we do not see a domain attribute in AD for computer objects - We understand in adsysdis.log you see the Warning but it is not having any impact - We can file a bug about the (domain) warnings but they are not going to be fixed since, again, there is no impactI'm not going to do any more research or work with them but suggest a bug fix gets filed in the next service pack.Hope this helps.Victor Meyer

You're right, Torsten, I'm "complaining". It's really poor practice; someone has thrown imaginary LDAP attributes into the console which they presumably thought existed, or would exist (or perhaps they had aliased them in their environment, who knows?)The point is, when health-checking a system for a customer, it's quite unhelpful when there are lots of warnings in a log, and you then tell that customer "Oh, that's all right - no, don't worry, all the money you've spent buying this software, and my time, isn't wasted, I know what I'm doing, honestly".I can't imagine much development time would be required to, for example, make it possible to simply remove this attribute instead of having it marked as "system" and thus a required attribute. Apart from anything else, surely some processing overhead and storage could be saved (perhaps not much, perhaps so, no time to test).Having now got a healthy infrastructure ourselves, it's still quite embarassing and frustrating explaining all the different "problems", and how not to worry about them - with respect you probably don't want to hear about the others I've raised with either our professional services or MS PSS, confirmed as "issues" but not yet fixed.With all this said, hats off to MS for a great product. Now they need to help us espouce the virtues of this system, by tidying up those things which, while not causing critical problems, combine to make the product look less professionally-designed than it perhaps is.Stevie Lamb

Hello everyone, I wanted to chime in and say I have seen this warning as well, but it has not caused me any grief (warning is ugly, but not an error). But I am wondering if someone out there can explain exactly what will cause AD System Group Discovery to write a DDR for a system? I ask becuase we were looking at a high number of machines that were no longer installed, and we enabled DNS Scavenging successfully. That resulted in AD System Discovery no longer creating DDRs for these old machines, but AD System Group Discovery is still writing DDRs, preventing the machines from automatically aging out of ConfigMgr (everything is basically 1 day old because discovery runs daily). Here's a bit of the adsysgrp.log...INFO: discovered object with ADsPath = 'LDAP://<machine in AD>... WARN: Could not get property (domain) for system (0x80005010) SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT WARN: Could not get property (memberOf) for system TST-MACHINE (0x80005010) SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT INFO: DDR was written for system 'TST-MACHINE' - D:\SMS\inboxes\auth\ddm.box\adhv5pjn.DDR at 2/23/2010 5:0:1. SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT I did find an old SMS 2003 SP2 KB on the same subject, but no mention of it since this fix was included in SMS 2003 SP3 (http://support.microsoft.com/kb/921463). Anyone else see this behavior? I'm not sure if it is a problem with ConfigMgr SP2 or earlier... or if there is something in the AD data that also needs to be purged. Yes, I know that the best solution would be to remove the objects from AD, but sometimes that doesn't happen. I do not remember this being a problem before now, but I really did not notice because the DNS aging was enabled after the SP2 upgrade. Thanks, Mark Collett