locked
Windows Update hlasí na W7 stanicích chybu kód 8007000D RRS feed

  • Dotaz

  • Po opětovném začlenění stanic s Windows 7 (64-bit) do reinstalované domény FIRMA.local (pod SBS 2003) nám na všech W7 Windows Update hlásí chybu s kódem 8007000D. Netuším proč, když ostatní stanice s WinXP se z lokálního WSUS 3.0 SP2 úplně normálně aktualizují. Nesetkal jste se s tím někdo?

    pondělí 2. května 2011 12:57

Odpovědi

  • Tak se musím přiznat, že jsem ten problém rozluštil. Skutečně to souviselo se starší verzí balíčeku wuident.cab.

    Omylem jsem si při nedávné instalaci WSUS rozbalil SP0 verzi a tu jsem v domnění že instaluji staženou poslední verzi SP2 nainstaloval. Vůbec mě tato varianta nenapadla, resp. až teď jsem si všiml wuident.cab verze z roku 2007. Pak už mi to bylo jasné. Provedl jsem upgrade WSUS na SP2 a chyba s kódem 8007000D se již na Windows 7 neobjevuje.

    Trochu mě však zaráží, že sám "velký" WSUS SP0 mi sám pro sebe nenabídl aktualizaci na WSUS SP2 ....

    pátek 6. května 2011 6:56

