3rd Party Software not installing from Replica Server

  • Mike

    Mike - 2013-02-21

    Hi guys,

    I have recently changed our set up from having two stand along WSUS servers each servicing their own office, to having one main upstream server and changing the other to a replica (mainly so we only had to go through one monthly procedure when deploying MS updates and for future expansion).

    I have managed to get this working fine for all users with Microsoft updates and all the machines have been fully updating over the last few days. I have also installed LUP on the same server as the main upstream wsus (along with SCUP) and use this to deploy Adobe and Java updates which is working fine for all computers linking directly to the main upstream server. However I am having problems with these updates installing in the office with the replica server. All users connected to the replica server are updating fine with Microsoft updates and can in fact see and download the Adobe and Java updates but every single one fails when trying to install.

    I am new to WSUS and have been learning about it over the last few weeks and set it up to this method using guides and forums to help resolve the issues as I came across them but cannot find a solution for this one.

    I suspect it could be to do with the either the certificates (although I have tried creating and deploying new certificates twice following guides and not had any joy and still get the same issue) or possibly to do with SSL between the two servers as I currently havent set up SSL between them but not sure if this will be required or if this is why I am having the problem?

    If anyone can help would be much appreciated!



  • Bryan Dam

    Bryan Dam - 2013-02-22

    Just so I'm clear, the clients of the replica server detect the unofficial packages but they simply fail to install them?

    The first thing to look at will be one of the replica client's windowsupdate.log to try and see why it failed. You might also look to see if the WsusContent folder of the replica has the package data.

  • Mike

    Mike - 2013-02-22

    Hi Bryan, yes you are correct the clients of the replica server will find the updates, download them and will then fail as soon as they try to install. The Microsoft updates all install fine and Java and Adobe both install fine on the clients that connect directly to the upstream server.

    I have attached the windowsupdate.log from one of the client machines, and it does seem to be a problem downloading the update despite it seeming to download on the client machine and seemingly attempting to start the install process before the error message comes up.

    I cannot find the WsusContent folder on the replica server, it does have the same drive connected to it that the upstream server has so may be using the same folder location? I havent specified otherwise and cannot find it through any of the install paths.

    Any further assistance would be great but you have given me a few avenues to explore and will update this forum if I make any further progress.



  • Bryan Dam

    Bryan Dam - 2013-02-22

    Digital Signatures on file ... are not trusted: Error 0x800b0109

    That error is CERT_E_UNTRUSTEDROOT which indicates a problem with the certificates. The client does not trust the certificate the update was signed with. Review the troubleshooting wiki page for suggestions.

  • Mike

    Mike - 2013-03-01

    Thanks for the help Bryan, I seemed to take one step forward and two back...

    I have sorted the certificate errors, completely removed all the certificates, issued new certificates (one from the main server and one from the replica server) and issues these to both servers and all clients via group policy (all updated fine). However I am now having a different issue, after doing this I am now not getting notification of any adobe/java updates on the clients connecting to the replica server, so there is no certificate error anymore but instead its not detecting the updates at all.

    Currently both clients connected to the main server and the replica can get and install windows updates sucesfully, and clients connected to the main server are still getting adobe/java updates and they are installing fine. I have tried numerous things to try and get this to work but still no sucess. I decided to install LUP and SCUP on the replica server and it all connected fine. I released the updates from there but it wouldnt allow me to approve as it was a replica server so I decided to stop it being a replica server (temporarily to test), approved one of the adobe updates and tested on a client machine and it detected the adobe update after a reboot and installed first time sucessfully.

    After doing this test the only difference I made was to move it back to being a replica server and tried releasing a new update from the main server LUP again and still nothing at all. Basically there seems to be a problem with the updates coming from the main server (despite seemingly being approved) as they are not being detected by the clinets on the replica.

    Any advise as to what I can do to fix this? At the moment I am close to scraping the replica server idea just to get it working for now but its creating double the work going through all the updates everytime they are released and at my company there is loads of procedures and paperwork when going through the standard microsoft updates so being able to avoid doing this twice everytime there is updates is very much favourable!

    Thanks for your assistance so far!


  • Bryan Dam

    Bryan Dam - 2013-03-02

    issued new certificates (one from the main server and one from the replica server)

    Are you saying that you issued two certificates? Only one certificate can be used throughout the entire WSUS environment. It doesn't matter where the certificate comes from as long as it's key is larger than 1024 bits and is distributed to every server and client.

  • Mike

    Mike - 2013-03-08

    Hi Bryan,

    I have now set up a second replica server to assist in trouble shooting and both have the exact same problem. I initially only had one certificate but it wouldnt work, simply would not find published updates for clients connected to the replica server but clients connected to the main upstream server were fine. When using LUP (on the main upstream server) I got the following error when trying to connect to the replica server:

    "There is no certificate on the ReplicaServerName. Until you create or import a certificate you will not be able to publish updates. Would you like to do this now?"

    If I tried to click on the replica server name under the localhost I got the following error:

    "Web Exception: Failed to connect to server. The underlying connection was closed: An unexpected error occured on a send."

    I read in another post on this forum that it still worked for them by ignoring this, but if I click "No" to the first message about creating a certificate, although it will still allow me to browse the server and see updates that have been approved etc, it still will not work. If I click "Yes" it gives me the option to Import Cert (ideal) but this doesnt work as comes up with:

    "You cannot import a certificate unless you are connected securely to the WSUS server using SSL"

    As I dont want to set up SSL (as it seems messy and over complex) just to get this to work the only other option is to create a new certificate. If I do this then it does create a certificate fine and allows me to export it and then LUP seems happy. I took this new cert and exported it and put it out to all servers and all clients but still it didnt work.

    I am assuming this is where my problem lies, is there anything you can suggest to try or am I going to have to go down the SSL route?

    In answer to your other question, I allowed SCUP to create my WSUS certificate initially that I rolled out and can confirm this was 2048 bits. The one LUP creates (which was the second one I tried to run alongside the other one) is only 512 bits which also may be the problem but again I dont have any control over this certificate unless I have the servers connected via SSL it seems.

    Thanks for your continued help.

  • Bryan Dam

    Bryan Dam - 2013-03-08

    Regardless of any warnings you get you may only use a single certificate in your environment. Use more than one and you are guaranteed to have failures like you describe.

    You only need to connect with SSL if you want to import the certificate but you don't need to in this case. Simply create/import a single certificate with LUP on the master server and distribute it according to the documentation. By deleting the self-signed cert from the WSUS store you can get LUP to prompt you again to create or import a cert.

    If you use a different port on the downstream servers you cannot connect to them using the hierarchy that LUP creates. It's one of the many things I want to figure out someday. If you're forced to connect directly to the downstream server you must ignore the certificate warning. It is a bug; in the current code base that warning isn't displayed for downstream servers.

    SCUP and LUP utilize the exact same API to generate the self-signed certificate. If you got different length certs then your servers are running different versions of WSUS which will also cause them to not sync correctly. You will need to make sure that you have applied the recent WSUS patches to all servers in your environment.

  • Mike

    Mike - 2013-03-13

    Got it working finally, just before patch Tuesday! Thank you for your help Bryan, couldnt have done it without you!

    Just FYI to anyone having the same issue, my problem was I was using the certificate SCUP was generating which was not working with LUP updates when going through the replica server. Once I changed this, removed all WSUS certifiactes from all servers, got LUP to generate a new certificate for the local host (which is the main upstream server), it then generated a 2048 certificate (when trying to generate one for the replica server using LUP it was only generating one that was 512 bits which was part of my problem). Roled this certificate out to all clients and both upstream and replica servers and then it all started to work.

    Microsoft updates still worked, it was just the LUP updates that were not working until I changed to the LUP certificate that was generated on the local host of the main upstream server. Just a note to anyone else going through this, make sure you expore the certificate in both .pfx and .cert as SCUP will require the .pfx version, and the servers and clients will require the .cert



  • Mike

    Mike - 2013-03-13

    Also just to note, as per Bryans post above, I am still getting the certificate error message from LUP when trying to select the replica server, but this can just be ignored and still works fine as long as the certificates are installed in the correct places on the replica server.


  • Bryan Dam

    Bryan Dam - 2013-03-13

    Excellent, glad you got that sorted out Mike.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks