Wrong TRK and Approved N/A issues


  • A while ago we did a migration from SMS to SCCM. The new SCCM server is running in mixed mode.

    Recently, two main "problems" were found with the clients that were migrated over from SMS:

    - Migrated clients on one of the sites have the wrong TRK. This only happens for one of the sites. Despite the fact that the TRK is that of the old SMS server, we can still push things to these workstations and receive reporting from them, which is a contradiction in terms of its own. If the TRK is wrong, the client should not trust the server.

    Apart from the fact that the TRK does not match the new TRK, everything else looks absolutely fine on these clients. The MobileClient.tcf file these clients have on the ccmsetup folder dates back to the pre-SCCM days, meaning that a new MobileClient.tcf file was never downloaded when the client was upgraded and mgirated over. Isn't this something that should be done automatically at the time of the client installation?

    - A lot of clients from both sites appear as approved N/A in the SCCM console. I've verified they have the SCCM client and not the SMS client, they're pointing at the right site code, client is in mixed mode, etc. I can't quite find anything wrong with the client. Also, again, we can push things to these workstations just fine.

    Some of the clients with approved N/A have the wrong TRK, some of them have the right TRK. Also, for clarification, some of the clients that are properly approved also have the wrong TRK, so it's not like the wrong TRK is only on the ones with approved N/A. This would mean the problem is completely separate from the one above.

    Because they are approved N/A as opposed to approved YES/NO, obviously they cannot be approved. But seeing as the server is in mixed mode, I can't see why they'd ever be in approved N/A. There are no errors on any of the logs, the clients are just working fine.

    So the questions I have about this issue are:

    What would cause a client in mixed mode to show up as approved N/A when everything is working properly and how to fix it.


    • Изменено cogumel0 7 июня 2012 г. 10:40
    7 июня 2012 г. 10:29