Všechny reakce

  • Zkus kouknout na tohle...

    http://answers.microsoft.com/en-us/windows/forum/windows_other-windows_update/code-8007000d-windows-update-encountered-an/e7ce6bc3-c543-42db-8607-ad622fdbe47d

    Je to chyba, při které nemůže vyhledat ten WSUS server. Změnil se jeho název/IP?

    pondělí 2. května 2011 13:43
  • Tak jsem zkoušel nástroj připravenosti aktualizace, viz. KB947821, ale nijak to věci nepomohlo. Dle vygenerovaného CheckSUR.log a CheckSUR.persist.log nebyly detekované žádné chyby, viz. níže. Přesto aktualizace u všech W7 i nadále zobrazují chybu s kódem 8007000D.

    =================================
    Checking System Update Readiness.
    Binary Version 6.1.7601.21645
    Package Version 11.0
    2011-05-03 19:07

    Checking Windows Servicing Packages

    Checking Package Manifests and Catalogs

    Checking Package Watchlist

    Checking Component Watchlist

    Checking Packages

    Checking Component Store

    Summary:
    Seconds executed: 704
     No errors detected

     

     

    středa 4. května 2011 6:03
  • Myslim si, ze jste na spatne ceste. Obrazek tomu nasvedcuje.

    1. Bud budete aktualizovat W 7 pres WSUS, nebo lokalne. Oboji nedava smysl.

    2. Predpokladam, ze aktualizaci budete ridit pres GPO a proces aktualizace bude invokovany ze strany klenta. W 7 bude v samostatne skupine a "viditelne" v seznamu na konzole WSUS. Pro skupiny budete mit vytvorene ukoly, ktere stanovi, co se ma aktualizovat.

    3. Pokud mate vse nastavene spravne na serveru, dejte na W 7 prikaz

        wuauclt.exe /resetauthorization /detectnow

    Dejte do nektereho "skladiste" (napr. SkyDrive) vypisy logu, nastaveni GPO a WSUS. Na WSUS moc nespechejte a nechte vse naplanovane probehnout v nastavenem case. (Ja nechavam pocitace probudit v mimopracovni dobu, provedu aktualizace a prikazem shutdown je uspim. Mozna by korektnejsim resenim bylo dat restart a pak shutdown, aby se mohlo provest pripadne dokonceni konfigurace aktualizace a uzivatele by mohli rano hned pracovat.)

    středa 4. května 2011 7:10
  • 1. W7 bych samozřejmě rád aktualizoval přes lokální WSUS, ale od nového přidání W7 stanic do domény je s tím problém, který končí chybou s kódem 8007000D. Jediný způsob, jak nyní na W7 stanicích mohu úspěšně provádět aktualizace, je přes odkaz na stažení přes web Microsoft Update.

    2. Nastavení aktualizací na stanicíh řídíme globálně přes GPO, která se na klienty propaguje bez hlášených problémů. W7 stanice zatím ve WSUS nemáme v samostatné skupině, protože pro to nemáme nějaký pádný důvod. Nicméně všechny naše stanice ve WSUS vidím a také sem reportují stav.

    3. Příkaz   wuauclt.exe /resetauthorization /detectnow   jsem provedl zatím jen na WS13, ale výše uvedenou chybu to také neopravilo. Proto jsem na WS13 provedl manuální detekci aktualizací přes Ovládací panely a Zjištění aktualizací na webu Microsoft Update. Jak je z hlášení WSUS patrné, tak stanice WS13 se po aktualizacích přes Microsoft Update nyní tváří v pořádku, resp. vyreportovala (viz. níže) že na ní neschází žádné aktualizace. Přesto je na ní lokálně stále hlášena chyba s kódem 8007000D.

    Zde je k nahlédnutí nastavení GPO.
    http://ddujca.bay.livefilestore.com/y1pClDl6Hv6xJTT9gOuT-4r1PQ7GJP812Tobd-JtZyIqrAsRaG3ZJxFPKyKMBp9Hf4UQ9cW2Zo9McwzPqjGxdLHpCVxFlwfvj2W/WS%20-%20Z%C3%A1sady%20aktualizac%C3%AD%20p%C5%99es%20WSUS%203.0.htm?psid=1

    Zde je k nahlédnutí C:\WINDOWS\Software Distribution\ReportingEvents.log ze stanice WS13
    http://ddujca.bay.livefilestore.com/y1pT4Ve3dPtjHkUNxn83rV0VKWvO7bcjEdyZ6vH8WWtBLeaxDxIvxlcgowuZdNRvnAXHzMFtNs9fTsjOQ7OTVRGgwb4aKu7-yZZ/ReportingEvents.log?download&psid=1 

    WOL za účelem provedení aktualiazací mimo pracovní dobu je hezká záležitost, ale bohužel ne všechny naše stanice se mi daří přes Wake-On-Lan probouzet. Možná pro to nemám správný sw, nebo to neznačkové stanice nedostatečně podporují. Pokud k tomu máte nějaká doporučení, tak se jim nebráním :-)


    čtvrtek 5. května 2011 7:53
  • 1. S takovym zpusobem reseni se nikam nedostaneme. Nepouzivejte zatim lokalni aktualizace.

    2. Deleni do skupin: Duvod je ten, ze v Automaticke aktualizaci se nastavuje software, ktery ma byt aktualizovan. (Pokud pujdete touto cestou, nastavte i synchronizaci tak abyste mel "cerstve" aktualizace. Pred zacatkem pracovni doby a vecer. Budou se hromadit aktualizace Security Essentials, ale system si vybere ty spravne.)

    3. To, ze je stanice 13 v poradku z hlediska aktualizace je sice pekne, ale k reseni problemu to neprispeje. Krome ReportingEvents.log poslete take WindowsUpdate.log ze stanice, kterou jste rucne neaktualizoval.

    Startovani stanic mimo pracovni dobu lze provest pres BIOS (Alespon desktopy by to mely umet.)

     

     

     

     

    čtvrtek 5. května 2011 8:55
  • 1. O.K.

    2. Jsem nijak neřešil. Asi nevím přesně, co máte na mysli. Nicméně, nemělo by to mít dopad globální aktualizace W7 přes náš WSUS. V nastavení WSUS je zvoleno stahování aktualizací i pro W7 a to by mělo být dostačující.

    3. Zde jsou k nahlednutí dva WindowsUpdate.log soubory. WS10 je stanice na které se aktualizace přes web Microsoft Update nikdy nepoužily. WS13 je stanice, na které jsme kvůli otestovaní několikrát použili i aktualizace přes web Microsoft Update. Na obou stanicích je reportována stejná chyba s kódem 8007000D.

    WindowsUpdate WS10.log

    ReportingEvents WS10.log

    WindowsUpdate WS13.log

    Jak je z logů patrné, tak stanice s WSUS spojení na http://srv01:8530 bez problémů navazují a resportují stav aktualizací, ale stále hlásí chybu s kódem 8007000D.

    • Upravený Marek Stodola čtvrtek 5. května 2011 16:27 doplnění log souboru
    čtvrtek 5. května 2011 16:11
  • 1. To jsem rad, ze postupujeme oba stejne.

    2. Tady vidim mozny problem. Podivejte se na tento radek z logu:

    2011-05-05 07:46:24:053  960 6d4 Agent   * Target group: (Unassigned Computers)

    Zpravidla se davaji pocitace do skupin a neponechavaji se v defaultni neoznacene skupine.

    Klient, cili W 7 spravne neinicializuje ....

    2011-05-05 07:46:24:084  960 6d4 Agent WARNING: WU client failed to initialize a download call from persisted data with potential error 0x80248002

    Patrani tedy smeruje k nalezeni pricin chyby s kodem 0x80248002

    Meli bychom nastavit do pocatecniho stavu lokalni databazi aktualizaci nasledujicim postupem (na stanici W 7):

    a. Zastavte  Windows Update service. (sc stop wuauserv)

    b. Prejmenujte %windir%\SoftwareDistribution na SoftwareDistribution.OLD.

    c. Restartujte sluzbu Windows Update (sc start wuauserv)

    d. Sledujte, co se deje v WindowsUpdate.log behem asi 15minut, zda dochazi k downloadu aktualizaci. Log prilozte.

     

     

    čtvrtek 5. května 2011 20:55
  • Na WS13 jsem již mezi prvními opatřeními zkoušel uvedení nastavení WU do defaultu. Tzn. postup jak píšete s přejmenovaním SoftwareDistribution a také s přejmenováním HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate, vymazáním WS13 z WSUS a opětovným spuštěním služby Windows Update. Bohužel ani tento "hrubý" postup chybu s kódem 8007000D na WS13 nevyřešil. Jak %windir%\SoftwareDistribution tak HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate po spuštění služby WU vzniklo znovu, WS13 získala nové SusClientId a objevila se znovu i ve WSUS, ale stále to situaci nevyřešilo.

    Vyzkouším založit pro W7 stanice ve WSUS spec. skupinu, ale moc si od toho neslibuji. Nikdy jsem skupiny nepoužíval a vždy mi to i pro W7 fungovalo, i když byly všechny stanice ve skupině Nezařazené počítače.


    pátek 6. května 2011 5:24
  • dobry WOL sw je od DePicuse

     

    MP

    pátek 6. května 2011 5:41
  • Já začínám tušit problém někde jinde. Podle mě těm našim W7 (64-bit) z nějakého důvodu "nevoní" balíček wuident.cab, který náš WSUS nabízí přes http://srv01:8530/selfupdate/wuident.cab.

    Když se podívám do Windows Update.log tak to vypadá že si stanice balíček stáhne, ale pak chce provést instalaci, ale ta právě skončí chybou. To se opakuje podle mě stále dokola.

    2011-05-06 07:40:30:176  956 318 Agent *************
    2011-05-06 07:40:30:176  956 318 Agent ** START **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2011-05-06 07:40:30:176  956 318 Agent *********
    2011-05-06 07:40:30:176  956 318 Agent   * Online = Yes; Ignore download priority = No
    2011-05-06 07:40:30:176  956 318 Agent   * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"
    2011-05-06 07:40:30:176  956 318 Agent   * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
    2011-05-06 07:40:30:176  956 318 Agent   * Search Scope = {Machine}
    2011-05-06 07:40:30:176  956 318 Setup Checking for agent SelfUpdate
    2011-05-06 07:40:30:176  956 318 Setup Client version: Core: 7.5.7601.17514  Aux: 7.5.7601.17514
    2011-05-06 07:40:30:176  956 318 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
    2011-05-06 07:40:30:178  956 318 Misc  Microsoft signed: Yes
    2011-05-06 07:40:30:180  956 318 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
    2011-05-06 07:40:30:182  956 318 Misc  Microsoft signed: Yes
    2011-05-06 07:40:30:183  956 318 Setup WARNING: SelfUpdate check failed to download package information, error = 0x8007000D
    2011-05-06 07:40:30:183  956 318 Setup FATAL: SelfUpdate check failed, err = 0x8007000D
    2011-05-06 07:40:30:183  956 318 Agent   * WARNING: Skipping scan, self-update check returned 0x8007000D
    2011-05-06 07:40:30:184  956 318 Agent   * WARNING: Exit code = 0x8007000D
    2011-05-06 07:40:30:184  956 318 Agent *********
    2011-05-06 07:40:30:184  956 318 Agent **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2011-05-06 07:40:30:184  956 318 Agent *************

    Nemůžete se někdo prosím podívat na WSUS server, obvykle do složky C:\Program Files\Update Service\Selfupdate  na soubor  wuident.cab.
    Ten náš je ze 17.4.2007 s digitálním podpisem 17.4.2007 14:12:50, což už je samo o sobě podezřelé, že je tak starý. Jako by si ho WSUS neuměl aktualizovat.

    A ještě jedna divná věc, které jsem si všiml. Náš WSUS3 SP2 na SBS 2003 prezentuje operační systém W7 stanic nikoliv jako Windows 7 ale jako Windows 6.1, viz. screenshot výše. Už jsem ale určitě viděl WSUS, kde se to bylo prezentováno jako Windows 7.  

    pátek 6. května 2011 6:02
  • Tak se musím přiznat, že jsem ten problém rozluštil. Skutečně to souviselo se starší verzí balíčeku wuident.cab.

    Omylem jsem si při nedávné instalaci WSUS rozbalil SP0 verzi a tu jsem v domnění že instaluji staženou poslední verzi SP2 nainstaloval. Vůbec mě tato varianta nenapadla, resp. až teď jsem si všiml wuident.cab verze z roku 2007. Pak už mi to bylo jasné. Provedl jsem upgrade WSUS na SP2 a chyba s kódem 8007000D se již na Windows 7 neobjevuje.

    Trochu mě však zaráží, že sám "velký" WSUS SP0 mi sám pro sebe nenabídl aktualizaci na WSUS SP2 ....

    pátek 6. května 2011 6:56