Error in Active Directory System Discovery (0x80005010)
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 very large number of computer 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?
回答
Active Directory System Discovery ... adsysdis.log.
I think there is some confusion going on in that thread. AD system discovery (adsysdis.log) does NOT add OU information; it's AD system GROUP discovery (adsysgrp.log)!
[...]
INFO: discovered object with ADsPath = 'LDAP://<domain controller>/<DN computerobject>'
WARN: Could not get property (domain) for system (0x80005010)
"Could not get property (domain)" is just a warning (no error) and does not prevent a DDR from being generated (at least what I've seen in my testlab). (I wasn't able to find "domain" as an attribute for a computer using ADSIedit). So I do see no problem in Trumpeteer's posting (except for using the wrong discovery method).
WARN: Could not get property (operatingSystem) for system (0x80005010) SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
Those warnings (properties domain, dNSHostName, operatingSystem, operatingSystemVersion) are not a real problem IMHO. Just double check those attributes for that computer using ADSIedit. The problem is "Failed to get IP Address for the system", that's why no DDR is generated. ConfigMgr must be able to resolve the name in order to generate a DDR.
WARN: Could not get property (operatingSystemVersion) for system (0x80005010) SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
WARN: Could not get property (domain) for system (0x80005010) SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
WARN: Could not get property (dNSHostName) for system (0x80005010) SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
ERROR: System SRV3 is a unsupported operating system, unsupported version, or malformed AD entry. Reported system type is: (). SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
WARN: CADSource::ProcessSystemInfo: Failed to get IP Address for the system. SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)- 回答としてマークTrumpeteer 2009年12月8日 14:14
すべての返信
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 very large number of computer 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 too am getting the exact same error. I'm also running SCCM 2007 R2 SP2. Looking at the AD schema, I don't even see that "domain" is an attribute of a computer object. Does anyone know how SCCM is supposed to obtain this attribute?
Victor S. - Enterprise Integration Solutions, RCM Technologies- I have this exact same issue with the same version. I may be calling microsoft in the next day if i cant find an answer.
- 回答の候補に設定fritschetom 2009年12月8日 13:25
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_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
INFO: Processing search path: 'LDAP://CN=COMPUTERS,DC=MY,DC=DOMAIN'. SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
INFO: Full synchronization requested SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
INFO: DC DNS name = 'dc01.my.domain' SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
INFO: search filter = '(&(objectClass=user)(objectCategory=computer))' SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
INFO: ads path = 'LDAP://dc01.my.domain/CN=COMPUTERS,DC=MY,DC=DOMAIN' SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
INFO: Bound to 'LDAP://dc01.my.domain/CN=COMPUTERS,DC=MY,DC=DOMAIN' SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
INFO: discovered object with ADsPath = 'LDAP://dc01.my.domain/CN=TEST1,CN=Computers,DC=MY,DC=DOMAIN' SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
WARN: Could not get property (domain) for system (0x80005010) SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
INFO: discovered object with ADsPath = 'LDAP://dc01.my.domain/CN=COMP2,CN=Computers,DC=MY,DC=DOMAIN' SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
WARN: Could not get property (domain) for system (0x80005010) SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
INFO: discovered object with ADsPath = 'LDAP://dc01.my.domain/CN=SRV2,CN=Computers,DC=MY,DC=DOMAIN' SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
WARN: Could not get property (domain) for system (0x80005010) SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
INFO: discovered object with ADsPath = 'LDAP://dc01.my.domain/CN=SRV3,CN=Computers,DC=MY,DC=DOMAIN' SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
WARN: Could not get property (operatingSystem) for system (0x80005010) SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
WARN: Could not get property (operatingSystemVersion) for system (0x80005010) SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
WARN: Could not get property (domain) for system (0x80005010) SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
WARN: Could not get property (dNSHostName) for system (0x80005010) SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
ERROR: System SRV3 is a unsupported operating system, unsupported version, or malformed AD entry. Reported system type is: (). SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
WARN: CADSource::ProcessSystemInfo: Failed to get IP Address for the system. SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)- I am also getting this message! Same version as well.Help!
- Hi,
In my case there was a problem with client registration on DNS server so I added the record to it after that I've had to flush the dns cache on the sccm server .
that's all. It's working now.
Lara
lara - I am having this problem as well now. The PC pings just fine so it will detect an IP address but whatever domain attribute it is looking for isn't found.
- 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 R2
Cheers Active Directory System Discovery ... adsysdis.log.
I think there is some confusion going on in that thread. AD system discovery (adsysdis.log) does NOT add OU information; it's AD system GROUP discovery (adsysgrp.log)!
[...]
INFO: discovered object with ADsPath = 'LDAP://<domain controller>/<DN computerobject>'
WARN: Could not get property (domain) for system (0x80005010)
"Could not get property (domain)" is just a warning (no error) and does not prevent a DDR from being generated (at least what I've seen in my testlab). (I wasn't able to find "domain" as an attribute for a computer using ADSIedit). So I do see no problem in Trumpeteer's posting (except for using the wrong discovery method).
WARN: Could not get property (operatingSystem) for system (0x80005010) SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
Those warnings (properties domain, dNSHostName, operatingSystem, operatingSystemVersion) are not a real problem IMHO. Just double check those attributes for that computer using ADSIedit. The problem is "Failed to get IP Address for the system", that's why no DDR is generated. ConfigMgr must be able to resolve the name in order to generate a DDR.
WARN: Could not get property (operatingSystemVersion) for system (0x80005010) SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
WARN: Could not get property (domain) for system (0x80005010) SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
WARN: Could not get property (dNSHostName) for system (0x80005010) SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
ERROR: System SRV3 is a unsupported operating system, unsupported version, or malformed AD entry. Reported system type is: (). SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)
WARN: CADSource::ProcessSystemInfo: Failed to get IP Address for the system. SMS_AD_SYSTEM_DISCOVERY_AGENT 19.11.2009 17:11:15 5360 (0x14F0)- 回答としてマークTrumpeteer 2009年12月8日 14:14
I think there is some confusion going on in that thread. AD system discovery (adsysdis.log) does NOT add OU information; it's AD system GROUP discovery (adsysgrp.log)!
"Could not get property (domain)" is just a warning (no error) and does not prevent a DDR from being generated (at least what I've seen in my testlab). (I wasn't able to find "domain" as an attribute for a computer using ADSIedit). So I do see no problem in Trumpeteer's posting (except for using the wrong discovery method).
Those warnings (properties domain, dNSHostName, operatingSystem, operatingSystemVersion) are not a real problem IMHO. Just double check those attributes for that computer using ADSIedit. The problem is "Failed to get IP Address for the system", that's why no DDR is generated. ConfigMgr must be able to resolve the name in order to generate a DDR.
I'm seeing the same error, "Could not get property (domain)", in both, the AD system discovery log and the AD system group discovery log. The other attributes are OK. In my case, it does seem that the DDRs are being created and applied to the systems' properties. The only issue I am noticing is that two records get created in the SCCM database for some of the systems with one record using the NetBIOS domain name and the other using the AD FQDN. One shows the source of the discovery as heartbeat and client install while the other shows the AD system and system group discovery methods. I am not sure though if the issue is being caused by this or by the Operating System Deployment process, where new PCs are joined to the domain automatically with their MININT- name, then renamed later. (This is changing in the new OSD process we're getting ready to implement.) Both records have the same name and show that the previous name was MININT-. In fact, other than the domain name being the short name versus the long name, all other attributes are identical.
Victor S. - Enterprise Integration Solutions, RCM Technologies- 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.Exactly! The terminology used to mee still seems confusing...
- I upgraded to SP2 yesterday and I'm also getting the same errors in adsysgrp.log. I take it there is no current resolution and it is not something to be concerned about?
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.- Mine are in AD system group discovery and also in system discovery log. I get this error: WARN: Could not get property (domain) for system (0x80005010)
DDRs are generated and AD system group and system discovery seem to be working fine. 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.- Hi Torsten,
I hear what you're saying, but it still doesn't make a lot of sense. A "Warning" means "it's not a problem, but look out", as opposed to "Error", which of course means "this is a problem".
In any event, many people here are reporting that the attribute "domain" is being requested - by the "Active Directory System Discovery" method, not the "...SYstem Group Discovery" method - showing it's not an isolated configuration issue. It's filling up my logs with needless noise, making Trace32 harder to use :).
The attribute is marked as "System", which the online help says means the discovery method requires this attribute. Yet it doesn't exist; I've ignored ADSIEdit and simply looked for it in an LDIFDE query of a couple of OUs, and not found it - it may exist in the schema, but for a different object class than "computer" - perhaps it exists as part of the "user" class, and the same list has been created for the User Discovery method, and then ported across to System Discovery in error?
As an MVP, any ideas when this might be remedied? I realise it's far from a show-stopper, but to be fair it's not good design either.
Thanks for your time,
Stevie
Stevie Lamb - 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 impact
I'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- 回答の候補に設定Victor Meyer 2010年1月18日 23:52
- 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
