When you configure single or multiple Group Update Providers in policies, then Symantec Endpoint Protection Manager constructs a global list of all the providers that have checked in. By default, this file is
C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\outbox\agent\gup\globallist.xml on 64-bit operating systems, or
C:\Program Files\Symantec\Symantec Endpoint Protection Manager\data\outbox\agent\gup\globallist.xml on 32-bit operating systems. Symantec Endpoint Protection Manager provides this global list to any client that asks for it so that the client can determine which Group Update Provider it should use. Because of this process, clients that have policies with only multiple or explicit Group Update Providers configured can also use single Group Update Providers, if the single provider meets the explicit mapping criterion. This phenomenon can occur because single providers are a part of the global list of providers that the clients get from their Symantec Endpoint Protection Manager.
So, all of the Group Update Providers that are configured in any of the policies on a Symantec Endpoint Protection Manager are potentially available for clients' use. If you apply a policy that contains only an explicit Group Update Provider list to the clients in a group, all of the clients in the group attempt to use the Group Update Providers that are in the Symantec Endpoint Protection Manager global Group Update Provider list that meet the explicit mapping criteria.
A Symantec Endpoint Protection client may have multiple IP addresses. Symantec Endpoint Protection considers all IP addresses when it matches to a Group Update Provider. So, the IP address that the policy matches is not always bound to the interface that the client uses to communicate with the Symantec Endpoint Protection Manager and the Group Update Provider.
If all types of Group Update Providers are configured in the policies on a Symantec Endpoint Protection Manager, then clients try to connect to Group Update Providers in the global list in the following order:
Providers on the Multiple Group Update Providers list, in order
Providers on the Explicit Group Update Providers list, in order
The Provider that is configured as a Single Group Update Provider
You can configure the following types of explicit mapping criteria:
IP address: Clients in subnet A should use the Group Update Provider that has the IP address x.x.x.x.
Host name: Clients in subnet A should use the Group Update Provider that has the host name xxxx.
Subnet network address: Clients in subnet A should use any Group Update Provider that resides on subnet B.
Multiple mapping criteria can be used in an explicit Group Update Provider list in a single policy. Symantec recommends that you be very careful how you configure multiple mapping criteria to avoid unintended consequences. For example, you can strand your clients without a means of obtaining updates if you misconfigure an explicit mapping.
Consider a scenario with the following multiple explicit mapping criteria configured in a single policy:
If a client is in subnet 10.1.2.0, use the Group Update Provider that has IP address 10.2.2.24
If a client is in subnet 10.1.2.0, use the Group Update Provider that has IP address 10.2.2.25
If a client is in subnet 10.1.2.0, use the Group Update Provider that has host name SomeMachine
If a client is in subnet 10.1.2.0, use any Group Update Provider on subnet 10.5.12.0
If a client is in subnet 10.6.1.0, use any Group Update Provider on subnet 10.10.10.0
With this explicit Group Update Provider policy, if a client is in subnet 10.1.2.0, the first four rules apply; the fifth rule does not. If the client is in a subnet for which no mapping is specified, such as 10.15.1.0, then none of the rules apply to that client. That client's policy says to use an explicit Group Update Provider list, but there is no mapping that the client can use based on these rules. If you also disabled that client's ability to download updates from Symantec Endpoint Protection Manager and the Symantec LiveUpdate server, then that client has no usable update method.