-

ConfigMgr 2012 update scan fails with 8007000E and causes incorrect compliance status.


Root Cause

Because Configuration Manager does compliance reporting, it has extremely broad scan criteria to determine what is applicable. This is different from a typical scan performed by the Windows Update agent which requires a smaller subset of criteria. If an update is on WSUS and in a non-declined state, the Configuration Manager scan criteria will cause the Windows Update agent to try to evaluate it.

Windows x86 clients have a much smaller addressable memory range than 64-bit clients. With enough updates, the data returned to Configuration Manager is large enough that RPC can’t allocate the shared section used to return the data. This is because overall memory usage of the svchost.exe process hosting the Windows Update Agent process is extremely high.

The result is that there is either not enough memory available to satisfy the request or there is not a large enough contiguous block of free memory to satisfy the request.


Workaround

From SCCM perspective, we need to deploy KB3138612 through Packaging or Application model on the affected clients. Post that we have to initiate the Patching Cycles for those.



Comments

Post a Comment

Popular posts from this blog

SCCM: Determining installed applications last use time_ SQL Query.

-
ConfigMgr will definitely be able to let SCCM admins know what are installed in the environment regardless if it is a server or workstation. SCCM by default comes with a set of reports that SCCM admins can utilize to gather information. The one that I am going to mention today is , "Computers that has a metered program but have not run the program since a specific date". What is so special about this report you may think, I had the same thinking as you but it is pretty interesting to know how is this data derived. The data set for this is based on Software Inventory and this means gathering file types that are on machines. The last used time is gathered asp art of software metering. This report will provide the information based on the files inventoried and their respective last used date. Nothing unique right? Here comes the interesting part, picture the scenario as below. All of us will know that in order for Microsoft Office to be used, it has to be inst
Read more

Unable to read existing WUA Group Policy object. Error = 0x80004005.

-
Image
Wanted to share.. It will be helpful to achieve maximum rate of patching compliance. As we often face issues to troubleshoot the systems with  "Enforcement Status Unknown" state. Issue Some of the servers / workstations are appearing as “ Enforcement Status Unknown ” in Patching Deployment Report. Logs mentioned below. Unable to find or read WUA Managed server policy. Unable to read existing WUA Group Policy object. Error = 0x80004005. Failed to Add Update Source for WUAgent of type (2) and id ({6219E813-D37D-4D15-ADA7-3E4DADF55C9E}). Error = 0x80004005. Resolution Issue appears to be with corrupt policy info locally on the machine.  Please go to c:\windows\system32\grouppolicy\machine and delete the registry.pol  file.  Run GPUpdate /force command after that .
Read more

SQL Query to find the detailed Enforcement Status of a Software Update Deployment for Patching.

-
Please find the query below. select vrs.name0, a.Assignment_UniqueID as DeploymentID, a.AssignmentName as DeploymentName, sn.StateName as LastEnforcementState, assc.StateTime , a.CollectionName, assc.Lasterrorcode from v_CIAssignment a join v_AssignmentState_Combined assc on a.AssignmentID=assc.AssignmentID join v_StateNames sn on assc.StateType = sn.TopicType and sn.StateID=isnull(assc.StateID,0) join v_R_System vrs on vrs.ResourceID=assc.ResourceID where a.AssignmentID=" Put the Assignment ID of the deployment "
Read more