Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Wednesday, June 19, 2019 9:27 PM
Hi,
I am having a weird issue recently. Started about 2 weeks ago. When imaging a new computer the computer shows up in Devices twice. One device name shows as Unknown, Active, Client installed, with proper GUID and a Resource ID 167779xx. The other device name is the correct computer name, inactive, client not installed and with no GUID and a Resource ID 20971527xx.
This seems caused client on the newly imaged computer not receiving the correct client settings. Current workaround is to manually delete these Unknown active devices in SCCM. The next time that computer checks in it register with correct information.
Any idea what could be the cause of this issue and is there some kind log(s) I can look for clue?
Thank you,
Henry
All replies (26)
Thursday, June 20, 2019 12:11 AM
What version exactly of ConfigMgr are you running?
Have you reviewed the properties of each resource, specifically the agent name and agent time property which will tell you exactly which discovery method (or methods) initiated the creation or update of the resource and the times that was done at.
Jason | https://home.configmgrftw.com | @jasonsandys
Thursday, June 20, 2019 3:25 AM
Hi Henry,
Based on my experience, all resources in ConfigMgr are created as the result of a discovery generating a DDR. Thus, the first step is to track the source of the DDR that created the original and duplicate resource. This can be seen if you view the properties of a resource in the console and examine the Agent Name and Agent Time fields. Once you know that you can examine the discovery itself and the timing of the discovery.
For more details, please refer to:
ConfigMgr (SCCM) – Duplicate Record Issue
Hope it helps. Thanks for your time.
Best regards,
Simon Ren
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Thursday, June 20, 2019 3:30 PM
Hi Jason,
The version is 1710. I just took a look it's agent properties. It's kind interesting.
For Unknown device they agent name is "Heartbeat Discovery" and agent time is when computer was being imaged. For the one with proper computer name the agent name is "SMS_AD_Systerm_Discovery_Agent" and the agent time is current. Unknown has proper hardware ID but correct computer name device hardware ID is null.
As if Heartbeat created the record without knowing it's device name and AD system discovery created another but not knowing it's hardware ID??
Thanks,
Henry
Thursday, June 20, 2019 4:11 PM
Do the computer objects already exist in AD or are they being pre-created?
Jason | https://home.configmgrftw.com | @jasonsandys
Thursday, June 20, 2019 5:20 PM
They are brand new computer so they do not exist in AD. The AD system object are created during OSD Task Sequence to join domain.
Simon's article is what I am doing manually to fix but require someone go in to fix it after new computer is imaged. This issue started about 2 weeks ago I am hoping to fix this once for all so no one need to manually clean duplicated device record.
Thursday, June 20, 2019 5:38 PM
Those are really old articles for ConfigMgr 2007 and 2012 (although the scenario is quite similar). I also seem to vaguely remember a similar "bug" or issue in a recent version of ConfigMgr CB, 1710 even maybe. Given that 1710 only has a month or two of support left, I highly recommend that you upgrade to a recent version of CB, like 1902 (of course that will require you going to 1802, 1806, or 1810 first as you can't go directly from 1710 to 1902).
Jason | https://home.configmgrftw.com | @jasonsandys
Monday, June 24, 2019 6:45 PM
Hi Jason,
I have updated SCCM to 1810. The Heartbeat still picking up device as Unknown and even stranger. It used to at least show client is Installed and Active now it both status is blank. AD System Discovery still pick up the same device but only shows Device name without other information.
It feels the issue is with Heartbeat discovery. That it didn't add the computer name/NetBIOS name when reporting to SCCM. When AD System Discovery run scan can't append information to the system resource record and created a new one.
Is there some kind heartbeat discovery log to look for clue?
Thanks,
Henry
Monday, June 24, 2019 7:02 PM
Yes, on the clients, it's part of the inventoryagent.log.
Have you validated the name on the system itself and have you validated that the agent is successfully and fully communicating with the site by checking the client logs (like clientidmanagerstartup.log and ccmmessaging.log)?
Jason | https://home.configmgrftw.com | @jasonsandys
Monday, June 24, 2019 10:44 PM
Hi Jason,
Seems the agent is not communicating with site correctly. I checked the logs you suggested it seems it have problem registering during OSD Task Sequence. I come across another post regarding to registering issue. It suggested to look at MP_RegistrationManager.log on the Management Point.
I found a bunch errors starting from 2 months ago. It keep on repeating these error on different GUID.
Verifying message signature for client 'GUID:C62404AC-B58D-4D99-B019-7DFBBB93B62F' failed with 0x80090006. MP_RegistrationManager 6/21/2019 2:03:17 PM 11876 (0x2E64)
CCMValidateAuthHeaders failed (0x80090006) to validate headers for client 'GUID:C62404AC-B58D-4D99-B019-7DFBBB93B62F'. MP_RegistrationManager 6/21/2019 2:03:17 PM 11876 (0x2E64)
MP Reg: Failed to verify RegistrationHint, 0x80090006, Registration Hint was not signed with the associated private key whose public key was registered with the SMSID (GUID:C62404AC-B58D-4D99-B019-7DFBBB93B62F). MP_RegistrationManager 6/21/2019 2:03:17 PM 11876 (0x2E64)
Processing Registration request from Client 'GUID:276b49d8-41d1-4790-ace9-d30287028066' MP_RegistrationManager 6/24/2019 8:26:58 AM 10768 (0x2A10)
Begin validation of Certificate [Thumbprint CD7C4ABBF483B40DDD85259C99B98E2C6EE629A8] issued to 'SMS' MP_RegistrationManager 6/24/2019 8:26:58 AM 10768 (0x2A10)
Completed validation of Certificate [Thumbprint CD7C4ABBF483B40DDD85259C99B98E2C6EE629A8] issued to 'SMS' MP_RegistrationManager 6/24/2019 8:26:58 AM 10768 (0x2A10)
Encountered database error while verifying headers for client 'GUID:276b49d8-41d1-4790-ace9-d30287028066' (0x87d00238). MP_RegistrationManager 6/24/2019 8:26:58 AM 10768 (0x2A10)
CCMValidateAuthHeaders failed (0x87d00238) to validate headers for client 'GUID:276b49d8-41d1-4790-ace9-d30287028066'. MP_RegistrationManager 6/24/2019 8:26:58 AM 10768 (0x2A10)
MP Reg: DDR written to [H:\SMS\mp\outboxes\rdr.box\PX1XPKVQ.RDR] for Client [GUID:276b49d8-41d1-4790-ace9-d30287028066] with Subject [S-1-5-21-2634412583-3736653284-1001856273-14149] Certificate Thumbprint [CD7C4ABBF483B40DDD85259C99B98E2C6EE629A8] MP_RegistrationManager 6/24/2019 8:26:58 AM 10768 (0x2A10)
MP Reg: Processing completed. Completion state = 0 MP_RegistrationManager 6/24/2019 8:26:59 AM 10768 (0x2A10)
MP Reg: Processing completed. Completion state = 0 MP_RegistrationManager 6/24/2019 8:27:59 AM 10768 (0x2A10)
I followed that thread checking ClientKeyData table in SQL
Select * from ClientKeyData where IsRevoked=1
Found a bunch RecordID that is marked as revoked... If continue following that thread it use update command to manually change the RecordID status
Update ClientKeyData set IsRevoked=0 where RecordID=<RECORDID>
In that post I also see your response
"Note that that's not a good place to delete certificates from. It is ultimately where they live, but you should always use the certificates snap-in to manage and manipulate certs."
Would you be able to suggest where exactly I need to go to get this registration issue solved?
Thanks,
Henry
Tuesday, June 25, 2019 1:26 AM
You can certainly try deleting the certs from the SMS cert store of the local computer account using the certificates mmc snap-in.
Jason | https://home.configmgrftw.com | @jasonsandys
Tuesday, June 25, 2019 4:27 PM
Hi Jason,
This is strange, I have not made any cert change yet. Here is the sequence.
- OSD the computer and Client's Heartbeat agent tried to register the device and gets "Encountered database error while verifying headers for client (0x87d00238)" and "CCMValidateAuthHeaders failed (0x87d00238) to validate headers for client". Two Devices shows in SCCM one as Unknown with Agent Name Heartbeat Discovery and the other proper Host name with Agent Name AD System Discovery but with no other attributes.
- Deleted the Unknown Device and the AD System Discovered record gets properly filled when restart the computer.
- Deleted AD System Discovered record try to get error message from #1 to show again in MP_RegistrationManager.log again. This time it's funny, it has no error when trying to register and the Agent Name shows as MP_ClientRegistration instead of Heartbeat Discovery.
Seem something in Heartbeat is not running correctly...
I am just going to do a test for the heck of it. I will temperately disable Heartbeat Discovery. Delete the Device from SCCM and AD then reimage the computer. See if the Unknown computer still shows up. Then this will tell me if the issue is indeed with Heartbeat.
Will let you know how it goes.
Henry T
Tuesday, June 25, 2019 4:59 PM
#2 happens because of heartbeat discovery so disabling it is not a good path here at all.
Are you using HTTPS client communication?
How was the base image created?
How exactly are the systems being joined to the domain during the TS and how are the computer accounts created?
Jason | https://home.configmgrftw.com | @jasonsandys
Tuesday, June 25, 2019 5:15 PM
Hi Jason,
I am using both. HTTPS or HTTP.
The base image is Win10 1709. Used a non domain joined VM to customize desktop, start menu and some default application then run the MDT litetouch to sysprep and capture the custom image. It was captured on January 2019 and imaged fine till recently.
The System joins Domain during TS with Apply Network Settings task. Using a domain admin account to a Designated OU.
Henry T
Tuesday, June 25, 2019 6:02 PM
Have you examined the Personal cert store of the image for the local computer account to validate that there are no certs present?
What happens if you use a clean image?
On a side note, why are you manually creating images? That's so anti-IT.
Jason | https://home.configmgrftw.com | @jasonsandys
Tuesday, June 25, 2019 6:34 PM
The reason is to remove all the Win10 default game and ads apps. Like Xbox, Twitter, Candy Crash and other entertainment stuff. Our boss don't want employee playing those while working.
I will try a clean image see if that make any difference. Btw that test I did with disabling Heartbeat discovery makes no change. Unknown still shows up and still from Heartbeat Discovery even it's disabled.
Henry T
Tuesday, June 25, 2019 6:51 PM
> The reason is to remove all the Win10 default game and ads apps.
Those are easily removed with a script or better yet, with Windows Servicing. Community tools like OS Builder (osdeploy.com) make this super trivial in fact. No image building needed at all.
Jason | https://home.configmgrftw.com | @jasonsandys
Wednesday, June 26, 2019 3:12 PM
Finally figured it out!!
I did a OSD with Win10 default WIM file. The same issue it registered both an Unknown device and netbios name device with not much attribute. I followed an article I found on troubleshooting Hardware inventory registration flow. https://www.enhansoft.com/troubleshooting-inventory-flow/ It doesn't seems to have any issue with the whole flow.
In the Dataldr.log it even shows it done the update.
Done: Machine=MININT-K9A44D2(GUID:074e0748-5d64-447d-a34d-bbfe5ab55ee1) code=0 (25 stored procs in XH6P5IWPF.MIF)
Basically the Client, MP and site server did everything it supposed to do during the OSD but was unable to register the device properly on Site server. But when running AD System scan it can register the device properly so it must be some permission related in OSD. It end up another admin have changed the Service Account used for OSD and that Service Account is missing Asset Manager permissions. That is why the record never got created properly.
After added the account to the role the new imaged device gets registered correctly and receiving correct Client Settings. Thank you very much for your assistance.
I will take a look the OS Builder see if it applies to our situation.
Thanks again,
Henry
Henry T
Wednesday, June 26, 2019 4:28 PM
Sorry, not following. There are no service accounts in ConfigMgr. Are you referring to an account used for another tool or the domain join account or the account specified for AD discovery or some other account?
Jason | https://home.configmgrftw.com | @jasonsandys
Wednesday, June 26, 2019 7:23 PM
Referring to the Doming Join account. And never mind issue started again just now... going back to read the logs...
Henry T
Wednesday, June 26, 2019 8:00 PM
So then I'm still curious what happens with a clean image directly from the Windows media/ISO.
Jason | https://home.configmgrftw.com | @jasonsandys
Thursday, June 27, 2019 4:17 PM
With Clean Image it still registered the device as Unknown.
Henry T
Thursday, June 27, 2019 9:32 PM
Hi Jason,
I saw some post about the TS it self has problem so I created a new one and only add join domain and product key part. Looking at the SMSTS.log again. I noticed below.
Attempting to release request using {ADE2A090-6039-4B3C-BF69-163EED540883} TSManager 6/27/2019 3:01:24 PM 5084 (0x13DC)
ReleaseRequest failed with error code 0x87d00317 TSManager 6/27/2019 3:01:24 PM 5084 (0x13DC)
Task Sequence Manager could not release active TS request. code 87D00317 TSManager 6/27/2019 3:01:24 PM 5084 (0x13DC)
And
RegQueryValueExW is unsuccessful for Software\Microsoft\SMS\Task Sequence, SMSTSEndProgram OSDSetupHook 6/27/2019 3:01:28 PM 4832 (0x12E0)
GetTsRegValue() is unsuccessful. 0x80070002. OSDSetupHook 6/27/2019 3:01:28 PM 4832 (0x12E0)
End program: OSDSetupHook 6/27/2019 3:01:28 PM 4832 (0x12E0)
Successfully finalized logs to SMS client log directory from C:\WINDOWS\CCM\Logs OSDSetupHook 6/27/2019 3:01:28 PM 4832 (0x12E0)
I can't really recall right now but doesn't "Unknown" only show up if the OSD failed? Is it because TS can't release request so it treated it as failed even everything is installed?
Henry T
Monday, October 28, 2019 10:05 AM
Hi Henry
Were you able to resolve this issue? We have the same one and I can't figure it out.
I also tried the same stuff you did before, but it's still not working.
Thanks and kind regards
Marco
Thursday, December 12, 2019 9:56 PM
I'm on CM1906 and had a similar issue. I don't know when it started but clients would begin working after a day or so. In my case I added our 2 sub CA certs to the existing root certificate in the Trusted Root Certification Authorities. It's detailed in this article:
Although the article refers to Macs, it worked for me.
Thursday, January 9, 2020 3:03 PM
Thank you for the feedback. I tried it, sadly without any success.
I'm in contact with Microsoft since a couple of weeks, but they're also still searching for the issue..
Tuesday, January 21, 2020 10:33 AM
We finally found the problem. The problem was a time issue. We have a couple of Management Point in our environment. One of them had client local time instead of UTC.
So what we found out, was the following:
We searched for the .RDR file in the MP_RegistrationManager.log (on the Management Point).
-You’ll need the GUID of a problem device for this (search for the following in the MP_RegistrationManager.log: **for Client [GUID:ed234490-da56-51e8-b0z1-fewad65e1cc0] with identity
**-You should find something like this: **MP Reg: DDR written to [D:\SMS\mp\outboxes\rdr.box\L9KAQYII.RDR] for Client [GUID: ed234490-da56-51e8-b0z1-fewad65e1cc0] with identity
**-Now go to your Site System Server and open the ddm.log (SCCM logs). Search for the RDR File in there: **9KAQYII.RDR
**-If you find the following entry, you probably also have a time problem: **DDR timestamp of "1/15/2020 7:20:35 AM" for agent "MP_ClientRegistration" is older than existing record's timestamp of "1/15/2020 2:51:48 PM"
**So next thing was, that we checked the time while PXE booting PXE boot starts and loads the boot image.
Task Sequence wizard starts with the password prompt. Before entering the password, check the time (F8, cmd and enter TIME). In our case client shows the time from BIOS (normally correct time, also in our case).
After we entered the password and clicked next, the time changed to client local time (F8, time: wrong time).
We saw in the smsts.log, that the time was changed, and that the client didn’t contact the nearest MP. Instead it contacted the first from the list (according to the ABC).
So next we took a look on the MP that we saw in the smsts.log. And the result was, that the time on this MP was wrong. So we changed it to UTC and tested again. Result: Everything works as it should (unknown heartbeat device and Active Directory discovered device melt together at the end of the Task Sequence).
Maybe that helps someone with the same problem (: