Skip to main content

Problem WSUS update shows not approved in downstream but it's approved at upstream already

 Problem WSUS update shows not approved in downstream but it's approved at upstream already


Four WSUS servers, one is acting as WSUS upstream server (WSUS1) and othre three are acting as WSUS downstream servers (WSUS2, WSUS3 and WSUS4) on sites. For some reason if I approve an update at WSUS1 the approval does not replicate to the downstream servers. This is causing the situation that on WSUS downstream servers there are multiple updates showing their approval status as "Not approved" even though these same updates are approved on the upstream server. Automatic daily synchronizations show as "Succeeded" result on every server.

Could you please advice on how start troubleshooting this issue?


Solution
1. Ensue that your downstream server is on a replica mode with port 8530 not 80.



2. let's perform the following tests to further narrow down the issue:

On Upstream server, connect to problematic downstream server via Connect to another server as below to check the result:




3. Install WSUS console on a client and connect to the problematic downstream WSUS server from the client WSUS console to check the result.

4. If it shown the update as approved, then it's an issue with your downstream server console. then do the following..

5.I understand that the issue will not occur when connecting from other console. Based on current situation, please following the instruction on the problematic WSUS server:
right click to server name in the console > choose "remove from console"


Reconnect to the WSUS: right click and connect to server and type "LocalHost" with port 8530, click connect.




6. ensure The client side targeting should be enabled on the WSUS server side. By default, it is disabled.
We could follow below steps to verify.
7. On the WSUS, create the computer group. For example, servers.
8.In the WSUS Administration console, click Options, and then click Computers. In the Computers dialog box, select Use Group Policy or registry settings on client computers. Click OK to save your settings.

9. On the client, deploy the GPO or manually create the registry keys to set the client's computer group as servers. Trigger the scan on the client. Wait for 10 minutes, check if the WSUS has automatically put the clients to the servers group.

The documents you may refer to http://technet.microsoft.com/en-us/library/dd939829(v=ws.10).aspx and http://technet.microsoft.com/en-us/library/dd939933(v=ws.10).aspx

Enable client-side targetingEnables users of client computers to add themselves to precreated computer groups on a WSUS server. This option is valid only when Automatic Updates is redirected to a WSUS server. If the Specify intranet Microsoft update service location policy is not enabled, this policy has no effect.
The available setting options offer the following results:
Option
Result
EnabledThe computer identifies itself as a member of a particular computer group when it sends information to the WSUS server. The WSUS server uses this information to determine which updates should be deployed to this computer. You can assign a client computer to more than one computer group by separating the computer group names with a semicolon and a space.
DisabledNo computer group information is sent to the WSUS server.
Not ConfiguredNo computer group information is sent to the WSUS server. A local administrator can change this setting by using local policy.




Enable client-side targetingEnables users of client computers to add themselves to precreated computer groups on a WSUS server. This option is valid only when Automatic Updates is redirected to a WSUS server. If the Specify intranet Microsoft update service location policy is not enabled, this policy has no effect.
The available setting options offer the following results:
Option
Result
EnabledThe computer identifies itself as a member of a particular computer group when it sends information to the WSUS server. The WSUS server uses this information to determine which updates should be deployed to this computer. You can assign a client computer to more than one computer group by separating the computer group names with a semicolon and a space.
DisabledNo computer group information is sent to the WSUS server.
Not ConfiguredNo computer group information is sent to the WSUS server. A local administrator can change this setting by using local policy.
Enable client-side targetingEnables users of client computers to add themselves to precreated computer groups on a WSUS server. This option is valid only when Automatic Updates is redirected to a WSUS server. If the Specify intranet Microsoft update service location policy is not enabled, this policy has no effect.
The available setting options offer the following results:
Option
Result
EnabledThe computer identifies itself as a member of a particular computer group when it sends information to the WSUS server. The WSUS server uses this information to determine which updates should be deployed to this computer. You can assign a client computer to more than one computer group by separating the computer group names with a semicolon and a space.
DisabledNo computer group information is sent to the WSUS server.
Not ConfiguredNo computer group information is sent to the WSUS server. A local administrator can change this setting by using local policy.


10. If that doesn't help so please uninstall the downstream server and check all options to uninstall, DB, Logs and Contents.
11. reinstall WSUS 3.0 with hotfixes needed like KB2734608 & KB2720211 and then ensure all the above settings are exist.

Comments

Popular posts from this blog

Integration with vCloud Director failing after NSXT upgrade to 4.1.2.0 certificate expired

  Issue Clarification: after upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Issue Verification: after Upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Root Cause Identification: >>we confirmed the issue to be related to the below KB NSX alarms indicating certificates have expired or are expiring (94898)   Root Cause Justification:   There are two main factors that can contribute to this behaviour: NSX Managers have many certificates for internal services. In version NSX 3.2.1, Cluster Boot Manager (CBM) service certificates were incorrectly given a validity period of 825 days instead of 100 years. This was corrected to 100 years in NSX 3.2.3. However any environment originally installed on NSX 3.2.1 will have the internal CBM Corfu certs expire after 825 regardless of upgrade to the fixed version or not. On NSX-T 3.2.x interna...

Calculate how much data can be transferred in 24 hours based on link speed in data center

  In case you are planning for migration via DIA or IPVPN link and as example you have 200Mb stable speed so you could calculate using the below formula. (( 200Mb /8)x60x60x24) /1024/1024 = 2TB /per day In case you have different speed you could replace the 200Mb by any rate to calculate as example below. (( 5 00Mb /8)x60x60x24) /1024/1024 =  5.15TB  /per day So approximate each 100Mb would allow around 1TB per day.

Device expanded/shrank messages are reported in the VMkernel log for VMFS-5

    Symptoms A VMFS-5 datastore is no longer visible in vSphere 5 datastores view. A VMFS-5 datastore is no longer mounted in the vSphere 5 datastores view. In the  /var/log/vmkernel.log  file, you see an entry similar to: .. cpu1:44722)WARNING: LVM: 2884: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device shrank (actual size 18424453 blocks, stored size 18424507 blocks) A VMFS-5 datastore is mounted in the vSphere 5 datastores view, but in the  /var/log/vmkernel.log  file you see an entry similar to: .. cpu0:44828)LVM: 2891: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device expanded (actual size 18424506 blocks, stored size 18422953 blocks)   Purpose This article provides steps to correct the VMFS-5 partition table entry using  partedUtil . For more information see  Using the partedUtil command line utility on ESX and ESXi (1036609) .   Cause The device size discrepancy is caused by an incorrect ending sector for the VMFS-5 partition on the ...