The most common causes are:

1. WSUS is not set to accept client-side targeting If Group Policy is setting TargetGroup, WSUS must be configured to use client-side assignment:
   • In WSUS Administration Console → Options → Computers
   • Select Use Group Policy or registry settings on computers
   If WSUS is still set to use console-based assignment, clients can contact the server but won’t be placed into the GPO-defined group.
2. The target computer group does not exist in WSUS The group name configured in policy must match a WSUS computer group.
   • In WSUS Administration Console → Computers
   • Right-click All computers → Add Computer Group
   • Create the group with the exact name used in TargetGroup
3. The client has not completed its first WSUS detection cycle yet Clients do not appear in the WSUS console until they connect to WSUS for the first time. To accelerate this:
   • Run gpupdate /force from an elevated Command Prompt if the settings come from Active Directory GPO
   • Restart the client
   • On Windows 10/11, open Settings → Windows Update and manually check for updates
4. The client registered before WSUS was switched to Group Policy targeting If the client first appeared while WSUS was configured for console-based assignment, it can remain in Unassigned Computers even though TargetGroup is now correct. In that case:
   • In WSUS Administration Console → Unassigned Computers
   • Manually move the computer to the correct group once
   • Then force another client scan and allow time for synchronization
5. Port or protocol mismatch in WSUS policy The intranet update service location must include the correct server name and port. Supported defaults are:
   • HTTP: 8530
   • HTTPS metadata: 8531
   • Alternatively 80 or 443
   If TLS/HTTPS is used, clients and downstream servers must use the WSUS server FQDN, and clients must trust the WSUS TLS certificate in the local computer certificate store.
6. Firewall access to WSUS is incomplete Clients need outbound access to the WSUS server ports. By default, WSUS uses:
   • 8530
   • 8531
7. Another Group Policy is overriding the WSUS server location If a higher-precedence domain GPO sets a different WSUS server name or port, the client scan can fail even though local values appear correct. The configured server name and port in Group Policy must exactly match the WSUS service location being used.

A practical validation path is:

1. In WSUS, confirm Options → Computers is set to Use Group Policy or registry settings on computers.
2. Confirm the WSUS computer group already exists and exactly matches TargetGroup.
3. Confirm the GPO Specify intranet Microsoft update service location uses the correct WSUS URL and port.
4. If using HTTPS, confirm the policy uses the server FQDN and the client trusts the certificate in the local computer store.
5. Run gpupdate /force, restart the client, and manually check for updates.
6. If the client still shows under Unassigned Computers, manually move it once or delete and re-register it only if necessary. Deleting the WSUS computer record removes its update history.

References:

• Context # Step 2: Configure WSUS
• Context # Deploy Windows client updates using Windows Server Update Services (WSUS)
• Context # Troubleshoot software update scan failures in Configuration Manager
• Context Computers Are Not Appearing In the Correct Computer Groups - Microsoft Q&A Hi!