| Home | Register | Members | Search | Windows Vista Tips | File Database | Links |
 |
| Thread Tools | Display Modes |
|
Guest
Posts: n/a
|
|
|
|
||
|
|
| |
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
Thanks for the quick response... See my responses below...
"Lawrence Garvin [MVP]" wrote: > "Dave Wright" <> wrote in message > news:0D94A5CD-AE39-4909-B280-... > > >I am getting several updates that are failing on my System Center > > I've tried running WSUSUTIL /reset on the WSUS server > > So, probably the correct syntax for the command would be good. There is no > forward slash on the CLI parameters for wsusutil.exe. > > Just run WSUSUTIL RESET I rechecked, and we did run WSUSUTIL RESET without the slash. I typed it wrong in the message. > If a file download failed, it will be logged in the Application Event Log of > the WSUS Server; > it will also be logged in the WSUS SoftwareDistribution.log > found in the folder %ProgramFiles%\Update Services\Logfiles I'm requesting access to the logs from our IT Systems group. I probably won't get it until Monday. > HOWEVER -- the client would not be able to detect the availability of the > update unless the EULA had been previously downloaded, and the update > approved; so this is more likely a case of the file being *deleted*, rather > than never downloaded. This is most interesting, because the server is locked down pretty tight. I'm not sure how the file could have gotten deleted. > > The EULA HAS been accepted in the System Center Console on the updates in > > question. > > Assuming that WSUS is actually the configured SUP for SCCM; the EULA would > have had to physically exist in order to have been accepted; so here we also > have confirmation that the file was likely deleted after being successfully > downloaded. I re-verified this, and in the SCCM Console, the metadata does show accepted for all Eula's that are being deployed. Still makes me wonder how the data was deleted in the first place. > > 2009-10-09 06:24:26:189 1100 43240 Setup Client version: Core: > > 7.2.6001.788 > > Aux: 7.2.6001.788 > > You'll want to make sure you have a plan for upgrading the WSUS Server to > SP2 as soon as possible. It is on my plate.  > > 2009-10-09 06:24:32:070 1100 43240 PT + ServiceId = > > {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = > > http://admsccmu2.na.admworld.com:80/...ce/client.asmx > > You also should remove the port suffix from the URL configured in policy for > the WSUS server. It's not necessary. I've had some issues with clients unable to connect to the server if the port is NOT specified. It may be a proxy issue there, but it seems that placing the port in the URL corrects the problem. Is there any problem with leaving this alone or do I run the risk of future problems? > btw.. Underscores are not a valid character in the Domain Name Service -- a > flaw in Microsoft DNS actually allows them to exist, but you should consider > renaming them, or at least refraining from them using in future names. This particular machine doesn't conform to our naming standards. Believe me, I want to get rid of them too.  > > 2009-10-09 06:24:32:148 1100 43240 PT Server URL = > > http://admsccmu2.na.admworld.com:80/...impleAuth.asmx > > 2009-10-09 06:24:35:549 1100 43240 Agent WARNING: Failed to evaluate > > Installed rule, updateId = {87CFBD65-2BD8-434F-AE28-59E3A2018AF3}.1, hr = > > 8004100E > These warnings are suspicious. For one, the UpdateIDs are not in the > Microsoft Catalog; for two, 0x8004xxxx error codes are highly unusual to be > seen in a WU log. This error code is usually seen in response to a missing > namespace in a WMI query. This could be an indication of a WMI issue on the > local client. I see these in almost all of my clients log files, even the ones that are not having any problems. I've generally been ignoring them because all seems to be working fine despite them. What do these mean? > So, the problem here is determining which updates these EULAs are supposed > to be for; because the UpdateIDs identified in the earlier entries are not > in the Microsoft Catalog. I'll do some additional investigating and see what I can find. I'm also going to have my systems guy re-run the WSUSUTIL RESET command. > This is a detection being initiated by SMS/SCCM (CcmExec) only 2.5 hours > after the above detection,which appears to be a regularly schedule detection > triggered by the WUAgent. > > Do you have two separate update methodologies in play here - SCCM *and* > WSUS? This is possible, and after checking on this machine likely. We are in the process of migrating to SCCM from WSUS. Roughly 2/3 of our clients have been migrated and 1/3 are still on WSUS only. This computer was in an OU in AD that was excluded from SCCM patching, but was still targetted for a test deployment in SCCM of Vista SP2. I moved the machine out of the old WSUS OU and into the an OU being patched by SCCM. One thing I am confused about though, and maybe you can clear this up for me. Under WSUS we used the WUAUCLT.EXE file with it's /DETECTNOW switch to force a machine to detect updates. Under SCCM we use the SCCM client action to initiate Software Updates Scan Cycle, but I've been told we can also use the old WSUS method. Is there a difference between the two methods or do they accomplish the same thing? Or was I given bad information and they are like apples and oranges? > > 2009-10-09 09:07:03:617 1100 434d8 Agent * Criteria = "UpdateID = > > 'cad30b29-e5a2-42ed-bcdc-501208b47b91' AND DeploymentAction = *" > *THIS* is the update package for Vista Service Pack 2 (KB948465)! > Found by the SCCM scan, but not being found by the WSUS scan. That is weird. Why would one scan pick it up and not the other? > > 2009-10-09 09:07:15:645 2436 43838 COMAPI WARNING: > > ISusInternal::GetEulaText > > failed, hr=80240033 > Which is again logged as failing, except this time with a code we know: > 0x80240033 -2145124301 WU_E_EULA_UNAVAILABLE EULA download failure OK, so this does confirm that Vista SP2 is failing because of the EULA. Thanks for the insight so far. I've learned lots from just one post. Monday, after I get access to the server logs and I have my server guy re-run the WSUSUTIL RESET command, I will check the client again and see if anything has changed and post details here. --Dave Wright |
|
|
|
|
|||
|
Guest
Posts: n/a
|
"Dave Wright" <> wrote in message
news:84DACDF1-3BF3-451C-9F84-... >> If a file download failed, it will be logged in the Application Event Log >> of >> the WSUS Server; >> it will also be logged in the WSUS SoftwareDistribution.log >> found in the folder %ProgramFiles%\Update Services\Logfiles > > I'm requesting access to the logs from our IT Systems group. I probably > won't get it until Monday. Can you give me some background on the interrelationships here? Are you the primary WSUS Administrator? Do you not have access to the WSUS Server directly? I'm really intrigued that you'd have to "request access" to these logs! :-/ Also, if access to the logs requires a special request -- we may have significant issues performing diagnostics and testing trying to identify the cause of this issue. (And you allude to this by indicating how "locked down" this server is.) > I'm not sure how the file could have gotten deleted. It might not have been deleted. It could also be the victim of an ACL change, a filesystem move, or other *controlled* activities which result in a change being made that functionally hides the file from the Update Services service. It might have been moved into a tree that's causing an invalid ACL inheritance. If that server really is locked down as tight as it seems, then it should be trivial for that System Administrator to identify when that file first appeared on the server and when it "disappeared" (or where it actually is at this moment). >> > 2009-10-09 06:24:32:070 1100 43240 PT + ServiceId = >> > {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = >> > http://admsccmu2.na.admworld.com:80/...ce/client.asmx >> >> You also should remove the port suffix from the URL configured in policy >> for >> the WSUS server. It's not necessary. > > I've had some issues with clients unable to connect to the server if the > port is NOT specified. It may be a proxy issue there, but it seems that > placing the port in the URL corrects the problem. That would definitely be a proxy issue, I'd think. The proxy may not be properly assuming a default port of 80; or may be appending the wrong port number onto the URL as it passed it through. Basic point, though, the HTTP specification says all HTTP listeners should respond on port 80 if/when the port number is not specified, so if the proxy is messing with that -- it's either a misconfiguration of the proxy server, or the proxy server is not fully protocol compliant. > Is there any problem with leaving this alone or do I run the risk of > future problems? If it's not causing any problems now, and removing it does, then I'd say leave it alone. I can't say that I remember any direct issues caused by the suffix, but I do know there's a reason I started recommending removing the :80 suffix. I probably should review my Sent Items archive and see if I can refresh my memory on why I started doing that. >> btw.. Underscores are not a valid character in the Domain Name Service -- >> a >> flaw in Microsoft DNS actually allows them to exist, but you should >> consider >> renaming them, or at least refraining from them using in future names. > > This particular machine doesn't conform to our naming standards. Believe > me, I want to get rid of them too. <G> Well.. maybe you have a good reason here -- it has a dysfunctional WUAgent and cannot be maintained in a 'secure' state. ;-) >> > 2009-10-09 06:24:32:148 1100 43240 PT Server URL = >> > http://admsccmu2.na.admworld.com:80/...impleAuth.asmx >> > 2009-10-09 06:24:35:549 1100 43240 Agent WARNING: Failed to evaluate >> > Installed rule, updateId = {87CFBD65-2BD8-434F-AE28-59E3A2018AF3}.1, hr >> > = >> > 8004100E > >> These warnings are suspicious. For one, the UpdateIDs are not in the >> Microsoft Catalog; for two, 0x8004xxxx error codes are highly unusual to >> be >> seen in a WU log. This error code is usually seen in response to a >> missing >> namespace in a WMI query. This could be an indication of a WMI issue on >> the >> local client. > > I see these in almost all of my clients log files, even the ones that are > not having any problems. I've generally been ignoring them because all > seems > to be working fine despite them. What do these mean? There was an issue a few weeks (months? time runs all together these days) ago, where the WUAgent was "seeing" updates that weren't suppose to be seen. A 'fix' for that issue was supposed to be released, and once the issue was acknowledged and we determined the issue was benign, I went on to other issues. It may be that this is related to that 'bug', and it's not actually been fixed (or you might not have the fix). Let me do some research on that issue and see what came of it. >> So, the problem here is determining which updates these EULAs are >> supposed >> to be for; because the UpdateIDs identified in the earlier entries are >> not >> in the Microsoft Catalog. > > I'll do some additional investigating and see what I can find. I'm also > going to have my systems guy re-run the WSUSUTIL RESET command. Make sure the server does not have any pending downloads, if the 'reset' command creates new download requests, that they're actually executed. >> This is a detection being initiated by SMS/SCCM (CcmExec) only 2.5 hours >> after the above detection,which appears to be a regularly schedule >> detection >> triggered by the WUAgent. >> >> Do you have two separate update methodologies in play here - SCCM *and* >> WSUS? > > This is possible, and after checking on this machine likely. That *could* be causing some miscommunication (and misreported status) between the two systems. > We are in the process of migrating to SCCM from WSUS. Roughly 2/3 of our > clients have been > migrated and 1/3 are still on WSUS only. This computer was in an OU in AD > that was excluded from SCCM patching, but was still targetted for a test > deployment in SCCM of Vista SP2. I moved the machine out of the old WSUS > OU > and into the an OU being patched by SCCM. AHHH!!!... Something you need to be aware of. It's a natural behavior of Group Policy. Moving a machine out of the "WSUS" OU, and into an 'SCCM" OU will *not* deactivate the WSUS configuration, unless the policy settings have been explicitly disabled (or modified) by the "SCCM" OU. I would suggest verifying that all of the policy differentials between those two OUs are being handled as expected. > One thing I am confused about though, and maybe you can clear this up for > me. Under WSUS we used the WUAUCLT.EXE file with it's /DETECTNOW switch > to > force a machine to detect updates. Under SCCM we use the SCCM client > action > to initiate Software Updates Scan Cycle, but I've been told we can also > use > the old WSUS method. Is there a difference between the two methods or do > they accomplish the same thing? Or was I given bad information and they > are > like apples and oranges? It's really two different client-side scenarios, and is also dependent upon whether WSUS is being used as the SUP for SCCM. I'm still learning the SCCM/WSUS scenario, so I'm by no means an expert on this, and you might find a better (read: more accurate) answer in the SCCM forum(s). The WSUS environment uses the native Windows Update Agent, as is done with Automatic Updates, Windows Update, or Microsoft Update. SCCM has it's own custom agent. Now, what I'm not sure about is whether this agent proxies through the WUAgent, or actually queries directly to the CM server. Also, that's probably dependent on whether WSUS is being used as the SCCM SUP, or not. Using the old "WSUS method" (e.g. using the WUAgent) would require, I believe, that WSUS is configured as the SCCM SUP. >> > 2009-10-09 09:07:03:617 1100 434d8 Agent * Criteria = "UpdateID = >> > 'cad30b29-e5a2-42ed-bcdc-501208b47b91' AND DeploymentAction = *" > >> *THIS* is the update package for Vista Service Pack 2 (KB948465)! >> Found by the SCCM scan, but not being found by the WSUS scan. > > That is weird. Why would one scan pick it up and not the other? It may not actually be approved in the *WSUS* environment, or it may not be approved for the *group* that this client is now detecting against with the WSUS Server. If the client was configured in target group 'A' under the "WSUS" GPO, and moving it to the "SCCM" GPO has caused client-side targeting to be disabled, or the client to be placed in target group 'B', the update may not be visible to the WUAgent from WSUS. >> > 2009-10-09 09:07:15:645 2436 43838 COMAPI WARNING: >> > ISusInternal::GetEulaText failed, hr=80240033 > >> Which is again logged as failing, except this time with a code we know: >> 0x80240033 -2145124301 WU_E_EULA_UNAVAILABLE EULA download failure > > OK, so this does confirm that Vista SP2 is failing because of the EULA. Yes, at least from the SCCM environment. -- Lawrence Garvin, M.S., MCITP:EA, MCDBA Principal/CTO, Onsite Technology Solutions, Houston, Texas Microsoft MVP - Software Distribution (2005-2009) My Blog: http://onsitechsolutions.spaces.live.com Microsoft WSUS Website: http://www.microsoft.com/wsus My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin |
|
|
|
|
|||
|
|
| |
|
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| 0x80244019 error: download failed | DickieRay | Update Services | 1 | 09-13-2006 01:46 AM |
| Download Error 0x80244019 | HubbleJS | Update Services | 3 | 08-18-2006 06:38 AM |
| Error 0x80244019 fail to download. | Marco | Update Services | 0 | 03-21-2006 05:41 PM |
| Error: Download Failed 0x80244019 | Matt | Update Services | 9 | 12-14-2005 01:02 AM |
| Download Fails - Error 0x80244019 | Scallica | Update Services | 2 | 11-11-2005 09:02 PM |
Linear Mode
