8 Replies Latest reply on Sep 10, 2014 12:10 PM by nhilez

    WSUS on Server 2008

    nhilez

      I have a 2008 server configured with WSUS. I have a number of Windows 7 clients that will not check in and these clients report the Last Status as "Not yet reported." I have found documentation that indicates the reason for this is due to a version mismatch between the client and Update Services; if the client is running 3.2.7600.256 then Update Services must be at least 3.2.7600.251 to allow connectivity. I have applied KB2734608 and KB2828185 to the 2008 server, which should have brought Update Services to .262. If I click on the server name in the Update Services console and check the server version it does reflect 3.2.7600.262. However, if I click Help | About Update Services... it reports the version as 3.2.7600.226! Has anyone seen this issue, and/or have any idea how to get past it? The updated clients (.256) still will not check in so I have to assume the Update Services are still at .226.

      I have attached PNG files of the Server Version and Help | About. Any assistance is appreciated.

       

      226.png

       

      262.png

        • Re: WSUS on Server 2008
          KMSigma

          WSUS versions can be a sticky subject.  Here's a super-short primer:

           

          WSUS 3.0 (SP2) + KB2720211 = Build 3.2.7600.251

          WSUS 3.0 (SP2) + KB2734608 = Build 3.2.7600.256

          WSUS 3.0 (SP2) + KB2828185 = Build 3.2.7600.262

           

          You should most definitely reboot your WSUS Server after these patches have been applied.  If you are still having issues, go ahead and post back.  We'll be sure to look at it.

          • Re: WSUS on Server 2008
            Lawrence Garvin

            However, if I click Help | About Update Services... it reports the version as 3.2.7600.226!

             

            This question is addressed in SolarWinds KB4107.

            Your server IS at build 262 (KB28281815 is installed).

             

            Which still leaves us with the question of why your clients are not communicating.

            The diagnostics for this will be found in the WindowsUpdate.log of a failing client.

             

            Most notably, if these clients just became WSUS clients recently, they may have been updated to a YET NEWER Windows Update Agent via WU/MU, which will require that you install KB2938066 to the WSUS servers and PM servers. But before you do that, let's confirm with the WindowsUpdate.log

              • Re: Re: WSUS on Server 2008
                nhilez

                I have posted two WindowsUpdate.log files here.  These are both for POS terminals that do not have a connection to the Internet.  015POSTERM3 last reported in to the WSUS server on 8/20/2014.  015POSTERM6 reported in to WSUS this morning around 7:30 am Eastern (I have only included the last 4 days of WindowsUpdate in this log file for brevity).  There does not seem to be a noticeable difference between the two log files.  The terminals are Windows 7 Pro Embedded and were built using the same image, and are the same hardware.

                If you can find the clue that gets me in the right direction for resolution you'd be a rock star in my book.

                  • Re: Re: WSUS on Server 2008
                    Lawrence Garvin

                    The logfile from 015POSTERM3 only includes a single detection event, combined with a service start/stop, at 8:30am this morning, but the most notable thing is this oft-seen error:

                     

                    2014-09-10 08:32:59:402 4004 eb4 PT Initializing simple targeting cookie, clientId = b97d90e4-9d1b-48b3-afac-bb6502e5c9e8, target group = , DNS name = 015posterm3
                    2014-09-10 08:32:59:402 4004 eb4 PT   Server URL = http://192.168.254.54/SimpleAuthWebService/SimpleAuth.asmx
                    2014-09-10 08:32:59:496 4004 eb4 PT WARNING: GetCookie failure, error = 0x8024400D, soap client error = 7, soap error code = 300, HTTP status code = 200
                    2014-09-10 08:32:59:496 4004 eb4 PT WARNING: SOAP Fault: 0x00012c
                    2014-09-10 08:32:59:496 4004 eb4 PT WARNING:    faultstring:Fault occurred
                    2014-09-10 08:32:59:496 4004 eb4 PT WARNING:    ErrorCode:ServerChanged(4)
                    2014-09-10 08:32:59:496 4004 eb4 PT WARNING:    Message:Server rolled back since last call to GetCookie
                    2014-09-10 08:32:59:496 4004 eb4 PT WARNING:    Method:"http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/GetCookie"
                    2014-09-10 08:32:59:496 4004 eb4 PT WARNING:    ID:451f2d05-6493-4ef3-acdd-9518a98d7278
                    2014-09-10 08:32:59:496 4004 eb4 PT WARNING: PTError: 0x80244015
                    2014-09-10 08:32:59:496 4004 eb4 PT WARNING: GetCookie_WithRecovery failed : 0x80244015
                    2014-09-10 08:32:59:496 4004 eb4 PT WARNING: RefreshCookie failed: 0x80244015
                    2014-09-10 08:32:59:496 4004 eb4 PT WARNING: RefreshPTState failed: 0x80244015
                    2014-09-10 08:32:59:496 4004 eb4 PT WARNING: Sync of Updates: 0x80244015

                     

                    This sequence is quite commonly associated with a duplicate SusClientID issue, but I've also seen it sporadically occur when a client is talking to a replica server. Having additional activity in the logfile could show a more complete picture.

                     

                    In the 015POSTERM6 logfile, which gives us a few days of history, we see normal operations until 8:30pm on the evening of Sept 7th, at which time the client encounters a collection of updates which, ostensibly, have defective metadata. In short, the detection appears to have failed with the error code 0x8007000E

                     

                    2014-09-07 20:31:16:133 744 6a0 Agent   * WARNING: Exit code = 0x8007000E

                     

                    This is an OUT_OF_MEMORY error, suggesting that it's a client-side error. It could be a function of a corrupted datastore, or it could be a full volume precluding expansion of the paging file.

                      • Re: Re: WSUS on Server 2008
                        nhilez

                        Unfortunately 015POSTERM6 is checking in -- and receiving updates, at least according to the Windows Updates applied as shown in Control Panel -- correctly.  In this case 015POSTERM3 is the one that won't report in.  I've deleted the SusClientID keys from both workstations and forced a /resetauthorization and /detectnow.  TERM3 still refuses to check in and report.

                          • Re: Re: WSUS on Server 2008
                            Lawrence Garvin

                            Okay.. good that '6' is checking in and receiving updates, but there's still an issue on that terminal that probably needs to be investigated.

                             

                            As for '3', if you can get me a more complete logfile than initially provided, I can possibly make a more accurate analysis.

                            Also worthy of note, '3' is logging the same 0x8007000E OUT_OF_MEMORY errors.

                              • Re: Re: Re: WSUS on Server 2008
                                nhilez

                                Attached is the previous WindowsUpdate log for TERM3.

                                I've noticed the 8007000E errors on all of my POS terminals (70 stores * average of 10 terminals per store) but since most of them are checking in I haven't bothered to run down the cause of the error yet.  The problem with terminals not reporting to the WSUS server has been going on longer than I've been employed here and this problem was just recently dumped into my lap, so my first priority has been to get them to check in.