Hardware Inventory Failing Message ID: 5416

Problem:  We started noticing hardware inventory failing right after we applied the 1706 update.  The management point was getting flooded with error messages like below Message ID: 5416 and the retry outbox filling up with thousands(25,000+ for us) of retry files.  There were no changes to inventory settings or issues with the configuration.mof file as far as we could tell.  We also checked for replication issues and DP corruption issues but nothing came up as a problem.

MP needs to reload the hardware inventory class mapping table when processing Hardware inventory. The MP hardware inventory manager cannot find a WMI class definition in the mapping table when processing a report. This should only happen if new definitions beyond those known to the site are added to the collected classes.

 

Possible cause: Inconsistent way the new definitions have been introduced.

Solution: Check that the mapping tables contain the information consistent with the hardware definition tables and that the definitions have been propagated properly.

Possible cause: Corruption of the data base.

Solution: Check the consistency of the data base.

Solution:  The solution ended up being pretty easy but frustrating, all we had to do was modify the hardware inventory classes(we added a class) in client settings and let the clients recompile inventory.  After doing that the retry box gradually went down as systems sent in inventory with the new settings and inventory is now updating in the database.

MP_Framework.log on Secondary Site Full of Errors

On my secondary site servers I was getting an issue where they looked like they were working fine.  Installation status in console showed success, all the site and component status messages in console showed green, and replication status was also green.  All looked fine until I noticed there were a lot of clients failing to get policy or showing inactive in the console and they were all in boundary groups that were assigned to secondary sites.

 

MP_Framework.log was the only place I saw errors that stood out on the secondary site.

CMpDatabase::GetClientPublicKeyEx(ClientID=’GUID:8C900341-7698-46D9-B4A3-43B28DAC7390′) failed (0x87d00242).

 

CMPDBConnection::ExecuteSQL(): ICommandText::Execute() failed with 0x80040E14

 

MPDB ERROR – CONNECTION PARAMETERS
SQL Server Name     : MSF1VSSS01P.xx.xxx
SQL Database Name   : CM_S01
Integrated Auth     : True
MPDB ERROR – EXTENDED INFORMATION
MPDB Method         : ExecuteSP()
MPDB Method HRESULT : 0x80040E14
Error Description   : Could not execute procedure on remote server ‘msf1vdbx03p.xx.xxx’ because SQL Server is not configured for remote access. Ask your system administrator to reconfigure SQL Server to allow remote access.
OLEDB IID           : {0C733A63-2A1C-11CE-ADE5-00AA0044773D}
ProgID              : Microsoft SQL Server Native Client 11.0
MPDB ERROR – INFORMATION FROM DRIVER
SQL Server Name   : MSF1VSSS01P
Stored Procedure  : sp_GetPublicKeyForSMSID
Native Error no.  : 7201
Error State       : 4
Class (Severity)  : 17
Line number in SP : 15

 

 

Turns out the issue was with my SQL configuration, at some point after the initial ConfigMgr install my SQL DBA’s or a hardening policy(still trying to get answers on that) went in and reconfigured the SQL servers to not allow remote connections.  I had to set both the Secondary site SQL server  and Primary site SQL server to allow remote connections.  Then restart SQL server and agent to apply setting.

 

 

After restarting SQL MP_Framework.log cleared up