Update for Windows Update Client addresses ConfigMgr 2012 Update Scan Issue – Windowsupdate.log Error 8007000E
Yesterday Microsoft has released an update for the Windows Update client. This relates to the issue with Windows 7 and Software Updates which I blogged about a few weeks ago.
This is the KB article: Windows Update Client for Windows 7 : June 2015
Interesting: the KB Article mentions this update does not only address the out-of-memory issue but also contains general improvements made to support upgrades to a later version of windows.
If you have Windows 7 x86 clients in your environment the best approach would be to release this update in your environment as soon as possible. Important : you need to install the hardening update KB2938066 on your WSUS servers prior to releasing this update!
Hope it helps!
Last week Kim blogged about an issue with Windows 7 and Software Updates that some of his customers had been reporting.
Kim had already outlined the issue and the symptoms, plus also provided a few workarounds which may help in resolving it. Through this post I wanted to inform you that now Microsoft has published a blog post that:
a) gives some more details on the root cause of the problem
b) outlines some possible workarounds and
c) most importantly : states a hotfix is in the pipeline which will be available in (late) Q2
You can find the full details here.
I ran into the same issue at one of my customers last week and have been working with Microsoft support to get this resolved. Below you can read some findings and experiences from the past days.
The workaround to Move wuauserv (Windows Update Agent) to its own SVCHost.exe instance did not prove to be very successful. Although we saw the scan job succeeding on a few clients at first, after a few additional scans the issue returned.
Next step was cleaning up WSUS. First we needed to verify what we could potentially clean up using the script provided by Microsoft:
To get things back on the rails in the end the only successful method was to run WSUS cleanup script to decline all superseded updates. Running the script with the –DeclineLastLevelOnly switch was not sufficient.
Important: Before running this cleanup script make sure to identify if any of the updates are still needed! It could be a superseding update has not yet been released due to your internal approval and/or release processes!
And while you are checking that also note that the script output may be misleading. Set the LastLevel column filter to False if you are actually looking for the Last Level Superseded Updates.
Running the script itself took around 15 minutes.
Note: if you are running multiple SUPS in your environment you should only run this on one SUP – the one with Windows Update set as synchronization source.
Hope it helps!
Another week gone by, so time for the weekly review post. It has been a slow week so only a few items were added to my list this time:
- Nice and detailed article on the ConfigMgrDogs blog about Windows Update process on the client.
- A best practice guide for (task) sequences in Configuration Manager 2012 R2 has been made available through the Microsoft download center. Note there are six files in total to be downloaded; although the naming convention hints there would be seven in total it seems file number VI does not exist.
Until next week!
Recently I encountered an issue in my lab during the initial Software Updates synchronization. The sync failed and as a result no updates were available in Configuration Manager. This blog post describes the issue and how to resolve it.
When examining the wsyncmgr.log the following entry is logged:
- Sync failed: WSUS update source not found on site PS1. Please refer to WCM.log for configuration error details.. Source: getSiteUpdateSource
As indicated in the previous error log, more information was to be found in the WCM.log. This is a screenshot of that log file:
This particular entry was indicating something was failing with the Subscriptions:
- Failed to set Subscriptions on the WSUS Server. Error:(-2147467259)Unspecified error
The entry logged just before that one points us further into the right direction:
- Subscription contains categories unknown to WSUS and SUP has no upstream server.~ Please either unsubscribe the unknown categories or import into WSUS an upstream package containing them.
The WCM.log entries refer to specific categories that are unknown – but do not specify any further details. I suspected there was an issue with the classifications and products that were enabled by default in the Software Update component configuration.
To work around this issue I followed these steps:
- Go to the Software Update Component properties and deselect all Products and Classifications which are enabled out-of-the-box.
- Force the Software Update Synchronization to run. Monitor the WCM.log and WsyncMgr.log to validate the synchronization is now running successfully. Note that no updates will be synchronized at this point, but the products and classifications catalog will be synched as part of the process.
- Enable the required Products and Classifications that were disabled previously, and run the synchronization again.
- Once I went through these steps the synchronization was working fine again:
Hope it helps!
Recently I have ran into an issue at a customer site where software update lists did not properly replicate down to child primary sites. Some of the latest update lists were either incomplete or not visible at all. As a result the customer could not properly advertise the latest software updates.
Initial investigation of the problem shows that the objmgr.box\INCOMING\ and objmgr.box\INCOMING\Retry folders on the child sites contained a lot of unprocessed CID and SDM files. Looking further into the objreplmgr.log errors like to one below are logged:
Processing replication file C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\objmgr.box\INCOMING\Retry\S00_73333.SDM in retry.
Successfully processed Object ScopeId_43C9B1DB-9FC7-4363-8027-36D0C5C24148/AuthList_14C762F6-811D-473F-941F-58B126C93CEF.3
SDM Package ScopeId_43C9B1DB-9FC7-4363-8027-36D0C5C24148/AuthList_14C762F6-811D-473F-941F-58B126C93CEF.3 does not exist in the DB, will insert it with the IsDeleted Flag Set.
SQL MESSAGE: sp_SetupSDMPackage – SDMPackage refers another SDMPackage that is not available yet
sp_SetupSDMPackage returns an error 2
Referenced SDMPackages are not available yet: http://schemas.microsoft.com/systemsmanagementserver/Site_43C9B1DB-9FC7-4363-8027-36D0C5C24148/SUM_cee535ab-0ae5-44e7-8fdf-0f698b27e6f9/1(0);
Failed to Delete Object ScopeId_43C9B1DB-9FC7-4363-8027-36D0C5C24148/AuthList_14C762F6-811D-473F-941F-58B126C93CEF.3. Will add the Replication File C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\objmgr.box\INCOMING\Retry\S00_73333.SDM to the Replication File Retry Queue.
Similar errors exists when the site is processing .CID files.
Interdependencies exists between the different items used for software updates. If the referenced objects are not available the new file will not be correctly processed. It seems that for this particular child site a hickup occured in the replication and the information on the child site is incomplete.
To resolve the issue I ran through the following steps:
1. Stop the SMSEXEC and SMS COMPONENT MANAGER services. This will bring all activity on the site to a standstill.
2. Rename the INCOMING folder to INCOMING_old and recreate an new empty folder structure (so INCOMING and all retry/bad subfolders).
This way we can monitor which files are replicating down and if they are properly being processed, and also see what is being moved into the retry and bad folders.
3. Run the following query on the child site database: Delete from CI_ConfigurationItems Where CIType_ID in (1, 6, 8);
Note that the ID’s may be different for each site. Run the query Select * from CI_Types to get the proper list.
We need to delete the following types: SoftwareUpdate, SoftwareUpdateBundle and AuthorizationList
4. Then run this query: Update CI_SDMPackages set IsDeleted = 1 where SourceSite = ‘XXX’;
Make sure to replace the XXX with the site code of the central site in the hierarchy.
5. And execute the following: Exec sp_DeleteOldSDMPackageData 0;
6. As a final step force a full replication by dropping a XXX.SHA file in the objmgr.box folder on the central site
Here XXX is to be replaced with the site code of the child site.
7. Restart the services stopped in the first step to bring the site back in operational mode.
Shortly after these steps you should see files appearing in the objmgr.box\INCOMING\ folder on the child site again. You can also see if they are being processed in the objreplmgr.log file. Do not be alarmed if initially some files are put in the retry folder again. They will eventually be processed when all dependencies are in place. A full replication can be time consuming: in my case it took over 12 hours for the procedure to complete. Eventually the end result was that the Update Lists showed up completely again.
Note: the above procedure includes making direct changes to the backend database. If you have a support contract I would highly recommend to involve a Microsoft Support representative to ensure you infrastructure remains supported.