locked
Client registration: No merging occuring between AD discovered and MP registred clients RRS feed

  • Question

  • Hello,

    I'm hoping I could get a hint on how to fix my issue. It's basically a conflict between AD discovery data and MP Registration data which end up in what we could call duplicate records, even though the records don't share any ID's. In fact the bad record has no ID's at all.

    Server: SCCM 2012 SP1 Version 5.0.7804.1000

    We install the client during the staging process with command line switches. At this time the client is not member of a domain yet.
    The command line is: /noservice SMSSLP=server smssitecode=site DNSSUFFIX=domain /mp:server.domain.xx

    After the installation of the client, we have some code that uses the SCCM API to check whether or not the client is really client. When confirmed, it adds the client to a series of collections.

    All is well so far. The workstation gets registred well and is tagged as followed in SCCM: "MP_ClientRegistration"
    Also "Heartbeat Discovery" gets added later or shortly after.
    It's also registred as being member of a workgroup, which is fine because the client is not member of a domain yet.

    After the SCCM client installation, the workstation joins the domain.
    This is where things go wrong. Not exactly at this moment in the staging process, but a little later at next delta discovery.
    Instead of merging the information that comes from the AD discovery to the existing and functional record, it creates a record that doesn't function and doesn't have any ID's.
    I end up having two accounts with the same name: One tagged with "MP_ClientRegistration" and "Heartbeat Discovery"(eventually) and without AD data; The other with "SMS_AD_SYSTEM_DISCOVERY_AGENT", no client membership BUT with correct AD data.

    So basically I want the AD discovery data to merge with the existing records, as I believe it's suposed to do.

    This is easy to reproduce. I just delete the AD discovered record and it gets recreated when initiate a new AD discovery.

    Many thanks in advance and best regards




    • Edited by Jazz.be Tuesday, September 17, 2013 2:54 PM Typos
    Tuesday, September 17, 2013 2:47 PM

Answers

  • Any chance that this is just a timing issue? AD discovery won't update workgroup client records. A heartbeat DDR will update the current (workgroup) client record with the AD information (=now member of a domain and no longer workgroup client) after it's joined to the domain. So you will end up in the situation you described if the AD DDRs arrives before the heartbeat DDR of the domain joined computer.

    Torsten Meringer | http://www.mssccmfaq.de

    • Marked as answer by Joyce L Monday, September 23, 2013 8:10 AM
    Tuesday, September 17, 2013 3:38 PM
  • To answer my own questions:

    1. Yes a Heartbeat Discovery did update the record, but I tested it by initiating a data discovery cycle locally on the workstation. See point 3
    2. I tried but it just leaves the duplicate where it is and I didn't obtain any additional tags in the Agent Name of the correct recourse. However, when I delete the duplicate and run a new AD discovery, no new duplicates are created.
    3. Data discovery cycle from the config mgr applet does the trick.

    My question is answered I think. As Torsten said, it's a timing issue.
    The delta check adds the duplicate.

    I'll probably just have launch a small script after joining the domain that removes the duplicate and initiates a data discovery cycle.

    • Marked as answer by Joyce L Monday, September 23, 2013 8:10 AM
    Wednesday, September 18, 2013 10:10 AM

All replies

  • Any chance that this is just a timing issue? AD discovery won't update workgroup client records. A heartbeat DDR will update the current (workgroup) client record with the AD information (=now member of a domain and no longer workgroup client) after it's joined to the domain. So you will end up in the situation you described if the AD DDRs arrives before the heartbeat DDR of the domain joined computer.

    Torsten Meringer | http://www.mssccmfaq.de

    • Marked as answer by Joyce L Monday, September 23, 2013 8:10 AM
    Tuesday, September 17, 2013 3:38 PM
  • Hello Torsten, thanks for your answer.

    I thought AD Discovery would match the newly found recourse with the existing one based on name or mac address or something, then merge them so it forms one complete recourse.

    If I understand correctly Hearbeat Discovery does update records, AD Discovery won't.

    1. So basically my recourse will have AD information on first Heartbeat Discovery after domain join?
    2. And will the AD discovery after that first heartbeat discovery do something about the "duplicate" recourse? (delete/merge?) Because even if I handle those duplicates once, they'll just reappear after each AD discovery.
    3. And last, can I do something similar to heartbeat discovery that will update the recourse, but from a local point of view? I have a task sequence running after the workstation has joined the domain.
    Regs


    • Edited by Jazz.be Tuesday, September 17, 2013 4:35 PM Typo
    Tuesday, September 17, 2013 4:27 PM
  • To answer my own questions:

    1. Yes a Heartbeat Discovery did update the record, but I tested it by initiating a data discovery cycle locally on the workstation. See point 3
    2. I tried but it just leaves the duplicate where it is and I didn't obtain any additional tags in the Agent Name of the correct recourse. However, when I delete the duplicate and run a new AD discovery, no new duplicates are created.
    3. Data discovery cycle from the config mgr applet does the trick.

    My question is answered I think. As Torsten said, it's a timing issue.
    The delta check adds the duplicate.

    I'll probably just have launch a small script after joining the domain that removes the duplicate and initiates a data discovery cycle.

    • Marked as answer by Joyce L Monday, September 23, 2013 8:10 AM
    Wednesday, September 18, 2013 10:10 AM