locked
Restoring Workgroup clients to new server RRS feed

  • Question

  • Have been having major issues resolving this. I am using 2012 R2 ,management point is HTTP. Have attempted updating new MP address in client via ccmsetup and VBscript. Change takes effect on local machine, but it is still not getting connected. I have uninstalled and reinstalled client from server package (server\SMS_<site code>). That makes it come up, but as unmanaged, and I am able to manually approve (test push of couple files fails). While researching, I ran across fix directing me to BgbServer.log. What I found is that all the clients are checking in (showing via IP address), but get the following for each (abridged):

     

    Can’t find corresponding certificate used in client registration for client

    Can’t verify signature in message without client certificate for client

    Invalid hook to be decoded. Authentication

    Failed to decode message body

    Failed to process SignIn message from client

    ERROR: Invalid message header from client when receive SignIn message

     

    As far as I know, the previous server did not use https (only been here 2 months). CertMgr.log also gets the single error – Failed to get connector certificate, but all other certs come back good. Could I import a cert from client machine to SCCM to resolve? Is there a place to allow anonymous login like WSUS? Am I missing something I can’t see?

     

    Any input is appreciated.

    Friday, October 24, 2014 1:41 PM

Answers

  • Not sure what you mean by that as it doesn't apply as far as I can tell. I am managing our remote and corporate sites from an SCCM server in Azure.

    However, I was able to resolve. After looking @ LocationServices.log, I was able to get a little better research and came up with following:

    Had to add the following switch:

    ccmsetup.exe RESETKEYINFORMATION=TRUE

    Found it worked best killing CCMEXEC running command with MP and site code redeclared and launching CCMEXEC. Sites began populating because they lost key they didn’t need anymore.

    • Marked as answer by Joyce L Friday, October 31, 2014 8:08 AM
    Monday, October 27, 2014 8:36 PM

All replies

  • New server? So another CM site? A restored one? What happened exactly?
    Also examine ClientLocation.log, LocationServices.log and ClientIDManagerStartup.log. (BgbServer.log is unrelated)

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

    • Proposed as answer by Joyce L Monday, October 27, 2014 6:28 AM
    Friday, October 24, 2014 1:50 PM
  • No restore. They were hardly using when I got here (not leveraging). Since we are in process of moving infrastructure into Azure, we decided to forgo issues and stand fresh one up. All domain clients came right back into fold. Since I added DNS alias to point to new server, they are all trying to hit it and getting refused due to cert that I don't think exists.

    As suggested:

    ClientLocation.log (repeated over and over)

    Raising event:
    instance of CCM_CcmHttp_Status
    {
     ClientID = "GUID:4551910B-3805-4A71-8DF5-0B07887C2569";
     DateTime = "20141027095443.169000+000";
     HostName = "SCCM01.xxxx.local";
     HRESULT = "0x00000000";
     ProcessID = 2120;
     StatusCode = 0;
     ThreadID = 456;
    };

    Workgroup client is in Intranet

    ClientIDManagerStartup.log

    Collects data w/o issue, however, last run 20 days ago.

    LocationServices.log

    I think we have a winner (or a least a clue)!

    Workgroup machine is looking to attach via HTTP and is able to resolve proper name. After if fails cert, it attempts old name, which still point to same server via DNS.

    Then hit its obvious conclusion:

    The TRK, MP Certificate and MP machine have changed on server. The client cannot validate the authentication information

    It does give me the cert string in log. Can I do something with this?

    Monday, October 27, 2014 2:19 PM
  • Since we are in process of moving infrastructure into Azure, we decided to forgo issues and stand fresh one up.


    So ConfigMgr is running in Azure and should manage on-premises machines? That would not be supported then: http://support.microsoft.com/kb/2889321

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

    Monday, October 27, 2014 2:29 PM
  • Not sure what you mean by that as it doesn't apply as far as I can tell. I am managing our remote and corporate sites from an SCCM server in Azure.

    However, I was able to resolve. After looking @ LocationServices.log, I was able to get a little better research and came up with following:

    Had to add the following switch:

    ccmsetup.exe RESETKEYINFORMATION=TRUE

    Found it worked best killing CCMEXEC running command with MP and site code redeclared and launching CCMEXEC. Sites began populating because they lost key they didn’t need anymore.

    • Marked as answer by Joyce L Friday, October 31, 2014 8:08 AM
    Monday, October 27, 2014 8:36 PM