Hello, anyone have suggestions for this issue on a couple of hundred Windows 7 Professional SP1 clients?

The one machine I'm looking at currently has no errors in the scan agent log or the Windows update log.  The WUAHandler log has the text in the subject line for 13 different updates.  After that text the next line is 'No updates were actionable for installation'.

The Updates Deployment log shows a ciStateError for each of the updates and then a line stating 'Not refreshing update presence stat as error CI Info status received'.  The next line has information about update failure including the Win32ErrorCode of 2147747432.

The Updates Handler log has a line for each of the updates with the same Win32ErrorCode above.

I have attempted several fixes including stopping the Windows Update service, renaming the c:\Windows\SoftwareDistribution folder, and starting the Windows Update service.  I have also re-registered various Windows Update related DLL files.

Unfortunately I cannot run the Mr. Fixit software update troubleshooter as these machines are remote to me.  They are also end user machines so avoiding reboots would be preferrable.  I can reboot them if absolutely neccesary though.

Any help would be greatly appreciated.



Did you try this?

social.technet.microsoft.com/Forums/en-US/configmgrsum/thread/3dce0fb0-4661-4db3-afaa-a940929685ea/

I considered trying that but it didn't seem to make much sense as the WUAHandler log states that the updates are already installed.  I have searched for the various update ID's in the WUAHandler log and have found their status to be 'installed'.

I am having the same exact issue.  This was not a problem last month.  I have rebooted to no avail.  The loop just continues.

hmm, 217747432 (decimal) = 0x80040668 (hex)
and, that hex error has a reference on the CM doc library:
http://technet.microsoft.com/en-us/library/bb735894.aspx

if you run a deployment re-evaluation cycle (which by default is only weekly), that might clear it up?

Thanks everyone for the suggestions so far.

Don:  We have our software updates deployment evaluation cycle set to run once a day.  I have manually kicked this off on several clients and they just come right back to where they were.  It seems like the machines are not evaluating the updates correctly.

I have also validated that the updates are actually installed.  What is going on?

Has no one experienced this before?

Anyone have any suggestions for this issue?

any possibility this is merely a wmi problem on those clients?

put the following in a vbs and test on one machine:

dim newCCMupdatesstore

set newccmupdatesstore = Createobject ("Microsoft.ccm.updatesstore")

newCCMupdatesstore.RefreshServercompliancestate

fyi, some related info over here: http://anoopcnair.com/2011/11/26/configmgr-sccm-software-update-related-wmi-checks/

Thank you for the suggestion.  I'll take a look.

grundlichkeit:

It certainly looks like a WMI problem.  The script did not help but going through the steps at the link you provided highlights a problem.

When looking at a specific update ID in the WBEMTest applet, it shows up as missing.  When I search for the same update ID in the WUAHandler.log file it shows as installed.

Any suggestions on how to fix this?  If it was XP I would have just recreated the WMI repository but since this is Windows 7, I've been leary of doing that...

• Edited by NTitus Thursday, December 13, 2012 8:32 PM direction

grundlichkeit:

It certainly looks like a WMI problem.  The script did not help but going through the steps at the link you provided highlights a problem.

When looking at a specific update ID in the WBEMTest applet, it shows up as missing.  When I search for the same update ID in the WUAHandler.log file it shows as installed.

Any suggestions on how to fix this?  If it was XP I would have just recreated the WMI repository but since this is Windows 7, I've been leary of doing that...

• Edited by NTitus Thursday, December 13, 2012 8:32 PM direction

grundlichkeit:

It certainly looks like a WMI problem.  The script did not help but going through the steps at the link you provided highlights a problem.

When looking at a specific update ID in the WBEMTest applet, it shows up as missing.  When I search for the same update ID in the WUAHandler.log file it shows as installed.

Any suggestions on how to fix this?  If it was XP I would have just recreated the WMI repository but since this is Windows 7, I've been leary of doing that...

• Edited by NTitus Thursday, December 13, 2012 8:32 PM direction

grundlichkeit:

It certainly looks like a WMI problem.  The script did not help but going through the steps at the link you provided highlights a problem.

When looking at a specific update ID in the WBEMTest applet, it shows up as missing.  When I search for the same update ID in the WUAHandler.log file it shows as installed.

Any suggestions on how to fix this?  If it was XP I would have just recreated the WMI repository but since this is Windows 7, I've been leary of doing that...

• Edited by NTitus Thursday, December 13, 2012 8:32 PM direction

grundlichkeit:

It certainly looks like a WMI problem.  The script did not help but going through the steps at the link you provided highlights a problem.

When looking at a specific update ID in the WBEMTest applet, it shows up as missing.  When I search for the same update ID in the WUAHandler.log file it shows as installed.

Any suggestions on how to fix this?  If it was XP I would have just recreated the WMI repository but since this is Windows 7, I've been leary of doing that...

• Edited by NTitus Thursday, December 13, 2012 8:32 PM direction

This may fix it. Test on one machine before deploying :)

net stop "Automatic Updates"
rename %windir%\softwaredistribution\datastore\logs\edb.log to edb_OLD.log
gpupdate /force
Try SCCM software updates again.

