locked
SCCM not discovering all systems in AD RRS feed

  • Question

  • We have recently noticed that systems are not getting discovered and populated in SCCM from AD correctly.    We have one domain in AD and one site in SCCM.  There are actually two issues going on:

    1)  When imaging workstations, the workstations are showing up in the All Systems collection.  However, they do not have a domain or site code assigned to them.  However, if I push the SCCM client to the workstation via the console and select the "Always install (repair or upgrade existing client), then the domain and site will be populated.  Even after doing this, they are still not showing up in the proper collection based on the query we have set up.  The collections mirror the OU structure we have in AD and the queries have always worked up until the last couple days. 

    On the workstatations, all of the SCCM components are installed and the appropriate ones are enabled.

    Here is what is in the clientlocation.log:

    <![LOG[GetCurrentManagementPointEx]LOG]!><time="11:08:36.270+240" date="07-07-2011" component="ClientLocation" context="" type="1" thread="3088" file="smsclientclass.cpp:1039">
    <![LOG[Setting Assigned Site]LOG]!><time="11:08:36.551+240" date="07-07-2011" component="ClientLocation" context="" type="1" thread="3440" file="smsclientclass.cpp:473">
    <![LOG[Assigning client to site '001']LOG]!><time="11:08:36.551+240" date="07-07-2011" component="ClientLocation" context="" type="1" thread="3440" file="smsclientclass.cpp:485">
    <![LOG[Getting Assigned Site]LOG]!><time="11:08:36.566+240" date="07-07-2011" component="ClientLocation" context="" type="1" thread="3440" file="smsclientclass.cpp:922">
    <![LOG[Client is currently not assigned to any site]LOG]!><time="11:08:36.566+240" date="07-07-2011" component="ClientLocation" context="" type="1" thread="3440" file="smsclientclass.cpp:587">
    <![LOG[Removing client site assignments]LOG]!><time="11:08:36.566+240" date="07-07-2011" component="ClientLocation" context="" type="1" thread="3440" file="smsclientclass.cpp:698">
    <![LOG[Raising event:

    instance of CCM_RemoteClient_Reassigned
    {
     ClientID = "GUID:ab6f6ef4-99c4-4880-8d6f-2531496d97b9";
     DateTime = "20110707150836.582000+000";
     LastAssignedSite = "";
     NewAssignedSite = "001";
     ProcessID = 3024;
     ThreadID = 3440;
    };
    ]LOG]!><time="11:08:36.582+240" date="07-07-2011" component="ClientLocation" context="" type="1" thread="3440" file="event.cpp:525">
    <![LOG[Client assigned to site '001']LOG]!><time="11:08:36.582+240" date="07-07-2011" component="ClientLocation" context="" type="1" thread="3440" file="smsclientclass.cpp:653">
    <![LOG[Discover Default MP]LOG]!><time="11:08:36.582+240" date="07-07-2011" component="ClientLocation" context="" type="1" thread="3440" file="smsclientclass.cpp:1359">
    <![LOG[Site Code is 001; Management Point is SCCMMP01.ABC.COM]LOG]!><time="11:08:36.582+240" date="07-07-2011" component="ClientLocation" context="" type="1" thread="3440" file="smsclientclass.cpp:1369">
    <![LOG[Setting Current Management Point]LOG]!><time="11:08:36.582+240" date="07-07-2011" component="ClientLocation" context="" type="1" thread="3440" file="smsclientclass.cpp:863">
    <![LOG[Management Point is SCCMMP01.ABC.COM]LOG]!><time="11:08:36.597+240" date="07-07-2011" component="ClientLocation" context="" type="1" thread="3440" file="smsclientclass.cpp:868">
    <![LOG[GetCurrentManagementPointEx]LOG]!><time="11:08:49.716+240" date="07-07-2011" component="ClientLocation" context="" type="1" thread="3492" file="smsclientclass.cpp:1039">
    <![LOG[Current Management Point is SCCMMP01.ABC.COM with version 6487 and capabilities: <Capabilities SchemaVersion="1.0">

    Excerpt from locationservices.log:

    <![LOG[A Fallback Status Point has not been specified.  Message with STATEID='500' will not be sent.]LOG]!><time="11:08:36.301+240" date="07-07-2011" component="LocationServices" context="" type="1" thread="3440" file="fspclientdeployassign.cpp:53">
    <![LOG[Processing pending site assignment.]LOG]!><time="11:08:36.301+240" date="07-07-2011" component="LocationServices" context="" type="1" thread="3440" file="lsad.cpp:3328">
    <![LOG[Assigning to site '001']LOG]!><time="11:08:36.301+240" date="07-07-2011" component="LocationServices" context="" type="1" thread="3440" file="lsad.cpp:3334">
    <![LOG[LSVerifySiteVersion : Verifying Site Version for <001>]LOG]!><time="11:08:36.301+240" date="07-07-2011" component="LocationServices" context="" type="1" thread="3440" file="lsad.cpp:5321">
    <![LOG[LSGetSiteVersionFromAD : Successfully retrieved version '4.00.6487.0000' for site '001']LOG]!><time="11:08:36.551+240" date="07-07-2011" component="LocationServices" context="" type="1" thread="3440" file="lsad.cpp:5129">
    <![LOG[LSVerifySiteVersion : Verified Client Version '4.00.6487.2000' is not greater than Site Version '4.00.6487.0000'. Client can be assigned to site <001>.]LOG]!><time="11:08:36.551+240" date="07-07-2011" component="LocationServices" context="" type="1" thread="3440" file="lsad.cpp:5452">
    <![LOG[Site and assignment sitecode match. Verifying site version]LOG]!><time="11:08:36.551+240" date="07-07-2011" component="LocationServices" context="" type="1" thread="3440" file="lsad.cpp:4288">
    <![LOG[LSVerifySiteVersion : Verifying Site Version for <001>]LOG]!><time="11:08:36.551+240" date="07-07-2011" component="LocationServices" context="" type="1" thread="3440" file="lsad.cpp:5321">
    <![LOG[LSGetSiteVersionFromAD : Successfully retrieved version '4.00.6487.0000' for site '001']LOG]!><time="11:08:36.566+240" date="07-07-2011" component="LocationServices" context="" type="1" thread="3440" file="lsad.cpp:5129">
    <![LOG[LSVerifySiteVersion : Verified Client Version '4.00.6487.2000' is not greater than Site Version '4.00.6487.0000'. Client can be assigned to site <001>.]LOG]!><time="11:08:36.566+240" date="07-07-2011"

    Excerpt from execmgr.log:

    <![LOG[Failed to instantiate UI Server {C2F23AE4-82D8-456F-A4AF-A2655D8CA726} with error 80004005]LOG]!><time="11:30:10.921+240" date="07-07-2011" component="execmgr" context="" type="3" thread="3836" file="uieventgenerator.cpp:164">
    <![LOG[Failed to instantiate UI Server 2 {E8425D59-451B-4978-A2AB-641470EB7C02} with error 80004005]LOG]!><time="11:30:10.921+240" date="07-07-2011" component="execmgr" context="" type="3" thread="3836" file="uieventgenerator.cpp:222">
    <![LOG[Failed to instantiate Updates UI Server {2D023958-73D0-4542-8AD6-9A507364F70E} with error 80004005]LOG]!><time="11:30:10.921+240" date="07-07-2011" component="execmgr" context="" type="3" thread="3836" file="uieventgenerator.cpp:279">
    <![LOG[Failed to instantiate VApp UI Server {00AAB372-0D6D-4976-B5F5-9BC7605E30BB} with error 0x80004005]LOG]!><time="11:30:10.921+240" date="07-07-2011" component="execmgr" context="" type="3" thread="3836" file="uieventgenerator.cpp:338">
    <![LOG[A user has logged on.]LOG]!><time="11:36:23.381+240" date="07-07-2011" component="execmgr" context="" type="1" thread="3672" file="execreqmgr.cpp:4522">
    <![LOG[Software Distribution Site Settings for the client are missing from WMI.]LOG]!><time="11:24:36.635+240" date="07-07-2011" component="execmgr" context="" type="3" thread="2024" file="softdistpolicy.cpp:1312">
    <![LOG[Software distribution agent was disabled]LOG]!><time="11:24:36.682+240" date="07-07-2011" component="execmgr" context="" type="1" thread="2024" file="execreqmgr.cpp:5868">
    <![LOG[OnVAppSettingChanged, failed to Enable/Disable VApp Client with error 0x80008281]LOG]!><time="11:24:36.775+240" date="07-07-2011" component="execmgr" context="" type="3" thread="2024" file="execreqmgr.cpp:5706">
    <![LOG[Software Distribution Site Settings for the client are missing from WMI.]LOG]!><time="11:24:37.010+240" date="07-07-2011" component="execmgr" context="" type="3" thread="3156" file="softdistpolicy.cpp:1312">
    <![LOG[Failed to instantiate UI Server {C2F23AE4-82D8-456F-A4AF-A2655D8CA726} with error 80004005]LOG]!><time="11:24:37.010+240" date="07-07-2011" component="execmgr" context="" type="3" thread="3156" file="uieventgenerator.cpp:164">
    <![LOG[Failed to instantiate UI Server 2 {E8425D59-451B-4978-A2AB-641470EB7C02} with error 80004005]LOG]!><time="11:24:37.010+240" date="07-07-2011" component="execmgr" context="" type="3" thread="3156" file="uieventgenerator.cpp:222">
    <![LOG[Failed to instantiate Updates UI Server {2D023958-73D0-4542-8AD6-9A507364F70E} with error 80004005]LOG]!><time="11:24:37.010+240" date="07-07-2011" component="execmgr" context="" type="3" thread="3156" file="uieventgenerator.cpp:279">

    2) The second issue that we are seeing is that new servers that are in AD are not getting populated in SCCM.

    On the site server I am seeing:  For servers, once they show up in SCCM, then we normally push the client to that server. We are now unable to do so, as they are not showing up in SCCM, even though they are in AD.

    In the ddm.log file I am seeing:

    DDR timestamp of "07/06/11 08:00:01" for agent "SMS_AD_SYSTEM_DISCOVERY_AGENT" is older than existing record's timestamp  of "07/06/11 08:13:47"           7/8/2011 8:29:36 AM      2968 (0x0B98)

    In the adsysdis.log I can see:

    INFO: DDR was written for system 'PRDADMSERVER' - E:\SCCM2007\inboxes\auth\ddm.box\adsl90ev.DDR at 7/8/2011 8:0:1.     7/8/2011 8:16:40 AM      58316 (0xE3CC)

    Heartbeat discovery is scheduled for every hour.

    AD System discover is scheduled for every 2 hours.

    On thing that concerns me is that in the Inboxes\auth\dataldr.box\badmifs, we have hundreds of these and I am not sure how to deal with them.

    If anyone can provide any insight on this, I would greatly appreciate it.

    Friday, July 8, 2011 2:24 PM

Answers

  • Pre-requisites for AD system discovery are that SCCM computer a/c should have read access to the container which has been specified in LDAP path. Machines should exist in that OU, entry for machine should be in DNS and AD system dicovery should be enabled.  If these things are all configured then its a little weird issue. I wuld suggest that you run site reset since it would reset permissions on all registry and folders including ddm.box. As for AD system group discovery, It will only discover the resources which have been discovered by AD system discovery, Hence dependant on it.
    • Proposed as answer by Adil Muhammad Saturday, June 29, 2013 11:51 AM
    • Marked as answer by Garth JonesMVP Monday, December 22, 2014 2:46 PM
    Saturday, May 25, 2013 2:00 PM

All replies

  • Hi

    Please check the below possible causes.

    1. make sure the Sysyem Container is created & the records are populated inside it
    2. Define the AD boundry correclty
    3. define the account  username & password coerrectly in SCCM

     

     

    Asela Aluthge


    A I Aluthge
    Saturday, July 9, 2011 6:43 AM
  •  

    1. make sure the Sysyem Container is created & the records are populated inside it
    2. Define the AD boundry correclty
    3. define the account  username & password coerrectly in SCCM

     

    Well ... all those items have absolutely nothing to do with discovery. Discovery does work without any boundaries defined and without the System Management container plus there's no account configurable.
    I do not see any major errors in the log snippets above. Just open those DDRs and check if they are generated by the same machines.

    Torsten Meringer | http://www.mssccmfaq.de
    Saturday, July 9, 2011 11:23 AM
  • The first issue might be the exactly issue mentioned in the following article.

    Solution: ConfigMgr 2007 clients may fail to download packages from a Server Share DP with a content hash mismatch error
    http://blogs.technet.com/b/configurationmgr/archive/2010/03/29/solution-configmgr-2007-clients-may-fail-to-download-packages-from-a-server-share-dp-with-a-content-hash-mismatch-error.aspx

    This issue may also occur when pushing SCCM clients to servers. Your second question may be resolved if you resolved the first issue.

    Another possible reason is the Client Push Installation Properties. You should make sure that Servers, Workstations and Domain controllers are all selected.

    Client Push Installation Properties: General Tab
    http://technet.microsoft.com/en-us/library/bb693531.aspx


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    Monday, July 11, 2011 9:04 AM
  • Well, it seems that over the weekend, the servers appeared in SCCM so that I can now push the client to them. 

    Workstations are getting populated in SCCM, however, the collections that they are supposed to be in are not updating.  So, I can see new workstations in the All systems collection, but query based collections aren't getting updated.

    I can see in the adsysgrp.log where the workstations are being discovered:

    INFO: discovered object with ADsPath = 'LDAP.....

    WARN: Could not get property (domain) for system (0x80005010)            7/12/2011 7:48:26 AM    67880 (0x10928)

    INFO: DDR was written for system.......

    In the colleval.log, I can see the query based collection getting refreshed, but no changes are made to the collection, when in fact, there should be multiple workstations being added.

    There have not been any changes made to the query, so it was working up until 2 weeks ago.  The machines are in the OU in AD, it's just not getting populated in the SCCM collection now.

    We changed the collection membership rules (yesterday) to update the collection every hour.  This morning, the collection still wasn't updated with those machines.  I've manually tried to update the collection, but that doesn't pick up the systems either.

    I'm not sure what I'm missing since there aren't any errors or failures.

    Tuesday, July 12, 2011 12:13 PM
  • In addition, in the properties for one of the workstations, I see the site name along with two agents: 

    SMS_AD_SYSTEM_DISCOVERY_AGENT

    Heartbeat Discovery

    I don't see the MP_Client registration or the SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT.  I'm assuming that this is why the collection is not getting updated, but since there aren't any errors in the logs, I'm not sure where to go next.

    Tuesday, July 12, 2011 12:43 PM
  • can you check if the client is installed with SCCM and is assigned(Yes) to site . seems like your client is not registered with SCCM .

    also check if your machine(client is installed and assigned to site) OU (LDAP path )which is specified under AD system group discovery ?

     


    //Eswar Koneti @ www.eskonr.com
    Tuesday, July 12, 2011 2:26 PM
  • On the workstations, the client is installed, it is assigned ("Yes") and it does have a domain and site code associated with it.  It is not obsolete.

    It is in a department OU in AD, but in SCCM, it is not in the collection for that departmental OU.  This is the issue that I'm trying to resolve.  There are no errors in the adsysgrp.log file and it looks like group discovery is finding this workstation. 

    Tuesday, July 12, 2011 4:18 PM
  • Try to find one affected PC in the "All systems" collection. Sort by name and see if there are any duplicates.
    Bring up the properties of that object(s) and double check the discovery agents (you've already done that, but did not mention if the timestamp is current).
    Make sure that the computer to be discovered is within the OU (LDAP) configured for AD system group discovery.
    Bring up resource explorer and check if hardware inventory was sent.
    Double check the system status and see if there are any errors.
    Torsten Meringer | http://www.mssccmfaq.de
    Tuesday, July 12, 2011 4:45 PM
  • Torsten:

    On one of the affected PC's, here is what happened:

    In AD,yesterday, the PC was moved to a different OU (we have one forest, one domain)

    The machine was deleted from SCCM-it did not show up in All Systems or any other collection

    The machine was reimaged via PXE (which installs the SCCM client as well)

    The machine reappeared in SCCM, however, when it did, it was in the collection for the OLD OU, not the new OU.

    This morning, there were duplicate entries for the PC. So, I again deleted both entries from SCCM and reimaged, via PXE.

    There are again, duplicate entries for this machine.  Both have the domain and site code correct (we have One SCCM site).

    One machine is showing as "approved and has the following agents/times:

    SMS_AD_SYSTEM_DISCOVERY_AGENT  7/11/2011 6:00PM

    MP_ClientRegistration  7/13/2011 9:21AM

    SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT  7/11/2011 7:15AM

    The creation date is 7/13/2011 9:22AM

    The other entry for this same machine in SCCM is Approved:  N/A

    SMS_AD_SYSTEM_DISCOVERY_AGENT  7/11/2011 4:00PM

    SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT  7/11/2011 5:45PM

    Heartbeat discovery  7/11/2011 6:34PM

    Creation date is 7/13/2011 7:47AM

    The guids for the pc's are different.  In SCCM, it is still showing up in the collection for the OLD OU.

    There are no errors in the Site System Status.

    However, in the SMS_Discovery_Data_Manager component, I see:

    The data file "E:\SCCM2007\inboxes\auth\ddm.box\MA78ZMEM.DDR" that was submitted by the client whose SMS unique ID is "GUID:b18cbd84-1104-41dc-b4dc-4caaa1356e4d", was rejected because the file was signed but the authentication key did not match the recorded key for this client.

    and

    SMS Discovery Data Manager has processed a discovery data record (DDR) for computer "BVHT1M1" with the SMS identifier of "GUID:4b73d7d0-1760-4a2a-98de-39e8d62d28ad" which has reported a new hardware identifier of "2:62130E0D5F129B55A798FBB1AC4A29180E2604F5". 1 existing records sharing this hardware identifier have been marked as obsolete.  The data in these records has been superseded by the data in the new record.

    Possible cause: The operating system and SMS client have been reinstalled on this computer.

    and

    SMS Discovery Data Manager has processed a discovery data record (DDR) for computer "BVHT1M1" with the SMS identifier of "GUID:b18cbd84-1104-41dc-b4dc-4caaa1356e4d" which has reported a new SMS ID of "GUID:20F323D6-8AE7-416E-8CD6-BEE7B004486D".  An existing record with the previous SMS identifier has been marked as obsolete.  The data in this record has been superseded by the data in the new record.

    Possible cause: The hardware properties of this client have changed substantially, and the client has generated a new SMS identifier.

    So, I don't understand why if I delete a system from SCCM, it would show back up twice after being reimaged as well as why does it not reflect the new OU in SCCM if our collections in SCCM are LDAP queries back to AD based on OU?

    Thanks

    Wednesday, July 13, 2011 2:45 PM
  • Hi Mandp,

    Did this get resolved? We are also facing the same issue.

    Any suggestions?

    Kind Regards,

    Tuesday, March 26, 2013 10:41 AM
  • One domain, and one AD, there shouldn't be to much problems. 

    My concern is though you are running AD discovery every two hours.  You have to be a patient man when administering SCCM.   The bad MIFs are a concern, have you made any changes the MOF files.  

    You should be only running AD system discovery one a night.

    Also have you tried doing a cert fix on the clients.  Where these upgraded from previous versions? Also what version of SCCM are you running?


    Tim DeCenso http://timrd.blogspot.com http://about.me/decenso

    Thursday, May 23, 2013 2:25 PM
  • Pre-requisites for AD system discovery are that SCCM computer a/c should have read access to the container which has been specified in LDAP path. Machines should exist in that OU, entry for machine should be in DNS and AD system dicovery should be enabled.  If these things are all configured then its a little weird issue. I wuld suggest that you run site reset since it would reset permissions on all registry and folders including ddm.box. As for AD system group discovery, It will only discover the resources which have been discovered by AD system discovery, Hence dependant on it.
    • Proposed as answer by Adil Muhammad Saturday, June 29, 2013 11:51 AM
    • Marked as answer by Garth JonesMVP Monday, December 22, 2014 2:46 PM
    Saturday, May 25, 2013 2:00 PM