Jump to content


jka816

Established Members
  • Posts

    6
  • Joined

  • Last visited

Everything posted by jka816

  1. I've been at this for a couple weeks and haven't had any lucky resolving it myself. I'm around ready to give up and rebuild or primary site. SCCM Ver: CB1802 Our old WSUS server was 2012R2 running WID and we wanted to move it to 2016 and SQL. I removed the SUP role, removed the server from SCCM, then decomed the server. I rebuilt the WSUS server on 2016, connected to SQL DB, installed SUP role, and synced WSUS. In SCCM everything appears to be functioning normally, I can see updates, metadata, create software update groups, deploy, etc and Offline Servicing works but Clients and Build and Capture task sequences fail to update. This issue is not specific to one client, update, or OS version. It's everything. I've included logs from a Windows 10 1703 client I just imaged. Following may help when looking through logs: SUG UID: {FB172790-25B5-4030-94EF-084AF60311D4} Unique Update ID: 2018-05 Update for Windows 10 Version 1703 for x64-based Systems (KB4132649) 5/17/2018 12:00:00 PM f176e292-745f-4757-9b64-c25f1d382bb0 Clients can see the SUGs deployed to them but they still fail to update: EnumerateUpdates for action (UpdateActionInstall) - Total actionable updates = 0 I do see some interesting behavior in the WindowsUpdateLog: 2018/05/29 09:40:33.8562624 4204 4372 Misc [0]106C.1114::05/29/2018-09:40:33.856 [endpointproviders]EP: error: 0x8024500C : - failed to get SLS data 2018/05/29 09:40:33.8562631 4204 4372 Misc [0]106C.1114::05/29/2018-09:40:33.856 [endpointproviders]EP: error: 0x8024500C: GetSecondaryServicesEnabledState failed 2018/05/29 09:40:33.8562643 4204 4372 Agent [0]106C.1114::05/29/2018-09:40:33.856 [agent]AutoRecovery: DetectAndToggleServiceState failed 0x8024500c 2018/05/29 09:40:33.8562714 4204 4372 Agent [0]106C.1114::05/29/2018-09:40:33.856 [agent]Failed to resolve federated serviceId 9482F4B4-E343-43B6-B170-9A65BC822C77, hr=8024500c 2018/05/29 09:40:33.8569169 4204 4372 Agent [0]106C.1114::05/29/2018-09:40:33.856 [agent]Failed to execute service registration call {0212BB3F-3F60-41E9-A2F8-134D35857144}, hr=8024500c (cV: Y9kDJUwh+kyup8zk.1.0.1) 2018/05/29 09:40:33.8586463 4204 4372 IdleTimer [0]106C.1114::05/29/2018-09:40:33.858 [agent]WU operation (SR.Device Driver Retrieval Client ID 1, operation # 3) stopped; does<NULL> use network; is not at background priority<NULL> 2018/05/29 09:40:33.8597622 4204 4368 DownloadManager [0]106C.1110::05/29/2018-09:40:33.859 [agent]Received power state change notification: Old: <unknown>; New: AC. 2018/05/29 09:40:33.8597634 4204 4368 DownloadManager [0]106C.1110::05/29/2018-09:40:33.859 [agent]Power state changed from <unknown> to AC. 2018/05/29 09:40:33.8647205 356 1832 ComApi [0]0164.0728::05/29/2018-09:40:33.864 [comapi]* END * Federated Search failed to process service registration, hr=0x8024500C (cV = Y9kDJUwh+kyup8zk.1.0) 2018/05/29 09:40:33.8670209 356 1756 ComApi [0]0164.06DC::05/29/2018-09:40:33.867 [comapi]ISusInternal:: DisconnectCall failed, hr=8024000C I also see the following behavior in the ScanAgent.Log, but I'm not sure if it's normal or not: CScanAgent::ScanByUpdates - Found UpdateClassification cd5ffd1e-e932-4e3a-bf74-18bf0b1bbd83 for Update:bba02b7f-1d17-4e92-bae9-9f3651dcc2de ScanAgent 5/29/2018 9:46:30 AM 11232 (0x2BE0) CScanAgent::CanPerformOnlineCatScan - Cannot perform online category scan as update does not belong to pre-defined classifications for this. ScanAgent 5/29/2018 9:46:30 AM 11232 (0x2BE0) Found CategoryID of :a3c2375d-0c8a-42f9-bce0-28333e198407 for Update:c03178c9-b5d2-4c5f-819f-c8871513e23d ScanAgent 5/29/2018 9:46:30 AM 11232 (0x2BE0) CScanAgent::ScanByUpdates - Found UpdateClassification 0fa1201d-4330-4fa8-8ae9-b877473b6441 for Update:c03178c9-b5d2-4c5f-819f-c8871513e23d ScanAgent 5/29/2018 9:46:30 AM 11232 (0x2BE0) CScanAgent::CanPerformOnlineCatScan - Cannot perform online category scan as update does not belong to pre-defined classifications for this. ScanAgent 5/29/2018 9:46:30 AM 11232 (0x2BE0) Found CategoryID of :a3c2375d-0c8a-42f9-bce0-28333e198407 for Update:c68e52ad-4e74-4f15-95d2-17da18f296fe ScanAgent 5/29/2018 9:46:30 AM 11232 (0x2BE0) CScanAgent::ScanByUpdates - Found UpdateClassification 0fa1201d-4330-4fa8-8ae9-b877473b6441 for Update:c68e52ad-4e74-4f15-95d2-17da18f296fe ScanAgent 5/29/2018 9:46:30 AM 11232 (0x2BE0) CScanAgent::CanPerformOnlineCatScan - Cannot perform online category scan as update does not belong to pre-defined classifications for this. ScanAgent 5/29/2018 9:46:30 AM 11232 (0x2BE0) Found CategoryID of :d2085b71-5f1f-43a9-880d-ed159016d5c6 for Update:cbb9515d-b809-4d11-983b-6047fea6c907 ScanAgent 5/29/2018 9:46:30 AM 11232 (0x2BE0) Any help or ideas of where to look would be much appreciated.
  2. Nearly two years later I finally fixed the issue so I figured I'd come back and update the thread. Using: Get-CMDevice | Where-Object { $_.SMSID -eq 'GUID:B1C18985-608A-4CD6-B25F-2D7ADADFD444'} I discovered that GUID belonged to the Site Server as I stated above and it showed the client as NOT blocked. However when running the following SQL Query: Select * from ClientKeyData where IsRevoked=1 I discovered the client was marked as revoked for some reason. I ran the following to fix it: Update ClientKeyData set IsRevoked=0 where RecordID=<RECORDID> You'd need to replace RECORDID with the corresponding record returned in the first query.
  3. I don't think it's an issue with SQL but the database itself, I just don't know SQL well enough to determine if that's true. The warning says "Client 'GUID:B1C18985-608A-4CD6-B25F-2D7ADADFD444' is unknown or has an invalid key registered in the database." This leads me to believe the GUID is somehow associated incorrectly in the DB.
  4. I also just checked my MP_RegistrationManager.log file and found the following: Processing Registration request from Client 'GUID:B1C18985-608A-4CD6-B25F-2D7ADADFD444' MP_RegistrationManager 10/21/2016 10:14:54 AM 10920 (0x2AA8) Begin validation of Certificate [Thumbprint 21C5FF81EE60B855E7FC8F767DA86BAC58DAA51A] issued to 'SMS' MP_RegistrationManager 10/21/2016 10:14:54 AM 10920 (0x2AA8) Completed validation of Certificate [Thumbprint 21C5FF81EE60B855E7FC8F767DA86BAC58DAA51A] issued to 'SMS' MP_RegistrationManager 10/21/2016 10:14:54 AM 10920 (0x2AA8) Raising event: [sMS_CodePage(437), SMS_LocaleID(1033)] instance of MpEvent_CertRevoked { ClientID = "GUID:E19C9C5C-5D8C-408D-A4BB-B7BD4A1441A4"; DateTime = "20161021151454.606000+000"; MachineName = "xxx-sccm1.xxxxxxxxxx.org"; ProcessID = 2948; Sender = "Client(SMSID = GUID:B1C18985-608A-4CD6-B25F-2D7ADADFD444)"; SiteCode = "XXX"; ThreadID = 10920; }; MP_RegistrationManager 10/21/2016 10:14:54 AM 10920 (0x2AA8) Client 'GUID:B1C18985-608A-4CD6-B25F-2D7ADADFD444' is unknown or has an invalid key registered in the database. MP_RegistrationManager 10/21/2016 10:14:54 AM 10920 (0x2AA8) CCMValidateAuthHeaders failed (0x87d0025e) to validate headers for client 'GUID:B1C18985-608A-4CD6-B25F-2D7ADADFD444'. MP_RegistrationManager 10/21/2016 10:14:54 AM 10920 (0x2AA8) MP Reg: Failed to verify RegistrationHint, 0x87d0025e. MP_RegistrationManager 10/21/2016 10:14:54 AM 10920 (0x2AA8) MP Reg: Processing completed. Completion state = 0 MP_RegistrationManager 10/21/2016 10:14:54 AM 10920 (0x2AA8) This makes me thing there is an issue in the DB but I don't know SQL well enough to fix it.
  5. I'm having the following warning popup over and over in the SMS_MP_CONTROL_MANAGER component: MP has rejected policy request from Client(SMSID = GUID:B1C18985-608A-4CD6-B25F-2D7ADADFD444) because this SMSID is marked as blocked. The issue is I cannot find a client with that GUID and I'm not blocking any clients within SCCM. I did a Powershell query for that SMSID as well as blocked devices. Get-CMDevice | Where-Object { $_.IsBlocked -eq $true} Get-CMDevice | Where-Object { $_.SMSID -eq 'GUID:E35DAB82-1F79-4850-8383-7A8D7C43E929'} Both returned no results. Anyone have any ideas?
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.