locked
Offline WSUS not downloading updates to clients RRS feed

  • Question

  • Hi All, I am having problems with patches not downloading from my offline WSUS server. On each update in the WSUS console I get the message 'Update downloading' or something along that effect and no updates are getting to my client machines. The method I used for installation is as follows:

    I installed a offline WSUS server on a Windows 2003 machine and connected XP clients to it. I imported some updates from a export WSUS server to the WSUScontent directory by copying the CONTENTs of the WSUScontent directory of the export machine into the CONTENTS of the WSUScotent diretory and imported both the relivant cab and log file by going to c:\program files\update services\tools and running the command wsusutil import abc.cab abc.log. I then checked that all my client PC's were checked into the  WSUS snapin and then approved all required updates.

    All not getting the shield on the client machine and all I am getting is 'Downloading Update' on all updates

    PLEASE HELP!

    Thursday, July 26, 2012 6:01 PM

Answers

  • Answered:

    After months of mucking about I finally found the solution to my problem!!!

    The problems was with the inital settings of the WSUS import server they didn't match the WSUS export server. I couldn't check these settings as I do not have permission to see or even be in the same room of the server (security is a nightmare here!). I had several settings slightly different to the export server, but I think the main one that was causing the problem was the language settings. I was being provided with updates only in English and my import WSUS server was trying to download in every language possible so even though I had the updates I needed on the import server the import server was still saying that the update had not been downloaded.

    I had a second problem, after matching the same settings as my export server as on my import server I found that the updates still didn't say downloaded. This was because I had already ran the wsusutil import command on the server and even though I had setup the settings correctly the updates still said they were downloading. I sorted this problem by removing wsus, reinstalling wsus,  settings up the settings correctly (first) and then  running the wsusutil import command. So if you have already imported the database before setting the correct settings you need to do what I did!.

    • Marked as answer by Barry Ian Wood Wednesday, December 12, 2012 1:05 PM
    • Edited by Barry Ian Wood Wednesday, December 12, 2012 1:09 PM I can't spell
    Wednesday, December 12, 2012 1:05 PM