Все ответы

  • Just did a few more tests, and according to the server, the clients with approved N/A do not have an agent name of mp_clientregistration, indicating that the client is not registered on the site.

    However, when going through the logs on the client, it clearly says:

    RegTask: Client is not registered. Sending registration request...    ClientIDManagerStartup    10/7/2011 1:04:42 AM    16040 (0x3EA8)
    RegTask: Client registration is pending.    ClientIDManagerStartup    10/7/2011 1:04:42 AM    16040 (0x3EA8)
    RegTask: Client is pending registration. Sending confirmation request...    ClientIDManagerStartup    10/7/2011 1:04:42 AM    16040 (0x3EA8)
    RegTask: Client is pending registration. Sending confirmation request...    ClientIDManagerStartup    10/7/2011 1:05:42 AM    16040 (0x3EA8)
    RegTask: Client is registered.    ClientIDManagerStartup    10/7/2011 1:05:42 AM    16040 (0x3EA8)

    10/7/2011 is when the client was migrated from SMS to SCCM, however according to the SCCM server, the object for this client was created on 10/14/2011 1:33:18 AM, meaning it was just over a week later. This time also coincides to when heartbeat is running on that computer, but I thought heartbeat discovery would not create new objects?

    After that, the low shows several times the same lines, the most recent being the following:

    RegTask - Executing registration task synchronously.	ClientIDManagerStartup	6/7/2012 7:45:15 AM	20664 (0x50B8)
    Reg Task: Client is registered, exiting.	ClientIDManagerStartup	6/7/2012 7:45:15 AM	20664 (0x50B8)

    In other words, it seems to me like whilst the client thinks it is registered, the server says it is not, which is why it has an approved N/A status.

    7 июня 2012 г. 12:28
  • How are you verifying the TRK?

    To remove the TRK on a client, follow these steps: . The clients will then use the TRK of the first MP that they communicate with:

    Client approval = N/A is typically nothing to worry about and is the result of the server losing the registration which often happens when you delete a client from the console and it gets recreated via a heartbeat discovery. The only known ramification of this (to my knowledge) is with OOB management.

    Jason | | Twitter @JasonSandys

    • Помечено в качестве ответа cogumel0 22 июня 2012 г. 17:27
    7 июня 2012 г. 14:12
  • I'm verifying the TRK through WMI:

    ' Get a connection to the root\ccm namespace on the local system.
    Set objWMIService = GetObject("winmgmts:\\" & strComputerName & "\root\ccm\LocationServices")
    ' Get all objects in the TrustedRootKey class.
    Set colItems = objWMIService.ExecQuery("Select * from TrustedRootKey")
    ' Loop through the available objects (only one) and display Trusted Root Key value.
    For Each objItem in colItems
    	WScript.Echo objItem.TrustedRootKey

    I managed to get it to remove the TRK using the instructions above, but according to the second link you provided, it seems like TRK might not be an issue at all as SCCM is published in AD:

    If clients can query Active Directory Domain Services in the site server's forest, they can verify that the management point is a trusted management point. If the clients cannot query Active Directory Domain Services to verify trusted management points, the clients use the trusted root key.

    According to that, TRK is only used when it fails to verify that the management point is trusted using AD. Is that the case?

    As for the client approval, according to the documentation for the heartbeat discovery, if an object is deleted from the console, the next Hearbeat Discovery should re-activate the old record, not create a new one: If that's the case and the old object gets re-activated (rather than a new one created) the information about the object being activated should still be there, however in this case it is not.

    I've tried stopping the client, deleting the certificate using ccmdelcert and starting the client up again on one of the computers with this approval problem and the client logs show that after the certificate is deleted it tries (and succeeds), however the object on the console doesn't reflect that and continues to say the object has no mp_clientregistration agent.

    7 июня 2012 г. 14:35
  • "If clients do not have the trusted root key, they will trust the trusted root key presented by the first management point they communicate with"

    I've never seen a record get re-activated though so I'm not sure what the documentation is refering to. Typically, what I think really happens is that another discovery method creates a new record and then heartbeat discovery updates that record. The server doesn't really care whether the client is approved or N/A is practice. The easy solution is to right-click these and select Approve.

    Jason | | Twitter @JasonSandys

  • About the TRK, the quote you've just provided seems to refer to when no TRK is present on the client and how they go about acquiring one. However in my case they already have a TRK, it just happens to be the wrong one.

    What I'm trying to understand is whether it is *really* important for the TRK to be correct in which case I have to fix them *now* or whether it's more of a fall back mechanism and only used when it can't get query AD for the trusted management point in which case I would still benefit from fixing it but don't have to have as high as priority.

    From what I can see, it looks like in my particular case (where SCCM is published in AD) TRK becomes a fall back mechanism, as I am still able to push things to the clients despite them having the wrong TRK. Is this the case?

    As for the approved N/A, whilst I know that the I can just right click approve them, I'm trying to figure out how they came to be in this state. Over 60% of the clients migrated from SMS to SCCM are in a approved N/A state.

    Most importantly, I'm trying to understand how the client can report that it's registered yet the console shows no MP_ClientRegistration agent. Even forcing the client to re-register by deleting the cert and monitoring the logs shows that whilst the client registers successfully, the console doesn't reflect that and still shows no MP_ClientRegistration agent.

    Much to my disappointment, currently we only have 2 discovery methods enabled: AD System Group Discovery and Heartbeat. We both know that AD System Group Discovery doesn't create objects, so if the object was deleted, it would have had to be the heartbeat discovery to create the object, though I can't find any documentation supporting this theory. Nothing I've found seems to indicate that Heartbeat Discovery has the ability to create objects if they don't exist.

    Unless I understand how this came to happen to begin with, I'm not sure I'm in a position to prevent it from happening again.


    • Изменено cogumel0 8 июня 2012 г. 9:48
  • Ok, I just deleted the object of a live client from the database and forced a heartbeat discovery.

    A completely new object was created, with no MP_ClientRegistration agent and with approved = N/A.

    So despite the fact that this goes completely against the document describing how heartbeat discovery works (or at least my interpretation of it), a new object is created.

    That also solves my issue with the approved = N/A, but still not entirely sure about the TRK. Would be nice to have some answers to the questions I asked above.

    8 июня 2012 г. 12:09
  • "About the TRK, the quote you've just provided seems to refer to when no TRK is present on the client and how they go about acquiring one. However in my case they already have a TRK, it just happens to be the wrong one."

    That's why I recommended deleting the TRK from the client -- so it could grab the correct one from AD. No, it is not a fallack mechanism and should be correct on all clients that you are managing.

    Jason | | Twitter @JasonSandys