• Proposed as answer by rpxn Thursday, December 13, 2012 11:16 PM
• Marked as answer by Nicholas Li Friday, December 21, 2012 4:03 AM
• Unmarked as answer by NTitus Tuesday, January 29, 2013 3:17 PM
• Unproposed as answer by NTitus Tuesday, January 29, 2013 3:17 PM

This may fix it. Test on one machine before deploying :)

net stop "Automatic Updates"
rename %windir%\softwaredistribution\datastore\logs\edb.log to edb_OLD.log
gpupdate /force
Try SCCM software updates again.

• Proposed as answer by rpxn Thursday, December 13, 2012 11:16 PM
• Marked as answer by Nicholas Li Friday, December 21, 2012 4:03 AM
• Unmarked as answer by NTitus Tuesday, January 29, 2013 3:17 PM
• Unproposed as answer by NTitus Tuesday, January 29, 2013 3:17 PM

This may fix it. Test on one machine before deploying :)

net stop "Automatic Updates"
rename %windir%\softwaredistribution\datastore\logs\edb.log to edb_OLD.log
gpupdate /force
Try SCCM software updates again.

• Proposed as answer by rpxn Thursday, December 13, 2012 11:16 PM
• Marked as answer by Nicholas Li Friday, December 21, 2012 4:03 AM
• Unmarked as answer by NTitus Tuesday, January 29, 2013 3:17 PM
• Unproposed as answer by NTitus Tuesday, January 29, 2013 3:17 PM

This may fix it. Test on one machine before deploying :)

net stop "Automatic Updates"
rename %windir%\softwaredistribution\datastore\logs\edb.log to edb_OLD.log
gpupdate /force
Try SCCM software updates again.

• Proposed as answer by rpxn Thursday, December 13, 2012 11:16 PM
• Marked as answer by Nicholas Li Friday, December 21, 2012 4:03 AM
• Unmarked as answer by NTitus Tuesday, January 29, 2013 3:17 PM
• Unproposed as answer by NTitus Tuesday, January 29, 2013 3:17 PM

This may fix it. Test on one machine before deploying :)

net stop "Automatic Updates"
rename %windir%\softwaredistribution\datastore\logs\edb.log to edb_OLD.log
gpupdate /force
Try SCCM software updates again.

• Proposed as answer by rpxn Thursday, December 13, 2012 11:16 PM
• Marked as answer by Nicholas Li Friday, December 21, 2012 4:03 AM
• Unmarked as answer by NTitus Tuesday, January 29, 2013 3:17 PM
• Unproposed as answer by NTitus Tuesday, January 29, 2013 3:17 PM

This may fix it. Test on one machine before deploying :)

net stop "Automatic Updates"
rename %windir%\softwaredistribution\datastore\logs\edb.log to edb_OLD.log
gpupdate /force
Try SCCM software updates again.

This worked for an XP machine but not on a Windows 7 machine. Any further suggestions would be appreciated.

• Edited by NTitus Tuesday, January 29, 2013 3:19 PM

This may fix it. Test on one machine before deploying :)

net stop "Automatic Updates"
rename %windir%\softwaredistribution\datastore\logs\edb.log to edb_OLD.log
gpupdate /force
Try SCCM software updates again.

This worked for an XP machine but not on a Windows 7 machine. Any further suggestions would be appreciated.

• Edited by NTitus Tuesday, January 29, 2013 3:19 PM

This may fix it. Test on one machine before deploying :)

net stop "Automatic Updates"
rename %windir%\softwaredistribution\datastore\logs\edb.log to edb_OLD.log
gpupdate /force
Try SCCM software updates again.

This worked for an XP machine but not on a Windows 7 machine. Any further suggestions would be appreciated.

• Edited by NTitus Tuesday, January 29, 2013 3:19 PM

This may fix it. Test on one machine before deploying :)

net stop "Automatic Updates"
rename %windir%\softwaredistribution\datastore\logs\edb.log to edb_OLD.log
gpupdate /force
Try SCCM software updates again.

This worked for an XP machine but not on a Windows 7 machine. Any further suggestions would be appreciated.

• Edited by NTitus Tuesday, January 29, 2013 3:19 PM

This may fix it. Test on one machine before deploying :)

net stop "Automatic Updates"
rename %windir%\softwaredistribution\datastore\logs\edb.log to edb_OLD.log
gpupdate /force
Try SCCM software updates again.

This worked for an XP machine but not on a Windows 7 machine. Any further suggestions would be appreciated.

• Edited by NTitus Tuesday, January 29, 2013 3:19 PM

It works for me on 2008 R2 servers, so this is a valid fix for the Windows 7 platform for the problem you described.

If it's not working for you, you've clearly got more issues going on. Have you checked your log files for clues?

In the interest of closing this thread:

I rebuilt the WMI repositories on several of the machines in question and that did not fix the problem.  After talking with Premier Services we have decided that reimaging the affected machines is about the only avenue for getting them fixed. I'm a little disappointed that we didn't find a solution but it is what it is.

