none
One particular software package no longer installs on Windows 7 after upgrade to SP1 - error 80070570 (file corrupt)

    Question

  • I am currently testing the RTM version of Windows 7 SP1 on my network and am finding that of the 40 or so packages that I am deploying to my test machines via SCE 2010 (7.0.2432.1), one single package is failing to install with error code 80070570.

    The package in question is a .exe install of Office Professional Plus 2010. This package works perfectly on Windows 7 RTM machines, but as soon as the same machine is upgraded to SP1, the package fails. The same package fails on the same machine even if Windows is reinstalled from scratch using the Windows 7 SP1 ISO install media. The problem is exhibited on multiple workstations (every one I've tried with SP1).

    The following is the relevant excerpt from the WindowsUpdate.log file:

    2011-02-24	20:17:49:056	 968	3d4	AU	#############
    2011-02-24	20:17:49:056	 968	3d4	AU	## START ## AU: Download updates
    2011-02-24	20:17:49:056	 968	3d4	AU	#########
    2011-02-24	20:17:49:056	 968	3d4	AU	 # Approved updates = 1
    2011-02-24	20:17:49:062	 968	3d4	AU	AU initiated download, updateId = {6714EF24-FDD1-4D37-A913-5494BC4EE240}.2, callId = {4438AF59-4575-429A-B11E-463B11D1A608}
    2011-02-24	20:17:49:062	 968	3d4	AU	Setting AU scheduled install time to 2011-02-24 22:00:00
    2011-02-24	20:17:49:063	 968	3d4	AU	Successfully wrote event for AU health state:0
    2011-02-24	20:17:49:063	 968	3d4	AU	Currently showing Progress UX client - so not launching any other client
    2011-02-24	20:17:49:066	 968	3d4	AU	Successfully wrote event for AU health state:0
    2011-02-24	20:17:49:066	 968	3d4	AU	 # Pending download calls = 1
    2011-02-24	20:17:49:066	 968	3d4	AU	<<## SUBMITTED ## AU: Download updates
    2011-02-24	20:17:49:069	 968	d60	DnldMgr	*************
    2011-02-24	20:17:49:069	 968	d60	DnldMgr	** START ** DnldMgr: Downloading updates [CallerId = AutomaticUpdatesWuApp]
    2011-02-24	20:17:49:069	 968	d60	DnldMgr	*********
    2011-02-24	20:17:49:069	 968	d60	DnldMgr	 * Call ID = {4438AF59-4575-429A-B11E-463B11D1A608}
    2011-02-24	20:17:49:069	 968	d60	DnldMgr	 * Priority = 3, Interactive = 1, Owner is system = 0, Explicit proxy = 0, Proxy session id = 2, ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
    2011-02-24	20:17:49:069	 968	d60	DnldMgr	 * Updates to download = 1
    2011-02-24	20:17:49:069	 968	d60	Agent	 * Title = Microsoft Office Professional Plus 2010
    2011-02-24	20:17:49:069	 968	d60	Agent	 * UpdateId = {6714EF24-FDD1-4D37-A913-5494BC4EE240}.2
    2011-02-24	20:17:49:071	 968	d60	DnldMgr	*********** DnldMgr: New download job [UpdateId = {6714EF24-FDD1-4D37-A913-5494BC4EE240}.2] ***********
    2011-02-24	20:17:49:073	 968	3e0	AU	Getting featured update notifications. fIncludeDismissed = true
    2011-02-24	20:17:49:073	 968	3e0	AU	No featured updates available.
    2011-02-24	20:17:49:095	 968	d60	DnldMgr	 * BITS job initialized, JobId = {C9A4B893-DB6C-4B8A-8323-24847740DFB4}
    2011-02-24	20:17:49:102	 968	d60	DnldMgr	 * Downloading from http://terra.crosfields.internal:8530/Content/D1/4CCA64C700B6519710E8DAF5F966F6AB2B941CD1.cab to C:\Windows\SoftwareDistribution\Download\e613dbced1d227f56710f53f192becee\4cca64c700b6519710e8daf5f966f6ab2b941cd1 (full file).
    2011-02-24	20:17:49:108	 968	d60	DnldMgr	 * Downloading from http://terra.crosfields.internal:8530/Content/14/1140B8A6902309C4D2F4354F1167809A6D0E3814.cab to C:\Windows\SoftwareDistribution\Download\e613dbced1d227f56710f53f192becee\1140b8a6902309c4d2f4354f1167809a6d0e3814 (full file).
    2011-02-24	20:17:49:115	 968	d60	Agent	*********
    2011-02-24	20:17:49:115	 968	d60	Agent	** END ** Agent: Downloading updates [CallerId = AutomaticUpdatesWuApp]
    2011-02-24	20:17:49:116	 968	d60	Agent	*************
    2011-02-24	20:17:54:063	 968	d60	Report	CWERReporter finishing event handling. (00000000)
    2011-02-24	20:18:11:065	 968	a10	AU	AU checked download status and it changed: Downloading is paused
    2011-02-24	20:18:11:068	 968	a10	AU	AU checked download status and it changed: Downloading is not paused
    2011-02-24	20:18:17:043	 968	ca0	DnldMgr	BITS job {C9A4B893-DB6C-4B8A-8323-24847740DFB4} completed successfully
    2011-02-24	20:18:26:757	 968	ca0	Misc	Validating signature for C:\Windows\SoftwareDistribution\Download\e613dbced1d227f56710f53f192becee\4cca64c700b6519710e8daf5f966f6ab2b941cd1:
    2011-02-24	20:18:26:769	 968	ca0	Misc	WARNING: Digital Signatures on file C:\Windows\SoftwareDistribution\Download\e613dbced1d227f56710f53f192becee\4cca64c700b6519710e8daf5f966f6ab2b941cd1 are not trusted: Error 0x80070570
    2011-02-24	20:18:27:046	 968	ca0	DnldMgr	WARNING: File failed postprocessing, error = 80070570
    2011-02-24	20:18:27:047	 968	ca0	DnldMgr	Failed file: URL = 'http://terra.crosfields.internal:8530/Content/D1/4CCA64C700B6519710E8DAF5F966F6AB2B941CD1.cab', Local path = 'C:\Windows\SoftwareDistribution\Download\e613dbced1d227f56710f53f192becee\4cca64c700b6519710e8daf5f966f6ab2b941cd1'
    2011-02-24	20:18:31:296	 968	ca0	Misc	Validating signature for C:\Windows\SoftwareDistribution\Download\e613dbced1d227f56710f53f192becee\1140b8a6902309c4d2f4354f1167809a6d0e3814:
    2011-02-24	20:18:31:296	 968	ca0	Misc	WARNING: Digital Signatures on file C:\Windows\SoftwareDistribution\Download\e613dbced1d227f56710f53f192becee\1140b8a6902309c4d2f4354f1167809a6d0e3814 are not trusted: Error 0x80070570
    2011-02-24	20:18:31:476	 968	ca0	DnldMgr	WARNING: File failed postprocessing, error = 80070570
    2011-02-24	20:18:31:476	 968	ca0	DnldMgr	Failed file: URL = 'http://terra.crosfields.internal:8530/Content/14/1140B8A6902309C4D2F4354F1167809A6D0E3814.cab', Local path = 'C:\Windows\SoftwareDistribution\Download\e613dbced1d227f56710f53f192becee\1140b8a6902309c4d2f4354f1167809a6d0e3814'
    2011-02-24	20:18:31:479	 968	ca0	DnldMgr	Error 0x80070570 occurred while downloading update; notifying dependent calls.
    2011-02-24	20:18:31:496	 968	a10	AU	>>## RESUMED ## AU: Download update [UpdateId = {6714EF24-FDD1-4D37-A913-5494BC4EE240}]
    2011-02-24	20:18:31:496	 968	a10	AU	 # WARNING: Download failed, error = 0x80070570
    2011-02-24	20:18:31:497	 968	a10	AU	#########
    2011-02-24	20:18:31:497	 968	a10	AU	## END ## AU: Download updates
    2011-02-24	20:18:31:497	 968	a10	AU	#############
    

     

    I know already that 0x80070570 corresponds to ERROR_FILE_CORRUPT, but I know the server copy is fine since it works on pre-SP1 workstations, and when I compare the copy downloaded to the SoftwareDistribution folder it matches the version on the server exactly. If I check the Digital Signatures tab in file properties for the file, it reports that "The digital signature is OK." The certificate used to sign the package is the same as is used for every other package, and they all install fine.

    I have tried creating a new package of the same install files, and that fails with the same error. I also tried removing a file from the installation package to ensure the package would be different bit-for-bit, and that package also failed. As a last resort, I uninstalled the antivirus software from the workstation, to no effect.

    The only unusual property of this package that sets it apart from other packages is its size. The total package size reports in Windows Update as 649.8MB, which makes it the single largest package on my SCE server, and as you can see from the above logs, SCE splits it into two .cab files, which I don't believe it does for the smaller updates. I know from my own experience and from other posts here (such as this one ) that there are issues with file signature verification of large files, but previously these seem to have only occurred on package creation. Creation of the package works fine, it's just the client install that's the issue.

    Thursday, February 24, 2011 9:34 PM

Answers

  • Hi Folks, the hotfix is now available.

    Please refer to KB Article at http://support.microsoft.com/kb/2607070

     

    Thanks much for the patience and again sincere apologies for any inconvenience this may have caused.

     


    Friday, September 02, 2011 6:58 PM
  • "Add the Stuff folder using the "Add Dir" button. (Click Next)."

    When you click the Tools/Create Update menu option, Add Dir is a button on the very first screen (right above "Add Files").

    That said, I don't think you need to do that anymore.  As my later comment noted, I believe the only files you need are the 3 .cab files.  So, a simplified set of instructions would be:

    1. Create a deployment folder (ie c:\WU).
    2. Extract the exe file using: WindowsUpdateAgent30-x86.exe -d
    3. When instructions on use appear, copy (only) the 3 cab files from the newly created folder at c:\ to c:\WU.
    4. Copy RunIt.exe (or RunIt64.exe) from http://sourceforge.net/projects/localupdatepubl/files/Binaries/ into c:\WU.
    5. Create a deployment package, using RunIt (or RunIt64) as the executable.
    6. Use Add Files to add the 3 cab files. (Click Next)
    7. Set the Impact to "Requires Exclusive Handling."
    8. Set the Reboot to "Always Requires Reboot."
    9. Set the command line arguments to: /L %windir%\system32\dism.exe /online /add-package /packagepath:. /norestart /quiet /logpath:"%windir%\temp\dism.log"
    10. Set the Return Code 3010 to be Success/Reboot.
    11. Set other fields as appropriate, but don't use "Microsoft" as the vendor. (Click Next).
    12. For the Installed rule, I use a File Version on WINDOWS \System32\wuapi.dll >= 7.6.7600.243
    13. For the Installable rule, I use Windows Version >= 6.1 SP 0.0 AND Architecture = x86

    Note that I still have no way to confirm (other than a response from MS) that just installing those 3 cab files will update everything that WuSetup does.  While it appears to work, use at your own risk.

    Wednesday, September 07, 2011 5:51 PM
    • Proposed as answer by sewellia Thursday, September 15, 2011 7:11 AM
    • Marked as answer by Crosfields School IT Thursday, September 15, 2011 7:20 AM
    Monday, September 12, 2011 2:06 PM
  • Hi sewellia,

    Mangesh has updated the blog with a new approach.

    This new approach will address the issues reported by you and you may not need a WMI script which helps create a dynamic group either.

    hope this helps.

    -Ganesh Majeti.


    • Edited by Ganesh Majeti Wednesday, September 14, 2011 5:03 PM
    • Proposed as answer by sewellia Thursday, September 15, 2011 7:10 AM
    • Marked as answer by Crosfields School IT Thursday, September 15, 2011 7:52 AM
    Wednesday, September 14, 2011 2:24 PM

All replies

  •  

    Hi,

     

    Thank you for your post.

     

    Please try again after stopping Windows Update Service, renaming the folder “C:\Windows\SoftwareDistribution” and restarting Windows Update Service.

     

    Regarding the error, please also try the methods in the following thread which is about a similar error:

     

    Error Deploying Office 2007

    http://social.technet.microsoft.com/Forums/en-US/systemcenterdevelopment/thread/41baa033-57c4-4355-90b2-9bab4f1b2d51

     

    Hope this helps.

     

    Thanks.

     

    Nicholas Li

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com.


    Nicholas Li - MSFT
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Friday, February 25, 2011 8:11 AM
    Moderator
  • Resetting the SoftwareDistribution folder as per your instructions had no effect. Regarding the thread you linked to, the recommendation there appeared to be to ensure the SCE server was running WSUS 3.0 SP2. This is already installed (version reports as 3.2.7600.226) as I am running my SCE 2010 install on Windows Server 2008 R2 SP1.
    Friday, February 25, 2011 9:12 AM
  • Hi,

    Can you confirm if the issue you are facing is exactly matching the below thread? There are few more facts discovered that I don't want to repeat here.

     

    http://www.edugeek.net/forums/windows/71480-system-center-essentials-sce-package-office-2010-not-installing-after-sp1.html


    KetanT | Microsoft
    Wednesday, March 02, 2011 2:40 PM
    Moderator
  • Yes, that's the exact same problem I'm seeing.
    Wednesday, March 02, 2011 5:50 PM
  • Hi,

    I am trying to reproduce this error. This may be WSUS side of the issue.

    Have you tried deploying package using WSUS?


    KetanT | Microsoft
    Sunday, March 06, 2011 7:57 AM
    Moderator
  • I thought all SCE packages were deployed using WSUS. Is there another way of doing it other than using the SCE console?

    Sunday, March 06, 2011 12:25 PM
  • more or less they are, sce converts application installs into cab files that wsus/windows update client can use.  
    Ok, so I changed my name...you can still call me Tom if you like. It's a...jump...to conclusions...mat.
    My Blog Site: http://tmagnuson.wordpress.com
    Monday, March 07, 2011 5:32 PM
  • I have got a local repro. I am doing some more testing and involve more folks and hopefully give you a heads up in a couple of days.

    Thanks.


    KetanT | Microsoft
    Wednesday, March 09, 2011 3:07 PM
    Moderator
  • Hi

    I'll need some more info around this.

    1. Application event log from working and non-working client machine (i.e. sp1 and non sp1)

    2. gpresult /v from working and non-working machine.

    3. windowsupdate.log from working and non-working machine.

    Let me know when  you are ready with the data and I'll share the SFTP workspace info where you can upload them. 

    Also, I'd like to confirm from you that small package works on both sp1 and non-sp1. Have you determined/identified size?

     


    KetanT | Microsoft
    Tuesday, March 15, 2011 9:44 AM
    Moderator
  • I'm currently rebuilding my test workstation with Windows 7 RTM to get the working logs, so should have all the data ready tomorrow morning.

    I can confirm that smaller packages work fine on RTM and SP1. I'm afraid I can't pin down the size at which it starts to fail. The next largest package I have is 173.5MB and that installs fine.

    Tuesday, March 15, 2011 4:26 PM
  • Great!

    Please send mail to blrforum-at-microsoft-dot-com to receive the workspace information.

    Thanks.


    KetanT | Microsoft
    Wednesday, March 16, 2011 6:01 AM
    Moderator
  • Requested files were uploaded Wed,16 Mar 2011 12:35:45

    Wednesday, March 16, 2011 12:37 PM
  • Thank you!

    I got the data. Let me get back once I am through that.


    KetanT | Microsoft
    Thursday, March 17, 2011 1:45 AM
    Moderator
  • Hi,

    It looks like the failures on the SP1 boxes are due to download and success on RTM machines are due to updates already downloaded: Take a look at the working and non-working logs comparision:

     

    ======================
    Non Working:
    ======================

     

    2011-03-15          15:41:13:434       1000       fb8         Agent      *   UpdateId = {6714EF24-FDD1-4D37-A913-5494BC4EE240}.2
    2011-03-15          15:41:13:436       1000       fb8         DnldMgr              ***********  DnldMgr: New download job [UpdateId = {6714EF24-FDD1-4D37-A913-5494BC4EE240}.2]  ***********
    2011-03-15          15:41:13:464       1000       fb8         DnldMgr                * BITS job initialized, JobId = {48E8B18F-D5FC-4875-8FEA-ED13C6C05C2C}
    2011-03-15          15:41:13:495       1000       fb8         DnldMgr                * Downloading from http://<domain Name>:8530/Content/D1/4CCA64C700B6519710E8DAF5F966F6AB2B941CD1.cab to C:\Windows\SoftwareDistribution\Download\e613dbced1d227f56710f53f192becee\4cca64c700b6519710e8daf5f966f6ab2b941cd1 (full file).
    2011-03-15          15:41:13:502       1000       fb8         DnldMgr                * Downloading from http://<Domain Name>:8530/Content/14/1140B8A6902309C4D2F4354F1167809A6D0E3814.cab to C:\Windows\SoftwareDistribution\Download\e613dbced1d227f56710f53f192becee\1140b8a6902309c4d2f4354f1167809a6d0e3814 (full file).
    2011-03-15          15:41:13:524       1000       fb8         Agent    *********
    2011-03-15          15:41:13:524       1000       fb8         Agent    **  END  **  Agent: Downloading updates [CallerId = AutomaticUpdates]
    2011-03-15          15:41:13:525       1000       fb8         Agent    *************
    2011-03-15          15:41:13:526       1000       9b4         AU          Successfully wrote event for AU health state:0
    2011-03-15          15:41:13:526       1000       9b4         AU            # Pending download calls = 1
    ..

    ..

    ..

    ..

    2011-03-15          15:41:59:718       1000       d8c         DnldMgr              WARNING: File failed postprocessing, error = 80070570
    2011-03-15          15:41:59:719       1000       d8c         DnldMgr              Failed file: URL = 'http://<Domain Name>:8530/Content/14/1140B8A6902309C4D2F4354F1167809A6D0E3814.cab', Local path = 'C:\Windows\SoftwareDistribution\Download\e613dbced1d227f56710f53f192becee\1140b8a6902309c4d2f4354f1167809a6d0e3814'
    2011-03-15          15:41:59:722       1000       d8c         DnldMgr              Error 0x80070570 occurred while downloading update; notifying dependent calls.
    2011-03-15          15:41:59:763       1000       9b4         AU          >>##  RESUMED  ## AU: Download update [UpdateId = {6714EF24-FDD1-4D37-A913-5494BC4EE240}]
    2011-03-15          15:41:59:763       1000       9b4         AU            # WARNING: Download failed, error = 0x80070570

     


    ======================
    Working Log:
    ======================

    2011-03-16          11:51:40:894       964        d2c         Agent    ** START **  Agent: Installing updates [CallerId = AutomaticUpdates]
    2011-03-16          11:51:40:894       964        d2c         Agent    *********
    2011-03-16          11:51:40:894       964        d2c         Agent      * Updates to install = 1
    2011-03-16          11:51:40:896       964        f74          AU          Getting featured update notifications.  fIncludeDismissed = true
    2011-03-16          11:51:40:897       964        f74          AU          No featured updates available.
    2011-03-16          11:51:40:900       964        d2c         Agent      *   Title = Microsoft Office Professional Plus 2010
    2011-03-16          11:51:40:901       964        d2c         Agent      *   UpdateId = {6714EF24-FDD1-4D37-A913-5494BC4EE240}.2
    2011-03-16          11:51:40:911       964        f74          AU          All updates already downloaded, setting percent complete to 100

    2011-03-16          12:03:07:440       964        54c         AU          All updates already downloaded, setting percent complete to 100
    2011-03-16          12:03:08:532       2428       ee8        Handler                  : Command line install completed. Return code = 0x00000000, Result = Succeeded, Reboot required = false
    2011-03-16          12:03:08:501       964        514         AU          All updates already downloaded, setting percent complete to 100


    ..

    ..

    ..

    2011-03-16          12:03:14:351       964        8f4          Report  REPORT EVENT: {2283B83A-11E8-4398-9D59-F1BE6B5509BA}                2011-03-16 12:03:08:735-0000     1              183         101         {6714EF24-FDD1-4D37-A913-5494BC4EE240}        2              0                AutomaticUpdates         Success                Content Install  Installation Successful: Windows successfully installed the following update: Microsoft Office Professional Plus 2010

     

     

    I am still doing some more tests on my labs around this issue. Did you build new machines that you were doing? I'd like to hear the result of Package deployment on RTM and SP1 boxes when they both don't have it downloaded.

     

     


    KetanT | Microsoft
    Monday, March 21, 2011 11:33 AM
    Moderator
  • The RTM test data I provided was a machine that had just been rebuilt. The SP1 machine was a machine on which I had tried the install several times during testing, but it failed from the very first try after a rebuild from a slipstreamed ISO, as did two other machines. If you really need it I can rebuild the SP1 machine again and try to get a result with a fresh download?
    Monday, March 21, 2011 2:34 PM
  • I can back up Crosfields claim. The errors happen on completely fresh installations of Windows 7 SP1 and Windows 7 RTM upgraded to SP1 with no other changes. The *first* download of the software as well as any subsequent downloads always fail. From what I've seen I suspect the winverifytrust subsystem, I'm curious if the developers that manage that code have any insights.
    Monday, March 21, 2011 6:45 PM
  • have you guys tried registering the windows update components?

    regsvr32 c:\windows\system32\

    wuapi.dll

    wuaueng.dll

    atl.dll

    wucltui.dell

    wups.dll

    try this on a NON Production machine that's not working to see if you encounter the same problem.  Post the update log after these dll's are re-registered and a installation is attempted


    Tim Magnuson | Microsoft Community Contributor Award 2011 |
    Ok, so I changed my name...you can still call me Tom if you like. It's a...jump...to conclusions...mat.
    My Blog Site: http://tmagnuson.wordpress.com
    Monday, March 21, 2011 8:18 PM
  • No luck for me when re-registrering the dll's on a fresh install with sp1. Still the same errors (nothing changed) as Crosfields.

     


    Tuesday, March 22, 2011 1:28 PM
  • can you post the update log from the installation attempt after the dll's were re-registered?
    Tim Magnuson | Microsoft Community Contributor Award 2011 |
    Ok, so I changed my name...you can still call me Tom if you like. It's a...jump...to conclusions...mat.
    My Blog Site: http://tmagnuson.wordpress.com
    Tuesday, March 22, 2011 3:18 PM
  • 2011-03-22        14:22:16:648     888      398       AU       #############

    2011-03-22        14:22:16:648     888      398       AU       ## START ##  AU: Download updates

    2011-03-22        14:22:16:648     888      398       AU       #########

    2011-03-22        14:22:16:648     888      398       AU         # Approved updates = 1

    2011-03-22        14:22:16:648     888      398       AU       AU initiated download, updateId = {33222FB6-6431-4E03-9999-49F7B2AF4993}.1, callId = {8E3382AD-05BF-4DF3-859A-D2A99ED2E8EF}

    2011-03-22        14:22:16:648     888      398       AU       Successfully wrote event for AU health state:0

    2011-03-22        14:22:16:664     888      398       AU       Currently showing Progress UX client - so not launching any other client

    2011-03-22        14:22:16:664     888      398       AU       Successfully wrote event for AU health state:0

    2011-03-22        14:22:16:664     888      398       AU         # Pending download calls = 1

    2011-03-22        14:22:16:664     888      398       AU       <<## SUBMITTED ## AU: Download updates

    2011-03-22        14:22:16:679     888      680       AU       Getting featured update notifications.  fIncludeDismissed = true

    2011-03-22        14:22:16:679     888      680       AU       No featured updates available.

    2011-03-22        14:22:18:020     888      de4      Inv        #########

    2011-03-22        14:22:18:020     888      de4      Inv        ##  END  ##  Inv: Inventory Collection

    2011-03-22        14:22:18:020     888      de4      Inv        #############

    2011-03-22        14:22:18:020     888      de4      DnldMgr           *************

    2011-03-22        14:22:18:020     888      de4      DnldMgr           ** START **  DnldMgr: Downloading updates [CallerId = AutomaticUpdatesWuApp]

    2011-03-22        14:22:18:020     888      de4      DnldMgr           *********

    2011-03-22        14:22:18:020     888      de4      DnldMgr             * Call ID = {8E3382AD-05BF-4DF3-859A-D2A99ED2E8EF}

    2011-03-22        14:22:18:020     888      de4      DnldMgr             * Priority = 3, Interactive = 1, Owner is system = 1, Explicit proxy = 0, Proxy session id = 1, ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}

    2011-03-22        14:22:18:020     888      de4      DnldMgr             * Updates to download = 1

    2011-03-22        14:22:18:020     888      de4      Agent     *   Title = Office 2010

    2011-03-22        14:22:18:020     888      de4      Agent     *   UpdateId = {33222FB6-6431-4E03-9999-49F7B2AF4993}.1

    2011-03-22        14:22:18:020     888      de4      DnldMgr           ***********  DnldMgr: New download job [UpdateId = {33222FB6-6431-4E03-9999-49F7B2AF4993}.1]  ***********

    2011-03-22        14:22:18:395     888      de4      DnldMgr             * BITS job initialized, JobId = {1ECB057B-B245-4EDE-95B4-A11FD2326D87}

    2011-03-22        14:22:18:488     888      de4      DnldMgr             * Downloading from http://sce2010.idgtest.nl:8530/Content/F4/DDF63F74109DEE3BE04CA0A045A505860BB41DF4.cab to C:\Windows\SoftwareDistribution\Download\ec3cab0df34e9f4a64814a32ab3225d3\ddf63f74109dee3be04ca0a045a505860bb41df4 (full file).

    2011-03-22        14:22:18:629     888      de4      DnldMgr             * Downloading from http://sce2010.idgtest.nl:8530/Content/82/C1F27DD24E4F195C78E25CD9EDA18C8C3C926182.cab to C:\Windows\SoftwareDistribution\Download\ec3cab0df34e9f4a64814a32ab3225d3\c1f27dd24e4f195c78e25cd9eda18c8c3c926182 (full file).

    2011-03-22        14:22:18:816     888      de4      Agent   *********

    2011-03-22        14:22:18:816     888      de4      Agent   **  END  **  Agent: Downloading updates [CallerId = AutomaticUpdatesWuApp]

    2011-03-22        14:22:18:816     888      de4      Agent   *************

    2011-03-22        14:22:20:017     888      de4      Report  REPORT EVENT: {3F68013C-B223-4C6E-BA43-6D35F9AF4531}            2011-03-22 14:22:15:010+0100  1          147       101       {00000000-0000-0000-0000-000000000000}         0          0            AutomaticUpdates        Success           Software Synchronization         Windows Update Client successfully detected 1 updates.

    2011-03-22        14:22:20:017     888      de4      Report  REPORT EVENT: {F898841C-FD6F-4F28-B875-BBFEF6039C64}            2011-03-22 14:22:15:010+0100  1          156       101       {00000000-0000-0000-0000-000000000000}         0          0            AutomaticUpdates        Success           Pre-Deployment Check Reporting client status.

    2011-03-22        14:22:20:017     888      de4      Report  REPORT EVENT: {F2738741-206C-420E-B935-B158A1113D8B} 2011-03-22 14:22:18:020+0100          1          126       104       {00000000-0000-0000-0000-000000000000}         0          0            InventoryEngine            Success           Inventory processing    Inventory: Successfully collected the inventory data

    2011-03-22        14:22:20:017     888      de4      Report  CWERReporter finishing event handling. (00000000)

    2011-03-22        14:22:36:408     888      268       DnldMgr           BITS job {1ECB057B-B245-4EDE-95B4-A11FD2326D87} completed successfully

    2011-03-22        14:22:40:899     888      268       Misc     Validating signature for C:\Windows\SoftwareDistribution\Download\ec3cab0df34e9f4a64814a32ab3225d3\ddf63f74109dee3be04ca0a045a505860bb41df4:

    2011-03-22        14:22:40:899     888      268       Misc     WARNING: Digital Signatures on file C:\Windows\SoftwareDistribution\Download\ec3cab0df34e9f4a64814a32ab3225d3\ddf63f74109dee3be04ca0a045a505860bb41df4 are not trusted: Error 0x80070570

    2011-03-22        14:22:41:024     888      268       DnldMgr           WARNING: File failed postprocessing, error = 80070570

    2011-03-22        14:22:41:024     888      268       DnldMgr           Failed file: URL = 'http://sce2010.idgtest.nl:8530/Content/F4/DDF63F74109DEE3BE04CA0A045A505860BB41DF4.cab', Local path = 'C:\Windows\SoftwareDistribution\Download\ec3cab0df34e9f4a64814a32ab3225d3\ddf63f74109dee3be04ca0a045a505860bb41df4'

    2011-03-22        14:22:43:114     888      268       Misc     Validating signature for C:\Windows\SoftwareDistribution\Download\ec3cab0df34e9f4a64814a32ab3225d3\c1f27dd24e4f195c78e25cd9eda18c8c3c926182:

    2011-03-22        14:22:43:114     888      268       Misc     WARNING: Digital Signatures on file C:\Windows\SoftwareDistribution\Download\ec3cab0df34e9f4a64814a32ab3225d3\c1f27dd24e4f195c78e25cd9eda18c8c3c926182 are not trusted: Error 0x80070570

    2011-03-22        14:22:43:192     888      268       DnldMgr           WARNING: File failed postprocessing, error = 80070570

    2011-03-22        14:22:43:192     888      268       DnldMgr           Failed file: URL = 'http://sce2010.idgtest.nl:8530/Content/82/C1F27DD24E4F195C78E25CD9EDA18C8C3C926182.cab', Local path = 'C:\Windows\SoftwareDistribution\Download\ec3cab0df34e9f4a64814a32ab3225d3\c1f27dd24e4f195c78e25cd9eda18c8c3c926182'

    2011-03-22        14:22:43:192     888      268       DnldMgr           Error 0x80070570 occurred while downloading update; notifying dependent calls.

    2011-03-22        14:22:43:207     888      df0       AU       >>##  RESUMED  ## AU: Download update [UpdateId = {33222FB6-6431-4E03-9999-49F7B2AF4993}]

    2011-03-22        14:22:43:207     888      df0       AU         # WARNING: Download failed, error = 0x80070570

    2011-03-22        14:22:43:207     888      df0       AU       #########

    2011-03-22        14:22:43:207     888      df0       AU       ##  END  ##  AU: Download updates

    2011-03-22        14:22:43:207     888      df0       AU       #############

     

    Tuesday, March 22, 2011 4:06 PM
  • Hi all!

    Have the exact same problem. Any news?

    Regards

    Niklas


    Niklas Silvergrund
    Thursday, March 24, 2011 1:47 PM
  • the problem looks similar to a previous problem with server OS's.  I wonder if this is along the same lines....  http://support.microsoft.com/kb/938759 

    Edit:  It may be related, but as far as i can tell, the update log would clearly indicate a WinVerifyTrust error if it had one....I'll keep racking my brain.


    Tim Magnuson | Microsoft Community Contributor Award 2011 |
    Ok, so I changed my name...you can still call me Tom if you like. It's a...jump...to conclusions...mat.
    My Blog Site: http://tmagnuson.wordpress.com
    Thursday, March 24, 2011 4:01 PM
  • SSE is installed on a brand new virtual machine with 2008 R2 SP1. Wsus is 3.0

    Regards

    Niklas

     


    Niklas Silvergrund
    Friday, March 25, 2011 10:01 AM
  • Would be nice to get this fixed soon. This problem is older than a month now...
    Monday, March 28, 2011 9:57 AM
  • Hi all,

     

    Thank you for the patience. We are still going to through testing.


    KetanT | Microsoft
    Monday, March 28, 2011 10:26 AM
    Moderator
  • Add another to this thread. Fresh install of SCE 2010 on Server 2008 R2. Failed deployment of Office 2010 to Win7 SP1 machines. I can provide logs if needed.
    Monday, March 28, 2011 1:29 PM
  • Hi..

    Did a try with Project 2010 as well. Didn't work either.


    Niklas Silvergrund
    Monday, March 28, 2011 1:59 PM
  • KetanTjust to throw a variable in the mix, I use MDT to deploy all of our client images.  Office 2010 was installed and captured with my reference image, and I tested it before capturing so I could verify it was working.  However, when I deploy that captured image to my production machines, I have to run a repair on Office because there is no mail icon in the control panel so it thinks Outlook isn't installed.  This could be a problem with my image (even though it was set up identically to my other production image pre-SP1, which worked fine), but this behavior didn't start until I had the image with SP1 included.  Maybe it's coincidental, but it could be related.  Just throwing in some ideas.

    Tim


    Tim Magnuson | Microsoft Community Contributor Award 2011 |
    Ok, so I changed my name...you can still call me Tom if you like. It's a...jump...to conclusions...mat.
    My Blog Site: http://tmagnuson.wordpress.com
    Monday, March 28, 2011 2:08 PM
  • Thank you for the patience. We are still going to through testing.

    Hi Ketan, could you reproduce the behavior?

    Are there any news about the progress of getting this fixed or a quickfix as workaround?

    Thanks in advance.

    Friday, April 01, 2011 12:25 PM
  • Similar problems here. Office 2010 deployment working just fine on W7 machines, but fails if SP1 has been installed. Any ETA for a fix please ?

    Thanks

     

    Friday, April 01, 2011 2:41 PM
  • <Crickets chirping>
    Wednesday, April 06, 2011 12:49 PM
  • Agreed. This really needs a resolution. As it is we're holding off on our SP1 upgrades and Vista to 7 migrations on all systems until this bug is fixed. I'm surprised that we haven't heard from anyone on the WinVerifyTrust team. If I were Microsoft internal that's the first place I'd go to try to find out why .cab files are failing to verify.
    Wednesday, April 06, 2011 5:19 PM
  • Hello All,

    I need to some repro data from you as it seems there are lot of people hitting the same issue. Please use the following upload information and collect Applicatoin/System/OpsMgr event logs from Server and client and Windowsupdate.log file from the client.

    Please make 2 sets of data(compressed), 1 with repro(SP1 scenario) and 1 working(SP0 scenario). Please name them unique so that it doesn't fail due to file existing (i.e. if you name it logs.zip its likely to hit duplication). You may add the time stamp in the name.

     

    URL; https://sftus.one.microsoft.com/choosetransfer.aspx?key=232b6a06-8ca8-47c2-8638-fe66f1609c32

    Access: %gnC-E@0LZajc

    Please do this within the week of 11th April.

    Thanks.


    Ketan Thakkar | Microsoft Online Community Support
    Sunday, April 10, 2011 8:44 AM
    Moderator
  • I have uploaded the requested logs. I eagerly await your reply.
    Monday, April 11, 2011 4:15 PM
  • The requested logs have been provided. When do you anticipate a fix or workaround for this issue?
    Friday, April 15, 2011 7:35 PM
  • Hello all,

    This is being addresed by specific groups looking after the product components involved into this. I'll post an update once I have the same from them or they will update this thread directly.


    Ketan Thakkar | Microsoft Online Community Support
    Saturday, April 16, 2011 5:44 AM
    Moderator
  • Add one more to the list of anxiously awaiting a fix!  I've got about 400 PCs with Windows 7 SP1 and haven't been able to deploy Office 2010 to any of them.  Really don't want to do it manually.
    Monday, April 18, 2011 6:10 PM
  • I'm having the exact same problem.  The only difference in my scenario is that I'm trying to deploy Acrobat 10 Professional as an upgrade using the MSI along with a transforms file.  All the XP and Win7 boxes are taking the update, except for the Win7 SP1 boxes.  The package is about 470MB.  I'm anxiously waiting for the Microsoft crew to respond with their findings as well.  I will be glad to upload my WSUS logs, etc..

    CLJ.

    Thursday, April 21, 2011 1:38 AM
  • I'm having the exact same problem.  The only difference in my scenario is that I'm trying to deploy Acrobat 10 Professional as an upgrade using the MSI along with a transforms file.  All the XP and Win7 boxes are taking the update, except for the Win7 SP1 boxes.  The package is about 470MB.  I'm anxiously waiting for the Microsoft crew to respond with their findings as well.  I will be glad to upload my WSUS logs, etc..

    CLJ.


    then it's not the same problem.  Acrobat installs fine on sp1.

    Tim Magnuson | Microsoft Community Contributor Award 2011 |
    Ok, so I changed my name...you can still call me Tom if you like. It's a...jump...to conclusions...mat.
    My Blog Site: http://tmagnuson.wordpress.com
    Thursday, April 21, 2011 12:46 PM
  • I've run into this as well.  Looking forward to a fix.
    Thursday, April 21, 2011 3:46 PM
  • I'm curious what you mean by "installs fine on SP1". I'm one of several who've run into the identical problem, attempting to deploy Adobe Acrobat X works perfectly right up until you have SP1 on Windows 7, then it fails with a WinVerifyTrust issue, the same issue folks in this thread are having with Microsoft Office. Why does WinVerifyTrust fail to verify signed packages over a certain size? We've been waiting about seven weeks for this answer and look forward to a fix. Until this is fixed SP1 for Windows 7 is a non-starter.
    Thursday, April 21, 2011 4:50 PM
  • I mean it installs fine on SP1 because I've deployed it to SP1 machines.
    Tim Magnuson | Microsoft Community Contributor Award 2011 |
    Ok, so I changed my name...you can still call me Tom if you like. It's a...jump...to conclusions...mat.
    My Blog Site: http://tmagnuson.wordpress.com
    Thursday, April 21, 2011 5:20 PM
  • This problem really has nothing to do with what package you are trying to deploy and all to do with the size. Every package I've tried that is more than a few hundred MB will fail, regardless of what program it is. I even created test packages of programs that otherwise install fine but where I added a 500MB file of random dummy data, and they immediately failed.

    Some versions of Acrobat are larger than others (Standard vs Pro, for example), and of course Acrobat Reader is tiny by comparison so won't have any problems. It wouldn't surprise me in the least if some packages of Acrobat fail while others do not. But if they fail with error code 0x80070570 and the package is a big one, it is almost certainly the same problem.

    Thursday, April 21, 2011 5:27 PM
  • Hi Tim, If you don't mind me asking, what deployment system are you using, what flavor of Acrobat X are you deploying, and how big is the biggest .cab file involved? Thanks.
    Thursday, April 21, 2011 5:42 PM
  • for OS deployments I'm using MDT2010.  But for pushing installs after the fact I use SCE2010.  Acrobat X Pro and Standard.  cab file size I'll have to check.
    Tim Magnuson | Microsoft Community Contributor Award 2011 |
    Ok, so I changed my name...you can still call me Tom if you like. It's a...jump...to conclusions...mat.
    My Blog Site: http://tmagnuson.wordpress.com
    Thursday, April 21, 2011 5:45 PM
  • actobat x pro's cab file is 458mb.
    Tim Magnuson | Microsoft Community Contributor Award 2011 |
    Ok, so I changed my name...you can still call me Tom if you like. It's a...jump...to conclusions...mat.
    My Blog Site: http://tmagnuson.wordpress.com
    Thursday, April 21, 2011 7:31 PM
  • I wonder if client performance has anything to do with it?

    I bring this up because I seem to remember a package signing issue with SCE2007 where the advice was that machines with fewer resources would be more susceptible. Perhaps different clients will fall at different package sizes depending on their performance?

    Thursday, April 21, 2011 11:29 PM
  • a definite possibility.  I work for a company that does mine planning and engineering using a lot of software that requires a pretty capable machine to run correctly.  Our standard desktop has 8gb of ram, a core i7 cpu and one or more ssd's.  If I have deployment issues, it's because of a parameter I don't have set correctly.  On a few occasions clients have problems, but more or less it's the config of the package itself.
    Tim Magnuson | Microsoft Community Contributor Award 2011 |
    Ok, so I changed my name...you can still call me Tom if you like. It's a...jump...to conclusions...mat.
    My Blog Site: http://tmagnuson.wordpress.com
    Friday, April 22, 2011 3:29 AM
  • Guys, so Acrobat is about 485mb.  When we deploy the package using our third party plug-in to WSUS called EminentWare we see that it builds two .CAB files to store the deployment package in.  We are thinking that Win7 SP1 trusts the signature on one of the .CAB files but not the other.  Does this sound like a possibility ?   Acrobat 10 Professional has no problem installing manually via Wizard or silent install on SP1. 

     

    Friday, April 22, 2011 1:56 PM
  • For what it's worth my test machines were hardware (Dell Latitude E6410s with 4 GB RAM) and Hyper-V VMs with 2 GB RAM. Not ruling out resources as a possibility though.
    Friday, April 22, 2011 4:44 PM
  • Any update on this issue?
    Monday, April 25, 2011 6:56 PM
  • Ketan - Do you have any update for us? We are also having this problem; we are looking at rolling out Windows 7 SP1 and so far, we can't deploy two large packages (Acrobat and Office)

    Please keep us updated


    Thanks

    Wednesday, April 27, 2011 7:43 PM
  • Hello Community,

    I appreciate your followups and patience. I have forwarded this to the relevant groups. They will directly respond to the thread once they have something that can be shared.

    Thanks.


    Ketan Thakkar | Microsoft Online Community Support
    Thursday, April 28, 2011 2:46 PM
    Moderator
  • I don't know how much patience I can give. 

     

    Is there any information that they would find helpful from us to hurry this matter along? We got burned by the SP1/WSUS fiasco (error code c0000034) and now need to format and reinstall Windows 7 (SP1) on all of our workstations before they will receive windows updates - but we're waiting on this to be resolved.

     

    If there is anything else we can provide, please let us know.

     

    Sam

    Wednesday, May 04, 2011 6:49 PM
  • This is getting ridiculous.
    I don't even know if i need to laugh or to cry... 
    Wednesday, May 11, 2011 10:36 AM
  • This is getting ridiculous.
    I don't even know if i need to laugh or to cry... 

    I'd rather sue at this point. Microsoft is not delivering on advertised functionality in a very expensive and current product.
    Wednesday, May 11, 2011 12:51 PM
  • Is there an ETA for the fix?
    Kevin
    Monday, May 16, 2011 1:30 PM
  • Hi All,

    We'll soon update this thread with some concrete update related to the issue you all are facing. We have been going through lot of testing and considering various scenarios that reproduces the issue.

    Thanks for the patience.


    Ketan Thakkar | Microsoft Online Community Support
    Wednesday, May 18, 2011 5:43 AM
    Moderator
  • Hi,

    While creating the package of Office2010 x86 (single exe file), did any of you hit below error?

    System.InvalidOperationException: Verification of file signature failed for file: \\SCE1010\UpdateServicesPackages\4eab1ac1-8adb-4fbb-af08-176deb287371\85096473-6032-4b7c-abe7-c060d8d983e5_2.cab
       at Microsoft.UpdateServices.Internal.BaseApi.Publisher.VerifyAndPublishPackage()
       at Microsoft.UpdateServices.Internal.BaseApi.Publisher.PublishPackage(String sourcePath, String additionalSourcePath, String packageDirectoryName)
       at Microsoft.EnterpriseManagement.SCE.Internal.UI.NewUpdatePackageWizard.PreparingPackagePage.PreparePackageBackgroundWorkerDoWork(Object sender, DoWorkEventArgs e)

     

    Can you please confirm?


    Ketan Thakkar | Microsoft Online Community Support
    Thursday, May 19, 2011 8:06 AM
    Moderator
  • I've been having the original issue, but I did not receive the above error when I was creating test packages of Office 2010 x86. However, my deployment was not a "single exe file" but a collection of files and folders as per the normal install media layout of Office 2010.

    I did receive this error when I tried to package Windows 7 SP1 (Windows6.1-KB976932-x86.exe), before it was later published to WSUS. This file is a single .exe which is 537MB in size.

    Thursday, May 19, 2011 9:51 AM
  • Hello

    We have exactly the same problem on Windows 7 x64 SP1 and Office 2010 x86 deployment with SCE.

    Please Microsoft, give us a solution :-)

    Thanks and regards

    Reto


    Thursday, May 19, 2011 2:50 PM
  • I've been having the original issue, but I did not receive the above error when I was creating test packages of Office 2010 x86. However, my deployment was not a "single exe file" but a collection of files and folders as per the normal install media layout of Office 2010.
    For me it's the same, i also used the collection of files and folders.
    Friday, May 20, 2011 11:51 AM
  • Nope.
    Friday, May 20, 2011 12:46 PM
  • I also used the files & folders as they would be found on the source media, not a single .exe file.  No errors when building the package in SCE.
    Friday, May 20, 2011 1:46 PM
  • I did not receive that error for Office 2010, but I also used files & folders to create the package.  I will add that I wanted to make a package for Mathematica which is 852MB as a single .exe and I did get a "Verification of file signature failed for file" error.
    Friday, May 20, 2011 2:46 PM
  • Hello All,

    Please add me to the list of affected, harried, system administrators who are trying to deploy large packages to windows 7 SP1 machines. This just hit me today and a quick search found this thread quickly (thankfully). I'm deploying Office 2010 to Win7SP1 machines (we just upgraded to SP1 last week so the timing was rather bad).

    I also had the same issue with Mathematica 7 described above, and never found a resolution. I resorted to startup scripts to silently install the package, which was particularly annoying as I was able to deploy the Mathematica 7 Player which uses the exact same installer technology.

    MS, please address this issue, and update these case notes. I suspect the other admins here are also looking for alternate, stable, deployment solutions after waiting months for more than confirmation of the issue.

    -Jonathan King

    Friday, May 27, 2011 1:49 PM
  • Hello Microsoft

    Please, please give us a solution for this problem :-)

    Thanks!

    Regards
    Reto 

    Monday, May 30, 2011 9:48 AM
  • Hi All,

    We'll soon update this thread with some concrete update related to the issue you all are facing. We have been going through lot of testing and considering various scenarios that reproduces the issue.

    Thanks for the patience.


    Ketan Thakkar | Microsoft Online Community Support

     

    Soon = 2 weeks now...

    This SUCKS

    (pardon my french)

    Tuesday, May 31, 2011 8:15 AM
  • Do you have any intention of addressing this issue?
    Tuesday, May 31, 2011 1:04 PM
  • Hi Ketan

    I'm getting exactly the same error, when I try to create a SCE Package for Adobe Acrobat Pro X 10.0 (only the MSI and the Data1.cab file).

    When I try to create the SCE package with the "normal" installation file from Adobe (AcrobatPro_10_Web_WWEFD.exe), that contains the MSI and Data1.cab files, then it works, but at the installation of the package I get the error 80070570 like all the others.

    So I think that these two errors are related.

    Wednesday, June 01, 2011 8:31 AM
  • Would it help if one or more of us called in to Microsoft's support center and opened a ($275) ticket with them? Has anyone done so yet? The call should be free if the bug is shown to be on there end, and by now I think that's a foregone conclusion.

    No offense to Ketan but I don't think this issue is getting the attention it deserves within Microsoft. I find it hard to believe that after 70 posts on a very pressing enterprise topic that Ketan is the only Microsoft employee to even respond to this thread. There's something wrong here.

    On a related note: we've been suffering with the printing subsystem in Windows 2008 and Vista for years now and Windows 7 SP1 supposedly offers some relief to the problems. We're dying over here with printing issues but we can't try the solution because of this deployment bug. Just adding this to let it be known that deployment isn't the only area affected by this problem.

    Wednesday, June 01, 2011 11:07 PM
  • I've encountered this one myself in a clean environment and I'm shocked to see that it's now nearly 4 months since this pretty serious issue was reported. 
    Friday, June 03, 2011 10:19 AM
  • Hello again,

    I just re-imaged a few computers and realized that the SP1 update is happening before my Office 2007 install, so I am encountering the above error even on pre-existing, working scenarios (without SP1 upgrade). I thought it was only an issue for me in relation to an Office 2010 upgrade, but that is not the case. So now I have an error in my PRODUCTION system that appears to be a low priority for Microsoft. What is the appropriate mechanism to create a case, or have this escalated to the appropriate technical support group?

    -jonathan


    -- Jonathan King
    Friday, June 03, 2011 3:21 PM
  • In the absence of any answers from Microsoft, there's another way we might figure out what the problem is:

     

    http://www.microsoft.com/downloads/en/details.aspx?FamilyID=61924cea-83fe-46e9-96d8-027ae59ddc11&displaylang=en

     

    That link goes to the documentation for Windows 7 / 2008 SP1. The last document is the list of hotfixes and security patches included in SP1. There are 970 listed. Downloading them would take time, since they'd surely require the email mechanism that goes along with downloading a hotfix from MS before it's blessed into a service pack.

     

    My thought is that there may be enough motivated individuals here to actually do the work; download roughly 100 patches each and try them out all at once, or preferably one at a time on a VM which has been snapshotted and rolled back each time. Discovering which patch or patches break the WinVerifyTrust subsystem should get us 90% of the way to a solution. Any interest in this idea? For some of us a little hard work is going to be better than sitting on our hands waiting for a hand-out that clearly isn't coming soon enough.

    Friday, June 03, 2011 5:12 PM
  • We can try doing them 1 by 1, however I'm 90% certain the update that effects this functionality is KB978601.  It directly refers to code execution and wintrust.dll.  SP1 users have no way of uninstalling it, I don't have any pre-sp1 machines here to look at.
    Tim Magnuson | Microsoft Community Contributor Award 2011 |
    Ok, so I changed my name...you can still call me Tom if you like. It's a...jump...to conclusions...mat.
    My Blog Site: http://tmagnuson.wordpress.com
    Friday, June 03, 2011 6:18 PM
  • Hi Tim, Just completed a relevant test:

     

    - Installed a fresh copy of Windows 7 (No service pack) on a VM

    - Joined to domain and patched all the way (Service pack 1 is not approved in WSUS)

    - Snapshotted VM

    - Installed Adobe Acrobat X through Windows Update (Local Update Publisher). This fails if SP1 is present. It succeeded as expected.

    - Rolled back to snapshot

    - Attempted to install patch KB978601, patch would not install, claiming it was already installed

     

    This leads me to believe that 978601 is not the culprit. I'm happy to try any other tests people want on my SP0 machine now that I have it.

    Sunday, June 05, 2011 7:43 PM
  • Ketan,

    We have customers that are experiencing the issue related to large CAB files.

    We have the same error code: 80070570

     

    Please confirm this is specific to Windows 7 SP1.

    I am assuming there will be a HF made available.

    Any updated information is much appreciated.

     

    Friday, June 10, 2011 12:28 AM
  • Hello, All,

    We are aware of this issue. We’ve  identified the root cause of the problem and are actively working on a fix. We will update this forum once the issue is resolved and apologize for any inconvenience this may have caused.

    Weijuan

    Tuesday, June 14, 2011 12:08 AM
  • Weijuan, thanks for the update.


    David
    Wednesday, June 15, 2011 11:53 PM
  • Thanks Weijuan for this positive news.

    But it's almost another week gone since your announcement, can you give us an ETA when this fix will be released, days, weeks, months?

    We need this information for planning purpose.

    Monday, June 20, 2011 7:39 AM
  • Hello Weijuan,

     

    We are also experiencing this issue. This is having a major impact on our Win7/Office 2007 deployment. Is there any update regarding the resolution timeframe?

     

    Best regards


    Chris Brunnmeier
    Monday, June 20, 2011 3:22 PM
  • If it's effecting a deployment, you could just include Office in the OS image.  Sysprep works fine with office applications.
    Tim Magnuson | Microsoft Community Contributor Award 2011 |
    Ok, so I changed my name...you can still call me Tom if you like. It's a...jump...to conclusions...mat.
    My Blog Site: http://tmagnuson.wordpress.com
    Monday, June 20, 2011 6:45 PM
  • Thanks Tim. While that would be an immediate solution (and one that I'll have to use for now), I have more than 50 PC's deployed with Office 2003 Pro. I invested in a Microsoft solution that presumably removes the manual process of deployment. With that said, I should be able to rely on the product that Microsoft markets as a mechanism for deploying Microsoft Office products. I (and many others) have wasted a tremendous amount of time trying to work through this issue. I hope that Microsoft stays engaged and provides a solution soon.

     


    Chris
    Monday, June 20, 2011 7:05 PM
  • No problem, I was trying to at least provide an alternative for pc's who are waiting deployment due to a fix for this issue. 
    Tim Magnuson | Microsoft Community Contributor Award 2011 |
    Ok, so I changed my name...you can still call me Tom if you like. It's a...jump...to conclusions...mat.
    My Blog Site: http://tmagnuson.wordpress.com
    Monday, June 20, 2011 7:13 PM
  • I'm also seeing this problem with deploying office 2010 using SCE2010.  I have found that using WUInstall to force deployment shows this error, but if I leave the workstation for 24 hours windows update will install office 2010 ok.   I have not applied sp1 to my image, I'm sure that this wasn't seeing this issue when I tested I few months back.  I'm currently removing all updates from my SCE/WSUS server and will try and deploy just office 2010 on to a non patched windows install.
    Wednesday, June 22, 2011 9:50 AM
  • Could we hear some details about the "root cause" of this problem? How many people are working on solving this?

     

    It's been over four months since this issue surfaced. It's been two weeks since the last official post, which like the others contains no real information. We pay a great deal for your software. It's time to produce a patch or a really good reason why there isn't one.

     

     

    Monday, June 27, 2011 9:23 PM
  • The problem seems te be the installed Windows Updates. I've installed a Windows 7 Pro x64 without Service Pack 1 and no updates and deployed a software package to the machine. The software package installed without any problem. The same software package does not install on Windows 7 with SP1. The error code is 80070570.
    Tuesday, June 28, 2011 10:07 AM
  • Right, maybe I should have been more specific. We're all here because SP1 breaks our software deployments that have large CAB files. What I want to know is what Microsoft knows. Do they know which hotfix inside the service pack breaks it yet, or if it's a specific hotfix that does it? We've got nothing but stonewalling from their camp and never heard from any technical expert on the issue. All we get is, "we're working on a fix", which is no longer convincing.
    Tuesday, June 28, 2011 4:24 PM
  • Hi,

    Given the lengthy delay in resolution of this issue, I need to look at alternate deployment solutions for Office 2010 and Mathematica 8.  If I use a startup script to install both of these apps and then later this issue is resolved, will Office try to re-install itself or will it detect the pre-existing install? I know with Office 2007 that this was a real problem, and I had to do lots of manual cleanup to get SCE to install Office2007 after manually installing it on some machines.

    I'm on a deadline (past it actually) and really need to get this deployed NEXT WEEK!

    Thanks for the advice,

    -jonathan

     


    -- Jonathan King
    Wednesday, June 29, 2011 3:21 AM
  • If I use a startup script to install both of these apps and then later this issue is resolved, will Office try to re-install itself or will it detect the pre-existing install?

    It will try to reinstall itself. SCE is not able to detect whether a .exe installer is already installed; it only knows whether it has already run the installer once itself.

    For the same reason, if you uninstall such a program using the Control Panel, SCE will not try to reinstall it, because as far as its concerned, it has done it once already so doesn't need to do it again.

    A workaround in this instance would be to use a third-party tool to tweak the WSUS detection rules on the package you have created. One such tool is Local Update Publisher, which I have used in non-SCE scenarios and works quite well, but there is a slight learning curve compared to SCE. Be aware that if you plan to tinker with the existing SCE-published package, a) this is definitely not supported by MS, and b) you will need to download the SVN version of Local Update Publisher as the currently released version only lets you see packages deployed using LUP.

    Wednesday, June 29, 2011 8:17 AM
  • I guess today's release of SP1 for Office explains the complete and utter lack of any assistance or information from Microsoft on this issue.

    Wednesday, June 29, 2011 3:05 PM
  • Since reporting the issue in February(!) I have tried to stand back as much as I can except to provide further information when requested. I had hoped by now it would speak for itself that this thread is now the most replied-to thread in 4 years in any of the System Center Essentials forums. Apparently not.

    We know that Microsoft have identified the problem. We know they are working on a fix. What we don't know is when we can expect that fix, and we have no confirmed information of the cause or how to avoid it (if that is even possible) other than "don't install SP1".

    That this situation exists would be forgiveable in some circumstances, but the sheer length of time this has gone on for is unacceptable.

    Next month, the Schools Agreement under which I license SCE is up for renewal. Since Microsoft are clearly unable or unwilling to answer questions about the problem itself, perhaps they could answer this: can anyone from Microsoft give me just one good reason why I should renew my SCE licence, when one of the core features does not work as advertised on the latest version of Windows?

    Monday, July 04, 2011 1:20 PM
  • I'm having the same problem, has there been a fix for this yet? We are running SCE 2007 and my Windows 7 SP1 machine is not updating.

    Thursday, July 07, 2011 4:37 PM
  • Add me to the list of affected customers.
    Friday, July 08, 2011 3:36 PM
  • Count + 1 SCE 2010 customer: We are affected as well and stuck with our migration.
    Sunday, July 10, 2011 9:39 PM
  • Count +1 more SCE 2010 customer.  We're affected and waiting for a patch.
    Tuesday, July 12, 2011 9:19 AM
  • Count +1 more

    Tuesday, July 12, 2011 12:39 PM
  • Count +1
    Wednesday, July 13, 2011 6:20 AM
  • I hoped the „Microsoft-PatchDay“ today solve this problem, but after some tests and check the content of the patches no of its solve the problem.

    What is to-do? The problem is known since end of February; accept as issue by Microsoft at May. Now we have July (two Patch-Days of Microsoft later), but not solution.

    How long we have to wait until the issue is solved? At the moment we cannot use SCE 2010 to deploy software to clients using Windows7 SP1?!?

    A very frustrating situation!

    Sorry my bad English.


    Wednesday, July 13, 2011 9:27 AM
  • Another affected customer - for as much as it's worth (not very much, it seems).

    We are looking for a replacement for System Center, due in part to this. The Kace appliance from Dell is very appealing.

    http://www.kace.com/

    Wednesday, July 13, 2011 2:33 PM
  • Count +1 SCE 2010 Customer. Having issue with ERSI ArcGIS Desktop 10 and a custom Visual Studio 2010 SP1 package.
    Monday, July 18, 2011 2:25 PM
  • Hi Folks,

    A public release of this fix would be made available around August 31, 2011. Please do not treat this as precise official release date, but an announcement & release might move by a week on either side. Microsoft has already initiated public release process and started working on this fix. I apologize for the inconvenience that might have caused. I will update the thread in future with further updates.

    Thanks,

    Tuesday, July 26, 2011 10:17 AM
  • Hi Mangesh, thanks for the update, I'm sure everyone waiting for the fix is glad to hear that it's on the way. Do you know if it will be a hotfix or part of the standard patch Tuesday package? If it's a hotfix then I look forward to seeing the link posted in this thread. Thanks!
    Tuesday, July 26, 2011 3:39 PM
  • Just as an FYI, we're now receiving Dell laptops with 512e "Advance Format" hard drives [1][2] and it appears that it's poorly supported in Windows 7 pre-SP1. Now we can't deploy Windows 7 boxes without SP1, and we can't deploy them with SP1. August 31 has never looked so far away as it does right now. Here's hoping the patch is on track for a speedy release.

    [1] http://support.dell.com/support/topics/global.aspx/support/kcs/document?c=us&l=en&s=hied&docid=408172

    [2] http://en.wikipedia.org/wiki/Advanced_Format

    Friday, August 26, 2011 4:04 PM
  • If you're keen to slog through workarounds on non SP1 boxes look here:

     

    http://www.delltechcenter.com/page/Deploying+Dell+systems+with+Advanced+Format+Hard+Drives#fbid=pBbKA3JTaIf

     

    Friday, August 26, 2011 4:33 PM
  • Hi Thomas,
    We have concluded testing on this and now in the process of finishing release requirements.
    This will get posted as a KB on Microsoft download center only.
    I will update this thread with the link when it gets live shortly.
    Thanks!
     
    Monday, August 29, 2011 11:47 AM
  • The above update strongly suggests we will be looking at a .msu file to fix this, with no release onto WSUS or the Windows Update Catalog. Of course, SCE does not support direct deployment of .msu files.

    Those now bashing their heads on the desk in contemplation of rolling out an update manually or via script (which is exactly what we are all trying to avoid with this bug) should take a look at Distributing hotfixes with LUP. While the process and the RunIt tool described therein are designed for use with Local Update Publisher, it should work just fine with SCE. You will not be able to use the more advanced targeting rules that LUP offers, so make a note for yourself to check whether this update is included in a later service pack so you don't end up trying to install it twice.


    Monday, August 29, 2011 8:00 PM
  • FFS  Hasn't someone at MS made the massive leap of logic that this fix is to fix an issue with SCE deploying to Win7SP1 so doing a fix that CAN'T be rolled out via SCE is little bit dumb.
    Thursday, September 01, 2011 3:03 PM
  • Any news on when this will be released?

    Thanks

    Thursday, September 01, 2011 7:13 PM
  • Hi Folks, the hotfix is now available.

    Please refer to KB Article at http://support.microsoft.com/kb/2607070

     

    Thanks much for the patience and again sincere apologies for any inconvenience this may have caused.

     


    Friday, September 02, 2011 6:58 PM
  • Thanks, fantastic! These are exe files. Any switches for silent installation? 

     

    Friday, September 02, 2011 7:30 PM
  • According to WindowsUpdateAgent30-x86 /?

    WUSETUP [/quiet [/norestart] [/norestartforapi]] [/uninstall]
    
    /quiet
    Quiet mode (no user interaction)
    
    /norestart
    Do not restart when installation is complete (used only with /quiet)
    
    /norestartforapi
    Ignore reboot required for API binaries (used only with /quiet)
    
    /uninstall
    Remove this version of the Windows Update Agent


    Friday, September 02, 2011 8:47 PM
  • Thanks Crosfield, I allready found out. 

     

    Extract the exe file using Run: WindowsUpdateAgent30-x86.exe -d

    When instructions on use appear, copy the newly created folder 

    Create a deployment package using this folder and select package setup file wusetup.exe  

    Deploy using installation  parameters:  /quiet /norestart

    Friday, September 02, 2011 9:01 PM
  • Thanks, I'll test it out in our environment ASAP.
    Friday, September 02, 2011 10:35 PM
  • OK, some observations from a few tests so far:

    • It does fix the problem (phew!)
    • Extracting the files seems to be optional. I deployed a package that simply called WindowsUpdateAgent30-x86.exe with /quiet /norestart and it behaved exactly the same way as extracting the package and calling wusetup.exe
    • Installing it with /norestart stops the machine from restarting at the end of the install (unsurprisingly), but the Windows Update service itself gets restarted, and following that the Windows Update history reports the update status as Canceled instead of Success, presumably because the Windows Update service was restarted before it could report a Success. In addition, I checked the version number of wuapi.dll and it doesn't actually get updated to the new version until a reboot is completed, so I think the reboot is necessary. I'm going to test deploying it without the /norestart option and see if that causes any problems.
    Friday, September 02, 2011 11:21 PM
  • Well.

    Installing without /norestart still doesn't trigger a restart.

    I think this is because Windows Update suppresses the restart operation, intending to do it at the end of the update batch, but because the Windows Update service gets restarted (and the update gets reported as Canceled, as above), it loses track and so never restarts the workstation.

    So, we are left with a pending reboot, and until this is done the Windows Update Agent is not yet ready to process large updates without them failing. I don't think we can even rely on another update triggering a restart the next time updates are run, because the agent update will be re-detected (since it was marked as Canceled last time), run again, and restart the Windows Update service again, causing it to lose track of any pending reboots...

    Has anyone else got this far in testing and seeing the same, or is it just me?

    Saturday, September 03, 2011 1:25 PM
  • Well.

    Installing without /norestart still doesn't trigger a restart.

    I think this is because Windows Update suppresses the restart operation, intending to do it at the end of the update batch, but because the Windows Update service gets restarted (and the update gets reported as Canceled, as above), it loses track and so never restarts the workstation.

    So, we are left with a pending reboot, and until this is done the Windows Update Agent is not yet ready to process large updates without them failing. I don't think we can even rely on another update triggering a restart the next time updates are run, because the agent update will be re-detected (since it was marked as Canceled last time), run again, and restart the Windows Update service again, causing it to lose track of any pending reboots...

    Has anyone else got this far in testing and seeing the same, or is it just me?


    I have detect the same behavior as you. It doesn't seems do be possible to deploy the update using SCE!!! The WU-Service restarts before the update is installed successful. Grrr.

    A little bit strange. We cannot use SCE to deploy large cab's when Win7 SP1 is installed and we cannot automate deploy the necessary update to solve the issue. Manual run the update on each client cannot be the solution!

    The only possible way seems to use a logonscript (by GPO)  that install the update (Software deployment by GPO isn't possible, because no MSI exists).

    The first who have write the script please publish it on this thread. The script should check if the update already installed.

    Many thanks.

    Saturday, September 03, 2011 4:09 PM
  • I have found a possible solution to deploy the necessary update.
    Quick and dirty, but it seems to work.

    My solution:
    Create a GPO and add a startup powershell-script to the computer section.


    Powershell-script like this:

    $ComputerName = get-content env:computername
    if(test-path "...UNC-PATH TO KB...\KB2607070\$ComputerName.txt"){exit}
    if(test-path "C:\Program Files (x86)") {...UNC-PATH TO KB...\KB2607070\WindowsUpdateAgent30-x64.exe /quiet /norestart} else {...UNC-PATH TO KB...\KB2607070\WindowsUpdateAgent30-x86.exe /quiet /norestart}
    New-Item "...UNC-PATH TO KB...\KB2607070\$ComputerName.txt" -type file

    If someone have a better solution please let me now your solution.

    Sunday, September 04, 2011 7:59 AM
  • How do we update the 'SelfUpdate' directories on the WSUS server (in our case it's the SCE server also) so that clients can self-update automatically?
    Monday, September 05, 2011 3:06 AM
  • How do we update the 'SelfUpdate' directories on the WSUS server (in our case it's the SCE server also) so that clients can self-update automatically?
    not sure, but I think it's not possible (necessary?) to do that.

    when I check the version of the wuauclt.exe in the "SelfUpdate" folder I found 7.4.7600.226. When I check the version on a Win7 client I found 7.6.7600.243. Analyze the "WindowsUpdate.log" I can see, that the update-service check the version each time to the "SelfUpdate" folder on the server and don't made any changes.
    Monday, September 05, 2011 8:29 AM
  • My solution involves using DISM.

    The good news is that it is fully automatable thru LUP (so presumably thru SCE as well), handling reboot events as expected.  wuapi.dll gets updated to the new version upon reboot.

    The bad news is that since I'm not using WUSetup.exe (or WindowsUpdateAgent30-x86.exe), I'm not sure how confident I feel about the install.  I can't immediately think of a way to tell if my approach is updating everything WUSetup does.

    Is there a way to get WUSetup to write log files?

    Monday, September 05, 2011 9:17 AM
  • I have found a possible solution to deploy the necessary update.
    Quick and dirty, but it seems to work.

    My solution:
    Create a GPO and add a startup powershell-script to the computer section.


    Powershell-script like this:

    $ComputerName = get-content env:computername
    if(test-path "...UNC-PATH TO KB...\KB2607070\$ComputerName.txt"){exit}
    if(test-path "C:\Program Files (x86)") {...UNC-PATH TO KB...\KB2607070\WindowsUpdateAgent30-x64.exe /quiet /norestart} else {...UNC-PATH TO KB...\KB2607070\WindowsUpdateAgent30-x86.exe /quiet /norestart}
    New-Item "...UNC-PATH TO KB...\KB2607070\$ComputerName.txt" -type file

    If someone have a better solution please let me now your solution.

    You would be better to store the "Flag" file on the local machine. That way when the machine is re-imaged/re-installed the hotfix should automatically be re-applied.
    Monday, September 05, 2011 10:22 AM
  • My solution involves using DISM.

    The good news is that it is fully automatable thru LUP (so presumably thru SCE as well), handling reboot events as expected.  wuapi.dll gets updated to the new version upon reboot.

    The bad news is that since I'm not using WUSetup.exe (or WindowsUpdateAgent30-x86.exe), I'm not sure how confident I feel about the install.  I can't immediately think of a way to tell if my approach is updating everything WUSetup does.

    Is there a way to get WUSetup to write log files?

    you can found some entries in the "WindowsUpdate.log" located in the windows folder.
    Monday, September 05, 2011 1:45 PM
  • you can found some entries in the "WindowsUpdate.log" located in the windows folder.

    Thanks.  I'll give it a look.

    If others want to experiment using DISM, these are the steps I'm using.  They are for LUP, but presumably SCE offers the same functionality.

    These instructions are EXPERIMENTAL.  Use at your own risk!

    1. Create a deployment folder (ie c:\WU).
    2. Create a subfolder in the deployment folder (ie c:\WU\Stuff).
    3. Extract the exe file using: WindowsUpdateAgent30-x86.exe -d
    4. When instructions on use appear, copy the contents of the newly created folder and subfolders from c:\ to c:\WU\Stuff.
    5. Copy RunIt.exe (or RunIt64.exe) from http://sourceforge.net/projects/localupdatepubl/files/Binaries/ into c:\WU.
    6. Create a deployment package, using RunIt (or RunIt64) as the executable.
    7. Add the Stuff folder using the "Add Dir" button. (Click Next).
    8. Set the Impact to "Requires Exclusive Handling."
    9. Set the Reboot to "Always Requires Reboot."
    10. Set the command line arguments to "/L dism /online /add-package /packagepath:stuff /norestart /quiet /logpath:%windir%\temp\dism.log"
    11. Set the Return Code 3010 to be Success/Reboot.
    12. Set other fields as appropriate, but don't use "Microsoft" as the vendor. (Click Next).
    13. For the Installed rule, I use a File Version on WINDOWS \System32\wuapi.dll >= 7.6.7600.243
    14. For the Installable rule, I use Windows Version >= 6.1 SP 0.0 AND Architecture = x86

    Approve the update for some test machines and cross your fingers.

    If you have done things correctly, there will be 3 cab files in C:\WU\Stuff (NOT a subdirectory of Stuff, but actually in Stuff).  I suspect that those 3 cab files may be all that's really required in order to install on W7, but I haven't confirmed that.  It appears that many of the other files might be for other platforms (XP, 2k3, etc).  At a guess, WuSetup just figures out what platform it is running on, then calls the appropriate tool to do the install.

    The instructions as written will install all 3 cab files.  I don't know if all 3 are always required.

    Monday, September 05, 2011 11:32 PM
  • I suspect that those 3 cab files may be all that's really required in order to install on W7

    I created and ran an update with just RunIt.exe and the 3 cab files.  It appeared to run exactly the same.

    The instructions as written will install all 3 cab files.  I don't know if all 3 are always required.
    Looking at the log files for runs with WuSetup, it also appears to install all three of the cab files.  I don't know that that's *all* that WuSetup does, but it looks like I'm on the right track.
    Tuesday, September 06, 2011 2:11 AM
  • The solution buy ImAsh seems ok, but for me it does not work when teh script is deployed by GPO, only when the powershell script is run directly or started through a batch file. Did anyone succeeed?

    The solution by LGS need more clarification. It least for me, as I am not familiar with LUP and DISM. Instruction 7: "Add the Stuff folder using the "Add Dir" button. (Click Next).", from what interface is this run? DISP is commend line and in LUP I do not fing these options.

    Can you be a bit more specific please?

    Thanks!

    Wednesday, September 07, 2011 10:48 AM
  • The solution buy ImAsh seems ok, but for me it does not work when teh script is deployed by GPO, only when the powershell script is run directly or started through a batch file. Did anyone succeeed?


    What on my solution doesn't work? I have test it and it work fine in my environment.

    Have you check, that you have to assign the script to the computer-sektion of the GPO? And also you have assign it to the "PowerShell Scripts" Tab and not "Scripts".

    I have a 2008 R2 DC, Possible only this mode supports to run PowerShell Scripts at logon?

    Wednesday, September 07, 2011 12:09 PM
  • Hello heuby,

    Yes, I assigned the script to the computer section of the GPO? And also to the "PowerShell Scripts" Tab. We are also running 2008 R2 Domain Controllers. 

    I tried all combinations, logon and logoff (user config) and startup and shutdown (computer), but no success.

    It looks more like a GPO problem, but other setings in the GPO are applied, but not the startup script

    Wednesday, September 07, 2011 12:25 PM
  • "Add the Stuff folder using the "Add Dir" button. (Click Next)."

    When you click the Tools/Create Update menu option, Add Dir is a button on the very first screen (right above "Add Files").

    That said, I don't think you need to do that anymore.  As my later comment noted, I believe the only files you need are the 3 .cab files.  So, a simplified set of instructions would be:

    1. Create a deployment folder (ie c:\WU).
    2. Extract the exe file using: WindowsUpdateAgent30-x86.exe -d
    3. When instructions on use appear, copy (only) the 3 cab files from the newly created folder at c:\ to c:\WU.
    4. Copy RunIt.exe (or RunIt64.exe) from http://sourceforge.net/projects/localupdatepubl/files/Binaries/ into c:\WU.
    5. Create a deployment package, using RunIt (or RunIt64) as the executable.
    6. Use Add Files to add the 3 cab files. (Click Next)
    7. Set the Impact to "Requires Exclusive Handling."
    8. Set the Reboot to "Always Requires Reboot."
    9. Set the command line arguments to: /L %windir%\system32\dism.exe /online /add-package /packagepath:. /norestart /quiet /logpath:"%windir%\temp\dism.log"
    10. Set the Return Code 3010 to be Success/Reboot.
    11. Set other fields as appropriate, but don't use "Microsoft" as the vendor. (Click Next).
    12. For the Installed rule, I use a File Version on WINDOWS \System32\wuapi.dll >= 7.6.7600.243
    13. For the Installable rule, I use Windows Version >= 6.1 SP 0.0 AND Architecture = x86

    Note that I still have no way to confirm (other than a response from MS) that just installing those 3 cab files will update everything that WuSetup does.  While it appears to work, use at your own risk.

    Wednesday, September 07, 2011 5:51 PM
  • When you click the Tool/Create Update menu option, Add Dir is a button on the very first screen

    Sorry. may be a stupid question, but in which program? Not SCE2010, but...?

    Looking forward trying this

    Wednesday, September 07, 2011 8:18 PM
  • in which program? Not SCE2010, but...?

    Ahh, you use SCE.  My bad.  When I read your message I thought you were using LUP.

    Unfortunately, I don't have SCE, so I can't provide the specific steps.  But these are pretty basic operations.  Hopefully it isn't that hard to create a package in SCE, and you have all the key bits.

    Wednesday, September 07, 2011 10:37 PM
  • Thanks LGS, I will try that!
    Thursday, September 08, 2011 8:10 AM
  • Sorry. may be a stupid question, but in which program? Not SCE2010, but...?

    Looking forward trying this

    read some messages above. It seems not to be possible to deploy the hotfix using SCE. Background: before the fix is successful installed the WU-Service restarts and the installation is canceled.
    Thursday, September 08, 2011 2:25 PM
  • LGS's method above should be possible in SCE2010 as well as in LUP - they are functionally very similar (the normal update method doesn't work in LUP either). The main advantage of LUP in this case is the more precise targeting rule that checks the version of wuapi.dll
    Thursday, September 08, 2011 2:39 PM
  • I tried using LUP, but still have some issues

    1) If using SCE2010, there is no 100% synchronization between the Groups in SCE and WSUS. Some of my clients do not occur in WSUS, but are otherwise functioning well in SCE. (All updates and packages are distributed).

    2) Using LUP to target the package made as described by LGS, dirtributes the packages at the clients that happen to be present in WSUS, but all installations fail with error code 80070643

    3) I see no way in creating a package in SCE in a way similar to the procedure given for  LUP, or to deploy the package created using LUP with SCE

    MS did not solve the issue by making this KB available. It only helps us if there is a simple way of deploying it!


    • Edited by sewellia Friday, September 09, 2011 12:21 PM
    Friday, September 09, 2011 9:06 AM
  • 2) Using LUP to target the package made as described by LGS, does run the packages at the clients that happen to be present in WSUS, but all installs fail with error code 80070643

    This thread is getting a little cluttered and hard to follow.  If you have questions about using LUP, perhaps it would be better to post them in the LUP forum.  If you are using the command line I recommended, there are at least 3 log files that you should make available (WindowsUpdate.log, runit.log & dism.log).

    MS did not solve the issue by making this KB available. It only helps us if there is a simple way of deploying it!

    Agreed.  I know I would feel a lot better about this solution if MS were to confirm that the approach I'm suggesting will correctly install the update on W7 clients.<hint><nudge><hint>
    Friday, September 09, 2011 9:35 AM
    • Proposed as answer by sewellia Thursday, September 15, 2011 7:11 AM
    • Marked as answer by Crosfields School IT Thursday, September 15, 2011 7:20 AM
    Monday, September 12, 2011 2:06 PM
  • Unfortunately, that doesn't really help.

    The method you've described is the first method I tried, and it requires a manual reboot. The whole point of using SCE for updates is for us not to have to manually intervene when installing updates.


    Monday, September 12, 2011 2:13 PM
  • The second option offered by Mangesh Sonar does not work either. This is exactly what everyone tried and does not work. (Deployment status "user cancelled the installation" 

     

    .

    Monday, September 12, 2011 2:39 PM
  • sewellia,

     

    log file shows "user cancelled the installation" because the update installed is a windows update agent itself and this causes the windows update to turn off followed by a immediate turn on. As soon as the this process ends, you could surely find the  updated dll's(mentioned in the blog) in the system32 folder.

    but the only thing we can't avoid is a restart for the update to take affect.

     

    Thanks,

    Ganesh Majeti.

    Tuesday, September 13, 2011 4:03 AM
  • Ganesh, could you please comment on the approach I have described (using DISM against the 3 cab files)?  This approach also results in the dlls getting updated, but is much easier to distribute.

    Unlike the solution you and Mangesh are proposing, using DISM works correctly with the WU Client, prompting the user for a reboot, instead of leaving the computer in a half-installed state until happenstance results in the machine being restarted.  It also doesn't report that the update was cancelled.  Correctly reporting the status of the update allows WSUS admins to know which machines installed the update, are pending reboot, or failed to install the update and need a technician to investigate.

    The question that needs answering with using DISM instead of WuSetup is "What (if anything) does wusetup.exe do on W7 *other* than launching the installer against the 3 cab files?"  While I'm confident that it does install using the cabs, it is quite possible it does something more.  Given that there are no docs and no log files, finding out what else WuSetup does without a response from MSFT is *really* hard.

    If (as I suspect) WuSetup doesn't do anything else on W7 besides just launch the installer against these 3 cab files, then there is a clean solution here. 

    But we really need someone who understands the specifics of what WuSetup does to confirm this (or to describe what else WuSetup does).  Are you that person?  Or can you find that person?

    Thanks.

    Tuesday, September 13, 2011 5:30 AM
  • Hi Ganesh Majeti

    The update will fail and try to install again and again.

    Can you you provide the WMI script needed to create a Dynamic group with clients that have WUAPI.DLL of the old version? Then we can target the KB2607070 update to that group only so that it only runs once on earch client.

    Thanks   

    Tuesday, September 13, 2011 9:30 AM
  • Hi LGS,

    Thank you very much for proposing this approach. I could figure out that same approach can be successfully adopted through SCE software deployment as well. Mangesh has updated the blog with mention of this and steps needed to deploy using DISM. Please have a look.... Thanks again!

    Regards,

    -Ganesh Majeti.

     

     

    Wednesday, September 14, 2011 2:20 PM
  • Hi sewellia,

    Mangesh has updated the blog with a new approach.

    This new approach will address the issues reported by you and you may not need a WMI script which helps create a dynamic group either.

    hope this helps.

    -Ganesh Majeti.


    • Edited by Ganesh Majeti Wednesday, September 14, 2011 5:03 PM
    • Proposed as answer by sewellia Thursday, September 15, 2011 7:10 AM
    • Marked as answer by Crosfields School IT Thursday, September 15, 2011 7:52 AM
    Wednesday, September 14, 2011 2:24 PM
  • YES YES YES. the last solution in the (updated) blog works! 100 clients done..

    Thanks to everyone who contributed to this thread!

     

     

    Thursday, September 15, 2011 7:13 AM
  • The update is now installing in a proper, managed way for us too now. I'd like to thank everyone who's been involved in producing this fix, especially the contributors to this thread. In particular, I'd like to thank LGS for coming up with the DISM based approach in Local Update Publisher that Mangesh Sonar translated into steps for SCE.

    While I am happy that this has been resolved, I think there are still some wider problems with the support of SCE that this issue has brought to light. The fact that it took more than 6 months after the initial report for a fix to be produced, when it had been reproduced internally within 2 weeks, is very disappointing. Granted, it does appear that the issue was related to parts of Windows for which the SCE team is not directly responsible, but users were not informed of this at all. I think I speak for many here when I say that it would have been much more reassuring to receive more frequent and more informative updates on the issue from Microsoft. It would have been better still if the official patch could have been rolled out correctly without the community having to provide an alternate install method that relies on a third-party tool.

    Together these things seem to indicate a lack of commitment to the SCE product and a lack of understanding of the issue by Microsoft. I hope that this is not the case, but it certainly seemed that way, and it has seriously shaken my confidence in being able to rely on SCE in the future. This is not a consumer product, and as paying business customers, I think we are entitled to expect better.

    Thursday, September 15, 2011 7:51 AM
  • Agreed on all counts, thanks and concerns as well. Sorry I wasn't around for the frenzied search for an install solution, the day after the patch came out my vacation started. Good work all!

    Friday, September 16, 2011 11:44 PM