# SUP Selection

*Applies to: Patch My PC Publisher*

## Overview

The Publisher should be installed on the top-level Software Update Point (SUP) in your ConfigMgr environment. The top-level SUP is the WSUS instance that typically, but not exclusively, synchronizes directly with the Microsoft Update catalog and is responsible for authoring update metadata before it is replicated downstream.

Publishing updates at the top-level SUP ensures that third-party update metadata flows correctly to all downstream SUPs/WSUS servers. This facilitates client devices, regardless of which SUP/WSUS instance they scan against, to successfully scan for, install, and report compliance on third-party updates.

{% hint style="info" %}
**Note**

In more complex or highly customized environments, it is possible to install the Publisher on a non–top-level SUP. However, this requires very careful WSUS and SUP configuration to ensure update metadata is correctly authored and replicated downstream as expected. These scenarios are uncommon and should only be implemented with a clear understanding of ConfigMgr/WSUS synchronization behavior, as misconfiguration can prevent clients from detecting or reporting on third-party updates.
{% endhint %}

{% hint style="warning" %}
**Important**

Installing the Publisher on a downstream SUP will prevent third-party update metadata from flowing correctly, which can result in clients connected to a upstream SUP from being unable to scan for or report compliance on published third-party updates.
{% endhint %}

## How to identify the top-level SUP

* The top-level SUP is typically, but not exclusively, the SUP that synchronizes directly with Microsoft Update.
* In most environments, this is the first SUP installed when more than a single site system with the SUP role is configured..
* In a CAS hierarchy, the Central Administration Site (CAS) SUP is typically the top-level SUP.

Consider the following scenarios to help you select the correct site-system to install the Publisher.

### Scenario 1 - Single SUP, Microsoft Update is the Synchronization Source

In the example below, there is a single site system that holds the SUP role. cm.lab.local is considered the top-level SUP because its synchronization source is Microsoft Update.

<figure><img src="https://3773699522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MX7dvS0r_4fc0AikgJS%2Fuploads%2FSIvgo4SsSlQknLCfWoSf%2Fimage.png?alt=media&#x26;token=07dc9a65-5926-453d-a13f-7a0c594917f7" alt="Single SUP top-level SUP" width="563"><figcaption></figcaption></figure>

### Scenario 2 - Multiple SUP's, Microsoft Update is the Synchronization Source

In the example below, there are multiple site systems that holds the SUP role.  bb-cm1 is considered the top-level SUP because its synchronization source is Microsoft Update.

<figure><img src="https://3773699522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MX7dvS0r_4fc0AikgJS%2Fuploads%2FsZ4UH4wwGv2lYJjMJDk6%2Fimage.png?alt=media&#x26;token=dff99346-8123-471c-a607-e54be9f8a043" alt="Multiple SUPs top-level SUP" width="563"><figcaption></figcaption></figure>

### Scenario 3 - Multiple SUP's, Microsoft Update is *not* the Synchronization Source

In the example below, the upstream synchronization source is not Microsoft Update, but sus.lab2.local. This is common in environments where the WSUS server that synchronizes with the Microsoft Update catalog is located in a DMZ. Even in this configuration, sus01.lab2.local is still considered the top-level SUP, as it is the authoritative source for update metadata within ConfigMgr.

<figure><img src="https://3773699522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MX7dvS0r_4fc0AikgJS%2Fuploads%2Fd4FiIQioGce52gOUUpXB%2Fimage.png?alt=media&#x26;token=49dcc444-7673-4539-8b8e-fbd7724f4a79" alt="Multiple SUPs top-level SUP, non-Microsoft source" width="563"><figcaption></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.patchmypc.com/patch-my-pc-publisher/publisher-requirements/configmgr-requirements/site-system-role/sup-selection.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