• Marked as answer by NTitus Monday, July 15, 2013 7:25 PM
• Unmarked as answer by NTitus 14 hours 6 minutes ago

In the interest of closing this thread:

I rebuilt the WMI repositories on several of the machines in question and that did not fix the problem.  After talking with Premier Services we have decided that reimaging the affected machines is about the only avenue for getting them fixed. I'm a little disappointed that we didn't find a solution but it is what it is.

• Marked as answer by NTitus Monday, July 15, 2013 7:25 PM
• Unmarked as answer by NTitus Wednesday, March 11, 2015 5:25 PM

In the interest of closing this thread:

I rebuilt the WMI repositories on several of the machines in question and that did not fix the problem.  After talking with Premier Services we have decided that reimaging the affected machines is about the only avenue for getting them fixed. I'm a little disappointed that we didn't find a solution but it is what it is.

• Marked as answer by NTitus Monday, July 15, 2013 7:25 PM
• Unmarked as answer by NTitus Wednesday, March 11, 2015 5:25 PM

In the interest of closing this thread:

I rebuilt the WMI repositories on several of the machines in question and that did not fix the problem.  After talking with Premier Services we have decided that reimaging the affected machines is about the only avenue for getting them fixed. I'm a little disappointed that we didn't find a solution but it is what it is.

• Marked as answer by NTitus Monday, July 15, 2013 7:25 PM
• Unmarked as answer by NTitus Wednesday, March 11, 2015 5:25 PM

In the interest of closing this thread:

I rebuilt the WMI repositories on several of the machines in question and that did not fix the problem.  After talking with Premier Services we have decided that reimaging the affected machines is about the only avenue for getting them fixed. I'm a little disappointed that we didn't find a solution but it is what it is.

• Marked as answer by NTitus Monday, July 15, 2013 7:25 PM
• Unmarked as answer by NTitus Wednesday, March 11, 2015 5:25 PM

In the interest of closing this thread:

I rebuilt the WMI repositories on several of the machines in question and that did not fix the problem.  After talking with Premier Services we have decided that reimaging the affected machines is about the only avenue for getting them fixed. I'm a little disappointed that we didn't find a solution but it is what it is.

• Marked as answer by NTitus Monday, July 15, 2013 7:25 PM
• Unmarked as answer by NTitus Wednesday, March 11, 2015 5:25 PM

Update:

Premier support case was reopened and troubleshooting determined that NTFS transaction log corruption was keeping updates from installing.  NTFS transaction log corruption seemed to be cause by a combination of hardware and FDE software.  FDE software vendor case was opened but vendor was not helpful.

Solution is to boot machine to WinPE and force check disk to run.  This has fixed 95% of the broken machines.  Unfortunately, it has trashed the rest.

• Marked as answer by NTitus 14 hours 1 minutes ago

Update:

Premier support case was reopened and troubleshooting determined that NTFS transaction log corruption was keeping updates from installing.  NTFS transaction log corruption seemed to be cause by a combination of hardware and FDE software.  FDE software vendor case was opened but vendor was not helpful.

Solution is to boot machine to WinPE and force check disk to run.  This has fixed 95% of the broken machines.  Unfortunately, it has trashed the rest.

• Marked as answer by NTitus Wednesday, March 11, 2015 5:29 PM

Update:

Premier support case was reopened and troubleshooting determined that NTFS transaction log corruption was keeping updates from installing.  NTFS transaction log corruption seemed to be cause by a combination of hardware and FDE software.  FDE software vendor case was opened but vendor was not helpful.

Solution is to boot machine to WinPE and force check disk to run.  This has fixed 95% of the broken machines.  Unfortunately, it has trashed the rest.

• Marked as answer by NTitus Wednesday, March 11, 2015 5:29 PM

Update:

Premier support case was reopened and troubleshooting determined that NTFS transaction log corruption was keeping updates from installing.  NTFS transaction log corruption seemed to be cause by a combination of hardware and FDE software.  FDE software vendor case was opened but vendor was not helpful.

Solution is to boot machine to WinPE and force check disk to run.  This has fixed 95% of the broken machines.  Unfortunately, it has trashed the rest.

• Marked as answer by NTitus Wednesday, March 11, 2015 5:29 PM

Update:

Premier support case was reopened and troubleshooting determined that NTFS transaction log corruption was keeping updates from installing.  NTFS transaction log corruption seemed to be cause by a combination of hardware and FDE software.  FDE software vendor case was opened but vendor was not helpful.

Solution is to boot machine to WinPE and force check disk to run.  This has fixed 95% of the broken machines.  Unfortunately, it has trashed the rest.

• Marked as answer by NTitus Wednesday, March 11, 2015 5:29 PM

Update:

Premier support case was reopened and troubleshooting determined that NTFS transaction log corruption was keeping updates from installing.  NTFS transaction log corruption seemed to be cause by a combination of hardware and FDE software.  FDE software vendor case was opened but vendor was not helpful.

Solution is to boot machine to WinPE and force check disk to run.  This has fixed 95% of the broken machines.  Unfortunately, it has trashed the rest.

• Marked as answer by NTitus Wednesday, March 11, 2015 5:29 PM