All replies

  • For the updates you approved on the disconnected machine ... were those updates already approved and fully downloaded to the connected machine before you did the file transfer?

    • How many folders/files exist on the connected server?How much disk space is used?
    • How many folders/files exist on the disconnected server? How much disk space is used?

    There are really only three known scenarios that will cause this:

    • The WSUSContent folder is transferred rather than the subfolders.
    • The import is performed before the file transfer.
    • The files never existed on the connected server.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Thursday, July 26, 2012 6:46 PM
  • Hi & thanks for the reply,

    Can I just clarify, I have 2 WSUS servers, an offline master and a slave WSUS server to update machines in a remote location.

    I have imported updates on the master WSUS server by first copying the directories inside the WSUSContent directory and then doing an wsusutil import of both the cab file and log file.

    The master WSUS server cannot deploy updates for some reason, but the slave WSUS (that looks at the primary for updates) can and is working correctly.

    The WSUSContent directory is over 32GB
    The WSUSContent directories are estimated to be over 100 directories (although I haven't counted) that are named by hexadecimal numbering (00, 0A, 0B, etc)

    As for the three scenarios that might cause this:
    * I transfered the directories inside the WSUSContent files not the WSUSContent itself
    * The file transfer was completed before the WSUSUTIL command was issued
    * The files must had existed on the connected server as the slave wouldn't have been able to download the updates from the master

    As you can see I have a bit of a puzzle on my hand.

    Tuesday, July 31, 2012 4:29 PM
  • The master WSUS server cannot deploy updates for some reason

    WSUS servers do not "deploy" updates -- clients are configured to retrieve updates from the WSUS server. Have you configured any clients to retrieve updates from the master server?

    The WSUSContent directory is over 32GB

    Approximate numbers are useless. Please open Windows Explorer on both the master server and the connected server that you exported from. Right click on the WSUSContent folder and select Properties from the context menu. Let the Properties Dialog count the number of folders, files, and space consumption on both machines. Do the dialogs have the exact same number of folders, files and space consumption?

    The WSUSContent directories are estimated to be over 100 directories (although I haven't counted) that are named by hexadecimal numbering (00, 0A, 0B, etc)

    =256= to be exact, named '00' to 'FF', although on a new WSUS server all 256 may not have been created yet.

    As for the three scenarios that might cause this:
    * I transfered the directories inside the WSUSContent files not the WSUSContent itself

    Excellent.

    * The file transfer was completed before the WSUSUTIL command was issued

    Not the question I asked, nor not even a requirement of the procedure. The question is whether the downloads to the connected server from Microsoft were completed before you initiated the file transfer.

    * The files must had existed on the connected server as the slave wouldn't have been able to download the updates from the master

    Not a true statement, and predicated on a misunderstanding of how WSUS works. *Updates* (which are exported and imported from the database using the wsusutil command) are completely different from the *Files* (which are downloaded to the WSUS server after you approve them).

    As you can see I have a bit of a puzzle on my hand.

    Yes, you do, and answering the questions presented -- which I present in at least one thread a week in this forum -- in an accurate and complete manner will contribute significantly to identifying your particular problem.

    Of course, properly stating  your problem in semantically correct terms helps a lot to. In your original post you stated "I'm having a problem with patches not downloading from my offline server." Well, patches are not supposed to download from an offline server!

    But, actually, the real problem appears to be that Clients are not getting updates from the offline server. -- which is a completely different issue, and has a completely different set of diagnostic steps.

    So, select one of the machines that is supposed to get updates from your offline master server, and do the following:

    1. Record the system time of that client.
    2. Reboot the client.
    3. Run this command from a command prompt: wuauclt  /resetauthorization /detectnow
    4. Wait 30 minutes.
    5. Open the C:\Windows\WindowsUpdate.log file, find the first entry dated after the time you recorded in Step #1, copy the rest of the lines to the end of the file, and paste those lines into a reply to this message.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Tuesday, July 31, 2012 9:05 PM
  • Hi,

    I followed your instructions and got this:

    Please note that in this log I have had to change the name of the WSUS server to acacac and the client that checked in (where this doc comes from) to clientalpha as this would break our security restrictions.

    2012-08-01 10:15:31:154  880 6e8 AU #############
    2012-08-01 10:15:31:154  880 6e8 AU ## START ##  AU: Search for updates
    2012-08-01 10:15:31:154  880 6e8 AU #########
    2012-08-01 10:15:31:170  880 6e8 AU <<## SUBMITTED ## AU: Search for updates [CallId = {7F7C90B5-494E-407A-A772-2F5504FC47D2}]
    2012-08-01 10:15:31:186  880 dcc Agent *************
    2012-08-01 10:15:31:186  880 dcc Agent ** START **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2012-08-01 10:15:31:218  880 dcc Agent *********
    2012-08-01 10:15:31:218  880 dcc Agent   * Online = Yes; Ignore download priority = No
    2012-08-01 10:15:31:218  880 dcc Agent   * Criteria = "IsHidden=0 and IsInstalled=0 and DeploymentAction='Installation' and IsAssigned=1 or IsHidden=0 and IsPresent=1 and DeploymentAction='Uninstallation' and IsAssigned=1 or IsHidden=0 and IsInstalled=1 and DeploymentAction='Installation' and IsAssigned=1 and RebootRequired=1 or IsHidden=0 and IsInstalled=0 and DeploymentAction='Uninstallation' and IsAssigned=1 and RebootRequired=1"
    2012-08-01 10:15:31:218  880 dcc Agent   * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
    2012-08-01 10:15:31:218  880 dcc Agent   * Search Scope = {Machine}
    2012-08-01 10:15:31:297  880 dcc Misc Validating signature for C:\WINDOWS\SoftwareDistribution\SelfUpdate\Default\wuident.cab:
    2012-08-01 10:15:31:345  880 dcc Misc  Microsoft signed: Yes
    2012-08-01 10:15:33:792  880 dcc Misc Validating signature for C:\WINDOWS\SoftwareDistribution\SelfUpdate\Default\wuident.cab:
    2012-08-01 10:15:33:792  880 dcc Misc  Microsoft signed: Yes
    2012-08-01 10:15:33:998  880 dcc Misc Validating signature for C:\WINDOWS\SoftwareDistribution\SelfUpdate\Default\wsus3setup.cab:
    2012-08-01 10:15:34:014  880 dcc Misc  Microsoft signed: Yes
    2012-08-01 10:15:34:014  880 dcc Setup ***********  Setup: Checking whether self-update is required  ***********
    2012-08-01 10:15:34:014  880 dcc Setup   * Inf file: C:\WINDOWS\SoftwareDistribution\SelfUpdate\Default\wsus3setup.inf
    2012-08-01 10:15:34:173  880 dcc Setup Update NOT required for C:\WINDOWS\system32\cdm.dll: target version = 7.4.7600.226, required version = 7.4.7600.226
    2012-08-01 10:15:34:221  880 dcc Setup Update NOT required for C:\WINDOWS\system32\wuapi.dll: target version = 7.4.7600.226, required version = 7.4.7600.226
    2012-08-01 10:15:34:237  880 dcc Setup Update NOT required for C:\WINDOWS\system32\wuapi.dll.mui: target version = 7.4.7600.226, required version = 7.4.7600.226
    2012-08-01 10:15:34:237  880 dcc Setup Update NOT required for C:\WINDOWS\system32\wuauclt.exe: target version = 7.4.7600.226, required version = 7.4.7600.226
    2012-08-01 10:15:34:237  880 dcc Setup Update NOT required for C:\WINDOWS\system32\wuaucpl.cpl: target version = 7.4.7600.226, required version = 7.4.7600.226
    2012-08-01 10:15:34:411  880 dcc Setup Update NOT required for C:\WINDOWS\system32\wuaucpl.cpl.mui: target version = 7.4.7600.226, required version = 7.4.7600.226
    2012-08-01 10:15:34:411  880 dcc Setup Update NOT required for C:\WINDOWS\system32\wuaueng.dll: target version = 7.4.7600.226, required version = 7.4.7600.226
    2012-08-01 10:15:34:491  880 dcc Setup Update NOT required for C:\WINDOWS\system32\wuaueng.dll.mui: target version = 7.4.7600.226, required version = 7.4.7600.226
    2012-08-01 10:15:34:491  880 dcc Setup Update NOT required for C:\WINDOWS\system32\wucltui.dll: target version = 7.4.7600.226, required version = 7.4.7600.226
    2012-08-01 10:15:34:554  880 dcc Setup Update NOT required for C:\WINDOWS\system32\wucltui.dll.mui: target version = 7.4.7600.226, required version = 7.4.7600.226
    2012-08-01 10:15:34:554  880 dcc Setup Update NOT required for C:\WINDOWS\system32\wups.dll: target version = 7.4.7600.226, required version = 7.4.7600.226
    2012-08-01 10:15:34:554  880 dcc Setup Update NOT required for C:\WINDOWS\system32\wups2.dll: target version = 7.4.7600.226, required version = 7.4.7600.226
    2012-08-01 10:15:34:777  880 dcc Setup Update NOT required for C:\WINDOWS\system32\wuweb.dll: target version = 7.4.7600.226, required version = 7.4.7600.226
    2012-08-01 10:15:34:777  880 dcc Setup   * IsUpdateRequired = No
    2012-08-01 10:15:38:002  880 dcc PT +++++++++++  PT: Synchronizing server updates  +++++++++++
    2012-08-01 10:15:38:002  880 dcc PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://acacac/ClientWebService/client.asmx
    2012-08-01 10:15:38:050  880 dcc PT WARNING: Cached cookie has expired or new PID is available
    2012-08-01 10:15:38:050  880 dcc PT Initializing simple targeting cookie, clientId = b2f0cb90-7f65-49a9-97dd-577fbcc3329a, target group = , DNS name = clientalpha.ccc.com
    2012-08-01 10:15:38:050  880 dcc PT   Server URL = http://acacac/SimpleAuthWebService/SimpleAuth.asmx
    2012-08-01 10:16:24:190  880 dcc PT +++++++++++  PT: Synchronizing extended update info  +++++++++++
    2012-08-01 10:16:24:190  880 dcc PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://acacac/ClientWebService/client.asmx
    2012-08-01 10:16:27:717  880 dcc Agent   * Found 0 updates and 65 categories in search; evaluated appl. rules of 1127 out of 1984 deployed entities
    2012-08-01 10:16:27:717  880 dcc Agent *********
    2012-08-01 10:16:27:717  880 dcc Agent **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2012-08-01 10:16:27:717  880 dcc Agent *************
    2012-08-01 10:16:27:844  880 113c AU >>##  RESUMED  ## AU: Search for updates [CallId = {7F7C90B5-494E-407A-A772-2F5504FC47D2}]
    2012-08-01 10:16:27:844  880 113c AU   # 0 updates detected
    2012-08-01 10:16:27:844  880 113c AU #########
    2012-08-01 10:16:27:844  880 113c AU ##  END  ##  AU: Search for updates [CallId = {7F7C90B5-494E-407A-A772-2F5504FC47D2}]
    2012-08-01 10:16:27:844  880 113c AU #############
    2012-08-01 10:16:27:844  880 113c AU Featured notifications is disabled.
    2012-08-01 10:16:27:844  880 113c AU AU setting next detection timeout to 2012-08-01 15:02:13
    2012-08-01 10:16:32:801  880 dcc Report REPORT EVENT: {6941D010-DF08-4C3E-9E3B-A76EA555C2D5} 2012-08-01 10:16:27:717+0100 1 147 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Software Synchronization Windows Update Client successfully detected 0 updates.
    2012-08-01 10:16:32:801  880 dcc Report REPORT EVENT: {A78EE101-0B95-4EF2-A7BE-531BB1F4831C} 2012-08-01 10:16:27:717+0100 1 156 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Pre-Deployment Check Reporting client status.
    2012-08-01 10:22:26:866  880 dcc Report Uploading 2 events using cached cookie, reporting URL = http://acacac/ReportingWebService/ReportingWebService.asmx
    2012-08-01 10:22:26:882  880 dcc Report Reporter successfully uploaded 2 events.

    Regards

    Barry

    Wednesday, August 1, 2012 6:16 PM
  • 2012-08-01 10:16:27:717  880 dcc Agent   * Found 0 updates and 65 categories in search; evaluated appl. rules of 1127 out of 1984 deployed entities

    This client is working perfectly. There are simply no updates available from the WSUS server for this client to install.

    • Either the client is in the wrong target group, or
    • The updates are approved for the wrong target group, or
    • The update files for the approved updates are not yet downloaded to the WSUS server.

    Since this is a disconnected WSUS Server -- my first guess would be that the import process was performed incorrectly and the disconnected WSUS server doesn't actually see any files as 'downloaded' -- which you pretty much already confirmed in your original post -- which kinda brings us back to the original problem being the correct problem - the disconnected WSUS server is not "downloading" updates -- except that it's not supposed to.

    So that brings us back to the unanswered questions from my July 26th reply:

    For the updates you approved on the disconnected machine ... were those updates already approved and fully downloaded to the connected machine before you did the file transfer?

    • How many folders/files exist on the connected server?How much disk space is used?
    • How many folders/files exist on the disconnected server? How much disk space is used?

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Thursday, August 2, 2012 3:24 PM
  • Hi Again, the details of my WSUS content file are:

    3,995 Files, 256 Folders

    32.0GB (34,402,875,482 bytes)

    32.0GB (34,410,987,520 bytes)

    and strored in D:\WSUS\WSUSContent

    ------------------------------------------------

    Today after a week of trying to get this to work I have pointed all of my client machines (away from my primary offline wsus server) and pointed them to my fallback wsus server to get there updates. This is temporary, but it proves that there is nothing wrong with the clients as each one downloaded around 70 updates and seeing that the fallback WSUS server is sync'd to the primary offline wsus server to get its updates I can only conclude that there is something wrong on the primary. Here is an example of the network I have and what I did to get the updates onto my clients. The network itself is completly seperated from the Internet, is separated into two locations, both having WSUS servers and one Sync'd to the import WSUS server. 

    The Yellow Ticks indicated the updates getting to the clients ok and the 'x' indicated some sort of problem.

    Thursday, August 2, 2012 3:29 PM
  • Hi,

      I am in a very weird situation here, I can't confirm that the updates were downloaded properly as they come from a different network and where provided to me by a different department. I will have to get in contact with the person that supplies the updates.

    My point I want to put across to you is that if the updates where not correctly downloaded on the original export WSUS server, why is it that the downstream WSUS server (the slave) on my disconnected network can get new updates (1076 during sync) from the WSUS import machine where I did the imported the updates? I just don't understand this.

    I am probably going to put a diagram up on this forum to try and better explain my position.

    Regards

    Barry

    Thursday, August 2, 2012 5:39 PM
  • Hi Again,

       here is a much better diagram of how my network looks like and maybe i'll try and explain it a bit better :-).

    1. I get given the wsuscontent directory, the cab file and the log file from a WSUS server on a disconnected network via portable HDD

    2. I copied the contents of the wsuscontent directory from portable HDD into the WSUScontent directory of the disconnected import server. The updates are constantly show as 'Downloading'

    3. I manually synced the downstream server with the upstream server and the downstream server detected approximately 1076 updates available from the upstream import server (the one that I copied the contents of the wsuscontent directory to!). 

    4. Every client on the downstream server found new updates, while the upstream (import server) constantly says its trying to download.

    If the updates that I got where possibly no good, why is it that the downstream server is able to get extra updates from upstream server.

    Please tell me if I have got this all wrong!! I really appropriate your opinion.

    Regards

    Barry

    Thursday, August 2, 2012 6:10 PM
  • Hi Again, the details of my WSUS content file are:

    3,995 Files, 256 Folders

    32.0GB (34,402,875,482 bytes)

    32.0GB (34,410,987,520 bytes)

    The file sizes are off by ~8mb. Do *both* servers report the presence of 3,995 files? If so, then at least one file is bigger on one server than on the other.

    seeing that the fallback WSUS server is sync'd to the primary offline wsus server to get its updates I can only conclude that there is something wrong on the primary.

    It's important to understand that whatever updates have not yet been properly imported to your offline upstream server, will not be available from your replica server for those clients to install, so merely pointing your clients to the replica server -- while getting them the several dozen updates each that the replica server already had available (likely from prior to your last import to the upstream server when the content store became broken) -- isn't going to get them the most current updates.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Thursday, August 2, 2012 7:46 PM
  • My point I want to put across to you is that if the updates where not correctly downloaded on the original export WSUS server, why is it that the downstream WSUS server (the slave) on my disconnected network can get new updates (1076 during sync) from the WSUS import machine where I did the imported the updates? I just don't understand this.

    The fact that the replica server is able to get from the upstream server the stuff that was available before the content store was broken during the most recent import is a key point.

    Assuming  you do monthly imports after Patch Tuesday, and it was the July import that failed -- and assuming previous imports worked perfectly -- then I believe detailed inspection will find that the replica server has all of the updates and content that were previously and successfully imported to the upstream server, but they do not have any of the content for the updates that were NEW in the most recent import. It would be physically and logically impossible for the replica server to get those files, since they 'do not exist' on the upstream server at this point.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Thursday, August 2, 2012 7:49 PM
  • here is a much better diagram of how my network looks like and maybe i'll try and explain it a bit better :-).

    I understand your network perfectly. It is a fairly simple scenario, and the nature of the environment was never in doubt. What our challenge here, really, is helping you to understand the intracies of how disconnected networks work, and how replica servers work.

    1. I get given the wsuscontent directory, the cab file and the log file from a WSUS server on a disconnected network via portable HDD

    2. I copied the contents of the wsuscontent directory from portable HDD into the WSUScontent directory of the disconnected import server. The updates are constantly show as 'Downloading'

    3. I manually synced the downstream server with the upstream server

    Ummm.. there is a very critical step missing here.... where did you perform the wsusutil import ???

    and the downstream server detected approximately 1076 updates available from the upstream import server

    Approximately!!!??? There's no "approximate" in WSUS operations! This is the third time you've tried to use approximations and estimates to troubleshoot this problem. These are critical numbers, and approximations and estimates are worthless!

    Are there actually and exactly =1076= updates physically present on the upstream server?

    4. Every client on the downstream server found new updates

    Did they install any updates that were released in July 2012?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Thursday, August 2, 2012 7:55 PM
  • I will get you this information tomorrow and I wouldn't estimate it!

    Regards

    Barry

    Thursday, August 2, 2012 8:56 PM
  • Hi,

    1. The wsusutil import command was done on the import server of my network. I navagated to the c:\Program Files\Update Services\Tools directory under CMD and typed wsusutil import july2012.cab july2012.log

    2. The Sync I did was manual on the downstream server. The details are as follows:

         31/07/2012 14:17 Manual Succeeded

         New Updates: 413

         Revised Updates: 31

         Expired Updates: 1917

    I did this sync manually after adding the udpates to the import server

    3. Yes on the downstream server it now has updates date stamped at 10/07/2012, which include KB2718523, KB2655992, KB2719985, Security Update for .net Framework 2.0 SP2 on Windows 2003 and XP

    There are more from this date I don't feel like copying them all.

    Regards

    Barry

    Friday, August 3, 2012 9:15 AM
  • 1. The wsusutil import command was done on the import server of my network.

    My apologies -- I didn't mean where, as in what machine, but where in the steps of the procedure. You did not list the performance of the 'wsusutil import'.

    3. Yes on the downstream server it now has updates date stamped at 10/07/2012, which include KB2718523, KB2655992, KB2719985, Security Update for .net Framework 2.0 SP2 on Windows 2003 and XP

    Does the downstream server have FILES for these July 10th updates?

    Also, I'm very confused about the number of updates.... your original number was 1,076 updates, but your sync from 7/13 reports 413 *new* updates <???>, and even more shocking, 1917 *expired* updates.

    Does the connected server also show 2,361 total updates in the catalog?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Friday, August 3, 2012 5:05 PM
  • Hi,

    I don't completely understand the statement 'performance of the wsusutil import'.

    When I did the wsusutil import process it took approximately 2 hours to complete (I can't give you an exact time!) and it wasn't disturbed until the command had finished processing.

    -----------------------------------------------------------------

    Yes the downstream server has files from the July 10th.

    Yes please ignore the 1,076 updates I mentioned before I was guesstimating and I got it very wrong, however I did reply with what I saw on the downstream server which I will repeat:

    The Sync I did was manual on the downstream server. The details are as follows:

         31/07/2012 14:17 Manual Succeeded

         New Updates: 413

         Revised Updates: 31

         Expired Updates: 1917

    This is actual information taken from the downstream server.

    Yesterday I pointed all my clients to the downstream server (in the remote location) and updated them from there. I then did an offline MBSA scan on one of the clients and found it only wanting one update.

    I can't tell you the amount of updates in the catalog until I get back off holiday which will be in two week. Just for your information I will be bringing in a WSUS consultant that I used before to help me design the system on this network. He will hopefully tell me whats going on with it and I will relay it to this forum. I personally (although I might be wrong) think there is something up with the WSUS 3.0 SP2 build when using it as completely offline WSUS server.

    I really need to get this issue nailed down as I have two WSUS servers on this network, but my company plan to have two WSUS servers on all 13 networks that I will managed, which means that I will have 26 offline WSUS servers to manage :-(

    Regards

    Barry

    Friday, August 3, 2012 10:14 PM
  • I don't completely understand the statement 'performance of the wsusutil import'.

    You listed the things you did.

    You did not list running the wsusutil import command.

    I'm merely asking when did you do that?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Thursday, August 9, 2012 8:36 PM
  • Answered:

    After months of mucking about I finally found the solution to my problem!!!

    The problems was with the inital settings of the WSUS import server they didn't match the WSUS export server. I couldn't check these settings as I do not have permission to see or even be in the same room of the server (security is a nightmare here!). I had several settings slightly different to the export server, but I think the main one that was causing the problem was the language settings. I was being provided with updates only in English and my import WSUS server was trying to download in every language possible so even though I had the updates I needed on the import server the import server was still saying that the update had not been downloaded.

    I had a second problem, after matching the same settings as my export server as on my import server I found that the updates still didn't say downloaded. This was because I had already ran the wsusutil import command on the server and even though I had setup the settings correctly the updates still said they were downloading. I sorted this problem by removing wsus, reinstalling wsus,  settings up the settings correctly (first) and then  running the wsusutil import command. So if you have already imported the database before setting the correct settings you need to do what I did!.

    • Marked as answer by Barry Ian Wood Wednesday, December 12, 2012 1:05 PM
    • Edited by Barry Ian Wood Wednesday, December 12, 2012 1:09 PM I can't spell
    Wednesday, December 12, 2012 1:05 PM
  • The problems was with the inital settings of the WSUS import server they didn't match the WSUS export server.

    Ooops. My apologies! That's an assumption I made (and, actually, have made on numerous occasions). Note to self: Double-check that the servers are actually configured identically. I'm mentally updating my "scenarios that can cause this", and explicitly adding "The disconnected server is configured for languages that are not configured on the connected server."

    Actually, you should be able to simply reset the Language settings, clear the BITS download queue, and then rerun the import. With the non-English settings disabled, the import process should then ignore the need for those files. If the opposite scenario had occured though -- the connected server was providing updates you didn't need/want (e.g. non-English, or Drivers), then rebuilding the database would definitely be advised.

    Glad you did get it sorted out, and thank you for posting back with the resolution for your issue!


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Wednesday, December 19, 2012 2:56 PM